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.
     

• #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
  

• 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).

• 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.
  

• 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.
  

• 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?
  

(09-13-2022, 01:43 AM)Fifi Wrote:

• 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?
  

-f

-f

-f

-f

-q

(09-13-2022, 02:01 AM)bert22306 Wrote: 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! 

(09-13-2022, 05:27 AM)DSMan195276 Wrote: :
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).

(09-13-2022, 05:27 AM)DSMan195276 Wrote: 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).

(09-13-2022, 05:27 AM)DSMan195276 Wrote: 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?

(09-13-2022, 05:27 AM)DSMan195276 Wrote: 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.

(09-13-2022, 05:27 AM)DSMan195276 Wrote: Also I would try the existing

-q

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

(09-13-2022, 05:27 AM)DSMan195276 Wrote: In regards to your installer, it's possible but we would need to talk about it.

(09-13-2022, 05:27 AM)DSMan195276 Wrote: 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

(09-13-2022, 05:27 AM)DSMan195276 Wrote: and also provide other helper scripts and such (which is not a bad thing! but still a major change).

(09-13-2022, 05:27 AM)DSMan195276 Wrote: 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).