QB64 Phoenix Edition v3.2.0 Released!

[DSMan195276]

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.

If you can get the line number from the error the next time it happens that would be very useful. Certainly I'll keep a look out but I wasn't able to recreate it when I tried

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.

In regards to GitHub issues, I'm just asking if you can make issues here for these feature requests you've listed. That's where we keep track of requested changes and also the best place to make them, things tend to get lost on the forum.

And I understand what you're getting at, we've (me, Steve, and some others) talked about offering a consistent link to the latest link and looked into it a bit. GitHub is a little annoying for not offering an easy way to make it, and pushing the releases somewhere else is a bit more complicated to setup. Certainly it is something we want to do though.

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?

The command is

-h

It looks like your helper script eats the

-h

flag and prints out a custom help, so you would need to skip that script to see the actual help with all the documented switches (perhaps when you wrote the script QB64 lacked a help dialog? That wouldn't surprise me).

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

I'm ready to discuss all your requests.

Probably the best starting point would be to just work on getting all the files used by your installer into a GitHub repo. If it would be distributed with the regular Linux releases then it would go somewhere in the main repo. If it would be distributed separate (and download the latest release as you're doing now) then we could make a separate repo for it in the

QB64-Phoenix-Edition

organization. But either way, the idea is to get all the files into a git repo so they can be maintained there, and also having them in a git repo would make it easier for us to get a better idea of how your installer works and what if any changes might make sense.

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

Yep, all that is understandable, it's basically the same issues/concerns we've had when talking about it. That said, I do think there's some very clear benefits because a packaged version could come precompiled, which would give significant speed-ups on first use and also solve some of the problems related to the directory permissions necessary for QB64-PE. Also, ideally once we've solved a lot of the existing problems it shouldn't really be necessary to worry about 'where' QB64-PE is installed - certainly you don't worry about where

gcc

is installed, it just works I think the end goal is that, but it's a ways away.