QB64 Phoenix Edition v3.11.0 Released!

[SpriggsySpriggs]

Another good update. Good job, guys

[bert22306]

While I'm sure I can adjust either way, this business about signed hex creates a real problem with consistency.

In order to make signed hex, or signed binary, work correctly by default, you have to make assumptions about word length. So for example, &hffff &hffffffff only returns a -1 if we all agree that we'll only use exclusively 16-bit or 32-bit signed numbers. Try 8-bit or other word lengths and this won't work.

So here's the deal. Don't know about everyone else, but in my work I use 6, 8, 12, 24-bit numbers, to name just a few, all of the time. Sometimes they are signed, other times they are unsigned. So to me, having a consistent way for this to work saves me having to check this out every single time I encounter a different length of number.

And crucially, the only "consistent way" for this to work is to always assume unsigned, and then let the user accommodate the sign, if necessary, in his program.

Here are some inconsistent results as of now:

-------------------
In each case, the binary number is all 1s.

8-bit:  255 (I think we can agree, 8-bit numbers are commonplace?)
Using Val(): 255

16-bit: -1
Using Val(): 65535

12-bit:  4095
Using Val(): 4095

24-bit:  16777215
Using Val(): 1.677722E+07

32-bit: -1
Using Val(): 4.294967E+09
-----------------------

That's the problem, as I see it. Mind you, the way Val works now, for me, is perfect! But as Steve ominously said, it's "wrong"(???)

Aaargh.

[SMcNeill]

@bert22306 That's why I keep mentioning that it's probably a good idea for everyone to just get in the habit of always adding a suffix to your &H values.

&HFF&& is 256. Will always be 256. Can't be anything but 256.
&HFFFF&& is 65535. Will always be 65535. Can't be anything but 65535.

Whether we patch the codebase later to mimic QB45 behavior, or not, your results will always remain consistent. If you use it inside VAL, DATA, or just a normal variable calculation, the result will remain consistant. It takes any ambiguity out of the procress and explicitly declares its type. (An integer64 in this case, which would hold all values up to &HFFFFFFFFFFFFFF before going into negative numbers. You can use ~&& for unsigned integer64 values, but I just usually find && to be less stretching of the fingers and easier/quicker typing usually.)

Without those suffix, QB64 has to take it's guess at what you intended. Is &HFF a byte? an unsigned byte? an integer? long? integer64?

QB45 was memory constrained and always tried to store the value in as small of a block as possible. They didn't have a _BYTE variable type, or an _UNSIGNED variable type, so &HFF would fit an INTEGER variable type as 256. &HFFFF also fits an INTEGER as -1. &H10000 is too large for an integer, and as such has to fit in a LONG variable.

Those old rules were designed with the hardware limitations which were commonplace back in the day (640k program size limits, ect). They don't honestly make the most sense in today's programming environment, but if we want to maintain backwards compatibilty, sooner or later we should adddress the issue. When we do, that means &HFFFF would always return -1, rather than the inconsistent -1/65535 which it bounces between now, depending on how/where it's called -- and that might end up breaking folks code which *assumed* the unsuffixed number would always remain signed/unsigned...

...and the best way to protect yourself and your code from that glitch ever affecting you, is to just take the half second to tak on the suffix you need yourself.

&HHFF% <-- integer,so 256
&HFF%% <-- byte, so -1
&HFF~%% <-- unsigned byte, so 255

No ambiguity and it's 100% future proof and will always give you the same result no matter where it's encountered.

Why not use it, once you realize that it may become an issue for you at some point in the future?

[bert22306]

&HFF&& is 256.  Will always be 256.  Can't be anything but 256.
&HFFFF&& is 65535.  Will always be 65535.  Can't be anything but 65535.

&HHFF% <-- integer,so 256
&HFF%% <-- byte, so -1
&HFF~%% <-- unsigned byte, so 255

No ambiguity and it's 100% future proof and will always give you the same result no matter where it's encountered.

Why not use it, once you realize that it may become an issue for you at some point in the future?

Right you are.  I have to train myself to do this consistently.

[bert22306]

So hey, here's to qb64 doing some true second guessing. Going from decimal to hex:

The program:

Code: (Select All)

_Title "Decimal to hex with negative and positive numbers"
Screen _NewImage(120, 43, 0)
Color 1, 7
Cls

