From survey results, approximately 25% of our users are hobbyists, 25% of our users are professionals and 50% are citizen developers. Therefore by definition, a citizen developer is the average developer.
It’s not actually impossible to compare the two. You couldn’t cast up in every case, such as already being in the largest type. For example, if this was UInt64 and Int64, there’s no larger type for the developer to cast into. Substitute those types’ min and max values of course. That’s why asking the dev to convert to a common type before comparing isn’t a viable solution. There’s been suggestions that a hidden larger type could be used by the compiler, and Aaron mentioned infinite precision integers. There are solutions.
Yes, but the same will occur, compiler should point a type error needing you to fix, and will be your job to invent a way to do what you want, without an int128 to scale up again. Your higher positive number when dealing with some signed operand will be 9,223,372,036,854,775,807 (63 bits), but when dealing with unsigned ones can be 18,446,744,073,709,551,615 (64 bits). Higher than this, you need another higher type like Int128 (128 bits) and Uint128 to use one more bit for positive numbers only.
I understand how these values work. That’s precisely my point. You want it to throw an error. I want it to just do the comparison. Right now it throws a warning.
One of the proposals was to use a hidden type that is not exposed to the developer. Something like a 65 bit integer that could hold both the 64 bits and a signing bit. Another proposal is to just use logic in the compiler to solve some of the basic assumptions first. Yet another would be infinite precision integers. There are a number of potential solutions.
A 128 bit integer wouldn’t solve the problem at all, because the problem would still exist when comparing a UInt128 to an Int128. The compiler has to be smarter about this comparison.
I think that this is impractical, much more easier to adopt Int128, as LLVM already supports it.
At some point you must reach a “limit of the platform” where we simply must acknowledge we reached. 128bits is a VERY HIGH limit.
Then that could be the internal type that is not exposed to us. Given that LLVM supports int128 already, that should be reasonably doable.
-Karen
It is very high. That’s why the current type conversion design is the wrong solution.
I’d rather have UInt128 available. There’s uses for it in the language, such as UUIDs. It can be done right now with memoryblocks or strings, but considering v4 UUIDs are just 128-bit numbers, that would fit nicely.
Disagree. We should have Int128, Uint128 and Quad. The compiler must be “clever” enough to scale values up, and the final one, when people start counting planets of the universe, should be int128, if we start counting atoms an overflow error should exist.
No. We are talking two different things here.
The SQL example is simply a convention. Primary Key must not be null, except when you are using SQLite. Just another convention and nothing really dramatic – we all know you have to read into the details of the database engine you are using and cannot simply work on the assumption that “all SQL is equal.”
What we are talking about here is a serious math bug. Nobody would expect a result as described in the OP. Especially none of the famous citizen developers.
If we take this topic to the extreme, it means that every Xojo bug where users found workarounds for is not worth fixing it. There are workarounds, and what do you know? You could break one by accident.
@Geoff_Perlman: I hear you talking about the number of users affected by a bug, and the class of users prone to suffer from it. Could you please elaborate where you take this “numbers” from? Did you do any surveys? Do you believe that every user who luckily found a workaround will still move one of his 5 Feedback points, freeing one of the several-year-old tickets where this one was spent on, making that one less important then?
No, sorry, I do not want to slide into sarcasm. This is a seriously meant question: Please tell us how you gather that numbers you are talking about.
7 Likes
There are developers who have dozens of reported and still unfixed bugs in feedback, but they can only add points to five cases. Because of this limitation one can’t even add points to all of his own cases - one can only add points to the most severe ones. The current feedback system is not suitable to collect/manage bug reports for a software (= Xojo) that has so many bugs. The system could work, if the bug count would be much lower. The feedback system is now completely overwhelmed.
5 Likes
I went through my current project and tried to make sure that I am using not only using the correct data types, but also doing my best to make sure that these data types are not converted to signed integers when they shouldn’t be.
I ran into two issues.
-
<https://xojo.com/issue/61926> - It appears that either the analyze is wrong or loops are forced to use signed integers.
-
<https://xojo.com/issue/61927> - Project constants are signed integers.
Both of which generate 100s of warnings in my project, making it very hard to track down other issues where Xojo is making the values signed when they shouldn’t be.
1 Like
Here we have 5k+ warnings (in 1 project) if we allow to analyse this 
1 Like
Remember RB did not originally have unsigned integers (IIRC it did not when I first started using it) … because of that a lot of very basic functionality has never been updated to take them into account… That is one of those cases I think.
-Karen
1 Like
I’ve noticed the same thing. Makes it a bit cumbersome to fix these warnings.
1 Like
I’ve read through all 157 posts to this thread and I’m a bit gobsmacked. I consider myself a hobbiest/citizen developer, having developed several specialized programs for my employer (a governmental entity) and have been using this product since RB1 came as a free trial on a MacAddict CD, around the days of Strout and Ballman. I too, have used Uints for flag storage and don’t think I’ve encountered this buggy result, but again, how would I know?
I’m a bit shocked by the responses on this thread. It boils down to 1+1=3 . That is wrong in any world, and if anyone is relying on this behavior in their old projects, they should never have done so. Taking advantage of a bug is very dangerous and for Geoff to say we don’t want to fix it because someone is doing that, is wrong. What about all of the other developers who expect their variables to be accurately compared? You seem to be saying you want it that way because someone, somewhere, who you can’t identify, may be misusing the product in some way that you don’t know. You’re ignoring everyone who is currently using the product and IN DANGER of accidentally relying on an answer that the compiler is incorrectly resolving.
Then let’s get to the justification for not fixing it because of the frequency of request. Geoff, frankly, that is unacceptable. TEN years ago, people pointed this out and Aaron closed it. I don’t think you were using the feedback points back then, but saying it has none now is a cop-out in my opinion. As everyone here knows, when you close a case, the feedback points are zeroed out. Later, others file bug reports for the same thing. People presumably assign feedback points, then the case is closed as a duplicate, zeroing out the points again. This happens several times and then Geoff defends the bug by saying there’s zero points allocated? This is smoke and mirrors.
A bug is a bug. This one can bite quite undetected. It needs to be fixed just for the sake of doing the right thing, not because of votes, not because there’s workarounds or not, but because the software is making wrong assumptions. And I disagree with Tim Streater, backward compatibility is not a justification for leaving it and documenting the bug is not an acceptable solution. Defending it by saying that SQLite has rules they won’t change is not providing a WRONG answer. With API 2.0 around, saying that it may break old code is, quite frankly, ridiculous. How much of that old code can work now? The solutions have been provided, Xojo just needs to act. If the problem is that there is not a compiler engineer at this time, then Xojo needs to be transparent with that fact, instead of rationalizing and defending.
23 Likes
Oh I think I see a “Nice Reply” badge being earned for this post. Well said Randy.
1 Like
Hi Randy,
First, thank you for being such a long time user. Wow, MacAddict! That really takes me back.
You would know because your logic would fail. This occurs when comparing a Uint to constant or literal that has a value that is outside of the bounds of a signed integer. That’s a REALLY BIG number. You’d get a bug report, step through your code and find that your literal does not compare properly to your Uint at which point you’d likely ask on the forum or contact us.
This behavior is not a bug. It’s by design. Xojo has not always had unsigned integer but it has always had signed integers. Signed integers (like all integer types) have a certain size/bounds. It has been argued that we could make the compiler handle this on its own. That is true. It might break some code but my guess is not many considering the very specific situation one must be in to encounter this.
We have chosen not to change the behavior because there’s a simple solution for those that ever run into this which now has been documented. Basically, you use CType to make clear what type you wish the literal to be so that you’re making an apples to apples comparison.
It’s not a question of technical skills as the release notes will tell you. We have fixed many compiler bugs in the past several years since we had a dedicated compiler engineer and have made the transition from 32 to 64 bit for the compiler as well. We have the talent we need.
The issue here is bang for the buck. Changing this behavior would have cost and that cost is not worth implementing a feature that impacts such a small portion of our users. If an engineer is working on this feature, we aren’t fixing some bug or implementing some other feature. That’s all that this comes down to in the end.
I hope this makes things a bit more clear.
1 Like