|macOS Native Helix & Xcode Transition Progress Report, Part Two: March 2008 – September 2007|
|Mar 26, 2008|
|Mar 22, 2008||
All projects are back on track! Helix RADE 6.1.1 (a couple of bug fixes) and Helix Server 6.1 (for PowerPC) are in the final stage of beta testing. Barring any show-stopping bug reports, we’ll be shipping them soon.
Helix Engine for macOS has resumed active beta testing, meaning that we are finally through the blizzard that was the wxWidgets 2.8 upgrade. On top of that, Helix Client for macOS is also in active beta testing.
On the Intel-native front, All three macOS products are well on their way. In our spare time (What’s that?!?) we started testing the Intel native Server. Early returns are that the speed boost is rather nice. However, we tapped out our funds that were dedicated to that project, so it has to wait a while longer. (If you’d like to commit funds specifically to finish the Intel-native code; contact Gil.)
|Feb 28, 2008||
Ugh. One of the bigger issues we have been struggling with is data rectangles that — for some mysterious reason — won’t display their data. We finally figured it out.
It turns out the lethal combination is: Center or Right alignment and Word Wrap turned off. In these situations the data rectangle appears to be empty. Here’s why, and how we plan on working around it.
Note: When word wrap is turned off, MLTE uses left alignment for all text.
But that is not quite true. More accurately, it should say:
Note: When word wrap is turned off, MLTE requires left alignment for all text.
At first, this appeared to be a kludge on Apple’s part: by internally treating the data rectangle as if it is extremely wide, MLTE could neatly fake “word wrap off” by making it impossible for text to ever need to wrap. After all, at approximately 20,000 pixels wide, the chances are pretty good that the user would never run out of room on the first line and word wrap would never occur! But that means that the calculation to position right or center justified text ends up placing the text far outside the displayed area.
But then we tested further and discovered that even after there are more than enough characters (approximately 3000) to fill a single line in this very large rectangle, additional text still does not wrap to the second line!!! So this appears to be nothing more than a bug in Apple’s code. (Yes, we filed a bug report, let’s see what — if anything — comes of it.)
But enough grousing about MLTE. Since Helix collections can be (and have been) created with these combinations, we have two ways of working around this new-found limitation:
We have chosen option 2: if a rectangle specifies Right or Center alignment, Helix now ignores the Word Wrap flag, always turning it on.
|Feb 25, 2008||
In response to the February 21 posting, a user asked this question:
Does this mean that development of the PPC based macOS Client is being put to one side so that the Intel based macOS Server can be delivered sooner?
Answer: No, this means that the attempt to deliver a working macOS Client (PPC or Intel) temporarily derailed the effort to get the new macOS Server (both PPC and Intel) out. The good news is that we have fixed that bug. The bad news is that it uncovered a related bug. Work continues.
|Feb 21, 2008||
While work continues on the macOS Client/Engine, we have turned our primary focus on delivering Helix Server 6.1. There are three reasons for this. First, is that Helix Server 6.0 does not run under macOS 10.5. Second is that Helix Server 6.0 is not Intel native. Helix Server 6.1 runs under macOS 10.5 and it runs natively on Intel-based Macs. Third is that it is required for the macOS Client.
We originally hoped to have that ready for release in late December, but as always, there is one bug that is proving difficult to fix. However, we recently had a breakthrough in understanding what is failing. In the one and only failing example, what appears to be a basic lookup date for user = username in users abacus does not display the value. However, other calculations (e.g: total sales for that date) that rely on the same value work fine.
First the background: when Helix Server is doing ‘work for itself’ it does so as a special user named ‘Server’ The problem is that because of the changes required for multi-threading data for the macOS Client, some tasks get sent to separate threads. In this specific case the lookup operates on a thread that is running on a ‘background’ thread with the username ‘Server’ instead of the real username. As a result, the lookup does not find a matching record and it returns undefined.
Why this works 99.9% of the time, and fails in this one case, we don’t know. But we have a plan to fix it and the engineers are plugging away.
|Feb 4, 2008||
Switching to macOS, running natively on Intel and PowerPC processors, building with Xcode instead of CodeWarrior, is an arduous task. Progress is being made, but some bugs are more difficult to fix than could be imagined. Our engineers are finding many instances where Helix worked ‘by magic’ in the past. They report finding things such as variables that were used for two distinct purposes that somehow managed to avoid colliding in the past. More insidious are cases where variables were created in an uninitialized state (when this happens, the variable contains a random value), and then specific paths through the code would fail to set the variable to a value, leaving other parts of the code to act on the uninitialized (random) value. These are common programming errors that tend to work due to the peculiarities of the compiler and/or operating system. The three switches we are undertaking (Classic to macOS, PowerPC to Intel, and CodeWarrior to Xcode) are causing many of these to bubble to the surface. We continue to knock them off, one by one.
On a more pragmatic note, it appears that Intel-native Helix may require macOS 10.5 (Leopard) or higher. The issue related to ‘buffer overflow’ attacks (see our September 18, 2007 entry) has been addressed in macOS 10.5, enabling us to build and execute Intel-native Helix without relying on third-party patches. We haven’t entirely decided to abandon this option, but the need to deliver a macOS native version of Helix ASAP argues against it.
|Dec 31, 2007||
The switch to wxWidgets 2.8.7 is proving to be the right decision. While making a thorough check to make sure basic functions are still working, a bunch of previously unreported bugs were uncovered and fixed.
|Dec 19, 2007||
As beta testers turn up unexpected issues, we see that there are changes to the way forms work in macOS then we had not considered problematic, but now we do. One of them is the fact that controls (popup menus, checkboxes, radio buttons) are not part of the tabbing order, regardless of how they are specified within Helix. I’ve written another simple utility that creates a detailed report on where you use Tab Field and Home Field commands in sequences.
Based on a number of factors, we made the decision last week to update from wxWidgets 2.6.x to 2.8.7 (the current version). This has set us back a few days, but is required to fix some rather ugly printing bugs.
|Dec 7, 2007||
A nice bit of news: we have confirmed that Helix Engine for macOS can display the contents of a PDF document via the picture tile. It even shows the first page of multi-page PDFs.
|Dec 5, 2007||
More progress: many more bugs squashed. We are getting closer, but there is more work to be done.
The "Getting Ready for macOS" seminar pointed out that we need to offer some tools to help you examine your collections to ensure a smoother transition to macOS. So we spent a little time writing some simple utilities for you.
|Nov 12, 2007||
Steady progress. Beta testing continues to progress nicely. Rewriting the whole user interface turns up lots of quirks in the way Helix used to work. Some we abandon for better solutions, some we keep for familiarity’s sake.
|Oct 29, 2007||
Steady progress. Beta testing has not shown any cases of collection damage (always a good first step!) and the list of bugs reported is being whittled on steadily.
Engineering also finished off the code for the Open Query dialog box — the dialog that opens when you click a query rectangle in an Open Query window.
|Oct 19, 2007||
The other shoe drops. In today’s edition of The Latest Word we announced that we are now building and testing Universal Helix products. We are running Intel-native!
|Oct 18, 2007||
On August 18, we posted a note to the effect that we had discovered that it is possible to support the PICT data format natively in macOS. Now comes this revelation: Native PICT support is definitely going away in macOS 10.5 (Leopard).
The good news is that this will not have a significant impact on our schedule. It was already in our plans to switch away from PICT to another format. The discovery that we could read and write PICT data in macOS 10.4 was seen as a bonus for us in that we wouldn’t have to ‘throw the switch’ quite yet.
As the information from Apple on the page referenced above indicates, the PICT format can still be read in macOS 10.5 — it is just writing (pasting) new PICT data that is going away. This news has little immediate impact on our plans and it only confirms what we knew all along: the PICT data format is obsolete.
|Oct 16, 2007||
Beta testing has been proceeding nicely. Our testers have identified a couple dozen bugs that we need to fix before this product is ready for daily use. Some of them are already fixed. Nothing major has been uncovered — and that is a huge relief! We should be able to start thinking about public beta tests and release dates in a few weeks.
Of course, that means that the promised price increase is all the nearer. If you are not aware of this ‘promise’ see this edition of The Latest Word for the details.
|Sept 18, 2007||
If you want to get a glimpse into why it takes so long to convert Helix’s code to run under Xcode, this page gives you insight into the most recent roadblock we encountered.
For those who don’t care to read that (or got dizzy trying!) here is the executive summary: in order to prevent ‘buffer overflow’ attacks, Apple disabled nested functions in Xcode when building Universal applications. Nested functions are a legitimate programming technique and (of course) Helix uses them extensively.
|Sept 8, 2007||