QB64 Phoenix Edition v3.2.0 Released!

[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