On 3/28/26 21:29, Luca Toniolo wrote:
Hi Bertho,
Two questions about the new parser:
1. Invalid variable names, what's the failure mode?
If the parser encounters a variable name with spaces (or otherwise not
matching [a-zA-Z_][a-zA-Z0-9_]*), will it refuse to start? A silently
dropped axis limit would be dangerous, so I'd expect a hard error,
what's your take?
2. Will we get Inline comments?
Since 2.7.x the parser doesn't support inline comments, VAR = value #
comment treats everything after = as the value. This is a common
source of confusion. Will the new parser support inline comments (e.g.
# or ; after the value)? If so, an escape character (e.g. \# or \;)
would be needed for values that legitimately contain those characters.
Thanks,
Luca
Thank you Luca for this work. I use several other sw packages but all of
those treat an #text or ;text as an inline comment, quite valuable in
describing what this variable actually does. I've been caught out many
times by forgetting this detail so fixing the parser V1.2 to accept
inline comments would be much appreciated here.
On 3/29/26 7:40 AM, Bertho Stultiens wrote:
Hi all,
The ini-file parser currently accepts spaces in variable names like:
[section]
one var = value
two_var= some thing
It is somehow, somewhat documented in
docs/src/config/ini-config.adoc. However, it is unclear and
undocumented what the first variable really is called and can be one of:
- 'one var'
- ' one var'
- 'one var '
- ' one var '
(note the leading and trailing space).
Using spaces in variable names is IMO very problematic and we all
know how to use underscores (_) I believe. Variables should only
contain letters, digits and underscore and not be allowed to start
with a digit, just like normal identifiers (regex:
[a-zA-Z_][a-zA-Z0-9_]*).
As I'm writing a new ini-file parser (mostly done) I'd like to get
rid of the spaces in variable names.
Note that values, that is, all text after the '=', still may contain
spaces and is left and right trimmed (stripped of whitespace). I.e.
variable 'two_var' has value 'some thing' in above example.
This variable name change could be added to the ini-file updater and
fixed if there are any of these spaced variable names. There is work
underway to update INI files to version 1.2 anyway.
A second change I'd like to make is in the way variables are assigned
to sections. Currently, it is allowed to start an ini-file with a
variable that has no section header, like in:
var=no_section_var
[section]
var=[section]var value
You can get to the first 'var' only if you do not specify the section
in the query. However, it is a very bad habit to allow variables to
be outside sections because it only works at the top of the file and
what do they describe? What is the problem of creating a section to
encapsulate them and thereby making variables mandatory subordinates
of a section header? It would be much more logical and consistent to
do so.
Additionally, I'd like to impose the same name restriction to
sections making them standard identifiers, just like variables above.
Using the same section name twice will result in a warning and the
contents are merged.
BTW, the new ini-file parser can be queried to return values as
string, real, signed/unsigned integer (64 bit) and boolean. The
parser does all necessary testing, conversion and error reporting. It
supports different radix conversion for integral numbers with a
prefix (hex: 0x, octal: 0o and binary: 0b) including optional leading
+/- sign in any base. You can also use maps to map strings to values
(or other strings) case sensitive or without case. This is also used
internally to map boolean values. The new parser also handles nested
#INCLUDE statements and no longer needs any includes to be handled
and converted before running the actual LCNC binaries.
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Don't poison our oceans, interdict drugs at the src.
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
