modules starting with a numeral q
I just ran into something that made me redo a module I'd made earlier
with a previous monthly build.
You've disallowed naming a module starting with a number to mount a
3dtouch, a Z probe for a printer, a considerable lower priced clone of a
bltouch as a module named 3dtouch_mnt. Now somewhat better defined in
the process as I found a couple duplicate lines while going thru it to
add suitable comments so it wasn't a total loss. Now named mnt_3dtouch
which is again legal.
But I am curious as to exactly why 3dtouch was made sick big bird, AKA
illeagle??
Thank you.
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
No good reason that I can see. It was done in the PR that added hex
constants but I don't really see a connection. It breaks my library so I
can't update any more. A previous change broke $variables so I can only use
the last release for command line builds but now I can only use old
snapshots in the GUI as well.
On Tue, 27 May 2025 at 16:39, gene heskett via Discuss <
discuss@lists.openscad.org> wrote:
I just ran into something that made me redo a module I'd made earlier
with a previous monthly build.
You've disallowed naming a module starting with a number to mount a
3dtouch, a Z probe for a printer, a considerable lower priced clone of a
bltouch as a module named 3dtouch_mnt. Now somewhat better defined in
the process as I found a couple duplicate lines while going thru it to
add suitable comments so it wasn't a total loss. Now named mnt_3dtouch
which is again legal.
But I am curious as to exactly why 3dtouch was made sick big bird, AKA
illeagle??
Thank you.
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
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
On 5/27/25 11:56, nop head via Discuss wrote:
No good reason that I can see. It was done in the PR that added hex
constants but I don't really see a connection. It breaks my library so I
can't update any more. A previous change broke $variables so I can only use
the last release for command line builds but now I can only use old
snapshots in the GUI as well.
Lets hope saner heads prevail and we/I get an answer that makes sense.
While posting I'd also state that a separate list for snaky stuff is
also bass ackwards, diluting the efforts to merge python into OpenSCAD,
which can only proceed at a pace controllable by the authors of this
software. Splitting the efforts means a prolonged doubling of the
efforts. As I see it.
Thank nop head.
On Tue, 27 May 2025 at 16:39, gene heskett via Discuss <
discuss@lists.openscad.org> wrote:
I just ran into something that made me redo a module I'd made earlier
with a previous monthly build.
You've disallowed naming a module starting with a number to mount a
3dtouch, a Z probe for a printer, a considerable lower priced clone of a
bltouch as a module named 3dtouch_mnt. Now somewhat better defined in
the process as I found a couple duplicate lines while going thru it to
add suitable comments so it wasn't a total loss. Now named mnt_3dtouch
which is again legal.
But I am curious as to exactly why 3dtouch was made sick big bird, AKA
illeagle??
Thank you.
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
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
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
On 27/05/2025 20:35, gene heskett via Discuss wrote:
On 5/27/25 11:56, nop head via Discuss wrote:
No good reason that I can see. It was done in the PR that added hex
constants but I don't really see a connection. It breaks my library so I
can't update any more. A previous change broke $variables so I can
only use
the last release for command line builds but now I can only use old
snapshots in the GUI as well.
Lets hope saner heads prevail and we/I get an answer that makes sense.
While posting I'd also state that a separate list for snaky stuff is
also bass ackwards, diluting the efforts to merge python into
OpenSCAD, which can only proceed at a pace controllable by the authors
of this software. Splitting the efforts means a prolonged doubling of
the efforts. As I see it.
Thank nop head.
On Tue, 27 May 2025 at 16:39, gene heskett via Discuss <
discuss@lists.openscad.org> wrote:
I just ran into something that made me redo a module I'd made earlier
with a previous monthly build.
You've disallowed naming a module starting with a number to mount a
3dtouch, a Z probe for a printer, a considerable lower priced clone
of a
bltouch as a module named 3dtouch_mnt. Now somewhat better defined in
the process as I found a couple duplicate lines while going thru it to
add suitable comments so it wasn't a total loss. Now named mnt_3dtouch
which is again legal.
But I am curious as to exactly why 3dtouch was made sick big bird, AKA
illeagle??
Thank you.
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
Hi,
I think the team maintaining OpenSCAD are doing a commendable
job—stability in the software has clearly been a high priority, and
that’s something I really value.
Some of the changes mentioned by Nophead and others seem to push against
that ethos a little, perhaps following current trends. I get that, but
it's a delicate balance.
For what it’s worth, I’m not a big fan of Python as a scripting
language, but I can’t deny its popularity. From my experience so far,
PythonSCAD can already do everything OpenSCAD can, with many functions
improved or expanded. That said, I wouldn't rely on it for serious
long-term design work—just a gut feeling, perhaps around the safety and
predictability of Python. To me, PythonSCAD feels like a completely
separate language from OpenSCAD, even though it builds on OpenSCAD under
the hood.
There are other OpenSCAD-like tools out there too, but I’m not sure we
need to bring users of those into this mailing list, or do we?
Right now, OpenSCAD isn't "broken," and I’d be concerned that trying to
integrate Python might be a case of fixing it until it is. As far as I
know, none of the developers are working full-time on this, and we
absolutely don’t want to risk discouraging or overwhelming the
volunteers. There are many more casual programmers using Python than
OpenSCAD, and I fear that shifting focus in the mailing list or the
project might be a distraction at best.
Best wishes,
Ray
On 5/27/25 17:00, Raymond West via Discuss wrote:
On 27/05/2025 20:35, gene heskett via Discuss wrote:
On 5/27/25 11:56, nop head via Discuss wrote:
No good reason that I can see. It was done in the PR that added hex
constants but I don't really see a connection. It breaks my library
so I
can't update any more. A previous change broke $variables so I can
only use
the last release for command line builds but now I can only use old
snapshots in the GUI as well.
Lets hope saner heads prevail and we/I get an answer that makes sense.
While posting I'd also state that a separate list for snaky stuff is
also bass ackwards, diluting the efforts to merge python into
OpenSCAD, which can only proceed at a pace controllable by the
authors of this software. Splitting the efforts means a prolonged
doubling of the efforts. As I see it.
Thanks nop head.
On Tue, 27 May 2025 at 16:39, gene heskett via Discuss <
discuss@lists.openscad.org> wrote:
I just ran into something that made me redo a module I'd made earlier
with a previous monthly build.
You've disallowed naming a module starting with a number to mount a
3dtouch, a Z probe for a printer, a considerable lower priced clone
of a
bltouch as a module named 3dtouch_mnt. Now somewhat better defined in
the process as I found a couple duplicate lines while going thru it to
add suitable comments so it wasn't a total loss. Now named mnt_3dtouch
which is again legal.
But I am curious as to exactly why 3dtouch was made sick big bird, AKA
illeagle??
This question has not been clarified yet.
Thank you.
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
Hi,
I think the team maintaining OpenSCAD are doing a commendable
job—stability in the software has clearly been a high priority, and
that’s something I really value.
So do I. But this python thing should be a separate thread but I'm the
one that broke it.
Some of the changes mentioned by Nophead and others seem to push
against that ethos a little, perhaps following current trends. I get
that, but it's a delicate balance.
For what it’s worth, I’m not a big fan of Python as a scripting
language, but I can’t deny its popularity. From my experience so far,
PythonSCAD can already do everything OpenSCAD can, with many functions
improved or expanded. That said, I wouldn't rely on it for serious
long-term design work—just a gut feeling, perhaps around the safety
and predictability of Python. To me, PythonSCAD feels like a
completely separate language from OpenSCAD, even though it builds on
OpenSCAD under the hood.
There are other OpenSCAD-like tools out there too, but I’m not sure we
need to bring users of those into this mailing list, or do we?
Right now, OpenSCAD isn't "broken," and I’d be concerned that trying
to integrate Python might be a case of fixing it until it is. As far
as I know, none of the developers are working full-time on this, and
we absolutely don’t want to risk discouraging or overwhelming the
volunteers. There are many more casual programmers using Python than
OpenSCAD, and I fear that shifting focus in the mailing list or the
project might be a distraction at best.
+10, Ray.
Best wishes,
Ray
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
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
I’ve been meaning to weigh in on this on another thread, but never got around to writing the email:
Before Jordan landed his work on binary operators and hex constants, we discussed this internally and agreed that allowing variables to start with a numeric character was an unintentional feature of OpenSCAD, and continuing to allow it would hinter future development (like adding hex constants).
We chose a path which also better aligns us with how other common programming languages manages identifiers: To simply disallow starting identifiers with a numeric constant.
As a starting point, we’ve only disallowed identifiers starting with “0x”, but not being fond of having a language design with such exceptions, and not knowing which other patterns we should reserve, we opted to signal a deprecation of all patterns, offering a warning on such usage.
Note: This is just a warning, and has no other effect on your designs. It’s there to let people know that upgrading their designs and libraries would be good before we eventually disallow this in a future version of OpenSCAD (likely to hit something like 5-10 years from now).
In the meantime, it’s not unlikely that we might introduce other literal constructs, but nothing is planned right now.
This isn’t set in stone yet, as this all still only affects a development version of OpenSCAD, but I don’t think simply undoing it is very realistic. Technical suggestions and/or implementations that helps us stake out a cleaner path for users, designers and library developers are welcome.
-Marius
Note that sequences with digits, an "e" or "E", and more digits, have
always been disallowed as identifiers, because they are numbers in
exponential form.
Thanks for responding.
It may be just a warning but anybody using my library gets a wall of
warnings and the only practical way to use OpenSCAD is with "stop on first
warning" enabled anyway.
Part numbers never start with 0x or 0b anyway so I don't see any potential
for future clashes.
On Thu, 29 May 2025 at 06:56, Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:
Thanks for responding.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
On 5/28/25 19:42, Marius Kintel wrote:
I’ve been meaning to weigh in on this on another thread, but never got around to writing the email:
Before Jordan landed his work on binary operators and hex constants, we discussed this internally and agreed that allowing variables to start with a numeric character was an unintentional feature of OpenSCAD, and continuing to allow it would hinter future development (like adding hex constants).
We chose a path which also better aligns us with how other common programming languages manages identifiers: To simply disallow starting identifiers with a numeric constant.
As a starting point, we’ve only disallowed identifiers starting with “0x”, but not being fond of having a language design with such exceptions, and not knowing which other patterns we should reserve, we opted to signal a deprecation of all patterns, offering a warning on such usage.
Note: This is just a warning, and has no other effect on your designs. It’s there to let people know that upgrading their designs and libraries would be good before we eventually disallow this in a future version of OpenSCAD (likely to hit something like 5-10 years from now).
In the meantime, it’s not unlikely that we might introduce other literal constructs, but nothing is planned right now.
This isn’t set in stone yet, as this all still only affects a development version of OpenSCAD, but I don’t think simply undoing it is very realistic. Technical suggestions and/or implementations that helps us stake out a cleaner path for users, designers and library developers are welcome.
-Marius
Thank you Marius. But the denial seems to have snuck in early and my
year old code puked over it, prompting a conversion that eliminated a
module named 3dtouch() in favor of mnt_3dtouch(), which then worked fine
with the may '25 build. Part remained the same so it wasn't a major
show stopper. I may stumble over more such requiring similar fixes.
When you have a rebuilt, seriously souped up 3d printer, its like that
hammer joke where everything looks like a nail, but is a print instead.
My Ender 5 plus can spit out polycarbonate parts like a normal printer
spits out PLA, but 10x faster. I also have about $3k in it. I guess you
could call me a bleeding edge user.
.
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