Quote:

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

Quote: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.

(04-26-2022, 11:58 PM)PhilOfPerth Wrote: 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.

(04-26-2022, 11:11 PM)SMcNeill Wrote:

(04-26-2022, 10:28 PM)justsomeguy Wrote:

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


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

(04-26-2022, 10:28 PM)justsomeguy Wrote:

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

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

(04-26-2022, 10:28 PM)justsomeguy Wrote:

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

(04-27-2022, 06:14 AM)admin Wrote: QB64 is mainly coded in BAS, C, and C++. 

(04-27-2022, 06:35 AM)admin Wrote: 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.