Blue Static

Archive for the ‘software’ tag

Announcing Mailpopbox

Posted on August 8, 2020 at 14:00 UTC, filed under the category Mailpopbox. Tags: software, Mailpopbox,

I’m excited to announce the first new Blue Static product in 13 years!

Mailpopbox is an email server that helps provide anonymity by accepting email to any account at the domain (i.e. a catch-all wildcard). All messages are delivered to a single mailbox, from which your email client downloads all the messages.

This is version 2.0.1, which you may find surprising for an “initial release.” I’ve been running Mailpopbox myself for more than three years, adding features and fixing bugs. So it has been fairly well-tested in production, and I decided it was finally time to release it.

Mailpopbox is also the first product to use GitHub for issue tracking, rather than Bugdar. I’m doing this as an experiment, so we’ll see how that goes. Pull requests are welcome via GitHub too, though the repository source of truth will remain self-hosted here on Blue Static.

You can download Mailpopbox 2.0.1 and read more on the product page.

MacGDBp 2.0.2 Released

Posted on April 18, 2020 at 07:00 UTC, filed under the category MacGDBp. Tags: software, MacGDBp,

Today I’m releasing MacGDBp 2.0.2 to address a major issue with the auto-updater and some other minor product bugs.

Somehow when upgrading the Sparkle updater framework when working on MacGDBp 2.0, the auto-update relauncher binary lost its executable bit. This resulted in the auto-update installation hanging indefinitely. Unfortunatley there is no way to automatically recover from this state. Users can run:

chmod +x*

… and re-run the in-product updater. Or simply download version 2.0.2 which has resolved the issue.

You can download MacGDBp 2.0.2 from the product page.

MacGDBp 2.0.1 Released

Posted on April 11, 2020 at 07:00 UTC, filed under the category MacGDBp. Tags: software, MacGDBp,

In March I quietly promoted the 2.0 beta 1 release to be the final, stable build. I decided to not do a blog post because there were no changes from the beta build.

Today I’m releasing 2.0.1 to address some issues. Thank you to everyone who reported these bugs. The release also improves dark mode support in the source viewer, which you can see below.

You can download MacGDBp 2.0.1 from the product page or by updating via Sparkle.

MacGDBp 2.0 Beta 1 Released

Posted on January 4, 2020 at 13:30 UTC, filed under the category MacGDBp. Tags: software, MacGDBp,

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

Posted on October 28, 2019 at 15:30 UTC, filed under the category MacGDBp. Tags: software, MacGDBp,

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.3

Posted on May 19, 2009 at 03:51 UTC, filed under the category MacGDBp. Tags: mac os x, MacGDBp, software,

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.

MacGDBp 1.3 Variable Inspector

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.

Toolchain and Gitcrement

Posted on April 4, 2009 at 20:54 UTC, filed under the category Uncategorized. Tags: Gitcrement, software, Toolchain, tools,

I’ve posted today a git repository called Toolchain. This is a collection of scripts that I use that others may find helpful. You can find the repository here. In this post, I’m going to talk about one of the items in Toolchain called Gitcrement.

Gitcrement is a set of two scripts that solves the problem of creating build numbers when using git for source control. Unlike Subversion, where the repository revision is the perfect choice for a build number, git has no such luxury because it uses SHA1 hashes for identifiers.

This is where Gitcrement comes in. Gitcrement is a simple interface to a database that contains a sequential ID number (the build number), a username, the current date/time, and a git SHA1 hash.

The has four commands: init, next, list, and current.

To create a new Gitcrement database, go into any git repository root and type “gitcrement init“, which will create a new database file called .gitcrement.

When you want to create a new build number, simply type “gitcrement next” to record the current user (`whoami`), date and time, and whatever SHA1 hash `git info .` would reveal.

To see the current build number type “gitcrement current” and to get a list of all the build numbers type “gitcrement list“.

That’s all there is to it. To make this system useful, however, it needs a script that can be run in Xcode to automatically call “next” and save the value as CFBundleVersion in Info.plist. So, there’s another Python script called, which you can use as a Custom Shell Script Build Phase. This will advance the Gitcrement number every time you build the “Release” target in Xcode.

Gitcrement requires Python 3.0, which is not installed by default in Leopard. You can find it here or through MacPorts or fink.

Also, you may need to edit the installation paths in the tops of both files to point to where your copy of “git” is (in and where you install the “gitcrement” script (in

You can download Gitcrement here:

Link in Gitweb

Source TGZ

Why Go Open Source?

Posted on December 29, 2008 at 19:47 UTC, filed under the category Uncategorized. Tags: open source, software,

People sometimes ask me why I don’t charge for the software I write. I explain to them that, to me, it’s not about the money. But that’s only part of the story. After thinking about it there are a few reasons why I release everything as open source.

1. You’re Giving Back to the Community

This is what the entire FLOSS community and its mentality is about. You have this great software and you want to give back to the greater community by making it open source. Doing so means that all developers can see how you’ve chosen to implement certain things, they can borrow code, and they can help improve software by submitting patches. For me, I learn a lot of programming languages and techniques by dissecting open source software, and I feel it’s only fair for me to give back to the community as much as it has given me.

2. You Don’t Worry About Business

I’ve been reading some articles about indie development and I watched all of the C41 videos. From doing so, I’ve realized that starting an independent software shop is a lot of work. You have to get a credit card processor, you have to have a licensing infrastructure, you have to worry about piracy, and (arguably the most difficult) you have to find the right price for your software. We’re software developers, not business people. This is not my idea of a good time and I’d much rather spend time developing rather than doing the aforementioned tasks. Going open source frees you from all of that.

3. People Can’t Have Expectations

That is sort of a half truth. People will always have expectations about software, regardless of whether or not they pay for it. But when you develop open source software, you’re essentially a volunteer. People get what they pay for. I try to do my best in creating software and supporting it, but because it’s open source, there’s no expectation that I have to. As a full-time college student, I don’t have a lot of free time — I develop when I can. If I had paying customers, there’d be an expectation for future versions on a reliable time scale, but I’m not under that pressure. Additionally, I do not have to support this software with immediate email responses, blog follow-up comments, or forum posts. I do so because I like doing so. If this were a business, people would have high expectations for support, but because I do open source work, if I deliver good support, it’s only a bonus. If I don’t, they really can’t complain because they don’t pay for anything.