QB64 Phoenix Edition v3.7.0 Released!

[RhoSigma]

I just updated lesson 2 using the Export As feature:

https://www.qb64tutorial.com/lesson2

So awesome not to have to create code images any longer! Now the tutorial users can copy and paste the code directly from the tutorial pages as well.

I'll get to the rest of the tutorial pages in a few days.

Thank you for keeping the QB64PE updates coming!

Glad it's useful to you and you so quickly adapted to it, that kind of usage is exactly what I had in mind when implementing the export feature. @a740g was also happy to use it when writing/exporting the eamples for the Wiki pages of the new unicode print functions.

[TerryRitchie]

I just updated lesson 2 using the Export As feature:

https://www.qb64tutorial.com/lesson2

So awesome not to have to create code images any longer! Now the tutorial users can copy and paste the code directly from the tutorial pages as well.

I'll get to the rest of the tutorial pages in a few days.

Thank you for keeping the QB64PE updates coming!

Glad it's useful to you and you so quickly adapted to it, that kind of usage is exactly what I had in mind when implementing the export feature. @a740g was also happy to use it when writing/exporting the eamples for the Wiki pages of the new unicode print functions.

I truly appreciate the addition

[bert22306]

Hey, thanks guys!

Speaking of added features, if you recall, back in the days of Galleon's QB64 SDL, he had a feature which allowed updates to be installed upon request, without having to reinstall the whole package. It's probably hard to do this again, with so many people contributing to the project, but I still thought I'd ask.

Any way to add that "update" button somewhere in the IDE, for instance?

[mnrvovrfc]

I know Galleon meant well with it but I prefer the current system of version/release, without "magic buttons". QB64PE has become way more complex than what QB64 was before it hit v1 and Galleon had those auto-updates for a time. Once in a while the Windows user will have to swallow the large pill with "g++" and if it fails, it could render the whole thing unusable and then he/she would have to reinstall completely anyway which could be very off-putting.

With a "magic button" in the IDE like that, asking for support on this forum could get real interesting. "Oh I'm on version 4.1 with ten updates but refuse to download gee-plus-plus because it's too hard. My Internet is too slow and don't need it." Because I have already seen a reply much alike on another forum before for a development project like this.

The "magic button" isn't going to persuade people that stubbornly keep the "dot-rip" v2.0.2 and there are plenty of them lurking on these forums which is really a shame. There are many others who have even older version/releases of QB64, afraid to try new things that might break.

An "update upon request" feature could mean in disguise a way to design a "standard" Windows installer so that it chooses where to install for the user, which is energetically rejected by many users. But it could be the only way to ensure that things are in an expected place so the updates don't break the whole system easily. Already we are making huge gains by creating programs and relating to libraries without needing to refer to the "home" QB64 directory so much.

I admit I wish this project didn't rely so much on Github repositories. That site gives me the creeps. It has become a different jungle of confusion and incompleteness from Sourceforge.

[a740g]

I just updated lesson 2 using the Export As feature:

https://www.qb64tutorial.com/lesson2

So awesome not to have to create code images any longer! Now the tutorial users can copy and paste the code directly from the tutorial pages as well.

I'll get to the rest of the tutorial pages in a few days.

Thank you for keeping the QB64PE updates coming!

Glad it's useful to you and you so quickly adapted to it, that kind of usage is exactly what I had in mind when implementing the export feature. @a740g was also happy to use it when writing/exporting the eamples for the Wiki pages of the new unicode print functions.

I truly appreciate the addition

Yeah. Me too. It was so much easier writing and pasting those examples in the wiki. 

[Kernelpanic]

Hey, thanks guys!

Speaking of added features, if you recall, back in the days of Galleon's QB64 SDL, he had a feature which allowed updates to be installed upon request, without having to reinstall the whole package. It's probably hard to do this again, with so many people contributing to the project, but I still thought I'd ask.

Any way to add that "update" button somewhere in the IDE, for instance?

An update function would be far too complicated compared to the (possible) benefit. The complete new installation is no problem with QB64:
Download: 2 minutes
Move to "Unzip" folder, unzip and move QB64pe to D:\Programs: 2 minutes
Rename the old version to alt-QB64...: 5 seconds
Copy the IDE settings from the old config to the new one: 2 minutes
Create a shortcut of the new QB64pe.exe on the desktop and rename it: 1 minute

Total time (rounded up): 10 minutes maximum. An update doesn't go faster either, and you don't have any problems. I've had enough problems with updates over the years.

[grymmjack]

THANK YOU!

[DSMan195276]

In regards to updates, personally I like the idea of having some kind of updater, but I haven't spent any time on it. IMO there's benefits to it since while it's "easy" to upgrade if you know what you're doing, new users frequently do something 'wrong' and then break their existing install (and when that happens, the errors tend to be very confusing). Providing some kind of updater simply takes out all the guess work and makes it easier for us to ensure everyone's on a good copy. Ultimately, anything that lets us spend less time troubleshooting and more time fixing bugs is a good thing

Also, how you go about "copying your config" isn't well defined. The config file structure may not stay the same in the future, and then suddenly nobody will know how to do a proper update. I think we'll certainly try to avoid that because people rely on it, but I don't know what the future holds and nothing in `./internal/` is guaranteed to stay the same across releases.

[Kernelpanic]

Also, how you go about "copying your config" isn't well defined. 

I was a little imprecise there. Copying the old config file means:
[IDE COLOR SETTINGS 1] and a compiler setting:
[COMPILER SETTINGS]  ExtraLinkerFlags=-Wl,--stack,26777216

[mnrvovrfc]

Keep both "config.ini" files around and use Meld. (shrugs)

That's a program that came with EndeavourOS that I used to be ignorant about its value.

But only in that case, it could be possible to write a QB64 program that could synchronize a "master" config file. It would take extra work for most people.

The thing is that more than once, I just unpacked the entire contents of the TAR.GZ into the place where I installed QB64PE earlier, and chose "Overwrite everything" without thinking about it. So I lost a few settings for "config.ini", had to fumble in the IDE again because of it. That's why I use another code editor wherever I can.

---

I didn't want to make anybody mad here with my comments. Probably get mad at what I'm going to write here instead. But this "update button" could have some consequences. Such as going to update the program without sitting down deeply to use it. Take it from me, I have installed many Linux distributions. Especially the ones based on Arch are going many days without being used. Usually the next time I go into one of them, it's to update it. It's a personality flaw that I have. :/

I have downloaded Audacity AppImage many times, about 50MiB a pop. For each point release they put out, I used the program maybe four or five times? Maybe more times for one point release than others. And this has been so far from v3.2.1 to v3.3.1 inclusive. I just noticed there is a v3.3.2 that I need to download.

Also think about it: do I need _UPRINTSTRING in my program right now? Will I need one of the recently-added statements and functions tomorrow or next week or next month? In a program that computes something like the Hebrew calendar and was designed to give "control breaks" about it like COBOL? A lot of stuff presented in this forum, which has nothing to do with graphics and music, could be run on v2.0.2. Maybe with a bit of discomfort on MacOS or Linux but still.

"OOH a cool function! I'm going to add it to my program, although I really don't know how to use it. Then boom. The programming system developers are ebil because they ate my program." As much as people are warned not to use $UNSTABLE features in a "release" version of an application created with QB64PE, they don't listen and then when it breaks or it doesn't work how it expects, the developers get the blame unfairly. Imagine if we had a "magic" update button? A few people would start doing it on purpose. I think eventually it was one reason why Galleon declined after a time; the other time was because he just became sick and tired of it.