Archive for the ‘MacGDBp’ tag
While I did state that the first beta of
MacGDBp would be out by the end of the year, I decided against pushing a new build before
immediately disappearing on holiday for two weeks. But today is the day!
Version 2.0 is not a complete rewrite, but virtually every aspect of the app has been updated and
improved. The biggest changes are under-the-hood, particularly around the interaction between the
frontend and the remote debugger, which now accurately tracks “transactions.” This allows MacGDBp to
fetch the contents of long arrays or large objects without issue. In addition, several components
have been refactored to improve the project’s code health and the app’s robustness. These
improvements fixed numerous long-standing bugs in the app.
The biggest new feature, by popular demand, is the ability to set symbolic breakpoints. This will
pause the debugger any time a function of a given name is called, rather than having to rely solely
on file/line breakpoints.
Unfortunately, the app will remain un-sandboxed and not code signed. The Sparkle updater is not yet
compatible with the app sandbox. And Apple’s annoying
two-factor authentication requirements rule out (for me)
obtaining a signing certificate. Sparkle will still verify the updates’ signature, however.
Finally, MacGDBp 2.0 sports a new, unified interface. All of the panels and windows have been
collapsed into a single, tabbed window.
See the changelog for the full list of new features
and bug fixes.
You can download MacGDBp 2.0 Beta 1 from the product page.
First, welcome to the new Blue Static! The site has a fresh coat of paint, it has been made more
mobile-friendly, and I have updated much of the content, pruning extremely old things while keeping
still-old-but-maybe-interesting items around for posterity. For the first time in the history of
the site, Blue Static is no longer powered by PHP: the entire site is now rendered as static files
It has been well over seven years since this site was last updated, and that is because I no longer
have the substantial amounts of time I once had to dedicate to Blue Static software. Since I now
spend all of my working hours writing and maintaining software, the allure of doing so as a hobby
has unfortunately diminished.
Over the past few months, I’ve pondered how to move forward with the various Blue Static projects.
I’ll outline some of those decisions now:
MacGDBp still has a large number of loyal users. I’m happy to report that in these intervening
years, I’ve worked sporadically on the next major version. The first beta of MacGDBp 2.0 will be
released before the end of the year! The entire core debugging engine has been rewritten and made
more robust, which has fixed many bugs and added new features. The new version will also be code
signed and notarized to be compliant with Apple’s increasingly locked-down macOS.
RGB Converter will remain available for download, but because Apple has removed
in macOS 10.15 Catalina, the widget will not be updated anymore.
Bugdar is the project that I’ve struggled to make a decision on. It is fairly safe to say that
any 2.0 greenfield rewrite will not happen. However
all of Blue Static’s bugs remain in the Bugdar instance that runs on this site, so it cannot go
anywhere over night. I am not currently enamored with other options, such as Github’s issue tracker, so
despite Bugdar’s visible age I will continue to run it for Blue Static’s purposes. There may be an
infrequent maintenance update, but I do not expect to make major changes to the software at this
What drove these decisions is that I have largely stopped writing software in PHP. It is
no longer my language of choice, and my interests have moved on to other programming languages and
software domains. MacGDBp remains important to me beacuse others find it useful and the code is
still fun to work on.
I’ll close with a teaser: there is at least one new project that I will be publishing in the future
under Blue Static. It has to do with email and is geared towards power-users.
Look forward to MacGDBp 2.0 Beta 1 coming to a Sparkle update near you!
MacGDBp 1.5 has been released. This update fixes a crash on 10.8 when adding a breakpoint. Credit for the fix goes to Paul Mitchell and Sam Fleming.
This release also includes a new feature that allows you to evaluate and see the result of an arbitrary PHP expression. For example, you can use
print_r to get a different view of PHP objects:
Full details are in the changelog.
Current SHA1: 0508dff
Last Release Build: Sun Sep 2 21:13:38 EDT 2012
MacGDBp 1.4.1 has been released; this is a maintenance update that fixes a few bugs. I meant to get this release out a few weeks ago, but I’ve been travelling recently and didn’t have the time.
You can download MacGDBp 1.4.1 from this page. Please file any new issues in the bug tracker.
Current SHA1: 7fde123
Last Release Build: 2011-04-29 00:33:16
After a slight delay trying to track down some bugs, I’ve decided to push MacGDBp 1.4 to stable distribution. While this release is not quite perfect and there are a few known issues (listed on the project page), I was tired of blocking the release on relatively minor bugs. This release has been a year in the making, and it makes significant improvements over the 1.3 branch. To find out more about what went into making this new version, check out some of the older posts on the blog.
You can download MacGDBp 1.4 from this page. Please file any new issues in the bug tracker.
Update: A minor bug had to be fixed with the released package. I’ve pushed a new binary and the few people who have downloaded the update will be prompted to update again.
Current SHA1: 4ce0d31
Last Release Build: 2011-02-26 14:21:17
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.
Current SHA1: 5cfd0db
Version: 126.96.36.199 β2
Last Release Build: 2011-01-14 23:48:03
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.
Current SHA1: 1ffc93e
Version: 188.8.131.52 β1
Last Release Build: 2010-12-18 14:18:34
Today I spent some time debugging MacGDBp 1.4. The issue I was having was that socket data was being processed out of order, and I couldn’t figure out why. Until I stuck it in the debugger. It turns out that when you call
-[NSAttributedString initWithHTML:documentAttributes:], it spins the run loop internally (making a nested run loop). If, for example, you have a socket scheduled on the main run loop in common modes, the socket will signaled if you create the NSAttributedString on the main thread. Here’s a stack trace:
#0 0x0000495e in -[DebuggerConnection handlePacket:] at DebuggerConnection.m:597
#1 0x000044e8 in -[DebuggerConnection readStreamHasData] at DebuggerConnection.m:508
#2 0x00003243 in ReadStreamCallback at DebuggerConnection.m:76
#3 0x9021cdd3 in _signalEventSync
#4 0x9021d7be in _cfstream_solo_signalEventSync
#5 0x9021ca88 in _CFStreamSignalEvent
#6 0x9021d707 in CFReadStreamSignalEvent
#7 0x906e7cd9 in SocketStream::dispatchSignalFromSocketCallbackUnlocked
#8 0x90694819 in SocketStream::socketCallback
#9 0x90694721 in SocketStream::_SocketCallBack_stream
#10 0x901d91ae in __CFSocketDoCallback
#11 0x901d8c97 in __CFSocketPerformV0
#12 0x90192ff1 in __CFRunLoopDoSources0
#13 0x90190c1f in __CFRunLoopRun
#14 0x901900f4 in CFRunLoopRunSpecific
#15 0x9018ff21 in CFRunLoopRunInMode
#16 0x989ee6e8 in -[NSHTMLReader _loadUsingWebKit]
#17 0x989e2ddb in -[NSHTMLReader attributedString]
#18 0x98842585 in _NSReadAttributedStringFromURLOrData
#19 0x9883f910 in -[NSAttributedString(NSAttributedStringKitAdditions) initWithData:options:documentAttributes:error:]
#20 0x98887a35 in -[NSAttributedString(NSAttributedStringKitAdditions) initWithHTML:options:documentAttributes:]
#21 0x988879a9 in -[NSAttributedString(NSAttributedStringKitAdditions) initWithHTML:documentAttributes:]
#22 0x0000acf7 in -[BSSourceView setFile:] at BSSourceView.m:93
#23 0x0000af91 in -[BSSourceView setString:asFile:] at BSSourceView.m:120
#24 0x00007bae in -[DebuggerController updateSourceViewer] at DebuggerController.m:264
#25 0x000081e4 in -[DebuggerController sourceUpdated:] at DebuggerController.m:353
#26 0x00005a6b in -[DebuggerConnection setSource:] at DebuggerConnection.m:839
#27 0x00004ecf in -[DebuggerConnection handleResponse:] at DebuggerConnection.m:694
#28 0x000049cc in -[DebuggerConnection handlePacket:] at DebuggerConnection.m:600
#29 0x000044e8 in -[DebuggerConnection readStreamHasData] at DebuggerConnection.m:508
#30 0x00003243 in ReadStreamCallback at DebuggerConnection.m:76
#31 0x9021cdd3 in _signalEventSync
#32 0x9021cd58 in _cfstream_shared_signalEventSync
#33 0x9019315b in __CFRunLoopDoSources0
#34 0x90190c1f in __CFRunLoopRun
#35 0x901900f4 in CFRunLoopRunSpecific
#36 0x9018ff21 in CFRunLoopRunInMode
#37 0x944ed0fc in RunCurrentEventLoopInMode
#38 0x944eceb1 in ReceiveNextEventCommon
#39 0x944ecd36 in BlockUntilNextEventMatchingListInMode
#40 0x98605135 in _DPSNextEvent
#41 0x98604976 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
#42 0x985c6bef in -[NSApplication run]
#43 0x985bec85 in NSApplicationMain
#44 0x00002c44 in main at main.m:21
At frame 30, the socket callback gets signaled because data is ready. This happens on the outermost loop invocation, which is supposed to happen (yay!). At frame 22, the data for this most recent network packet is still being processed. At frame 21, there’s the call to initWithHTML for NSAttributedString. And at frame 15, trouble starts when the run loop gets spun again, while still processing sources from the first/outermost run loop invocation. At frame 2, while still processing the packet from frame 30, the socket source gets signaled again and new data is read and processed, while still processing the first piece of data. Sigh.
I haven’t yet decided how I’m going to get around this problem. The issue is that more data gets read from the socket before the current packet finishes handling, making a hot mess (it screws up internal state). The easiest conceptual solution is to push the socket stuff into its own thread on its own run loop, but that will require a fairly significant refactoring. Another option would be to schedule the socket in its own run loop mode, but then I’d be responsible for spinning the loop myself and would have to manage that carefully.
Update: I bit the bullet and refactored. In the long run, this is probably a good thing because it forced a separation of components that deal with CFNetwork itself and the response to the data received from it. It also split a 1032 line file into two files, one about 600 lines and one about 500 lines.
Posted on March 30, 2010 at 04:59 UTC,
filed under the category
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.
Current SHA1: a7725f8
Version: 184.108.40.206 β
Last Release Build: 2010-03-29 17:51:39
So I know I promised at Thanksgiving an update on the state of things. Well I lied/got busy. Sorry; these things happen. The past few months have been a whirlwind. So here’s a brief personal update before I talk about software.
In May 2009 the Mac port of Chromium (the open source project that Google uses for their Chrome browser) was starting to gear up. I’d been interested in working on a Mac browser project for a while; but Firefox’s code seemed beastly and I never have been a fan of XUL. Safari is great, but it isn’t open source. Enter Chromium: an open-source, truly native, WebKit-based browser. Consider it love at first sight. Fast forward 12 patches and four months later to August when I am nominated and made a committer. My work has all involved bridging the cross-platform C++ model (as in MVC) to Objective-C/Cocoa land. I wrote the Mac the page info window, history menu, cookie manager, font and language settings, download settings, and added favicons throughout various parts of the UI. Now, present day. Last week Google offered me an internship position in Manhattan. I’m thrilled at the opportunity and am excited to start work there in May with such smart, interesting, and talented people. I expect to learn a lot!
So now let’s talk software.
Last time I wrote about the future of Bugdar 2, I posted a link to a list of phases development that would occur. The original plan was to create 1.3 as a stepping stone to 2.0. That line of development has since been abandoned. Instead, I decided to greenfield the project. There were many reasons for doing this; but here are the two big ones:
I have a better, more focused vision of what I want Bugdar 2 to be. When writing Bugdar 1, I didn’t have a clear goal of what I wanted — there was no philosophy to the design, I was merely thinking “copy Bugzilla, but do it better”. Overall, I think I was successful with this. But this is not Bugdar 2, at all. Bugdar 2 will be a refined, incredibly flexible system that I am excited to share with you. But because the two projects will be so different, trying to create a large, temporary scaffolding system (version 1.3) was extremely time consuming and kludgey.
ISSO. Originally dubbed the “Iris Studios Shared Objects” framework. This thing is ancient. The first version dates back to when I was a rather n00b PHPer. The first commit was from 12 January 2005! Since that time I’ve had a lot more development experience and completed a Minor in Computer Science. A better, more-efficient architecture could be devised.
I wrote an entirely new PHP framework (that will require PHP 5.3+) that is a bare-minimum, no-frills framework. I call this Phalanx and the code is currently available on Github; it is licensed under the GPL version 3. Phalanx is event-driven. Rather than writing another MVC framework, I decided to look at the problem of web frameworks through the lens of functional programming. The problem with MVC on the web is the lack of state; HTTP is not persistent. Functional programming focuses more on inputs and outputs (and the transformations between them), which is how Phalanx works. Each Event class defines a set of inputs that it accepts and the outputs it will return. This also makes unit testing much more clear-cut. I won’t get into further details here, though. That’s for another post.
So before I could start moving again on Bugdar, I had to write this new framework. That took a matter of months (July – January). But I’m now back on Bugdar. Phalanx makes development really fast, and in the past two days I’ve implemented the basic user system, a preliminary Auth2 API, and initial submission and listing of bug reports. I’ve posted a new roadmap for Bugdar 2.
I’ve been refactoring and cleaning up MacGDBp’s code over the past few months. It’s also been accumulating various fixes for non-critical bugs. I’d also like to re-tackle the socket/network layer for 1.4, as I tried and failed to improve this in 1.3. You can probably expect this update before Spring.
I’m also working on redesign the Blue Static site. It really hasn’t changed since 2006 (insert the ‘learned a lot’ bit here) and it’s time. I’m not very far on this, yet.
Wow that’s a lot. More in the next few days. UI mocks to come.
« Older Entries