OmniPlan 1.5 RC 2 is now available and is a free update for existing OmniPlan 1.x owners. Thanks to all you brave testers out there, we're now closer than ever to releasing the final. If you find any issues in RC 2 please please please let us know as soon as you can. Also, if you're a Leopard user we strongly recommend that you use OmniPlan 1.5 instead because there are some known issues between OmniPlan 1.1.2 and Leopard.

Highlights of this version include a permanent solution to prevent the overlaid progress meter that comes up for some slow operations from forcing Spaces to switch to the space containing the document window. If you previously disabled the progress meter entirely as we suggested in the release notes for OmniPlan-1.5 beta 3, they will remain disabled until specifically reenabled. In a Terminal window, type “defaults delete com.omnigroup.OmniPlan LongOperationIndicatorDisabled” We also patched up the Automatic Software Update interface in the Italian localization.

To learn more about all the changes in OmniPlan 1.5, please see the release notes for more details!

Please keep in mind that this release is still under development. Your feedback will help us improve the software, and we apologize if it breaks your computer, corrupts your files, and ruins your weekend. A more stable release is also available. As always, please let us know if you have any questions or comments. You can contact us directly via our support page or by using the Send Feedback feature in your copy of OmniPlan.

For current 1.5 beta users, you can use our nifty new software updater to download and install the new beta. For everyone else, go here to download the RC!

OmniOutliner 3.6.4 beta 1 is now available and is as usual free for all 3.x owners. Sorry, no QuickLook support yet but that is coming later. This fixes the 10.5 crash we missed in the last release and the Spaces bug that switched you to OmniOutliner on an autosave. And, exciting news for some, the “a” prefix bug is hopefully fixed with this release as well!

Download page
Release Notes

If you encounter any problems with this release, please let us know!

OmniPlan 1.5 RC 1 is now available and is a free update for existing OmniPlan 1.x owners. We're getting closer to final and if you're a Leopard user, we strongly recommend that you use OmniPlan 1.5 instead because there are some known issues between OmniPlan 1.1.2 and Leopard.

Some highlights of this version include fixes for a crash when closing a document that contained assignments, a crash when dragging new dependency lines in the gantt chart (for real this time!), and a fix for the Software Update preferences that would throw up a “valueForUndefinedKey” error in beta 5. If you are experiencing any issues in RC 1, please let us know as soon as possible.

This version also includes some other bug fixes and enhancements (far too many to list here). To learn more about the changes in 1.5 RC 1, please see the release notes for more details!

Please keep in mind that this release is still under development. Your feedback will help us improve the software, and we apologize if it breaks your computer, corrupts your files, and ruins your weekend. A more stable release is also available. As always, please let us know if you have any questions or comments. You can contact us directly via our support page or by using the Send Feedback feature in your copy of OmniPlan.

For current 1.5 beta users, you can use our nifty new software updater to download and install the new beta. For everyone else, go here to download the RC!

Bill Bumgarner has posted a few great articles on Objective-C method tracing using dtrace:

• Objective-C: Printing Class Name from Dtrace
• Objective-C: Using Instruments to trace messages-to-nil

I have a internal tool at Omni that traces message sends by creating new method IMPs to wrap the existing ones in a trampoline, but it requires some nasty assembly stubs and has only ever worked on Sparc, ppc and x86. It is very fast, but hard to maintain and a little fragile (and doesn't handle the nil case). A 90% solution can be obtained by extending Bill and other's work.

Ken sent out a partial tracing solution this morning and finally got me off my keister. Here is a D script that catches ObjC message sends and dumps a OPML fragment (which can then be wrapped in the XML goo via an external shell script or whatever) and then viewed in OmniOutliner.

Download: objc-trace-opml.d.gz

This isn't a perfect solution by any means. Some of the issues:

• This has to be run in an essentially single-threaded program; any background threads must be totally quiescent or you'll get a mixture of output from multiple threads. It wouldn't be too hard to modify this script to include a thread identifier or maybe just filter out anything from background threads.
• This won't handle exceptions correctly; they'll break the OPML nesting. Our internal tool handles this, but since NSError arrived on the scene, this is less of an issue. Just avoid tracing code with exceptions.
• dtrace is slow when matching all entries in the objc provider. The startup time on this script is something like 40 seconds on my machine. Annoying, but not the worst thing ever, since you are likely to trace once and then spend a fair bit of time examining the results.
• This particular variant of the script will only work on x86 due to the hacky way I check for objc_msgSend_stret.
• dtrace can overflow its buffer and drop events when there are massive numbers of probe hits. Run with a big buffer and trace only the exact set of methods you need. Ideally you'll be running in the debugger, stop right before where you need to trace turn on tracing and then 'next' over one or two lines of code. The '-b' flag to dtrace can also be used to increase the buffer size.

Some of the nice bits:

• No assembly-fu required.
• Call hierarchy is preserved and can be expanded/hoisted and such in OmniOutliner.
• Both the class of the receiver and the class of the method implementation are included. So, you can see that +[MySuperclass initialize] is getting called on MySubcass, for example.
• All method invocations are shown, so you can see nested calls to super instead of just the initial call to objc_msgSend. I've not tested whether cached method IMPs get traced too; normal code should get traced as expected. Swizzling, IMP caching or dynamically registering methods will possibly not work as well.
• The pointer value of the receiver is emitted. By the time you examine the output, it might be dead and gone, but a surprising amount of the time it isn't. For example, things like static NSStrings, NSScriptClassDescriptions, interface widgets and other cache-once data may still be around for submitting to 'po' in the debugger.

I actually posted this to our website last week, but forgot to post this on the blog. Go me!We've had a tremendous response to OmniFocus, and despite bringing on two support ninjas over the last year to help out with it, we're still struggling. Frankly, that sucks. Solution: more hiring!Visit our jobs page for more information.