Guidelines for Contributing to QB64

[mnrvovrfc]

My new philosophy is to let QB64 be what the community want it to be. Even if we end up with 1000s of commands that barely get used by the majority, it is better than QB64 not being used at all. And if someone implements something incredibly stupid/unnecessary (such as a _HELLOWORLD command) the beauty of a repository is that it can always be rolled back later. Because of this philosophy, you won't see me standing in the way of any changes.

This is the way.

Welcome to the forums. I think we've crossed paths before.

[SMcNeill]

My new philosophy is to let QB64 be what the community want it to be. Even if we end up with 1000s of commands that barely get used by the majority, it is better than QB64 not being used at all. And if someone implements something incredibly stupid/unnecessary (such as a _HELLOWORLD command) the beauty of a repository is that it can always be rolled back later. Because of this philosophy, you won't see me standing in the way of any changes.

This is the way.

This is the guiding philosophy which we've faithfully followed, as set down for us by Galleon about ten years ago now.  For some reason, Cory and the folks at the QB64 Official Team like to pretend that everything we do is all part of some "Steve Show", but that couldn't be further from the truth.  Our development model is based entirely upon the practice of:

Does your idea meet all of the above criteria? If so your next steps are...

1) Code it! (make sure you note any files you change and where for your own reference)
2) Submit it.
i) If you are a QB64 repository contributor, grab the latest version of the repository, make your changes and push them  (I and the community will test the next dirty build [which is automatically created from the repository] and as long as it works, job done!) or...

ii) Become a repository contributor by asking me on the Q&A forum

The only real change we've made over the years is that now we ask folks to make a Pull Request with any changes which they're interested in implementing, so that our developers -- who Galleon called "repository contributors" -- can review such changes for stability and bug fixes, before merging the changes into our repository.

At no point is there a case of some guy named "Steve" directing everyone to go out and do one thing or another.  Each contributor contributes with the time and changes which interests them, and which they work on voluntarily.  Those that have asked to join the long term "repository contributors", are welcome into the development channels and such -- not so that we can push work onto them and make them do what we wish -- but so that those of us with more experience with the layout and style of the source can help guide them to making whatever enhancements and fixes which they're interested in.

We're not an exclusive club of old timers.  Anyone is welcome to join us, if they're interested in contributing to the project and have some idea which they think they can implement to make things better for all, and which follows the loose guidelines as laid out for us oh-so-long ago.   

[Richard]

Our guidelines are the same as always:


Quote from Galleon:

I was recently asked for guidelines about the process for contributing to QB64's source code/core functionality.

I am supportive of ANY change to QB64 which:
...
6) Does not allow mixed language/CPU specific command integration (such as inline C++ code, assembly, etc)
...

I disagree with point #6.

Assembly should be allowed in my opinion - some other BASICs have it.

My understanding is that QB64(pe) will only work on computers with INTEL based processors (putting aside Virtual Machine implementation, which I do not think many users of QB64 are heavily involved with).

So, although QB64 is cross-platform compatible - it will not work on a MAC that is non-Intel - so QB64 is processor (class) specific.

There are some commands. for instance, that cannot work on a MAC, and I suppose on LINUX - those commands I gather may use Windows API's.


I found it extremely difficult (but still possible) to have the "equivalent" of in-line Assembly in QB64 - though in my case, it was worth the trouble. 

The author of the quoted "rules" apparently, in the early days of development - actually used M$ PDS 7.1 to create the so-called QB 4.5 compatible package, known now as QB64(pe), that we use today - sounds a bit silly to me (PDS 7.1 has more features than QB 4.5).

[SMcNeill]

My understanding is that QB64(pe) will only work on computers with INTEL based processors (putting aside Virtual Machine implementation, which I do not think many users of QB64 are heavily involved with).

So, although QB64 is cross-platform compatible - it will not work on a MAC that is non-Intel - so QB64 is processor (class) specific.

QB64 will run on ARM-based processors, with just a few changes to the source.  The only reason we're not offering and advertising it as a supported system is that none of the current devs have an ARM-system to test and debug any issues that might arise.   There's several posts on the forums here which highlight the changes needed to run on an ARM-based system such as the Pi or newest MACs.

