Archive for the ‘MacGDBp’ category

MacGDBp 1.4 Beta 2

I’m happy to announce MacGDBp 1.4 Beta 2. It’s been nearly a month since the first beta was released and more than 200 people have tested Beta 1. I haven’t received any critical bug reports, which means that the internals are stable enough to ship. Beta 2 is the Release Candidate; barring any significant issues, this will be promoted to Stable in a month or less.

This release has a couple of bug fixes and adds two small enhancements:

• #210, #195 Add a “Stop” button to detach the debugger from the current session
• #209 Drag a file onto the source view in the Breakpoints window to load the contents

You can download MacGDBp 1.4 Beta 2 from this page. Please file any new issues in the bug tracker.

Tracking Info:
Current SHA1: 5cfd0db
Version: 1.4.0.74 β2
Last Release Build: 2011-01-14 23:48:03

MacGDBp 1.4 Beta 1

I’m happy to announce the first beta of MacGDBp 1.4. This release represents nearly a year’s worth of work rewriting the entire internal structure of the application. As mentioned previously, MacGDBp 1.4 now communicates to the backend in an asynchronous manner. Not only does this change increase the robustness of the program, it should no longer beachball while waiting for responses from Xdebug. Because it took such a long time to stabilize this branch, there is very little in the way of new features for this release: almost all the work for this release was done for making the network changes and increasing stability.

One new point to be aware of is that the concept of “reconnect” is gone in this version. Instead, the debugger is now either attached to the backend or is detached. When attached, MacGDBp will start debugging any connections from Xdebug. When detached, MacGDBp will send the “detach” command immediately after receiving any new connections, aborting the debug.

There is one known issue:

