Comments on: On Drunken Haxies http://nslog.com/2005/12/03/on_drunken_haxies The Weblog of Erik J. Barzeski Tue, 07 Feb 2012 16:40:07 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: emd http://nslog.com/2005/12/03/on_drunken_haxies#comment-17663 emd Tue, 06 Dec 2005 00:20:50 +0000 http://nslog.com/2005/12/03/on_drunken_haxies/#comment-17663 Although without APE, there is still mach_inject (http://rentzsch.com/mach_inject/) Although without APE, there is still mach_inject (http://rentzsch.com/mach_inject/)

]]> By: Erik J. Barzeski http://nslog.com/2005/12/03/on_drunken_haxies#comment-17662 Erik J. Barzeski Mon, 05 Dec 2005 22:49:48 +0000 http://nslog.com/2005/12/03/on_drunken_haxies/#comment-17662 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. 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.

]]> By: emd http://nslog.com/2005/12/03/on_drunken_haxies#comment-17661 emd Mon, 05 Dec 2005 22:11:10 +0000 http://nslog.com/2005/12/03/on_drunken_haxies/#comment-17661 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. 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.

]]> By: Erik J. Barzeski http://nslog.com/2005/12/03/on_drunken_haxies#comment-17660 Erik J. Barzeski Mon, 05 Dec 2005 21:12:41 +0000 http://nslog.com/2005/12/03/on_drunken_haxies/#comment-17660 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. 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.

]]> By: emd http://nslog.com/2005/12/03/on_drunken_haxies#comment-17659 emd Mon, 05 Dec 2005 20:55:44 +0000 http://nslog.com/2005/12/03/on_drunken_haxies/#comment-17659 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: <blockquote>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.</blockquote> 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: <blockquote>Code that has no bugs can fail due to a haxie.</blockquote> 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. 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.

]]> By: Erik J. Barzeski http://nslog.com/2005/12/03/on_drunken_haxies#comment-17658 Erik J. Barzeski Mon, 05 Dec 2005 20:38:45 +0000 http://nslog.com/2005/12/03/on_drunken_haxies/#comment-17658 Haxies don't <strong>expose</strong> 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. 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.

]]> By: emd http://nslog.com/2005/12/03/on_drunken_haxies#comment-17657 emd Mon, 05 Dec 2005 20:20:44 +0000 http://nslog.com/2005/12/03/on_drunken_haxies/#comment-17657 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. 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.

]]>