QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: Richard on November 05, 2019, 07:27:05 pm

Title: VERSION info
Post by: Richard on November 05, 2019, 07:27:05 pm

Is it possible to get more detailed Windows and QB64 versions via a program?

compilerVersion$=_OS$ :  PRINT compilerVersion$

only returns      [WINDOWS][64BIT]

Would like e.g. what QB64x64 > Help > About > returns :-

QB64 Version 1.3 Revision [dev build] From git eba0593

Thanks

Title: VERSION Info
Post by: RhoSigma on November 06, 2019, 01:50:18 am

_OS$ ?? -> returns the OS and the eiter 32/64 bits -> seems ok for a fucnction called _OS$

Mentioning the "About" window you obviously looking for build information of QB64 or your compiled programs respectivly. This should, however, implemented in a new function, not into _OS$.

But why do you need it??  Guess you wanna check if certain keywords are available for use at runtime. That's useless, as an older QB64 version, which doesn't know a particular keyword would error out anyways, if you try to compile a program which uses this keyword.

Title: Re: VERSION info
Post by: Richard on November 06, 2019, 04:35:27 am

Thanks   ΡΣ      (  Code Page 869   xC7 (199.)  xCF (207.)   Unicode U+03A1  U+03A3  )

I am currently experimenting with two running instances of QB64x64 - one the latest stable version 1.3 and the other the development build version (with different IDE background color and compile settings) on the same laptop.

The first instance of QB64 is where I generate the basic code and this program is ported to the second instance which among other things inserts line numbers (as labels) corresponding to the IDE line numbers (with some modification). When I have a problem (which I am experiencing now giving infinite loop) I enable in the second instance of QB64 TRON/TROFF (equivalent code - experimental) to display where the program is looping. Meanwhile in the first instance of QB64 I can continue program refinements.

As the one program runs in both instances of QB64, I would like only the second instance to automatically "TRON" (equivalent) and a other debug features - hence the usefulness of the program automatically determining which QB64 version environment is being accessed.

If there is a FUNCTION available (or one can be specially made) it would be appreciated.

I will also evaluate using vWATCH

I miss the interpreter environment debug capabilities of PDS 7.1 

Title: Re: VERSION info
Post by: SMcNeill on November 06, 2019, 05:01:09 am

There is an easy way you can do this, but it’d be local to your machines and not something global you can share and compile elsewhere....  (Though that may be sufficient for your needs here.)

Inside the source directory, if you root around a bit, you’ll find one of the “hidden secrets” of QB64 — a set of bas files called something like header_stub.bas and footer_stub.bas.  (I’m not at my PC right now, so I don’t have access to check perfect root/file name structure at the moment.  I’ll come back and edit, or post the exact information later for you.)

Those two files work like a series of global $INCLUDE statements which you can use to add custom functionality to ALL your code.  Anything put in the header file will basically go at the start of all your programs, anything in the footer will go at the end of all your programs.

In this case, I’d use those and a simple set of the precompiler commands to set some CONST values in my programs.

In the header_stub, for the regular version, I’d add something like:

$LET QBVD = TRUE
CONST QBVD = “QB64 Stable Build v1.3”

Then, in the header_stub, for the development version, I’d add something like:

$LET QBVD = TRUE
CONST QBVD = “QB64 Dev Build v1.3+”

Then inside a program, I’d write a simple precompiler check up top:

$IF QBVD = UNDEFINED THEN
    CONST QBVD = “Undefined Version”
$END IF

Then you can write your code to make use of that CONST value.  In your folder where you keep the stable build, it’d be the first result.  In the folder where you keep the development build, you’d have the second result.  In case there’s a folder which isn’t locally changed (as if you shared the code on the forums for others), the program itself would set the undefined version for the value.

It’s the easiest way I know to add the functionality you’re looking for, to your code.

EDIT: They're inside the folder: source\embed\, and are called header_stub.bas and footer_stub.bas.

Title: Re: VERSION info
Post by: RhoSigma on November 06, 2019, 05:11:01 am

Or easier...

You have both QB64 instances installed in their own folder, guess so. Then just create a semaphore file in one folder and in your program simply check for the existence of that file.

eg. just create an empty text file "debug.txt" in the QB64 folder which you use for debugging, then in your program do:

Code: QB64: [Select]

1. IF _FILEEXISTS("debug.txt") THEN debugmode% = -1: ELSE debugmode% = 0
2.  

Ok, works only as long as you don't use the "Compile EXE to source folder" option from the RUN menu, otherwise you must add the full path to the _FILEEXISTS check.

Title: Re: VERSION info
Post by: FellippeHeitor on November 06, 2019, 09:16:26 am

Quote from: RhoSigma on November 06, 2019, 01:50:18 am

_OS$ ?? -> returns the OS and the eiter 32/64 bits -> seems ok for a fucnction called _OS$

Mentioning the "About" window you obviously looking for build information of QB64 or your compiled programs respectivly. This should, however, implemented in a new function, not into _OS$.

But why do you need it??  Guess you wanna check if certain keywords are available for use at runtime. That's useless, as an older QB64 version, which doesn't know a particular keyword would error out anyways, if you try to compile a program which uses this keyword.

I'm 100% with Rho here. But, if you must, try the following (provided you'll save this file to the QB64 folder):

Code: QB64: [Select]

1. '$include:'source/global/version.bas'
2. print Version$
3. print BuildNum$
4. PRINT AutoBuildMsg

Title: Re: VERSION info
Post by: SMcNeill on November 06, 2019, 09:51:50 am

Quote from: RhoSigma on November 06, 2019, 05:11:01 am

Or easier...

You have both QB64 instances installed in their own folder, guess so. Then just create a semaphore file in one folder and in your program simply check for the existence of that file.

eg. just create an empty text file "debug.txt" in the QB64 folder which you use for debugging, then in your program do:

Code: QB64: [Select]

1. IF _FILEEXISTS("debug.txt") THEN debugmode% = -1: ELSE debugmode% = 0
2.  

Ok, works only as long as you don't use the "Compile EXE to source folder" option from the RUN menu, otherwise you must add the full path to the _FILEEXISTS check.

If you add the full path, wouldn’t both versions find it just the same?

Title: Re: VERSION info
Post by: RhoSigma on November 06, 2019, 10:09:27 am

:) correct Steve, obviously it must be the path relative to the compiled EXE. Expressed different the path from the EXE back into the QB64 main folder, which of course again only works as long as he maintains the same folder structure in both versions.

BTW - I'd go with Fellippes approch here, it's nice and easy and works even globally, as every QB64 setup has the version.bas file in it.

Title: Re: VERSION info
Post by: SMcNeill on November 06, 2019, 10:27:49 am

Quote from: RhoSigma on November 06, 2019, 10:09:27 am

:) correct Steve, obviously it must be the path relative to the compiled EXE. Expressed different the path from the EXE back into the QB64 main folder, which of course again only works as long as he maintains the same folder structure in both versions.

BTW - I'd go with Fellippes approch here, it's nice and easy and works even globally, as every QB64 setup has the version.bas file in it.

Aye.  We used to have to update version.bas manually, but it’s been incorporated into the build process now, which is why I didn’t mention it.  Linux/Mac auto-builds have been failing for a while now (I think we finally traced the issue to the Travis build script, so it should be fixed soonish, I think.), so I wasn’t certain if their buildnumber has been updating properly.  (Apparently they have been, or else Richard wouldn’t see different versions in Help, but I didn’t think of that.... /blush.)

Fellippe’s answer is probably the best to implement here.

Text Only | Text with Attachments