QB64 Phoenix Edition v3.2.0 Released!

[Fifi]

Hi Coolman,
Thank you for your post.

under linux the script setup_lnx.sh does the job. i modify it slightly to optimize the generation of the executable and i remove some sections. it's done quickly. it takes me a few minutes to compile everything. too frequent changes waste a lot of readaptation time. i think it's better to keep the script as is. that said nothing prevents to put another script to let the choice to the users.

You're right, the old setup_lnx.sh script does the job.
Fortunately should I add.
However, this script isn't multi lingual and doesn't install InForm that, for me (and a lot of other users), is a mandatory QB64PE addon like was vWATCH64 that Fellippe Heitor offered to be integrated in QB64.
This old fashioned script doesn't allow you to uninstall QB64PE or even to make a backup of your work before reinstalling or uninstalling your preferred programming language.
So, I don't critic the Matt Kilgore's work.
I never did, nor ever will.
I just propose a second way, more user friendly, powerful and versatile.
So, as you said, why not have the two install scripts in the package and let  the choice to use the one or the other?
Just my two cents.
Cheers.
Fifi
Note: I'm even thinking to a graphical install executable in the future if I've time and can ever do it with InForm-pe.
PS: Why the Matt's name mention was removed from the setup_lnx.sh file? This is not fair for him even f it's a tiny bash file! .

[DSMan195276]

PS: Why the Matt's name mention was removed from the setup_lnx.sh file? This is not fair for him even f it's a tiny bash file! .

I don't have time to respond to everything at the moment (I'll write a proper response later), but just to clarify, I'm Matt And I took my name out, I made some changes and it didn't seem necessary to keep.

[Kernelpanic]

What bothers me a bit is that when you start QB64, write something, and then want to save it as a program, you always start in the QB64pe installation directory; see the screenshot. This applies to all versions.

Could this be changed to:
1. Start in the last directory in that was saved - or
2. One can specify the default directory, like this: D:\lab\QuickBasic64

[bplus]

+1 Would be nice to spec a startup directory, specially with all these new versions of QB64 coming ;-))
My current QB64 folder is over 11,000 files and would be nice not to have to navigate to it for access. It would save a couple of clicks.

[Fifi]

Hi Kernelpanic.

What bothers me a bit is that when you start QB64, write something, and then want to save it as a program, you always start in the QB64pe installation directory; see the screenshot. This applies to all versions.
Could this be changed to:
1. Start in the last directory in that was saved - or
2. One can specify the default directory, like this: D:\lab\QuickBasic64

This is the "Run as" and "Make executable only as" I suggested in my post.
However, +1 also for your two proposals that would be good too.
Cheers.
Fifi

[Fifi]

Hi Matt,

Thank you for your post.

PS: Why the Matt's name mention was removed from the setup_lnx.sh file? This is not fair for him even f it's a tiny bash file! .

I don't have time to respond to everything at the moment (I'll write a proper response later), but just to clarify, I'm Matt And I took my name out, I made some changes and it didn't seem necessary to keep.

I didn't know you (DSMan195276) were Matt.
So, I was only defending your work and copyright.
But if you removed your name yourself, that's fine with me.

Looking forward for your other points later.

Cheers.
Fifi

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

[mnrvovrfc]

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.

"bz2" is even less supported than 7-zip, which could be a PITA on Linux if "p7zip" wasn't pre-installed with distro. "7z" is used for Windows package because that is already approaching 100MB with no easy way to cut it down. A lot was already taken away from MinGW, and even more functionality (such as device and language support) would have to be taken away that wouldn't please a lot of people. I suppose an archive could be made available which uses M$ Visual Studio's C++ compiler instead of "g++" but for the people willing to waste time and disk space with that programming system. Inventing that archive would have its own complications. ZIP is like WAV, widely supported and that's why it exists at all. ZIP is inherently very inefficient, a format carried way beyond its prime, it wasn't designed for files much larger than 10MB. So 7-Zip was created which retains some legacy features. What a shame RAR is closed source, but as of v5 the author might have been more interested in retaining the commercial customers: the recovery record could actually produce a larger RAR than v4 did!

If you are on Linux don't bother with "unrar-free" because it hasn't been updated in a really long time and cannot handle many RAR files. Definitely it cannot handle any RAR created by WinRAR v4 or later. I'm saying this because it's possible that "utility" is set as dependency of "winetricks".

I don't know nor care what is going on with Windows beyond Windows10 but M$ need to get out of their arse already, at least support "7z" for reading without requiring 7-Zip or WinRAR installed. Either that or support "tar.gz" or something like that without forcing the user to go into WSL or something else. There are a few other things that File Explorer can't do which cause it to lag behind "dolphin" for KDE Plasma which irritates me for other reasons (animations for starters).

EDIT: "latest", no thank you I'd rather know what is this "latest" version/release. "Latest" could be taken literally by somebody who uses "archive-dot-org" to obtain such a ZIP file because he/she could do so. A "latest" could be hosted on somebody else's server and left there for a long time for download, and there are just too many of those bad people to compete with.

[mnrvovrfc]

This old fashioned script doesn't allow you to uninstall QB64PE or even to make a backup of your work before reinstalling or uninstalling your preferred programming language.

The problem is that I might have a different way of working than you do, and we are different from a third person, and so on. I don't know where you save your BAS files and include files and stuff like that, and if you retain executable files created by QB64 and where. Otherwise, backing up involves saving "internal" folder contents except "c" and "help" members, and it includes "config.ini" which is for the IDE. It gets a bit more complicated if you're also interested in retaining the "a" and "o" extension files that are in "internal/c". Even more complicated if you ever needed to modify "libqb.cpp" like I had to on Solus because "zenity" instead of "xmessage" was available to display runtime error dialog boxes, or had to modify any source code portion including "QB64.BAS".

Reinstalling and uninstalling is left entirely to the user especially on Windows because he/she might want to keep multiple version/releases around. They are willing to spend the extra disk space. Might still like the old buggy SDL version 0.954 for simple arcade games. A few people are still using Steve's modification of that one too. There might be a reason to put in the "dot-com" version. Meanwhile the latest "Phoenix Edition" could be kept around while the user becomes acclimated to the present and future. It's less desireable for me to do this on Linux, but I don't have to worry about taking away C/C++ compiler when I want to reinstall QB64PE.

[SpriggsySpriggs]

Personally, I'm glad the setup_win.bat script doesn't uninstall or delete anything. I know how to prepare my folders for a new version and wouldn't want that to be automated.