QB64 Phoenix Edition v3.2.0 Released!

[DSMan195276]

QB64 Phoenix Edition v3.2.0!
https://github.com/QB64-Phoenix-Edition/...tag/v3.2.0

Enhancements

1. #21, #164 - The $Unstable command was added - @mkilgore
   • $Unstable allows usage of language features that are not yet finalized.
     
   • Features hidden behind $Unstable may have breaking change in new releases, unlike regular parts of the language which do not have breaking changes in new releases.
     
2. #155, #164 - Added MIDI support to

   _SNDOPEN

   - @a740g, @mkilgore
   • MIDI support is current unstable, and hidden behind $Unstable:Midi.
     
   • MIDI is enabled by using the $MidiSoundFont metacommand to specify a soundfont for playing MIDI files.
     
   • The selected soundfont is compiled into your program, so the file does not need to be present at runtime.
     
3. #162, #164 - Compiler settings can be supplied on the command line - @mkilgore
   • QB64-PE now accepts the

     -f

     flag for supplying settings accessible in the

     Compiler Settings

     menu.
     
   • Settings are only applied for that run of QB64-PE (they do not modify the preserved IDE settings)
     
   • Using

     -f

     with no flag will print all of the available options.
     

Bug Fixes

• #161 - Fixed _MOUSEMOVE when window is resized - @mkilgore
  
• #165 - Fixed compiling source files that have a

  '

  in their name - @mkilgore
  
• #169, #171 - Fixed

  _SNDOPEN

  to return zero on failures. - @a740g
  
• #170, #171 - Fixed

  PLAY "MB"

  so that it also causes

  SOUND

  commands to play in the background - @a740g
  

Full Changelog: https://github.com/QB64-Phoenix-Edition/...0...v3.2.0

[Pete]

Looks like this release is full of "SOUND" improvements, congrats to the developers. One issue, Matt. FreeBASIC called... and their horse logo wants its $UNSTABLE back.

Pete

[Kernelpanic]

What a pace! It's starting to get scary. 

Is also included Pete's math super routine for pi with a million digits after the decimal point? 

[bplus]

Thanks to all involved, the project seems as alive as ever!

[Fifi]

Hello all.


News: Very good, good, bad and requests.


Very good:

• The new release 3.2.0 of QB64PE.Thousands of thanks to the development team for all the improvements.
  
• My new multi tongues installation script for Linux is available for QB64PE 3.2.0.
  Not only you can install (and safely uninstall) QB64PE v 3.2.0 but also a forked version of InForm v 1.3 (the latest) that I've adapted to work with QB64PE and that I've named InForm-pe.
  More, now when you uninstall (or reinstall) QB64PE and InForm-pe, the script allows to make an automatic backup of your current installation.
  The script still proposes to create starters on your desktop as well as entries in the application menu.And like before, you can invoke both QB64PE and InForm from any terminal session without being obliged to be into the QB64PE folder (just as you do with GCC or any standard compiler).

Good:

• The script is now available in six languages (by default English, but also French, German, Italian, Russian and Portuguese) accordingly to you system language and will soon propose other tongues.
  

Bad:

• I've been able to reproduce several times a blocking problem that freezes the IDE. Then, I've to kill the QB64PE process and QB64PE can't even be restarted unless you clean the /internal/temp folder. I'll give more details on another dedicated message.
  
