Goldenseal Pro Progress Report (23 Jul)

Progress on Goldenseal for Mac has been slow but steady. Most of the basics are finished, but there are many small details still left to test and fix. We are testing it with TurtleSoft data, but the software is not good enough for daily use, yet.

Our staff is also still working on the shopping cart for SmartKnives. We bought many vintage Swiss Army knives and Leatherman tools from airport confiscations in the years after 9/11. Now it’s time to sell them to collectors. Setting up the e-commerce has taken longer than expected. Unfortunately, it will continue to consume time between now and year end.

In the short run, it’s going to delay completion on the first release of Goldenseal Pro for Mac. However, programming is hard, and very few people can keep it up full-time. Taking breaks to do inventory counts and photography is a good break. A chance for ideas to percolate.

In the long run, the extra income will allow us to pay subcontractors for the Windows version and  multi-user code. Our staff has less experience in those areas, and there are plenty of contractors able to do the work. It will take time to ramp up software sales, and this is something to fill in the gaps.

We came close to launching SmartKnives in 2015. The plan then was to subcontract the entire upgrade, so it was something to do while we waited. That was before we discovered how few people actually know how to write 64-bit software for Macintosh. It was long before we gave up on contractors, and tackled the Pro update with our own staff. That’s when we discovered the reasons why competent Cocoa developers are so rare.

In the mid 1990s we talked with some Venture Capital folks, considering a quicker and more massive launch for the original Goldenseal. One of their requirements was sufficient “barriers to entry”. Essentially, it means you need patents or some other protection to make sure there won’t be too much competition. They saw QuickBooks looming, and thought it would eat our lunch and only leave crumbs. It did.

We have struggled with Cocoa the past few years. But what keeps us going is the fact that it’s difficult for everyone. Cocoa is just about the only way to write Mac software that will run on Catalina. QT is an alternative, but that also is no easy road.

When we finally finish this thing, it will put us behind that barrier to entry.

Dennis Kolva
Programming Director


Goldenseal Pro Progress- Leaks & Crashes (Jul 5)

Our staff is back at work on Goldenseal Pro. The first thing we faced was a new problem while editing list items. The OK and Cancel buttons used to work fine, but suddenly they didn’t.  It turned into a journey down the rabbit hole of Cocoa memory management.

Memory is a general problem for all programmers. Apps need to use many small chunks of RAM: thousands, sometimes millions of them. If you don’t delete them when done, it’s a memory leak. Leaks cause the app to gradually use up more and more memory space. Eventually it will get slow. Pile up enough leaks, and it will crash. Web browsers often do that.

Preventing leaks is not easy. Delete something too early, and the program will fail when you access a long-gone bit of memory. Usually the app crashes from that, but sometimes it reads corrupted data and causes a hard-to-fix bug. Wait too long, and there’s no way to go back to tidy up.

The C and C++ programming languages are considered “hard” because they require programmers to manage raw memory.  On the other hand, most newer programming languages do the memory management for you. Usually that involves periodic garbage collection: automatically deleting objects from memory, when they are no longer needed.

Apple’s Cocoa framework started out by requiring programmers to manage their own memory, just like C++. It then added its own memory manager in 2010. Rather than garbage collection, Cocoa uses something called ARC (automatic reference counting).

We turned on ARC when we first started programming Goldenseal Pro for Mac. Sometime in the past year or two it was accidentally turned it off, possibly during an Xcode update. The setting is buried in a list of 200+ other build settings, so it’s easy to overlook.

Removing ARC caused no noticeable problems, since the app was never used long enough to show leaks. Finally we noticed the setting this March, and turned ARC back on. That broke the buttons, and a few other things.

Our staff has worked with ARC long enough now that I feel confident in saying it’s the worst of both worlds. Yet another complaint about Cocoa.

It’s possible to write code in Python, Java, Javascript or other garbage-collected languages, and simply not worry about memory. It’s all taken care of for you. During run time there may be weird multi-second delays as the app cleans up memory, but it’s a small price to pay for convenience.

It’s also possible to use C or C++, and manage memory reliably. Many tricks exist to make it easier. We used them for the original Goldenseal, and it almost never leaks or crashes.  Recent versions of C++ provide even better tools for managing memory. We use them in any new code we write.

With its in-between approach, ARC is definitely not mindless. It makes you decide whether to make connections “strong” or “weak”. It sometimes deletes things unexpectedly. It also is hard to debug. There are tricks to help track down memory problems, but nothing as simple as in C++.

Despite all that, the buttons are working again. Then for a while, the app crashed when editing a second list item. That is fixed too. Both were general “object lifetime” problems caused by ARC. They also applied to code in other places, so all those are also fixed now. Sometimes it’s one step backwards, two steps forward.

Dennis Kolva
Programming Director