That was good and when you think about, since QB64's goal is to work in Vista, not sure what Linux has to do with anything until that first goal is met ;-).

Ok, To ease the reading experience, I will break this reply into three sections. The QB64 project section (below), the Source Code section (below that one) and finally, the linux port section.


QB64 PROJECT WISE:

Though we're free to talk about what QB64 should do, anything that pertains to QB Compatibility per se. Hence, if select case, SHELL and others need to be discussed, yeah now is the time since this is what QB Compatibility is all about, the language. But even the whole _RangeOfAddOnsFunctions() could be discussed/suggested, that's fine, but nothing should be expected to be added, not yet, as add ons, so far, come after QB Compatibility itself, which is THE way to go :-). One list (and only one list), somewhere should exist entitled "What really will go in" or something like that and that list should be updated when need be (hence when Galleon concludes that a given suggestion warrants integration to the current code base.

Galleon really does have two hands and so far it's amazing what he managed to do, my hat is off to him. But being the only developer does have it's advantage as far as keeping the focus of the project where it needs to be. That too so far has been proven throughout all first 6 demos that got released. Sure, some things may take longer (maybe due to just two hands typing, other may be dependent on other language features being available first. If there's one thing the QB64 Project has consistently shown thus far is it's direction and purpose. Galleon has a vision and a direction for his project and so far he's sticking to it. Which is great, which is Demo $6 is so good and why demo #7 promises to be that much better as per the goal of the project as well as the fact that he seems excellent at detecting what needs to be done before a given functionality can be implemented.

As long as people realize that what they suggest shouldn't be considered part of a release until after Galleon says it will go in. You might not know that to add this or that feature, a certain number of other features need to be coded in first (should he decide to add the feature in the first place). I think that since Galleon ultimately decides what goes in and when, it helps him make sure that QB64's ultimate goal is respected and gets priority over any add ons. Perhaps some different things will be implemented maybe because galleon needs it (specifically now that Demo #7 will aim to self compile, so those too will appear.

<---- Pete's Pop Stand ----> ;-)

SOURCE CODE:

Personally, I think releasing any source code right now is overkill, whether you release C++ or BASIC code. I agree with Galleon here, there's no real reason to release the source code at least until QB64 can compile itself. Personally I would wait till we're at (or very close to) version 1.0 release candidate :-). It's just too early for source code to be of any use and will only open up some "Fresh cans of worms" namely:

1. I see confusion setting in. People tempted to help Galleon by trying to debug. A very nice helping effort that can and probably will lead to loss of control over the codebase. This can have the effect of regressing the project more than helping it move forward.

2. I can see plenty of opportunities for code criticism by anyone and everyone that happens to think they can do things better, faster, quicker and/or smaller. I think it just opens door to make comments and wast Galleon's time in replying to useless posts instead of bringing the project forward in that same time. It's easy to say "nah, I'd never do that" and maybe those people wouldn't. But I wouldn't rule out everyone that pops on network54 out of this equation just yet.

<-- Clippy's Hotdog Stand -->

THE LINUX PORT:

Well, as of today it doesn't exist and I'm glad it doesn't, not because I don't want a linux port, but because in my opinion, it's much better to port a stable working version of a project to other OS rather than fall into the chaos of porting 1/2 way done incomplete code to other platforms and then suddenly falling with Os x CodeBases to main and fix and stabilize and take 2 tylenols extra strength every 4 hours every time you sit down to code anything on any OS.

Now, I'm answering for myself here, so far, from my observations here, I think I can "assume" that Galleon has a similar idea about porting efforts. Sure linux or Mac users have to wait, but to them I say: "Do you want to have a non working thing to use now, or a stable and reliable working product to use later?". I for one will probably always favor waiting to get something better. Like the old saying says: "Any good thing is worth waiting for." This goes double for projects like this one. ;-)

My two cents. :-)