• The new -f switch kills the original -f switch that was used to load a file in the IDE (please see the original qb64.sh (now /usr/bin/qb64pe.sh or simply run qb64pe -h) prior to create new switch.
  

Requests:

• Due to the speed of new releases, is it possible to display the release version (currently 3.2.0) into the IDE title bar?
  
• In the "Run" menu of the IDE, would it be possible to add an option "Run as" and a second option "Make executable only as" (to simulate the -o switch)?
  
• When using the -x switch, would it be possible to have a complete silent output for example by adding a -n switch (for no blabla)? Then the return codes of the compilation process could be 0 if the compilation failed and 1 if the compilation was successful?
  
• For both Linux and macOS, would it be possible to compress  the project with the .tar.bz2 option Vs the .tar.gz. There is a gain of 20 % in size. And the size matters LoL
  
• Would it be possible to have a fixed place on GitHub where should always be posted the latest QB64PE release without any numbering version such as "QB64PE_latest-lnx.tar.bz2" and "QB64PE_latest-osx.tar.bz"? This is not in contradiction of the current way but a simple request that would avoid for me to store the package on my own web sever at home since i've a low bandwith.
  
• Finally, could my installation script become the standard installation script included in the QB64PE package? If not, why?
  

I'm looking for making a similar installation script for macOS and I'll let you know when it will be ready.



To download my installation script (that is more sexy than the old current one), please go to my dedicated web page: www.l7d.ddns.net.


TIA for your return, critics and suggestions.


Cheers.


Fifi

[bert22306]

All looks good from here. Please, guys, don't burn out!! These rapid updates make me nervous. We've had enough teams burning out already! 

[DSMan195276]

• I've been able to reproduce several times a blocking problem that freezes the IDE. Then, I've to kill the QB64PE process and QB64PE can't even be restarted unless you clean the /internal/temp folder. I'll give more details on another dedicated message.
  
• The new -f switch kills the original -f switch that was used to load a file in the IDE (please see the original qb64.sh (now /usr/bin/qb64pe.sh or simply run qb64pe -h) prior to create new switch.
  

Requests:

• Due to the speed of new releases, is it possible to display the release version (currently 3.2.0) into the IDE title bar?
  
• In the "Run" menu of the IDE, would it be possible to add an option "Run as" and a second option "Make executable only as" (to simulate the -o switch)?
  
• When using the -x switch, would it be possible to have a complete silent output for example by adding a -n switch (for no blabla)? Then the return codes of the compilation process could be 0 if the compilation failed and 1 if the compilation was successful?
  
• For both Linux and macOS, would it be possible to compress  the project with the .tar.bz2 option Vs the .tar.gz. There is a gain of 20 % in size. And the size matters LoL
  
• Would it be possible to have a fixed place on GitHub where should always be posted the latest QB64PE release without any numbering version such as "QB64PE_latest-lnx.tar.bz2" and "QB64PE_latest-osx.tar.bz"? This is not in contradiction of the current way but a simple request that would avoid for me to store the package on my own web sever at home since i've a low bandwith.
  
• Finally, could my installation script become the standard installation script included in the QB64PE package? If not, why?
  

In regards to the blocking issue, yes please write a clarification of it somewhere. We resolved one such issue a few months ago, I wasn't aware there was another (or that the original wasn't resolved for you).

For the

-f

switch, can you clarify, you're saying QB64-PE itself already had an

-f

switch? I just checked to be sure and the older QB64PE versions do not support an

-f

flag, the behavior you're talking about works by just passing a filename with no flag. We didn't remove an

-f

flag in QB64PE, so perhaps the flag was removed in some older version of QB64?

All your requests seem pretty reasonable  I'd ask that you make GitHub issues for them if you can, that's the best way to make sure they don't get lost. Also I would try the existing

-q

switch for quiet output, I believe it will give you what you're looking for.

In regards to your installer, it's possible but we would need to talk about it. I'm not particularly tied to the existing install script, but switching to yours would be a fairly major change in how QB64-PE installs on Linux since you place things in global directories and also provide other helper scripts and such (which is not a bad thing! but still a major change). Personally I'd rather just look at creating proper packages for the more popular distributions rather than more complicated install scripts, but I also think proper packages are a long way out so perhaps your install script could be a reasonable in-between (potentially offered along side the existing one).

All looks good from here. Please, guys, don't burn out!! These rapid updates make me nervous. We've had enough teams burning out already! 

I wouldn't worry too much about that personally Honestly the release schedule makes things easier, no reason to rush stuff if it can just go in a release next week. I also wouldn't expect new features every week, that wasn't and isn't the goal. Things get done when they get done

[mnrvovrfc]

:
In regards to your installer, it's possible but we would need to talk about it. I'm not particularly tied to the existing install script, but switching to yours would be a fairly major change in how QB64-PE installs on Linux since you place things in global directories and also provide other helper scripts and such (which is not a bad thing! but still a major change). Personally I'd rather just look at creating proper packages for the more popular distributions rather than more complicated install scripts, but I also think proper packages are a long way out so perhaps your install script could be a reasonable in-between (potentially offered along side the existing one).

If this has to do with "setup_lnx.sh" then I wouldn't wish to have it changed. Maybe except the command lines that write heavy on the terminal. It's good to see some commands seen of what is being done to build QB64 on Linux, but some people might like to have it muted. Otherwise, the "setup_lnx.sh" is the best it's ever been IMHO.

[Fifi]

Hi DSman195276,
Thank you very much for your clear and interesting return.

In regards to the blocking issue, yes please write a clarification of it somewhere. We resolved one such issue a few months ago, I wasn't aware there was another (or that the original wasn't resolved for you).