decimal1 = -2
hex1$ = Right$("00" + Hex$(decimal1), 2)
Print "-2 to 8-bit hex: "; hex1$
Print
hex2$ = Right$("0000" + Hex$(decimal1), 4)
Print "-2 to 16-bit hex: "; hex2$
Print
hex3$ = Right$("000000" + Hex$(decimal1), 6)
Print "-2 to 24-bit hex: "; hex3$
Print
decimal1 = 254
hex1$ = Right$("00" + Hex$(decimal1), 2)
Print "254 to 8-bit hex: "; hex1$
Print
decimal1 = 65534
hex2$ = Right$("0000" + Hex$(decimal1), 4)
Print "65534 to 16-bit hex: "; hex2$
Print
decimal1 = 16777214
hex3$ = Right$("000000" + Hex$(decimal1), 6)
Print "16777215 to 24-bit hex: "; hex3$
End

And the results:

-2 to 8-bit hex: FE

-2 to 16-bit hex: FFFE

-2 to 24-bit hex: FFFFFE

254 to 8-bit hex: FE

65534 to 16-bit hex: FFFE

16777214 to 24-bit hex: FFFFFE

Moral of the story: It's clever enough to figure out if I'm trying to use signed hex or unsigned hex. Weird, man!

PS. Thinking about it, without having to explicitly state "signed" or "unsigned," this is probably the best default. All you have to do here is limit the input + values, when using signed.

[chikega]

Congrats to the QB64 PE Team!

[TerryRitchie]

Is there a way to change the HOME key operation to the pre v3.11.0 IDE method? I don't see a setting in the IDE to change the new way HOME works to the previous method.

When I hit HOME I prefer for it to take me to the beginning of the line, and then hitting HOME again takes me to the beginning of the code. It's simply muscle memory I have gotten used to over the years.

v3.11.0 IDE now takes me to the beginning of the code on a line the first time HOME is pressed and then to the beginning of the line the second time HOME is pressed.

If there is no way to switch back it's no big deal, I'll just have to retrain these old muscles again.

[RhoSigma]

Is there a way to change the HOME key operation to the pre v3.11.0 IDE method? I don't see a setting in the IDE to change the new way HOME works to the previous method.

When I hit HOME I prefer for it to take me to the beginning of the line, and then hitting HOME again takes me to the beginning of the code. It's simply muscle memory I have gotten used to over the years.

v3.11.0 IDE now takes me to the beginning of the code on a line the first time HOME is pressed and then to the beginning of the line the second time HOME is pressed.

If there is no way to switch back it's no big deal, I'll just have to retrain these old muscles again.

LOL, so you're the first who wants it the old way. The new way is actually same behavior as N++ and other editing environments use per default. Certainly it would be possible to add a menu option, but then our IDE menues soon look like in N++ and not like BASIC/Compiler/Debug related anymore.

Would you be satisfied with a hidden config option for that to change, which you can set by directly editing the config.ini file in the manner like the "wikiBaseAddress" and "ErrorColor" settings?

[TerryRitchie]

Is there a way to change the HOME key operation to the pre v3.11.0 IDE method? I don't see a setting in the IDE to change the new way HOME works to the previous method.

When I hit HOME I prefer for it to take me to the beginning of the line, and then hitting HOME again takes me to the beginning of the code. It's simply muscle memory I have gotten used to over the years.

v3.11.0 IDE now takes me to the beginning of the code on a line the first time HOME is pressed and then to the beginning of the line the second time HOME is pressed.

If there is no way to switch back it's no big deal, I'll just have to retrain these old muscles again.

LOL, so you're the first who wants it the old way. The new way is actually same behavior as N++ and other editing environments use per default. Certainly it would be possible to add a menu option, but then our IDE menues soon look like in N++ and not like BASIC/Compiler/Debug related anymore.

Would you be satisfied with a hidden config option for that to change, which you can set by directly editing the config.ini file in the manner like the "wikiBaseAddress" and "ErrorColor" settings?

Nah, like I said I can adapt. The old way is just something I got used to.

[zaadstra]

A bit late but since this has not been mentioned, I get a positive with ESET detection on padlock.dll.
It is located in D:\qb64pe-3.11.0-x64\internal\c\c_compiler\opt\lib\engines-3.

Here is the Virustotal report for padlock.dll.

I know of the (old?) advice to exclude the qb64 folder from the scanners eyes.  But this never was necessary here.
Also, this is not a fresh compiled blob from my hands but a part of the compilers, which seem as pretty official files to me.

So better double check here.

I'm not sure if I compiled a prog with it yet, I get the positive alert every day when running a backup.