[Deprecation] Variable names starting with digits

[pcremades]

Hi all,
I'm trying version 2025.04.27 of OpenSCAD and I receive tons of warning related to variable names starting with digits in NopSCADlib. This will become a big issue.

[nophead]

Are you using the latest version? I merged a PR to fix the variables names in maths.scad. Are you seeing some from somewhere else?

[pcremades]

Yes, many vitamins have names starting with digits: 2p54header, 6p4mm_disc, just to name a few.

[nophead]

Yes but I thought the warning was just for those that looked like hex constants.

[pcremades]

Nop, it seems variable names in general can't begin with a digit. It will take a huge amount of work to change every single variable name in the library. I can contribute as I'm actively using NopSCADlib in several projects.
Can you figure any other way of doing this?

[nophead]

Well I will just stop updating OpenSCAD rather than changing all my projects. It hasn't really been compatible with NopSCADlib since the semantics of $variable were changed just after the last release.

[tpimh]

In order to just suppress the warning, we can simply prefix all variables starting with a number with an underscore. If this is fine, I can prepare a pull request with this change.

[nophead]

Yes but that will break all my projects.

[tpimh]

Yeah, this sucks. It's possible to fix the existing projects by running the same replacement command, or a special shim can be made that will be just full of statements like 2p54joiner = _2p54joiner, and it would need to be included in every old project (but then again it will generate all the same warnings).

Anyway, this is not such a major concern, because it's just a warning for now, and it's going to stay this way in the next OpenSCAD release. However the release after the next release would not tolerate variable names starting with digits. Given how often the releases happen, we have years to figure out a good solution.

[nophead]

The last release is the only one that works properly for me since they broke $ variables soon afterwards. I might get around to making my own fork to restore that and remove this warning. It is crazy to change semantics after a decade of people using it.

[pcremades]

What if we write a Python script to automatically rename all the variables in the library? It could also be used to rename variables in any project.

P.D.: what is the problem with $ variables semantic? Could you point me to the discussion/change log?. I'm just curious.

[nophead]

One used to be able to define a $variable at the top of a file and then use it. Now it would be ignored if the file is used by another file but not if it is opened in the GUI. The change was under the disguise of refactoring but when I complained it was argued it was more correct.

To bodge around I include global_defs.scad when making STLs but that just stops the undefined variable errors. So you can't easily change say $extrusion_width for part of a project unless you do make_all with the last release. Otherwise you would need to define it in all the functions and modules of the used file.

I can replace all the variables in my projects but I don't want to. I prefer correct part numbers.

[d-smith391]

FYI, version 2025.03.12 appears to be the last version that didn't throw the warnings.

I use nophead's lib for quite a few projects. It's unfortunate the way the latest OpenSCAD releases have gone with this library. I've already offloaded non-GUI usage to a "build" server running the 2021.01 to use this libraries' wonderful automation scripts — which take some time without manifold.

Then used the OpenSCAD snapshots for faster GUI (development) work. Looks like I'll be pinning that one too to 2025.03.12 until some solution is found — the warnings mask other messages I use unfortunately.