As usual, this one is a vicious. J've been able to reproduce it but not each time. The problem occurs when you load a large source file in the IDE from the command line (e.g. qb4pe /opt/qb64peInForm/UiEditor.bas.), but this is not systematically. When this occurs, the IDE displays an error message of the type "violation in line 11XX" and is frozen. Then, the only way to get out is to close the window via the cross of the title bar of the window. Then, if you try to restart the ide (even without loading a source file), the IDE freeze immediately and infinitely. Then, the only solution to fix his problem is to clean all the files of the /opt/qb64pe/internal/temp but the one with the root information Then, you can restart the IDE without this problem. But as I said, this is not systematic and you may have toe experiment this king of command several times before to reproduce ths problem. I got this problem several times when doing my InForm-pe fork.

For the

-f

switch, can you clarify, you're saying QB64-PE itself already had an

-f

switch? I just checked to be sure and the older QB64PE versions do not support an

-f

flag, the behavior you're talking about works by just passing a filename with no flag. We didn't remove an

-f

flag in QB64PE, so perhaps the flag was removed in some older version of QB64?

I guess you're right. This -f switch was introduced several years ago in my early previous script for QB64 0.98 in the qb64.sh file. I must admit that I don't use this switch very often and just found the conflict yesterday.

All your requests seem pretty reasonable  I'd ask that you make GitHub issues for them if you can, that's the best way to make sure they don't get lost.

I've always been reasonable in all my requests in the past but sometimes it was difficult to be understood (I'm still a native froggy)
With regard to the GitHub request, let me be more precise: Don't modify anything in the current process that creates a new place for each and every new release that is absolutely perfect, but just add a fixed place to store each new release always at the same place and always with the same name, so without any numbering version. I suggest the following simple names:
- https://github.com/QB64-Phoenix-Edition/...st.tar.bz2 for Linux, (please .tar.bz2 Vs .tar.gz for a 20% size gain)
- https://github.com/QB64-Phoenix-Edition/...st.tar.bz2 for macOS, (please .tar.bz2 Vs .tar.gz for a 20% size gain)
- https://github.com/QB64-Phoenix-Edition/...latest.Zip for Windows 32 bit (Please .Zip Vs .7z since 7z is not natively supported on multiple Windows release).
- https://github.com/QB64-Phoenix-Edition/...latest.Zip for Windows 64 bit (Please .Zip Vs .7z since 7z is not natively supported on multiple Windows release).
This would allow my script to download QB64PE automatically from GitHub without being obliged to modify
the script for each new release. This is why I host it on my own server.

Also I would try the existing

-q

switch for quiet output, I believe it will give you what you're looking for.

Yes, the -q switch (I guess for quiet) is exactly what I needed but I didn't know it.
BTW, what is the command to display all the qb64pe switch?

In regards to your installer, it's possible but we would need to talk about it.

I'm ready to discuss all your requests.

I'm not particularly tied to the existing install script, but switching to yours would be a fairly major change in how QB64-PE installs on Linux since you place things in global directories

The next release of my script that I'm already working on will not anymore have a fixed installation folder and will allow you to specify where you want to install the products QB64PE and InForm-pe on your system.

and also provide other helper scripts and such (which is not a bad thing! but still a major change).

No problem, I can remove the helpers as long as QB6PE has its own.

Personally I'd rather just look at creating proper packages for the more popular distributions rather than more complicated install scripts, but I also think proper packages are a long way out so perhaps your install script could be a reasonable in-between (potentially offered along side the existing one).

Creating proper packages is another (long) story and also have its pro and cons, the major last one with packages such as .deb being:
a) their relative inflexibility wit regard to where the product are installed and,
b) the practical incapability for the end user to modify it, which is not the case of a source bash script. (i.e., with my script, if you want to change the location of the installation there is only one variable to modify in the source files).
Note: BTW, creating a package of the type .deb or equivalent for other Linux distributions than Debian/Ubuntu bases requires, from what I know, a fixed place holder on a fixed server (or repository) and a fixed name for the product to install. I've to double check that further but in any case, I doubt this way would be as flexible as my script for example for the choice of the installation location that I will introduce in my next release. Just my two cents.
Looking forward.
Cheers.
Fifi

[Coolman]

under linux the script setup_lnx.sh does the job. i modify it slightly to optimize the generation of the executable and i remove some sections. it's done quickly. it takes me a few minutes to compile everything. too frequent changes waste a lot of readaptation time. i think it's better to keep the script as is. that said nothing prevents to put another script to let the choice to the users.