suggestions for future QB64

[Jack]

instead of the badly supported _Float replace it with a decimal64 type, that would solve a lot of the floating-point error complaints

[Pete]

Hi Jack,

Nice idea, but we're currently _SOL on _DEVELOPERS.

I received a message from Fell today, concerning his future involvement. It read: "Hi there. I'm no longer involved with the project, so no."

We will have to see how this all shakes out. For now, it's just about reestablishing a place to connect, here.

Thanks,

Pete

[PhilOfPerth]

How about a "signature" (or whatever you want to call it) for QB64, something along the lines of "Preserving the Past, Enjoying the Present, Building the Future!"

[bplus]

How about QB64 Forever!

[Pete]

How about QB64 Forever!

Must I optimize everything you do?

QB64-ever

Pete  

PS You know Mac, at The QBasic Forum, had the mantra: "QBasic Forver" I'm sure he would not mind a bit, God rest his soul, if we used the "Forever" part.

[bplus]

How about QB64 Forever!

Must I optimize everything you do?

QB64-ever

Pete  

PS You know Mac, at The QBasic Forum, had the mantra: "QBasic Forver" I'm sure he would not mind a bit, God rest his soul, if we used the "Forever" part.

Oh I just found this little nugget that I missed earlier. Interesting how I am learning more about Mac now, must of been quite a guy!

QB64ever is good! until we move up to QB128 then... not so much ;-))

[Pete]

How about QB64 Forever!

Must I optimize everything you do?

QB64-ever

Pete  

PS You know Mac, at The QBasic Forum, had the mantra: "QBasic Forver" I'm sure he would not mind a bit, God rest his soul, if we used the "Forever" part.

Oh I just found this little nugget that I missed earlier. Interesting how I am learning more about Mac now, must of been quite a guy!

QB64ever is good! until we move up to QB128 then... not so much ;-))

Agreed. The best we can do then is: QB128myhomework, and that isn't exactly sending the most positive message.

Pete


Tarnation! My signeechar keeps changin'!

[justsomeguy]

Forgive me, if this is presumptuous, but if it were me, this is more or less what I would do.

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

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

• 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 my 2 cents.

[Pete]

Forgive me, if this is presumptuous, but if it were me, this is more or less what I would do.

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

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

• 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 my 2 cents.

Your 2-cents is pretty much the way things have worked since 2007. The creator and first developer, Rob (Galleon) was a loan gun. He did an astonishing amount of coding on the project. For for whatever reason he was overly fond of using GOTO statements. That was a double edged sword. It helped him develop faster, because he had a good memory of the code, but after he left the project, well, I can imagine some of the shocked faces of folks who looked at the coding style. Luckily, Fell and luke jumped in, and handled it extremely well with the existing construct. That was probably around 2012 or 2013, I think. Anyway, Fell sure seemed to be tired of all the work involved, quit the project, is not coming back, and my guess is we will need to find someone like him if the project is to continue forward. As for fixing a few bug issues, that will probably get taken care of by those familiar with the project within this community. As for new platforms like mobile devices, I think that would require a re-write in JAVA. That's a tall task. Personally, I'd love to see a  version of QB64 to write mobile apps.

Pete

[SMcNeill]

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