[a740g]

My understanding is that QB64(pe) will only work on computers with INTEL based processors (putting aside Virtual Machine implementation, which I do not think many users of QB64 are heavily involved with).

So, although QB64 is cross-platform compatible - it will not work on a MAC that is non-Intel - so QB64 is processor (class) specific.

QB64 will run on ARM-based processors, with just a few changes to the source.  The only reason we're not offering and advertising it as a supported system is that none of the current devs have an ARM-system to test and debug any issues that might arise.   There's several posts on the forums here which highlight the changes needed to run on an ARM-based system such as the Pi or newest MACs.

Well, you can do assembly if that is what you really want.

Inside a C header file, write your assembly routines using GCC inline assembly. See GCC-Inline-Assembly-HOWTO (ibiblio.org)

Ensure, you do not have weird external dependencies.

Once done, use "DECLARE LIBRARY" to declare your routines in the ".bas" file and then call those from your BASIC code. See DECLARE LIBRARY - QB64 Phoenix Edition Wiki

But all this stuff is easier said than done.

And like Steve said, we are thinking about supporting ARM in the future. So, writing stuff in assembly will make your code less portable.

[mnrvovrfc]

I disagree with point #6.

Assembly should be allowed in my opinion - some other BASICs have it.

Ask the head developer of Purebasic how he goes about doing things so the messy business is translated into one of three operating systems and at least two architectures (x64_64 and ARM). Reading the "gcc" manual*, in the chapter about extensions to "ANSI C" reveals some mind-boggling things that were done for the sake of portability.

* @a740g provided a link above with information...

Learned from Spriggsy : might have to do "DECLARE CUSTOMTYPE LIBRARY" if "DECLARE LIBRARY" doesn't work.

I have code for Turbo Pascal which doesn't run on my outdated copy of 32-bit Free Pascal, before we start talking about assembly blocks supported by that programming language which are all over the contributions of the great PC MAGAZINE book written by N.J.Rubenking. "Oh but Purebasic looks like Pascal then like that, which is what I want," well, not on freeware anytime soon, not toward programmers doing this as hobby and not being paid for it, and with less than 5% of people downloading the product donating for it regardless of the orange-button company.

To make a long story short: I don't want to see any "ASM... END ASM" blocks in QB64(PE) code. Sorry. I like the current system of including "dot-H" files for people like me who are afraid of C/C++ and then, "What assembly? It's too hard!"

About Galleon (maybe) having used M$ BASIC PDS v7.1, it was a start for QB64, or it might not have started at all. This is despite the fact there was a lot of emphasis on compatibility with QBasic (ie. the interpreter packaged with MS-DOS 5+) and not as much with any other BASIC language product.

[DSMan195276]

I disagree with point #6.

Assembly should be allowed in my opinion - some other BASICs have it.

My understanding is that QB64(pe) will only work on computers with INTEL based processors (putting aside Virtual Machine implementation, which I do not think many users of QB64 are heavily involved with).

So, although QB64 is cross-platform compatible - it will not work on a MAC that is non-Intel - so QB64 is processor (class) specific.

A different perspective, the biggest problem with assembly support is just getting it to actually work without having it be a giant pain to use that breaks when you slightly change your code. If you take a look at inline assembly in C you can get an idea of how it quickly gets complex, the compiler needs to know exactly what your inline assembly does so that the code it produces around it will continue to work correctly.

The alternative of not having you inform the compiler of what your assembly does will make using inline assembly extremely expensive, as we'll have to basically save all state (Ex. registers) beforehand, restore it afterward, and also tell the compiler it cannot rely on any cached reads from memory and has to do them again.

[grymmjack]

This is the way.

Welcome to the forums. I think we've crossed paths before.

Thanks! Probably have!

[grymmjack]

Since everything is compiling using C is there that much of a reason to use ASM these days? Besides preference, and longevity and such.

[Jack]

I use FreeBasic which has support for inline asm but I avoid it due to portability and also because inline asm can often interfere with gcc optimization
I think that code readability is priority one and using asm code in the middle of Basic will most likely make it non-portable and hard to understand