I normally use a first-line comment to keep track of code version, like "; logger code version V26b "
Later, there is a print instruction to embed it in my log file, I'm using OpenLog which takes ascii input.
This is simply a manual duplication - i.e. " Ser1Print "this is version V26b"
- but it means I need to update both and I often forget. Thirdly of course there is the filename, which has the version as a suffix - like "logger3 V26b.gcb"
-
I'd like to #define "version" as my version number - like:
"#define version V26b"
however if I try and print it, I can't
"Ser1Print version" tries to print variable V26a which is undefined, and throws a compiler error ( option Explicit is active - to avoid unintentional variable creation such as this)
"Ser1Print str(version)" ought to work, to convert the V26b into a string, but throws the same variable undefined error.
Is there a standard approach for this sort of thing, perhaps based on filename?
I guess I could dimension a string and populate it with my version, but it costs RAM, and it looks clumsy defining strings before even the processor type.
Any help or advice appreciated.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Maybe I am not understanding. It is my understand of what you are trying to achieve.
See the program and output below.
#chip 16f877a, 4#option explicit#define Version "this is version V26b";SetupLCDParameters#define LCD_IO 4#define LCD_NO_RW#define LCD_Speed fast#define LCD_WIDTH 20 ;specified lcd width for clarity only. 20 is the default width;-----DefineHardwaresettings#define LCD_RS PORTB.0#define LCD_Enable PORTB.1#define LCD_DB4 PORTC.3#define LCD_DB5 PORTC.2#define LCD_DB6 PORTC.1#define LCD_DB7 PORTC.0;-----Includelibrary#include<SoftSerial.h>;-----ConfigSerialUART:#define SER1_BAUD 9600 ; baudrate must be defined;ConfigI/Oportsfortransmitting:#define SER1_TXPORT PORTC ; I/O port (without .bit) must be defined#define SER1_TXPIN 6 ; portbit must be definedPrintVersionSer1PrintVersion
Gives the following on the simulator.
I am sure I have misunderstood what you are trying to do.
If you really want the short filename ( without the extension ) then add this code at line 258 of C:\GCstudio\gcbasic\preprocessor.bi and compile GCBASIC.
If you start a copy of GCSTUDIO, select the SPANNER ( setting ) you will see GC BASIC Compiler, select it. This has a new function under <f4>... 'build GCB compiler'.</f4>
' Add a constant called SOURCEFILE that is the short filenameDimnewConstantasStringnewConstant=ReplaceToolVariables("%namepart%("+SourceFile(1).FileName+")")replace(newConstant,".GCB","")'Constant as a stringSSC=SSC+1StringStore(SSC).Value=newConstantStringStore(SSC).Used=0AddConstant("SOURCEFILE",";STRING"+Str(SSC)+";")
Then, in your source program you have a new constant that is a string of source file name.
Ser1Print SOURCEFILE
I get 'first-start-sample' in my terminal.
Enjoy
If folks think this is beneficial then I can add the compiler as a permanent capability.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So sorry for the delay in responding, I was expecting an email alert but failed to tick the "subscribe to this topic" box.
You've cracked it, I just needed to put the #define in quotes, that was all !
#define Version V26g ; doesn't work, undeclared variable V26g #define Version "V26g" ; with quotes ! - works perfectly, compiles...
I've also taken the trouble to find the "formatting help" tab on the left - many mysteries solved - but not quite working yet - the ">" should put my code into blockquotes, but I don't see it in the "preview". Maybe when it's posted it will work. I will look.
Many thanks also for delving out a formal solution that uses the actual code filename.
I totally offer my single vote to have SOURCEFILE added as a reserved term - but also happy without.
Whilst on the subject:
To have a "tree" function, like DOS, that shows the hierarchy of #included functions would be nice. It would highlight the simplicity of GCBasic - it seldom goes more than 2 levels deep. I did try and work out the #include tree for an Arduino program - had to give up on level 5.
Essentially, if it doesn't work as expected there's very little you can do to unravel it.
- I love GCBasic's asm file that clearly shows what gets included and where it is from. To append a simple text-based "tree" structure would be delight beyond measure.
Thanks and respects
Last edit: Anobium 2024-01-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Re the formatting of posts. It is hard to describe how to fix.. but I had a hack at your post formatting. I think. You cannot have leading spaces and quoting a # requires a leading and trailing SingleBackQuote.
Regarding TREE report.
I am not sure that I could produce anything meaningful.
The concept of a tree from the user program is not hard to produce ( ha ha! ) but what would it show.
An insight for you. All the system includes are in the file lowlevel.dat. These are all loaded automatically. All other #includes and #inserts are loaded when required,
Any of these files is only marked as used when the specific user program calls something in the source file. So, the compiler loads all then marks those used.
The concept of a tree, for me, does not exist but there is a hierarchy. As show below in my mock up. The hierarchy starts with the user source, then, the system includes, then the optional includes and any inserts.
Brilliant :)
my thoughts? - we're on different time zones so it's a bit like postal chess.
I will test the sourcefile compiler constant shortly, it's a classic substitution move, from a thing that can go wrong, to a thing that can't. Nice play.
On formatting, bear with me, I should master it.
Regarding the #include tree:
my interest is in being able to drill down into what the compiler does, and where it gets it from - principally so that there is the possibility of further analysis if it is not doing what I expect.
I do despair at the complexity of Arduino, as mentioned, and appreciate the simplicity of GCBasic. To illustrate the point, I'd like to slightly correct the example you gave:
from this:
├───hardware includes
│ ├───glcd.h
│ ├───glcdssd1306.h
│ └───lots more
to this:
├───hardware includes
│ ├───glcd.h
│ │ └───glcdssd1306.h
│ └───lots more
The point being that glcd.h as an include, then includes the particular LCD chip, only. You know where you stand.
My attempts at deciphering Arduino code might be mistaken, but seemed to involve at least four sub-levels, making analysis impossibly complicated - even if perhaps hierarchically purer.
We avoid introducing an entirely new nomenclature for well-known concepts; for example, we stick to the term type, avoiding the word class; we retain the terms variable and procedure, avoiding the new terms instance and method.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, that just looked good enough to post, to close the point.
Even the prime founders of computer science rejected the unnecessary complexity and obfuscation imposed upon it.
I'm hoping that the forum here is of a similar mind, and recognise that simplicity is not unsophistication. That's why we like BASIC, it's perfectly good enough and it works - with no need to learn geeky syntax.
What's wrong with "For I = 1 to 10 ... Next I "
versus "For I < 11, I++" - and a critical lone apostrophe somewhere further down?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Glad you're in agreement, I don't really understand why Comp.Sci isn't taught like all other subjects, going from the particular, with concrete examples, to the general. Computers are not difficult if you start with small tasks in assembler. Who else builds a house from the roof down?
Latest build? - Yes please :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I really appreciate the option you've given, but sadly I've a few other demands on my time right now - so I'll probably wait for the formal release, and pick it up next Thursday or so.
I've also recently bought a I2C analyser, so I'm hoping to debug the HW I2C better - but it's not a huge priority since SW I2C is working fine. I'll start a new post on that.
best regds
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I normally use a first-line comment to keep track of code version, like "; logger code version V26b "
Later, there is a print instruction to embed it in my log file, I'm using OpenLog which takes ascii input.
This is simply a manual duplication - i.e. " Ser1Print "this is version V26b"
- but it means I need to update both and I often forget. Thirdly of course there is the filename, which has the version as a suffix - like "logger3 V26b.gcb"
-
I'd like to #define "version" as my version number - like:
"#define version V26b"
however if I try and print it, I can't
"Ser1Print version" tries to print variable V26a which is undefined, and throws a compiler error ( option Explicit is active - to avoid unintentional variable creation such as this)
"Ser1Print str(version)" ought to work, to convert the V26b into a string, but throws the same variable undefined error.
Is there a standard approach for this sort of thing, perhaps based on filename?
I guess I could dimension a string and populate it with my version, but it costs RAM, and it looks clumsy defining strings before even the processor type.
Any help or advice appreciated.
Maybe I am not understanding. It is my understand of what you are trying to achieve.
See the program and output below.
Gives the following on the simulator.
I am sure I have misunderstood what you are trying to do.
Last edit: Anobium 2024-01-10
If you really want the short filename ( without the extension ) then add this code at line 258 of C:\GCstudio\gcbasic\preprocessor.bi and compile GCBASIC.
If you start a copy of GCSTUDIO, select the SPANNER ( setting ) you will see GC BASIC Compiler, select it. This has a new function under <f4>... 'build GCB compiler'.</f4>
Then, in your source program you have a new constant that is a string of source file name.
I get 'first-start-sample' in my terminal.
Enjoy
If folks think this is beneficial then I can add the compiler as a permanent capability.
So sorry for the delay in responding, I was expecting an email alert but failed to tick the "subscribe to this topic" box.
You've cracked it, I just needed to put the #define in quotes, that was all !
I've also taken the trouble to find the "formatting help" tab on the left - many mysteries solved - but not quite working yet - the ">" should put my code into blockquotes, but I don't see it in the "preview". Maybe when it's posted it will work. I will look.
Many thanks also for delving out a formal solution that uses the actual code filename.
I totally offer my single vote to have SOURCEFILE added as a reserved term - but also happy without.
Whilst on the subject:
To have a "tree" function, like DOS, that shows the hierarchy of #included functions would be nice. It would highlight the simplicity of GCBasic - it seldom goes more than 2 levels deep. I did try and work out the #include tree for an Arduino program - had to give up on level 5.
Essentially, if it doesn't work as expected there's very little you can do to unravel it.
- I love GCBasic's asm file that clearly shows what gets included and where it is from. To append a simple text-based "tree" structure would be delight beyond measure.
Thanks and respects
Last edit: Anobium 2024-01-23
Build 1325 now has the new constant
SOURCEFILE
. I update the Help also for other in the future. See https://gcbasic.sourceforge.io/help/_other_directives.html I also tidied the table of other constants and functions.Re the formatting of posts. It is hard to describe how to fix.. but I had a hack at your post formatting. I think. You cannot have leading spaces and quoting a
#
requires a leading and trailing SingleBackQuote.Regarding TREE report.
I am not sure that I could produce anything meaningful.
The concept of a tree from the user program is not hard to produce ( ha ha! ) but what would it show.
An insight for you. All the
system
includes are in the filelowlevel.dat
. These are all loaded automatically. All other#includes
and#inserts
are loaded when required,Any of these files is only marked as used when the specific user program calls something in the source file. So, the compiler loads all then marks those used.
The concept of a tree, for me, does not exist but there is a hierarchy. As show below in my mock up. The hierarchy starts with the user source, then, the system includes, then the optional includes and any inserts.
This is the hierarchy and this could be added.
But, have you seen the HTML report? This shows the subroutines called. I could adapt this table to show source file(s).
Subroutines
Your thoughts ?
Last edit: Anobium 2024-01-23
Brilliant :)
my thoughts? - we're on different time zones so it's a bit like postal chess.
I will test the sourcefile compiler constant shortly, it's a classic substitution move, from a thing that can go wrong, to a thing that can't. Nice play.
On formatting, bear with me, I should master it.
Regarding the #include tree:
my interest is in being able to drill down into what the compiler does, and where it gets it from - principally so that there is the possibility of further analysis if it is not doing what I expect.
I do despair at the complexity of Arduino, as mentioned, and appreciate the simplicity of GCBasic. To illustrate the point, I'd like to slightly correct the example you gave:
from this:
├───hardware includes
│ ├───glcd.h
│ ├───glcdssd1306.h
│ └───lots more
to this:
├───hardware includes
│ ├───glcd.h
│ │ └───glcdssd1306.h
│ └───lots more
The point being that glcd.h as an include, then includes the particular LCD chip, only. You know where you stand.
My attempts at deciphering Arduino code might be mistaken, but seemed to involve at least four sub-levels, making analysis impossibly complicated - even if perhaps hierarchically purer.
Perhaps this is a good point to pay respects to Niklaus Wirth, inventor of Pascal, and a strong advocate of simplicity.
https://www.theregister.com/2024/01/04/niklaus_wirth_obituary/
In particular, his paper " a plea for Lean Software", and I implore all to read it here: https://liam-on-linux.dreamwidth.org/88032.html
Sorry, that just looked good enough to post, to close the point.
Even the prime founders of computer science rejected the unnecessary complexity and obfuscation imposed upon it.
I'm hoping that the forum here is of a similar mind, and recognise that simplicity is not unsophistication. That's why we like BASIC, it's perfectly good enough and it works - with no need to learn geeky syntax.
What's wrong with "For I = 1 to 10 ... Next I "
versus "For I < 11, I++" - and a critical lone apostrophe somewhere further down?
I totally agree with Niklaus Wirth and I thank you for the URLs.
Do you want the latest build. I have a full full build ready here with the new constant working.
Glad you're in agreement, I don't really understand why Comp.Sci isn't taught like all other subjects, going from the particular, with concrete examples, to the general. Computers are not difficult if you start with small tasks in assembler. Who else builds a house from the roof down?
Latest build? - Yes please :)
Whilst waiting for Angel to publish the build . You can take the compiler exe's from https://gcbasic.com/reps/goldbuild/masterbuild/GCB@Syn/GreatCowBASIC/
You will need to select the specific exe file then select the context menu and use 'save' as'.
You need to take gcbasic.exe, gcbasic32.exe & gcbasic64.exe. Replace your local exe's and then try your test program again.
Enjoy !!
I really appreciate the option you've given, but sadly I've a few other demands on my time right now - so I'll probably wait for the formal release, and pick it up next Thursday or so.
I've also recently bought a I2C analyser, so I'm hoping to debug the HW I2C better - but it's not a huge priority since SW I2C is working fine. I'll start a new post on that.
best regds