NSLog();

7 Comments »

7 Responses to "On Drunken Haxies"

1. | Reply emd
   Posted 05 Dec 2005 at 3:20pm #
   

   I think the point that everyone is missing is that occasionally haxies EXPOSE a bug in another product. This bug may only appear when you are running haxies, but that doesn't make it a haxie bug! If this is the case, telling a user to just disable haxies appears to solve the problem, but actually just masks it.

   I would rather both groups work together to find the issue before assigning blame.

2. | Reply Erik J. Barzeski
   Posted 05 Dec 2005 at 3:38pm #
   

   Haxies don't expose jack shit. If a bug does not occur without a haxie present, it's not a bug. Haxies alter the OS and the way in which an application uses resources, the OS, frameworks, network connections, etc. It doesn't "expose" anything, nor does it exacerbate anything. Code that has no bugs can fail due to a haxie.

   You're wrong, and people aren't missing the point.

3. | Reply emd
   Posted 05 Dec 2005 at 3:55pm #
   

   I should apologize about the statement "may only appear when you are running haxies". I meant to say, "may appear more frequently when running haxies".

   I would swear I saw DB state an issue that was exacerbated with a haxie, but where the actual issue was a product issue, not a haxie bug. That is the case I am talking about. Aha, I found it:

   For the most part, ShapeShifter just swaps graphics with no slowdown (sometimes feels faster), however if something is a custom view (like the labels field in the Finders contextual menu) there can be a miniscule hit -- as in imperceptible unless you counting milliseconds while profiling. It just shouldn't have been happening, so it was weird, so I was curious.I contacted the author, which didn't go well at first once he heard APE was involved, but a few samples later and a bug was found in the date formatting code. This bug wasn't a huge deal on its own, but ShapeShifter was exacerbating it to the point where it was extremely noticeable. The author passed on version 1.3.3b5, which fixed the issue, and I'm going to assume that version 1.3.3 which is online now has the fix in for it.

   In this particular case, there was a bug in GyzaMail that was made worse by the presence of a haxie (ShapeShifter). So, the bug was NOT in ShapeShifter, it only appeared that way.

   That is really my only point. And I do agree with this statement of yours:

   Code that has no bugs can fail due to a haxie.

   The corollary to that is: Code that has bugs may fail only when using a haxie, due to the nature of the bug. Fix the bug and the app + haxie may work much better.

4. | Reply Erik J. Barzeski
   Posted 05 Dec 2005 at 4:12pm #
   

   Based upon my own experience, the instances in which an existing bug is "made worse" by a haxie and when there is no bug but only a crash due entirely to the presence of the haxie, the latter outnumbers the former by a magnitude of three or more.

   In your example, you're not talking about a crashing bug, merely a slowdown. A bug, sure, but basically one caused because the code that causes the slowdown is negatively affected by the haxie.

5. | Reply emd
   Posted 05 Dec 2005 at 5:11pm #
   

   As long as you are 100% positive that the crash is a bug in a haxie and not just "made worse" by the presence of a haxie, I completely agree with you.

6. | Reply Erik J. Barzeski
   Posted 05 Dec 2005 at 5:49pm #
   

   Additionally, a bug - even in the application itself - that does not exist without the haxie but which appears with the haxie is not really a bug, either, nor is it worth any of the developer's time.

   And don't get me started on the ability of APE to allow for rampant (and easy) piracy.

7. | Reply emd
   Posted 05 Dec 2005 at 7:20pm #
   

   Although without APE, there is still mach_inject (http://rentzsch.com/mach_inject/)