Announcing QB64 Phoenix Edition v0.7.1 Release!

[admin]

Release v0.7.1 - QB64 Phoenix Edition/QB64pe (github.com)

• If a .bas file had a space in the name, it would not compile properly.
  
• When multiple instances of the IDE were used, the second instance would not always recompile the program after changes are made.
  
• The symbol file was fixed to work correctly even when the EXE variable provided to the Makefile includes a path.
  
• The version number was fixed to correctly reflect the release version.
  
• Fix to windows setup_win.bat cleaning up the mingw compilers after installation.
  
• Fix to IDE freeze occurring due to invalid line endings coming from git.
  
• Fix to Run Only not deleting the temporary executable on some distros of Linux.
  
• Fix to _DESKTOPWIDTH and _DESKTOPHEIGHT. They no longer require a valid window handle to generate a proper response.
  

Enhancements:

• IDE wiki parser has been enhanced and replaced for more versatile and professional looking pages inside Help.
  
• Creation of a new MakeFile system.
  

Release v0.6.0 Notes

• Add "Run Only" option to IDE menu.
  
• Swap out PNG library for modern version -- we now load PNG files about 30% faster.
  
• Fix to page width with variable width fonts.
  
• _Bin$ added to the language. (see wiki for more information)
  
• Removed/Replaced several more links which were pointing to the old qb64.org sites and forums.
  
• Using the number-based $VERSIONINFO flags will now also set the string versions of those flags, if values for them are not provided.
  

Release v0.5.0 Notes

Another step forward in making our first version "1.0" as the new team working on QB64. This release (version 0.5) now:

• Has swapped out the mingw compilers to updated versions for Windows users.
  
• Reduced the size of the repo considerably for those who wish to download direct and setup QB64 manually, for whatever reason.
  
• Prepacked Linux and max versions of QB64, which come in at less than 10MB each now.
  
• We've swapped out all the references to the now defunct .net and .org sites that we could find, and replaced them to proper, working links which now connect to our new wiki, forum, and all at qb64phoenix.com.
  
• $Color:0 and $Color:32 has now been tweaked to work with $NoPrefix. Color names will remain the same in all cases, if $Color is used without $NoPrefix. When $Color is used in conjunction with $NoPrefix, the colors of Red, Green, and Blue which would normally conflict with the now underscoreless commands of _Red, _Green, _Blue, have been altered to have NP_appended to them (for No Prefix). Example: Color NP_Red, Orange for a red on orange color.
  

Click on the big title above to go directly to the release page and grab yourself a copy of the latest version for all your QB64 needs!

[SMcNeill]

One thing you can all have fun and giggle at poor ole Steve over... I forgot to update the version number in the IDE, so if you click the About, it'll still show you a version 0.6.0. This hardly seemed like a game breaker, or any reason to kill the build process and sort over, so everyone is welcome to GPL (Giggle, Point, and Laugh) at me over upgrading 0.6.0 to 0.6.0... LOL!

I'll sort this automated build stuff out yet, unless it kills me first!

[bplus]

What is Creation of a new MakeFile System?

[SMcNeill]

What is Creation of a new MakeFile System?

For an explanation of what a makefile system is, read up on the basic tutorial here on them: Makefile - Quick Guide (tutorialspoint.com)

As Matt mentioned in his previous post on the forums here: ""the change itself replaces all the scattered build logic with a single Makefile - this will make it much easier to make improvements to QB64 in the future, but it should not have any real user-facing changes, QB64 should appear to work pretty much exactly as it did before."

He's promised he's going to write up a nice explanation of the new makefile setup and all the options and such with it, so I'll leave it to him for the detailed breakdown about how and what everything is doing with the changes here. 

[Coolman]

i haven't had time to examine the new makefile yet. has the -O2 compiler option been enabled to speed up qb64 and the generated programs. from the tests i've done, qb64 is basically unoptimized because it doesn't use the gcc or g++ optimization flags. i find this surprising. a global variable at the beginning of the makefile to specify -O2 or -O3 would be very useful.

[DSMan195276]

1. Documentation on the new build system is here, along with a bunch of other general information on the repository and how it gets built.
2. I've been working on a new dialog for setting the C++ compiler settings, I just merged it so it should be available in the next version of QB64. A screenshot of the dialog is below, the 'Compile program with C++ optimization flag' setting will use

-O2

(We'll work our way up to

-O3

, I'm still a little skeptical of

-O2

as it is The setting is off by default for now):


./setup_lnx.sh does not currently set it (which I think you'll want to do) but you can use the

EXTRA_CXXFLAGS

to provide it, as documented in the build system documentation.

Edit: Also note, I discovered a bug in

0.7.1

that the

Makefile

does not respect

EXTRA_CXXFLAGS

, sorry about that. The issue is already fixed in

main

and will be addressed in the next release. If you don't want to wait you could grab the latest

main

build to try it out.

[Coolman]

*** Documentation on the new build system is here, along with a bunch of other general information on the repository and how it gets built.

thank you very much @DSMan195276

*** I've been working on a new dialog for setting the C++ compiler settings

very good idea. it will let the choice to optimize or not (for those who are skeptical) the compilation of programs...

*** Also note, I discovered a bug in

0.7.1

that the

Makefile

does not respect

EXTRA_CXXFLAGS

I will wait. Thanks again for your efforts.

[DSMan195276]

FWIW I 100% agree we with using

-O2

or

-O3

, we should have been doing so from the very beginning. Unfortunately though I've already seen more than a few questionable practices in

libqb.cpp

that I'm surprised currently work and could easily get broken by optimizations that will be done, so I think some more testing and likely fixing of

libqb.cpp

is necessary before we turn it on by default. Eventually I would like us to get there though, to the point where offering a checkbox to turn it off isn't necessary.

[Coolman]

it's true that if the author of qb64 didn't activate these optimizations options, you have to wonder about the reason. maybe he tried and found some anomalies. in my tests of both versions, i didn't see any visible problem but i'm not the designer and i didn't really examine thoroughly the source code of qb64. the only thing i noticed is that the programs are much faster in graphical commands, computations, sorting algorithms, string manipulations. ... the speed gain is so important that I decided to take the risk. I appreciate the speed of development with qb64. I intend to use it for console programs in bash scripts for personal use. for this kind of processing, speed is essential. that said, you are right. it would be necessary to make thorough tests before activating by default these optimization options.