Announcing QB64 Phoenix Edition v0.8.2 Release!

[Fifi]

Hello all,

Would it be possible to have somewhere on this forum a simple button that refers to the "latest stable version" with always the same name such as "qb64_lnx_stable", "qb64_osx_stable" and "qb64_win_stable" without any other numbering as well as a another simple button that links to the latest development version such as "qb64_lnx_dev", "qb64_osx_dev" and "qb64_win_dev" once again without any numbering.

This would allow external scripts to download releases like the one I did for QB64, InForm and vWATCH64 on Linux where the latest stable version was always in the same place and always with the same name without having to (as I have fact) to modify the script for each new version.

With github, the names and the places (the links) were changed for every new release.

That's why I ended up hosting the latest files on my own personal web server, which wasn't always up to date if I didn't follow the news every day.

If you can, I'll be happy to re-offer my multilingual (6 languages) install (and uninstall) bash script for qb64phoenix on Linux.

Looking forward.

TIA.

Cheers.
Fifi

[DSMan195276]

Good news and bad news:

The good news is that GitHub does actually have a

releases/latest

endpoint, so you can use that to get the latest version. The bad news is that I recently changed the asset names to include the version number (so it's easy to tell what you're downloading, and also so that the different versions don't conflict when downloaded) so they're no longer predictable for you and mostly leaves you back where you were.

If you're a bit adventurous there is a GitHub API that can give you the information you need, try hitting

https://api.github.com/repos/QB64-Phoeni...ses/latest

and you'll get back JSON that includes both the tag name (indicating the version) and also the individual assets with their names and download links (so you can look for the

qb64_lnx*.tar.gz

asset and download it via the associated link). If you're willing to use

jq

in your script then I think this is a pretty viable approach as all the information is right there. If you don't want to use

jq

then you could still do it, but you'll have to resort to some ugly text parsing to get the information you need.

We probably could also push the release artifacts somewhere else with a stable name like you're suggesting, however I can't make any expectations that it would be setup soon, so if possible I'd recommend just getting the necessary information from GitHub instead. Still I think it's a reasonable idea, and certainly doable.

For development versions things are a lot messier. We don't have a development/stable distinction with QB64 PE, there's just a stable branch, and ideally the latest release shouldn't be that far behind where that branch is. You can however make use of the CI builds made off of the

main

branch, and you can probably get those via the API but I'm not really sure how. The CI artifacts are also not the same thing as a release, they're a zip file that actually contains the release artifact inside (along with some other build information). So long story short I'm not sure it's worth worrying about dev versions at the moment.

[bert22306]

For whatever it's worth, I think it's important to know what version we are downloading, before we begin downloading. With a stable name, how would that be (reliably, consistently) possible?

Depending what antivirus is used in the PC, extracting the files from the .7z file can be a relatively slow process. And for those with slow Internet access, the download can also be a bit laborious. I'm happy with the way you've set it up in github now, actually.

[doppler]

Quickie.

Would there be an advantage to compile QB64 source using -Ofast or -Os just for speed or size.  I see by test times posted, Ofast or Os would be better.  But is it better for QB64 source ?  The IDE, and compiler (bas) output parts.  Is the real question.  If it's only a second or two, there is no advantage.

Thoughts ?

[DSMan195276]

For whatever it's worth, I think it's important to know what version we are downloading, before we begin downloading. With a stable name, how would that be (reliably, consistently) possible?

Yes I largely agree, that's why I added the version into the name Maybe for a stable download link we could have it redirect to the correct location? Then you could still get the correct version in the name of the downloaded file. I haven't really thought about it though, I wouldn't say it's in the plans at the moment just given everything thing else to do xD

Would there be an advantage to compile QB64 source using -Ofast or -Os just for speed or size.  I see by test times posted, Ofast or Os would be better.  But is it better for QB64 source ?  The IDE, and compiler (bas) output parts.  Is the real question.  If it's only a second or two, there is no advantage.

"Advantage" is subjective, so somewhat hard to say. I would not use

-Ofast

because it introduces optimizations that break the standard, but functionally

-O3

would do basically the same optimizations anyway so you could use that. I would say, the time and resources it takes to compile with those settings is a significant problem, on Windows it can take 10+ minutes and many GBs of RAM. That said people (including me) have done it, and others have reported significant speed-up with the IDE (which I would expect), so perhaps that's worth it.

The other aspect I've mentioned before is that stability using any of the

-O

levels is not all that clear at the moment, so I'm hesitant to use it for release builds without more investigation.

[doppler]

The other aspect I've mentioned before is that stability using any of the

-O

levels is not all that clear at the moment, so I'm hesitant to use it for release builds without more investigation.

Every child knows, "Results will vary." "Batteries not included."

Personally I would try a "-O" something on just QB64 source.  Never every "Using bleeding edge tech." on formal release's.  At least till the edge matures, and doesn't cut badly.

[Fifi]

Hello all.

Sorry for this dumb question but I'm not familiar with make and its makefile nor the gcc configuration file.

So, may I ask in what part of the makefile or of the config.ini file (or elsewhere) can I play with different -O options just to test different results.

Little "glitch" on Linux: when using the setup_lnx.sh script, once the compilation starts, the makefile throws an error from line 6: $(error "OS must be set to 'lnx', 'win', or 'osx'").

Is this test really mandatory since the setup_lnx.sh script sets the OS to "lnx" in line 113: "make OS=lnx BUILD_QB64=y -j3" ?

TIA.
Fifi

[DSMan195276]

For the

OS

thing, there's a GitHub issue about it, it's not all that serious because it's just the 'clean' call, but you do need to supply the

OS

variable every time you call the Makefile.

https://github.com/QB64-Phoenix-Edition/.../issues/89

The easiest way to try different compiler settings is via the new dialog. Checking the 'compile with C++ optimizations' box will automatically add

-O2

, or you can drop a different setting into the 'extra C++ compiler settings text box.

[Fantomas]

Hi,



When i use QB64PE v 0.82 i have regulary this error message (see below). Then i need quit QBPE and restart it...:
After this error, it cames back for each character i type on keyboard

[DSMan195276]

When i use QB64PE v 0.82 i have regulary this error message (see below). Then i need quit QBPE and restart it...:
After this error, it cames back for each character i type on keyboard

This is a good find, I believe the issue is that

./internal/temp/undo2.bin

is getting deleted while QB64pe is running and that then crashes the IDE. So two thoughts:

1. It probably shouldn't be getting deleted. I suspect you might be triggering a "clean" to happen (There are a few things in the IDE that can do this) which I think is clearing out a bit too many files from

./internal/temp

, including

undo2.bin

.

2. QB64pe should be able to handle this file getting deleted, it needs more error handling around it not existing since this file is not really critical to keeping the IDE functional.