Writings from the sticks

No this isnt a rant about segregating developers into groups – maybe that will be a different post.

This is more about a couple recent conversations.

One had to do with how Xojo handles conversion & comparison of unsigned & signed values. Turns out that while I closed the bug report way back when based on info from a compiler developer I now think that was the wrong move.

Citizen developers shouldn’t be expected to know, and usually don’t want to know, the arcana of why a 32 or 64 bit value compares to another using a specific x86 or x86_64 instruction that performs a bitwise comparison (which IS whats going on).

What they DO know is Xojo compares in a way that appears to them as really really wrong. The following code on 64-bit Mac and Windows, says “Value is greater than 0.” On 32-bit Mac and Windows, the message box says “Value is less than or equal to 0.”

Var Value As UInt32 = 4294967295
If Value <= 0 Then
  MessageBox("Value is less than or equal to 0")
Else
  MessageBox("Value is greater than 0")
End If

Thats not helpful and the explanation is truly arcane and relies on the bit wise representation of the values to explain why it appears so wrong. It might even explain some really erratic an unusual errors that people report that only occur once in a while.

The other issue that another user I was helping recently stumbled into was one I had never even thought about. If you create sql statement that uses prepared statements and dont provide as many bind variables as specified in the query then it can just silently do .. something.. which appears to vary depending on the database in use.

Again, this is not helpful and could quietly be doing harm by inserting bad data.

Thankfully this has been reported & fixed now(that no one noticed until now is a different issue)

But these two point out a specific problem. A citizen developers should be able to rely on the IDE and compiler to point out as many bugs and errors as early in the process as possible AND they should do “sensible” things.

Comparing what looks like a giant positive number and telling me its less than zero isnt sensible. Silently inserting nil instead of reporting a mismatch in the number of bind parameters isnt sensible.

Neither helps anyone, of any skill, write better more bug free code.

Shouldnt that be the goal though ?

I’m currently posting a tutorial about the TextInputCanvas at If Not Nil

A powerful and flexible but under documented control in Xojo’s toolkit it forms the basis of the Code Editor in the IDE

I’ve been poking about with some alternative tools – probably more than I have in the last decade or more.

Previously I’d look at them for “competitive intelligence” reasons. To see where they were, where they were going and what things they did better.

Now that focus has shifted entirely. I, like many others, have been looking at other tools with an eye towards maybe moving away from Xojo. Thats not likely to happen ASAP but there are some promising options I’ve looked at.

B4J is one.

Its visual designer behaves differently than Xojo’s but its not entirely foreign. And one thing you’;ll find different is that the B4J style of working is that you have to add references to controls & windows & the events they handle in a manner that is different than Xojo’s.

Its not better, or worse, just different.

Last night I sat and created a simple web browser app which in B4J took me about as long to create as it did in Xojo. Its really simple with a text field, a button, and an html viewer.

So that easy stuff just works – exactly as you’d expect.

I’ll report more as I tinker more.

Sometimes you get a crash log and start digging through the call stack assuming that what it shows you is The Truth.

But, it may not be.

If you strip symbols from your apps then the crash logs you get can be horribly misleading.

For instance a crash that looks like

Thread 0 Crashed:
0  libsystem_kernel.dylib              0x00007fff6597bfce __pthread_kill + 10
1  libsystem_c.dylib                   0x00007fff658d830a abort + 127
2  libsystem_c.dylib                   0x00007fff658a0360 basename_r + 0
3  XojoFramework                       0x000000010ca2fa79 _Z29ShowDebuggerConnectionFailurev + 0
4  SpawnCompiler.dylib                 0x000000011262b260 REALPluginMain + 934808
5  SpawnCompiler.dylib                 0x0000000112694dfb REALPluginMain + 1367859
6  Xojo                                0x0000000107a430cb DebuggerMap.LookupLineAddress%b%o<DebuggerMap>si8&i8 + 107
7  Xojo                                0x000000010a207ac5 StudioDebuggerUI.StudioDebuggerUI.LookupBreakpointAddress%i8%o<StudioDebuggerUI.StudioDebuggerUI>si8 + 421

Where the offset from REALPluginMain is an enormous value is VERY likely NOT correct that the call site was in REALPluginMain

So why does this happen ?

The system component that records the stack trace simply looks for symbols that are before the call site and reports those.

If symbols have been stripped then you see the problem. That crash logger cannot find the “correct” symbol and so may simply walk back a long long way to find one that hasnt been stripped. It reports that + a really large offset.

Exceptions in Xojo however ARE quite accurate.

We have MS trying to move Xamarin into a much more capable x-platform tool chain. Windows, iOS, Android, macOS (eventually) and even web is on the roadmap somewhere.

And, as of Sept 22, we get the announcement that the Swift team has released a toolchain for Windows.

What remains unclear with the both toolkits is how easy it will be to design a UI in a cross platform way.

Some tools already do work x-platform, like Elements compilers.

But they require you to have different custom UI’s per platform usually made in the platforms “preferred tool” – Xcode on macOS and VS on Windows

If I wanted to use those tools I’d already be using them and have a single common “platform abstraction layer” then my common business logic I can just share and a custom UI per platform.

IF these big guys ever figure this out it could put a lot of pressure on a tool like Xojo.

Thom stumbled on something absolutely ancient and has posted about it.

All I can say is I’m disappointed at Xojo’s response to this.

Once upon a lifetime ago Apple did a release of macOS X that was focused solely on bug fixes & performance improvements.

Over the years people using Xojo have said how they wish Xojo would do such a release. Either tick tock back and forth or some other scheme.

And usually those requests have been in comments on forums threads etc.

Well I put a feature request in feedback so others can vote for it etc and Xojo gets a good sense of how important it is

EDIT : case rocketed up the top 20 list and now has been closed as “unactionable”

Pick a decently long list of reproducible bug and fix them

That was in theory the reason we spent time to create reproducible bug reports

Disappointed that “do a release with nothing but bug fixes” is seen as unactionable.

EDIT 1 : I’ve rewritten the request in a way that it _should_ be actionable

230 – 220 * .5 = 5!

Really 😛

* saw this on a twitter feed and loved it !

This past weekend I took a novice hang glider source and it was a blast !

Some of the things it showed me

1. rocks dont fly
2. Norm is mostly a rock
3. omg there are muscles there, and there, and there ?
4. and why do all those muscles hurt now ? 😛

I’m sure a lot of people imagine that this is a simple thing and a few quick basics and pretty soon you’re running off cliffs and gliding for hours.

Turns out the flying part is the easy part.

Take off and landing is hard !

Still had a great time and might just have to try this one again.

Apparently a bunch were removed for older versions of Xojo

I recreated some