• The expanded and selected item state of the variables tree is not preserved across debugger commands (bug #208)

You can download MacGDBp 1.4 Beta 1 from this page. Please try out this new version and file any new issues in the bug tracker.

Tracking Info:
Current SHA1: 1ffc93e
Version: 1.4.0.61 β1
Last Release Build: 2010-12-18 14:18:34

MacGDBp 1.4: Becoming Asynchronous

In between working on Bugdar 2, Phalanx, and Chromium, I’ve also been working on MacGDBp 1.4.

With the 1.3.0 release, I tried to address a couple of issues with the underlying network communication layer (called SocketWrapper, which was an Obj-C bridge to a BSD socket). The primary issue I tried to address was with Unicode characters; MacGDBp really only knows how to deal with ASCII text, which has proven problematic for international users. I tried to address this with the 1.3 branch by switching how data was stored and processed. But the 1.3.0 release was an utter failure from this perspective. It crashed extremely often, which lead to the 1.3.1 release that reverted the new network-layer changes. (That said, the new features introduced by 1.3 have been well-received.)

But the issues with the network layer ran far deeper than just dealing with Unicode text. MacGDBp uses synchronous communication with the debugger engine. When you issue a command (step in/out/over, get source, get properties, etc.), the command would be sent and then the thread would block until it received a response. This is bad, especially because MacGDBp does not use background threads; all the communication happens on the main UI thread. This can lead to beach balling and a bad user experience. So, why did I do this? Because synchronous communication makes for a dead-simple API. Asynchronous communication requires a lot more bookkeeping and works through callbacks.

So, for 1.4.0, I decided it was time to revisit the debugger backend. Rather than just trying to adjust how data is transmitted (ASCII vs. Unicode), I decided to rewrite from scratch the entire Xdebug communication layer. Rather than using raw BSD sockets, the 1.4 branch uses the CFNetwork API. This yields two huge benefits. The first is that all network activity is asynchronous because socket stream events are scheduled on the run loop. When data is available, a callback is executed and the UI is updated (as opposed to blocking the thread while waiting for a response). This also makes the application more robust, because if the response never comes, it will not lock up the entire UI. Secondly, by using a Foundation-level framework, UTF8 support comes pre-baked via the toll-free bridge to NSString.

I’ve been rewriting the back end in my spare time and it’s finally starting to stabilize. This release is still fairly far out, though. This core network change is also leading to a large refactoring of the entire application to make it more easily unit testable in the future. One of the results of this is creating a new LoggingController to record all network activity. The goal with this “hidden feature” is to make it easier to track down causes of bug reports. The log looks like this; it’s not pretty, but it should get the job done:

I haven’t yet selected the set of feature enhancements that are scheduled for this milestone. Before any new feature work can be started, the 1.4 trunk needs to become as stable as the 1.3 branch. If you have any feature requests, please search for or file new issues and vote them up in the bug tracker.

Tracking Info:
Current SHA1: a7725f8
Version: 1.4.0.40 β
Last Release Build: 2010-03-29 17:51:39

MacGDBp 1.3

I’m pleased to announce MacGDBp 1.3. This release features a new tool that allows you inspect values in the variables list via a HUD (screenshot below). This inspector will allow you to see long strings and to select/copy text values. To access this feature, go to Window → Inspector (Shift+Cmd+I). The currently-selected variable (which now, in 1.3, remembers itself across debugger stepping) will have its full value displayed in the HUD window.

Under the hood, there are two significant changes. The first is a rewrite of the receiving side of the socket layer (it now precisely uses the message length when buffering memory), which should eliminate the “buffer is incomplete” errors that occasionally popped up. The second is that the PHP stack will no longer be managed internally. After every debugger step, the entire stack will be now re-created because Xdebug proved to be unpredictable for keeping in sync with an internal state. Debugger actions may now seem a little less snappy, but I think accuracy is more important than speed here. In 1.4 I’m going to use a caching mechanism that will speed up performance by reducing network access.

This release also features a bunch of bug fixes, a couple of which would cause the debugger display to not work under certain circumstances. As always, the change log and commit log have all the details on the release.

MacGDBp 1.1 Released

I just released version 1.1 of MacGDBp. This release is a minor feature update, as well as a bug fix release.

A few important features that made it into this release are settings to change the Xdebug port to use, keyboard shortcuts and menu items for debugging commands, and breakpoints are now saved on quit so that when you re-open MacGDBp all your old breakpoints are there.

Furthermore, the MacGDBp is now updated via Sparkle rather than the custom software mechanism I wrote for version 1.0 and 1.0.1.

Finally, I’d like to thank Ciarán Walsh for providing some key patches for stability and memory leaks.

The Road to MacGDBp, Part II

The bug with XML parsing I mentioned in the last post caused me days of grief. I’ve been trying to find the cause of that bug (off and on, albeit) for months. It turns out the fix was very simple. All that’s left is creating the breakpoint manager and then MacGDBp will be released. Hopefully by the end of next week v1.0 will be in your hands!

In this post, I’m going to talk about icon design. One of the ideas I had for this was to use the PHP logo in some way — but using logos in an icon is tacky. Instead, I decided to keep the purple of the PHP logo. Since PHP is internet-based, I decided to take inspiration from the words “World Wide Web” and I drew out a globe. So at this point, I had a purple globe. Now I had to decide what to design on top of the globe (because a purple globe only conveys internet connectivity). For this I really saw two options: a screwdriver and wrench or a toolbox. On Mac OS X, the screwdriver-wrench combination usually implies configuration (c.f. Color Sync Utility, Raid Utility, configure toolbar item, etc.). Debugging is not in the same vein as configuring, so I ruled that one out. The toolbox, while unused on Mac OS X (except for the Adobe ExtendScript Toolkit), seemed like a good fit. I should also note that I thought about drawing a yellow spray can — akin to the debug icon in Xcode — but quickly dismissed it for being too similar to Xcode.

This is the paper sketch I first did of the icon:

Then I recreated the sketches digitally. You can see how the design evolved here.

The final step (not outlined above) was adding drop shadow to the entire icon. This is the final design:

Hopefully the next post about MacGDBp will be the release announcement!