Month: June 2023

Source Control (Jun 28)

The source code for our new accounting software is in a thousand-odd text files. We write code there, fix any compiler errors, run the app, then repeat until the interface looks good and works properly. Our staff can chug along in that cycle for weeks on end, and get a lot done.

Our code sits on top of many, many thousands of files from other people. It takes several apps to manage the project. Those use smaller apps. There are settings and kits, libraries and preferences and details. The whole thing is a precarious pile. Updates often break something and require time to fix. Preparing a new machine for duty takes at least a day or two.

The past week was mostly spent on hardware and software setup for two more Macs and a new Windows machine. We need to build and test for three OS types (Mac Intel, Mac ARM, Windows). We also need to run both Qt5 and Qt6 for a while. It’s a lot of permutations.

Source control helps keep everything in sync. It stores a repository on each computer, and pushes changes to and from a master copy that’s in the cloud. It’s a good backup system that gives a snapshot of the project at each save, with notes on what was added/fixed/removed.

Until early 2022, we used SourceTree (desktop app) for local backups, and BitBucket (online site) for the shared repository. Then they released an update that didn’t work on Windows, so we switched to GitHub (desktop app and online). It worked OK, but wasn’t as good at reloading past versions. Sometimes we need that to find out when a hidden bug appeared. Then we can compare the bad code to the previous day’s save, and locate the problem more easily.

Since we were already installing and tweaking hardware, software and tools, it made sense to try SourceTree/BitBucket again for source control. It works OK on Windows now. Merging in the GitHub saves was a challenge, and I think some history got lost. Worst case, we have a slightly harder time tracking down an old bug, some day.

The bad news is, there are two new compilers at work, and both give new warnings and error messages. Our staff is resolving them now. The good news is that keeping compilers happy is worth the effort. They catch subtle problems that may turn into real bugs later.

Dennis Kolva
Programming Director
TurtleSoft.com

 

Mac ARM (Jun 17)

The bugs we find in our new accounting software keep getting smaller and smaller. So our staff has moved on to the final phase: building an app that other people can use. There are a few steps needed to make that happen.

The first is getting the code to run on new Mac ARM chips: M1, M2 and variations. It requires a jump from Qt5 to Qt6. Early versions of Qt6 had many bugs and missing features, so we waited as long as possible to make the switch. Better to get most of the coding done in a mature framework.

The good news is, it only took a day to update from 5 to 6. Most of the time was spent doing a half dozen clean installs, until we finally had all the correct files. Then, a few small changes in our code was enough for it to compile in the new framework. Surprisingly easy for such a big change.

The bad news is, TurtleSoft Pro crashed immediately when run on an M1 Mac. The app starts by reading in a bunch of data that describes each data class, and it failed there.

In the most recent post, I mentioned that we modernized some old 70’s C++ code to make reports go faster. The ARM version failed in similar ancient code, also inherited from the NeoAccess database. We stepped through it, but the problem was too hard to understand.  Qt6 seemed to lose track of pointers that Qt5 handled properly. It could be a Qt bug, or some quirk in ARM coding, or just bad C++ coding practice that isn’t supported by newer compilers.

Rather than struggle with a mystery bug, our staff took a couple days to rewrite and modernize the descriptor code. Now it’s cleaner and easier to maintain, and it works in Qt6.

The new accounting software still gives other errors when run on M1/M2 Macs. Our staff is tackling them gradually. There’s a Qt developer forum that often is helpful. Some may be lingering bugs in Qt’s support for ARM chips. Qt6 has been out for almost 18 months, but it’s still not perfect.

The really bad news is, we need to use NeoAccess itself to read existing Goldenseal files, before converting them to the new format. Currently, most Neo code fails on newer Macs. They really loved to use void pointers, and that’s what confuses Qt6. A rewrite could take years.

There may be a generic fix, especially if it’s a Qt6 bug. If not, the update from Goldenseal may need to run on an Intel Mac (or Windows). Worst case, our staff will convert user files here and send them back.

Next week, our staff will start building for Windows. That probably won’t have many compatibility problems. Most of the work will be tweaking appearances so they look good. With luck, building on another platform will help to narrow down which problems are Mac ARM, which are Qt6, and which are ours.

Dennis Kolva
Programming Director
TurtleSoft.com

Progress Bars & Reports (Jun 7)

TurtleSoft’s first construction estimating software was a 300K Excel spreadsheet. It was about maximum file size for the Mac Plus it ran on. Loading took 20 minutes, so a progress bar was vital. After opening an estimate, I’d go outside, split/stack firewood, and watch the bar through the window.

For our new estimating/accounting app, a progress bar is less important. Chips and storage are 1000x faster these days, so most things only take a second or less.

However, the past week our staff has been testing and debugging reports. Those can be big enough to still need a progress bar. So we finally hooked up the built-in bar at the bottom of the window. Most times it just flashes, but reports with thousands of records take a few seconds to load.

A permanent progress bar is much safer. Goldenseal pops up a separate window, which has caused all sorts of problems over the years. Too easy to show multiple windows, or leave the bar dangling after the action finished, or remove it twice and crash. Sometimes the progress window would intercept messages meant for something else.

The new system has none of those flaws. It’s also just 18 lines of code instead of 200.

While testing reports, we noticed that using a date range didn’t go any faster. That was odd. It should look at fewer items if you only want the current year. The Find command is speedy when you search for dates or other common data. That happens because we index the most important fields. Reports ought to use indexing, also.

We stepped through code in the debugger, and discovered the problem. Reports loop through records with some ugly 1970s-ish code, inherited from the NeoAccess database. It’s hard to understand, and impossible to modify. There’s no choice but to open every record, every time. There was a comment dated 2004: “some day we should replace this mess”.

Last week, we did. It took a complete rewrite, but the new code is faster and easier to maintain. One more piece of ancient cruft is on the way out. It’s also used in a couple other places, but we’ll zap those soon.

Our staff just ended a 3 month break from programming, while selling a house and moving the office. It’s easy to accumulate stuff when staying in one building for a decade or three. There’s still one more move in the future, but that should only take a week or two.

Dennis Kolva
Programming Director
TurtleSoft.com