suggestions for future QB64

[justsomeguy]

• Work out a roadmap of the future of what you guys want it to be, and what you guys want it to become.
  
  

What do you use QB64 for? Do you want to modernize it? Do you want it stay the same? Do you want it to include more platforms. What is one small feature or bug fix that you want the most? Perhaps take specific polls on what people are happy with, and what they are not happy with. 

I apologize, this sounded like an interrogation. I meant "guys" as in the community, and, it is simply a hypothetical list of questions to pose to the community, to help build your roadmap.

As you mention, we're all hobbyist, and anyone who wants to join us with working on the project is welcome to fork a branch, make their changes, and then ask for a pull request.

I would love to help you guys, but without more or less knowing what everyone else is working on, I could end up conflicting with someone else's work. For instance: I started to try to untangle the spaghetti logic in the beginning of QB64.bas, but then I realized Keybone was working on "QB-lite". So, obviously going to conflict.

Perhaps maybe a spot on the forum to announce what you are working on in the QB64pe repo?

[PhilOfPerth]

I noted the comment from @justsomeguy about us not all being at the same level. This totally resonates with me.
I'm not one of the "illuminati" of QB64, nor am I a complete novice. So I would welcome a part of the forum that talks at my level, gives solutions at my level, and allows me to make comments at my level.
I'm not saying that I don't get the help I need - most times I do, and thanks to those who provide that help - but sometimes, it's a bit heavy for my skill-level. So bring on the split-level sub-forums.

[Pete]

I noted the comment from @justsomeguy about us not all being at the same level. This totally resonates with me.
I'm not one of the "illuminati" of QB64, nor am I a complete novice. So I would welcome a part of the forum that talks at my level, gives solutions at my level, and allows me to make comments at my level.
I'm not saying that I don't get the help I need - most times I do, and thanks to those who provide that help - but sometimes, it's a bit heavy for my skill-level. So bring on the split-level sub-forums.

Yeah, but we're not like a lot of code forums out there, you know, the ones that assume you already know everything about the language. I've always wondered why anyone would assume that someone who knows everything about the language would ever ask a question in the first place. I mean there is an old saying that there are no bad students, only bad teachers. Well, close. In reality, we see both.

My advice is if you ever get a reply where you feel the explanation went over your head, just reply back with something like, "Could you go over that again in layman's terms?" I usually go with something like, "Hold on there sparky, is that you talking or did your M.I.T. degree hack your account again? Well, that's just me. Anyway, my gut tells me the forum members will be able to communicate at all levels without the need for level sub-forums. I just want folks to feel free to ask what they want the way they want to ask it. Having stated that, watch Steve get right on to dividing up the forum into levels! I hate that guy, Murphy.

Pete

[admin]

Nah. I'm with you on this one, @Pete. People should feel comfortable asking for help whenever they need it. If the response is too technical, then feel free to ask folks to give examples and explain in greater detail. Everyone around here *enjoys* helping others learn the language and use it for whatever tasks they can.

It's why why we've stuck around the project for as long as we have -- a genuine love for the language, its simple syntax, and helping others to learn to love it just as much as we do!

[Pete]

Well what do you know, Reverse Murphy's Law comes through for me again. You know, Steve and I don't often agree on things. I think the last time we did was sometime around the era when the dinosaur population became extinct; but then who needs those QBasic programmers around anymore, now that we haveQB64-Phoenix? Now if you guys will excuse me, this brontosaurus burger isn't going to cook itself. Bob, pass the sour cream!

Pete

[Tim]

• Work out a roadmap of the future of what you guys want it to be, and what you guys want it to become.
  

What do you use QB64 for? Do you want to modernize it? Do you want it stay the same? Do you want it to include more platforms. What is one small feature or bug fix that you want the most? Perhaps take specific polls on what people are happy with, and what they are not happy with. 

For now, our goal is simply to pick up the pieces and make certain things work with the new constraints which we find ourselves working under.  Links have to be updated so things don't try to call out to the old websites and end up locking up.  We've got to update the parsing methods so that the wiki pages display properly under the new syntax.  We're looking for broken links and those missing pieces which are out there, and are looking to put them all together again.



While doing this, we're also pushing a few needed changes into the language.  The old windows mingw compiler (which is probably over half a dozen years old) is being replaced with a slightly smaller, updated version.  We're setting up an automated build process for the repo.  The way we pack and store files in the repo is changing (we're losing about 1-1.5GB of repo file size by just compressing and hosting the window's compilers independently).



So work goes on; it's just not going to be pushing anything major for a while (unless you consider replacing the compilers as something major), as it's going to take us a few months probably to get things all sorted out and back on track once again. 


*******************************************
*******************************************

• Work out who your core dev team is, and what their constraints are.
  

As far as I know, we are almost all hobbyist and working for free, because we enjoy it. Whomever takes the reigns of developer, will need to balance this project and life.

We've already had several people rejoin our "team", if you want to call us that.  As you mention, we're all hobbyist, and anyone who wants to join us with working on the project is welcome to fork a branch, make their changes, and then ask for a pull request.  Once it's tested and shown to break nothing, any of the members of the current team can pull those changes into the repo.  The guys who are part of our "team" right now are all there as much for quality-control, as for any sort of "I'm the boss, do what I say" scenario.  People work where they can, on what they can, and then others review and discuss their work just to keep things stable, before it's pulled into the official language.

*******************************************
*******************************************

• Decide on a programming style.
  

Not everyone is at the same skill level, and we don't all have the programming style. Outline some best practice's in the Wiki. 

• Prioritize bug fixes and refactoring
  

This is a no brainer. The current code base is not very approachable, and can be difficult to track down bugs.

• Trickle out small features somewhat regularly, and work on big features as time allows.
  

This shows the community that you are active and as you get better with the code base, new features will be quicker to add.

This is basically what we're working on at this point in time.  Everyone is sorting out a new workflow.  How are we doing the repo?  Who approves pull requests?  What limits are we going to have going forward?  What rules to add to the language?

Bug fixes are one of the biggest things we've been talking about, along with the issues in addressing them.  QB64 has became a "Frankenstein Language" over the years.  There's parts of it in C.  Parts in BASIC.  Parts in assembly.  We used to have SDL under the hood, then swapped to Glut and OpenGL..  Things were ripped apart, and then band-aided over, with the concept that "let's get it working -- even if it's just partially -- to begin with, and then we can come back and get it working right later."

As for the slow trickle of releases, we're working on that as well.  When we got the fix so that the help menu would work with our new wiki, we pushed that release out.  We'll probably be pushing another release out here in just a few more days with the swapped out compilers for windows.  Things are still moving forward -- it's just taking us a little while to glue all the pieces back together again smoothly together. 

So, if a person wanted to work towards at least trying to be a developer for QB64, what language or languages would be the tip top best to learn? What is the pathway to get there?

[admin]

QB64 is mainly coded in BAS, C, and C++.

[Tim]

QB64 is mainly coded in BAS, C, and C++. 

Would that be BAS as in Basic, or does BAS stand for something else? (There is a lot that I do not know.)

[admin]

BAS, in this case is QB64 *.bas files. You can find our source files inside the internal/source folder, and internal/c folders, included with all versions of QB64.

[Tim]

BAS, in this case is QB64 *.bas files.  You can find our source files inside the internal/source folder, and internal/c folders,  included with all versions of QB64.

Could QB64 be completely coded/recoded using QB64 only?