QB64 Phoenix Edition v3.11.0 Released!

[a740g]

QB64 Phoenix Edition v3.11.0!

https://github.com/QB64-Phoenix-Edition/...ses/latest

Enhancements

• #419 - Filesystem refactor and update - @a740g
  

             Added _FILES$ to read file and directory names programmatically.
             Added _FULLPATH$ to get an absolute or full path name for a specified relative path name.
             _DIR$ now works as expected on Linux & macOS.
             FILES now works on Linux & macOS. 
             KILL now supports deleting files on Linux & macOS using wildcards.

• #421 - Updated MinGW-GCC to v13.2.0 and LLVM-MinGW to v17.0.6 - @a740g
  
• #422 - Updated miniaudio to v0.11.21 - @a740g
  

Bug Fixes

• #420 - Fixed several CONST issues - @SteveMcNeill
  

             Negative &H, &B, and &O numbers will now evaluate to the correct values.
             Type suffixes on numbers will no longer cause CONST to ignore the rest of the expression past the suffix.
                 Ex. 20& + 1 previously caused the + 1 to be ignored, it now evaluates correctly as 21.

**Full Changelog**: v3.8.0...v3.9.0

[NakedApe]

Yee haw, this here Phoenix Edition just keeps gettin' better and better! Thanks, A1 dev team!

[Kernelpanic]

Damn, you guys are good, really good!
If only one could reconcile this with Microsoft and its Visual Basic. That would be more practical than all the NET stuff.
If I lived in the USA, I would simply call MS and ask through to the people who worked with VisualBasic. They're still there, these people. Certainly.

I tried via email, but there is only support etc. Forget it! And I can't call.
1. My English is not good enough for a conversation
2. It's too expensive from Germany.

From America I would ask myself questions until I got an answer: Yes or No.

[mdijkens]

I just notice that serial communication does not work anymore:

Code: (Select All)

Open "COM4:74880,N,8,1,BIN,CS0,DS0,RB8192" For Random As #99

Above statement has always worked up till 3.8.0
With 3.11.0 (and 3.10.0) the program is silently aborted at this line, not responding to 'On Error' around it...

Anyone know what/when this has changed?

[a740g]

I just notice that serial communication does not work anymore:

Code: (Select All)

Open "COM4:74880,N,8,1,BIN,CS0,DS0,RB8192" For Random As #99

Above statement has always worked up till 3.8.0
With 3.11.0 (and 3.10.0) the program is silently aborted at this line, not responding to 'On Error' around it...

Anyone know what/when this has changed?

Thank you for reporting. We are investigating this and might have a solution soon. 

See Pull Request #428 for more updates.

[JRace]

This is the second time in a row that I've taken a day free of online forums (fora?) and have come back to find a new version of PE.
I wasn't expecting a new version so close on the heels of 3.10.0, but it's good to know THIS compiler has an active dev team.


Thumbs up!

[a740g]

I just notice that serial communication does not work anymore:

Code: (Select All)

Open "COM4:74880,N,8,1,BIN,CS0,DS0,RB8192" For Random As #99

Above statement has always worked up till 3.8.0
With 3.11.0 (and 3.10.0) the program is silently aborted at this line, not responding to 'On Error' around it...

Anyone know what/when this has changed?

This is fixed!

The next release will have the fix included.

Thanks!

[mdijkens]

I've been playing a bit more with hex values

Code: (Select All)

Print &hFFFF
Print &hFFFFFFFF

Both print -1 now

But 

Code: (Select All)

Print Val("&hFFFF")
Print Val(&hFFFFFFFF")

Still print 65536 and 4294967295

While QBX (7.1, I don't have QB 4.5 anymore) prints -1 and -1

[TerryRitchie]

I've been playing a bit more with hex values

Code: (Select All)

Print &hFFFF
Print &hFFFFFFFF

Both print -1 now

But 

Code: (Select All)

Print Val("&hFFFF")
Print Val(&hFFFFFFFF")

Still print 65536 and 4294967295

While QBX (7.1, I don't have QB 4.5 anymore) prints -1 and -1

QB 4.5 prints both as -1.

[SMcNeill]

The issue here is that QB64 doesn't have one central place where it calculates &H, &B, and &O values for us.  The functionality for those functions was apparently added in piece by piece as various other commands came into being.

CONST has a separate &H handler.
VAL has a separate &H handler.
DATA has a separate &H handler.
Normal variable evaluations have a separate &H handler.
(other things probably do as well, but my brain isn't listing them all for me at the moment).

And some of these places return signed values, and some return unsigned values, and it's all just a mess.  (Heck, for that much, what these various things return to us has changed inconsistently over the various versions.  QB64-SDL and shortly after returned unsigned values with CONST.  Then sometime after, it swapped to signed values.  3.10 reverted us back to unsigned values, as I posted on, thinking it'd always been that way.  3.11 has reverted that back to signed...)

And now that we're noticing the issue, it's a real headache to sort out what to do about it.   There's a LOT of code affected, in a lot of different places.  Do we go in and tweak them all, one by one, to make them QB45 compatible?  Or do we whistle innocently and leave them so they remain QB64-compatible?  

QB64 has now been around as long as QB45 ever was, and that now leads us to a condundrum:  Do we now go in and change these issues now that we've finally noticed them, thereby breaking any QB64 program which relies on them with their current quirky behavior?  Or do we leave them alone so folks program will continue to run like always, without them having to go back and rewrite their QB64 stuff once again?

At the moment, we've decided to just leave things be.  Nobody has really been reporting issues with the current behavior.  Nobody is really clammering for a fix to maintain 100% compatibility.  There's a LOT of code which would need to be changed to make everything behave universally the same, and there honestly appears to be very little demand from the user base, wanting us to invest the time and manpower into working on the &H, &B, &O stuff.

---

For now, folks should just make a note somewhere in the back of their brains that says, "QB45 &H, &B, &O may not be 100% compatible in all cases.  The values returned may be unsigned instead of signed, so if I ever compile 40-year old code, then I should keep that in mind in case any issues arise."

---

Biggest takeaway I think folks should take from all this is:  &H, &B, &O values should always have an ending suffix to be 100% certain to never have any issues with them in your code.