Why are we deflecting onto operating systems? There are plenty of apps that break in the move between os’s both in windows and macos.
There are countless issues that you need to run older editions of VS for things that just weren’t brought over to newer editions or whole technologies that are sometimes deprecated or simply superseded and Microsoft often fix long standing issues in newer editions.
I assume you consider the impact of how people perceive the language due to the removal of Basic and Dim. I’m sure if you were a regular windows user, you’d have fixed the following by now:
You mean the “ignorance is blissed” method; you couldn’t have said it better. You can’t control what you don’t measure, but if your measuring system is flawed then who cares about the rest … just hold on for the ride.
Windows is not considered a toy operating system and yet it is filled with application shims designed to mimic behavior of bugs that specific popular application developers were assuming were by design behavior.
As a platform developer, we don’t always have the luxury having a narrow view of the situation. We have to consider the overall impact.
The purpose of points is to help us determine which cases are having the most impact.
Correct but it is relative to other cases. Sometimes it’s obvious that a case is or soon will impact a lot of users. Much of the time it’s less obvious or we would be making an educated guess about it. Rankings OTOH provide concrete evidence relative to other cases as to which ones are most important to users.
Relative to other cases in Feedback. As I said to Julian, rankings (and also subscribers as well) help us compare cases against others to determine relative impact. If a case is 5 years old but has only one user subscribed to it, that’s not going to likely get the same attention as a case that’s a month old and has 10 users subscribed to it with most of them ranking it as their #1 issue. So it’s the relative ranking that really matters.
> I think you should try taking the forums a little more serious
OK, fair enough. It’s not a new type in the sense that it’s not exposed to the user. However, you know as well as I do that we are very careful about not breaking code especially in ways that would be hard to detect. In this case, there’s an easy workaround so it doesn’t seem like it that’s worth subtly breaking existing code.
I’m sure most who have bitten by this bug has already progammed in the workaround, and so it remains unchanged until it affects the next person. I think this is another example of Sometimes, no news is bad news
I truly believe you are wrong in this instance. I understand your concern about breaking code, you know I do. But even if there is something that would break - which isn’t known at this time - you’re still defending your product being egregiously wrong. This should be fixed, even if broken code becomes more broken. Anybody who has already worked around the problem will be unaffected, as the workarounds will continue to work. Anybody who hasn’t noticed their code is broken will suddenly find it fixed. They may not notice a difference at all. Regardless, the product becomes better for it. Do you know how much time I’ve spent wrapping zeros in CType(0, UInt64) just to work around this? Literally hours. That’s something I’d have to do anyway because it’s not like I’d get a fix tomorrow. But you’re arguing that’s the way it has to be, because you aren’t confident you can get the fix right. This is a solvable problem, yet you’re accepting mediocrity.
For anybody that doesn’t understand the scope of this problem, I’m serious, turn on the warning. Nearly any code that uses an integer type besides Integer will be flagged. UInt8, UInt16, UInt32, UInt64, Int8, Int16, Int32, Int64, and UInteger. They’ll generate warnings all over the place because constants and literals are always Integer, and therefore generates comparison and assignment issues. Oh and be sure to analyze in both 32-bit and 64-bit mode to test really test, since Integer means something else in each.
The code’s already broken. Unbreaking it should be the goal, even if there is some growing pains… which there shouldn’t be anyway.
I’m not defending it being wrong. I’m saying there’s a cost to fixing it and that cost (breaking other user’s code in ways they wouldn’t immediately notice) is too high. If fixing it would highlight every place in their code where the new behavior is present so the user could then make the necessary changes, that would be fine but it doesn’t work that way.
User code should not require changes. The code would start working correctly. Don’t go off of Aaron’s comments in 2218. Aaron was right that any special treatment of the literal will cause some kind of problem. That’s not the case with the proposed solution. There should be no backwards compatibility problems.
Doesn’t closing a case remove its rank, and makes it impossible for people to sign on if they are affected? As a test I tried adding both the duplicate and the original 2008 case to my top 5, and they both still said “Rank: None.” In this thread we’ve seen references to 3 separate cases submitted over the years (2218, 11935, and 40465), and within those cases at least 10 people are participating.
While I agree it may not impact many people, or better, most people aren’t aware of the issue, or if it affects them or not (i.e. unknown bugs.) In this case, it feels like math correctness should be win over backward compatibility—If that’s even a concern, as the fix is supposed to be backward compatible.
But entertain me for a second and let’s assume it isn’t compatible, and explore the position “Few people are impacted”.
If that’s the case, what’s stopping us from making the math correct? If very few are impacted one way (i.e. the way it is; with wrong math), then won’t few be impacted the other way too (fixed with smart type promotion; correct math). If you agree that few are impacted both ways, it might as well be the correct way?
Regardless, if the proposed “Comparison Type Promotion” solution is indeed inherently backward compatible, then there’s nothing to worry about. Sure, that’s for your engineers to determine. But will they get a chance to even entertain the idea with the report being closed, as a duplicate of an older closed report, which was made prior to the discovery of a new solution?
YOU CLOSED IT?! The goal is to just sweep the bug under the rug isn’t it? Jason is right, because all the bugs are closed, they can’t be ranked. Your argument that it must not affect a lot of people because it isn’t ranked doesn’t hold water because you won’t allow it to be ranked.
I was curious what a buddy of mine thought of this situation. He’s a senior engineer at Wayfair, so I kinda feel like he has an idea what he’s talking about, don’t you? Here’s his thoughts on the matter.
Just after the end of the screenshot (couldn’t fit it) he concludes “Idk, stuff like this makes me never want to use them.”
It’s embarrassing when your compiler has a math bug. It’s extremely embarrassing when it exists for 10 years without being fixed. It’s downright insane to refuse to fix it. To plug your ears and pretend it’s not happening. This isn’t a minor a bug.
And for now, I’m going to get my kids to school, then pull my twitter account out of retirement to talk to Aaron. I’m not done with this.
After talking to Aaron Ballman, the general conclusion is that this behavior is right for a C/C++ style language. But Xojo isn’t a C/C++ style language. He says
For Xojo’s target audience of people who write code but don’t consider themselves professional programmers, this is a problem worth solving.
I think it’s reasonable to tell C or C++ programmers “these are the rules of the language and you have to figure out how to make sense of that, best of luck.” But I think it’s less reasonable to make people who aren’t computer scientists sit down and think about how literals get typed and how that impacts basic comparison operations
Personally, I think the best way forward is for integer and floating-point operations to use an infinite precision type
I think it’s also defensible to say this is not a bug. We designed it to behave this way, after all, so it is an intentional design choice. If I had a time machine and infinite resources, I’d do it differently now.
I still wish we bit the bullet and went with infinite precision types. But at the same time, hardware back then wasn’t really good for that sort of thing and RB had no optimizer.
Take that as you will. You know I truly believe this should be fixed.
That may not needed here.
We just need a bit more logic in the compiler for handling various types.
if both sides are the same type, fine, compare them.
If not, upgrade both sides to a common upper type like int64.
If you compare Int64 with UInt64, add extra checks. e.g.
if ValueUInt64 < ValueSInt64 then
becomes internally:
if (ValueUInt64 <= MaxSInt64) and (CType(ValueUInt64, Int64) < ValueSInt64) then
or other direction:
if ValueUInt64 > ValueSInt64 then
will be internally:
if (ValueUInt64 >= MaxSInt64) or (CType(ValueUInt64, Int64) > ValueSInt64) then
There may be 16 or so combinations to handle special like this, but that is doable.
And of course make some unit tests to verify behavior is right for all cases.
Perhaps the cost is too high to fix it because they don’t have a compiler engineer on staff?
Aaron’s point about not doing it the right way many years ago because of both hardware capabilities and RB not having an optimizing compiler, makes the compromise BACK THEN understandable if unfortunate… but that was BACK THEN.
It hard to imaging how the proposed solution would break any code… but if it did it would be a LOT less likely to than subtle bugs caused by things as they are…
This is a subtle bug that can exist and cause erroneous results, but might never be found… Those are the type of issues that need to be fixed REGARDLESS of the number of reports for the product to be respected and trusted widely IMO.
Most forums that are owned by the tool provider operate in this way. This is not unique to Xojo - as you are a FileMaker developer too you will know that they maintain a very strong presence in their forums and frequently close threads down for far less than what Xojo allow on here.
Go onto the official Apple/Microsoft forums and see how quick your topics are closed if you stray from the rules.
Personally I find the continual attacks and sniping to be unconstructive.
Few Devs are affected by this issue = A fix will possibly affect a few Devs only
Some Devs already use a workaround = A fix won’t affect any of those
Many Devs have possibly an issue because of false comparissons = A fix will just be a fix for of them
If so, please stop arguing with your customers and fix it. Let’s then verify in an Alpha/Beta if this is really causing code to break… I mean, that’s what Xojo pre-realeases are for, or?
