MacGDBp 2.0 Beta 1 Released

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.

Looking Towards the Future

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 by Hugo.

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 Dashboard 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 time.

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 Released

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.

Tracking Info:
Current SHA1: 0508dff
Version: 1.5.0.104.0
Last Release Build: Sun Sep 2 21:13:38 EDT 2012

Bending PHP to Your Will

One of the best features of Objective-C is protocols. These are akin to PHP and Java interfaces, but have one huge advantage: you can mark certain methods as required or optional. This is useful in implementing the delegate pattern because if you do not care about a certain method, you can simply not implement that method. In PHP, this is not possible with interfaces: you must implement all the methods of an interface in order to implement the interface. While this is fine and makes sense in most cases, it’s not always convenient.

So I set off to find a way to create protocols in PHP. The language is fairly dynamic, so I was able to come up with a solution called WeakInterface. Before jumping into the implementation details, let’s see how it works in practice:

First you define your interface as you would normally:

interface AllOptionalInterface {
  public function DoSomething();
  public function DoSomething1(Closure $arg);
}

The class that implements this only cares about the DoSomething method, so it implements it:

class AllOptionalImpl {
  public function DoSomething() {
    echo 'I did something!';
  }
}

Note that this class isn’t said to implement this interface because it does not implement all the methods. Now in the code that is going to call this interface, you do the following:

$delegate = new WeakInterface('AllOptionalInterface');
$delegate->Bind(new AllOptionalImpl);
$delegate->DoSomething();
$delegate->DoSomething1(function() { echo 'Wow!'; });

This code will output “I did something!”. Let’s go line-by-line. First, $delegate is being created as an instance of WeakInterface, whose constructor takes the name of the interface to “implement.” Then the interface is bound to an instance of the implementation. And then finally two methods are called on the interface, and the one with an implementation is actually called. Calling DoSomething1() is a no-op.

I mentioned above that in Objective-C you can mark some methods as required, too. And that’s done with a docstring when using WeakInterfaces:

interface OneRequiredInterface {
  public function DoSomething();
  /** @required */
  public function DoAnything();
}

If you failed to implement DoAnything(), the call to WeakInterface::Bind() would throw an exception. But what if the number and type hints of the arguments of an implementation do not match that of the interface? WeakInterface has that base covered, too. Bind() will also check the parameters of all method implementations to make sure that the signatures match the interface’s.

That’s WeakInterface in a nutshell, but how does it actually work? It’s easiest to start with a callstack. So when $delegate->DoSomething() is called, this is how WeakInterface actually invokes the implementation:

#   Time    Memory  Function    Location
1   0.0033  975328  hoplite\base\WeakInterface->DoSomething( )  ../example.php:14
2   0.0033  975856  hoplite\base\WeakInterface->__call( )   ../weak_interface.php:0
3   0.0033  975856  hoplite\base\internal\MethodImp->Invoke( )  ../weak_interface.php:84
4   0.0033  976568  ReflectionMethod->invokeArgs( ) ../weak_interface.php:145
5   0.0033  976608  AllOptionalImpl->DoSomething( ) ../example.php:0

WeakInterface implements the magic PHP method __call(), which is invoked whenever a method call is performed and no method is found by the runtime. It captures this and then forwards the invocation on to an implementation helper MethodImp, which then uses reflection to finally invoke the proper implementation.

Going deeper, when a WeakInterface is constructed, the interface passed to it is reflected and the method list is walked. For each method, a MethodImp is created. When the WeakInterface is bound, that set of MethodImps is looped over, checking that any required methods are implemented and that any implementations match the interface’s method signature. At call time, the method name is looked up in the MethodImp table and the arguments are forwarded to the actual implementation.

One note on performance: due to the number of intermediate method calls, using WeakInterface is roughly four times slower than a plain method call. For most applications, this should not be significant at all; but for performance-critical code, you should steer away from WeakInterface.

The code is available here along with a unit test.

MacGDBp 1.4.1 Released

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.

Tracking Info:
Current SHA1: 7fde123
Version: 1.4.1.91.97
Last Release Build: 2011-04-29 00:33:16