Xojo Can’t Math

Pop on over to Thom McGrath’s blog post about the ongoing saga of a 12 year old bug in the Xojo compiler. It’s an interesting, long, and complex issue that could affect your code if you use unsigned integers in your code. Admittedly, this bug may only affect a very small percentage of applications but it’s still a bug.

I think this saga exposes several things about Xojo. First, the way they use Feedback is fundamentally broken. For this particular bug they say it doesn’t affect many people because it has no points but because they’ve closed it the item won’t accumulate points. Voila! Nothing done about it in 12 years. Circular logic at its best.

Secondly, I truly believe that since they do not have a compiler engineer this bug won’t get fixed. Heck, most likely can’t get fixed because of lack of experienced personnel. Compilers are not simple things. I don’t buy for a second that Xojo has enough developers for the product they have.

The thread on the Xojo forums was long and contentious, and I don’t think Xojo did themselves any favors by arguing. While I appreciate Geoff talking to us in the forum it does kind of amplify the perception (reality?) that’s he’s not really listening.

I think I can say this with near 100% surety: We want Xojo to succeed. Many of us need Xojo to succeed for our careers and business.

Anyway, happy coding everyone!

16 thoughts on “Xojo Can’t Math

  1. Its simply heart braking and leaves me speechless.

    If something has been bugged for 12 years (or whatever time it was) it does not make it any less bugged. And absolutely does not make it working as intended and warrant closing the thread.

    This needs to stop, we all care about Xojo and we need it to succeed, but beating off the customers is not the way to succeed. There is no need to defend something that is clearly not right, doing so only makes harm.

    And this hiding behind surveys needs to stop also, maybe there were surveys, I have never gotten one, nor has any of the many Xojo licenses I managed for customers which I had buy Xojo over the years. There could be 20 licenses there at least I managed, those are example of customers that don’t come to forums or submit bug reports. This does not mean its simple customer who wants everything made for simple users, it simply means its customer who bought some big product and wanted to have Xojo in case if they needed to access the source code of the product they bought.

    Please Xojo work with your customers, not against them, then we all succeed.

    • I have received the surveys but I don’t think they’re very helpful and certainly don’t get down to a granular level. It asks some simple questions: 1) On a scale of 1-10 how likely are you to recommend Xojo to someone else? 2) Any other comments? and 3) Can we contact you for additional information? So…not helpful and doesn’t give much information.

      When we had ARBP survey years ago we had multiple data points on what pro users needed. Reporting was #1 which was sort of implemented but certainly not fully implemented to what many needed (i.e. with drop-in report viewer and designer components). The #2 item was a more powerful grid component and you can see where that’s gone since then.

      My point is that ignoring the community has been a very long-term problem.

      • We do a number of surveys throughout the year and one more in-depth annual survey. I have your response to our annual survey from July 2019. I think I mentioned this on the Xojo forum, but our annual survey will be posted in the next few weeks and I encourage you to fill it out and be specific. Keep in mind that the surveys will only go to people who are opted in to receive emails from us. The results of the survey are reviewed with the entire Xojo team.

        • If the only people you do survey are those that have said yes to receiving emails then there could be a significant number who you do NOT survey
          That could skew the results and validity of the survey

          • In the 13 years during which I was an avid supporter of Xojo (no long such). I too never recieved a survey beyond the simple 3 question one mentioned above. So my assumption (without evidence to the contrary) was those surveys either never existed, or were sent only to those from whom a glowing response was known to exist

          • DaveS and Norman – Perhaps you forgot but you both did fill out the July 2019 survey in full as well.

    • I’ve never seen any such survey. Sometimes it feels like if you visit the forum, you’re automatically outside their target audience. This whole “citizen developers” thing needs to stop. A developer is a developer. Just because I’m working on an internal tool that nobody but me will use, doesn’t mean I don’t need it working correctly. When did unsigned integers become an advanced topic? To me it’s a data validation technique. For example, why is Array.Count not returning a UInteger? It can never be less than zero, so what advantage is there it having it return a value that can be negative?

  2. ” This whole “citizen developers” thing needs to stop. A developer is a developer. Just because I’m working on an internal tool that nobody but me will use, doesn’t mean I don’t need it working correctly. ”

    Almost every app I have written for internal use is used by other people at the company, and for some apps not just those in my department…

    For internal apps the UI do not have to be as “spiffy” as for commercial apps, but they do need to be very bug free and reliable…. if not it’s my reputation and standing in the company gets negatively affected.

  3. I read Thom’s blog post and I still disagree with this being classified as a compiler bug so much as a compiler behavior for programmers to be aware of. Eventually, the compiler has to generate code for a particular CPU instruction set (or some other interpreter) and at the time this feature was developed the only two instruction sets we cared about were x86 and PPC. Neither of these CPUs let you compare signed and unsigned values with a single instruction — they compare (typeless) bit patterns instead. So the options were: fast comparisons with signed vs unsigned issues or slow comparisons without them, and we picked fast comparisons because of how often integers are compared. It could be reasonably argued that we should have picked a different conversion direction than we did or to go with the slow-but-correct code generation approach, but I find it hard to argue this is a bug.

    tl;dr: *do not mix signed and unsigned types in comparisons* because it’s generally a sign (pun totally intended) that you’ve done something confusing. If you have to mix signed and unsigned types, *tell the compiler what you want to happen* by casting them to the same type.

    FWIW, there are other instances of incorrect behaviors that are along these same lines. When you do a division by zero, we all know that’s going to either be -Infinity, Infinity, or Not a Number as a result, but integers can’t represent those things and so if you’re doing integer division you get a behavior that you could call a bug, but is really still just programmer error. Dividing Int32(-2147483648) by Int32(-1) is another great example; 2147483648 can’t be represented by a 32-bit number, despite it being the mathematically correct answer. At some point, you have to make concessions to what the hardware allows you to do efficiently or you have to live with really inefficient runtime performance to catch all of the edge cases.

    As for the argument that no one has demonstrated code with a behavioral change, consider:

    Function foo(FirstValue as UInt32, SecondValue as Int32)
    If FirstValue > SecondValue Then
    … first block …
    Else
    … second block …
    End If
    End Function

    Code like this will change behavior for some pairs of values if you change the implicit conversion direction and it can be difficult to look at that code and spot the fact that you’re relying on a specific conversion behavior because you may not be expecting those inputs when writing the code but things work out fine by happenstance when the function is called with those inputs. Given that this behavior has been in place for more than a decade, you can safely assume this is relied upon (see Hyrum’s Law for details).

    I remember adding a signed/unsigned comparison warning to explicitly point out this issue when developers ran into it. Does that warning no longer trigger?

    • Because of API 2, if you have API 1 code you get hundreds of warnings making the warnings unless.

      In any case for a product aimed at “Citizen Developers” and hobbyists, I think this should be classified this as a bug today because it is unintuitive and can result in buggy user code that the complier will allow.

      While I understand the practical restraints at the time, and back then in RB not many were using UInts, time advances and so should the product…

      UInts have always felt tacked on to the framework to m because they were never fully integrated into it (which admittedly is a big job) but Xojo IMO needs to mature and deal with such things. particularly for it’s target audience.

      BTW when you define constants at the Class/module level teh IDE still won’t let us define the datatype for a numeric constant ourselves …

      That is one of the things I mean by the framework not keeping up with capabilities added over the years.

      -Karen

      • > Because of API 2, if you have API 1 code you get hundreds of warnings making the warnings unless.

        Ugh, yeah, that’s certainly not ideal.

        > While I understand the practical restraints at the time, and back then in RB not many were using UInts, time advances and so should the product…

        I guess that’s more of a philosophical question — should working code continue to work after an upgrade?

        > UInts have always felt tacked on to the framework to m because they were never fully integrated into it (which admittedly is a big job) but Xojo IMO needs to mature and deal with such things. particularly for it’s target audience.

        They were definitely tacked on. IIRC, we added them only for declare syntax (because we needed explicitly-sized types) but then decided to allow declare-only types as native types. I remember pushing for this but in hindsight, I’m not convinced it was the best idea.

        > BTW when you define constants at the Class/module level teh IDE still won’t let us define the datatype for a numeric constant ourselves …

        Correct — numeric constants all have Integer type, and we never came up with a syntax for letting you suffix a literal to give it a more specific type (or allow you to cast things as a constant expression, IIRC).

    • I believe the warnings still get raised but a warning might be insufficient

      Basically make a way for a user to select whether certain warnings should be treated as errors instead

      • > Basically make a way for a user to select whether certain warnings should be treated as errors instead

        Yeah, that would be a super sensible feature regardless of signed/unsigned comparison behavior. I’m a bit surprised the feature isn’t already there, to be honest.

    • I disagree… If this were not a compiler issue, the why is it that so far Xojo is the only language that I (and others) have been able to manifest this error? I will agree the issue is not LLVM (as Swift and others use that as well), but more the preprocessing that Xojo does before LLVM gets ahold of it.

  4. I don’t agree that this is hardware or CPU related at all. This is more of compile type thing since at compile time when generating the machine code then the types are known, and different kind of machine code should be generated depending on if its Int vs Int (or UInt vs UInt which is same case) or Int vs UInt or UInt vs Int.

    Everything is known at compile time to make those decisions on how to generate the machine code. So in the end product there should never be loss of speed, except when you have the 2 edge cases obviously, where there would be more machine code to do the conversion.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.