Hi,
Guest
Questions about rotate_extrude parameters - working on warning messages
V
vulcan_@mac.com
Mon, Sep 15, 2025 12:09 PM
i am looking at the code that processes the rotate_extrude node to fix issue 6198
the relevant code in RotateExtrudeNode.cc
I think it better to do all param validation in one place so i replace the check for convexity <=0 with this:
// convexity for this module must be 2 or greater
node->convexity = max( (double) 2.0, static_cast<int>( parameters["convexity"].toDouble() ) );
Why does all this happen? would it not be better to simply have defaults of
start = 0.0
angle = 360
or is protecting legacy behavior?
// If an angle is specified, use it, defaulting to starting at zero.
// If no angle is specified, use 360 and default to starting at 180.
// Regardless, if a start angle is specified, use it.
bool hasAngle = parameters[{"angle","a"}].getFiniteDouble(node->angle);
if (hasAngle) {
node->start = 0;
if ((node->angle <= -360) || (node->angle > 360)) node->angle = 360;
} else {
node->angle = 360;
node->start = 180;
}
bool hasStart = parameters["start"].getFiniteDouble(node->start);
if (!hasAngle && !hasStart && (int)node->fn % 2 != 0) {
LOG(message_group::Deprecated, "In future releases, rotational extrusion without \"angle\" will start at zero, the +X axis. Set start=180 to explicitly start on the -X axis.");
}
in that last if() statement the value of $fn is tested to be odd .. hummm
okay, i see it now. IF $fn > 0 globally then it controls the shape if the circle and the extrusion .. and for odd values of $fn the extrusion has a “joint” in the generated polygon along the -X axis .. is that the reason for starting at 180 degrees when a and start are not given?
in any case i think this check and the message are not needed - agree? disagree ?
And .. 2 points about when angle and start are not given:
1 the check for $fn being odd is not needed when $fn <=3 as that is the smallest non-zero value it can have .. so if legacy is important then $fn == 3 is not a special case .. the check for odd $fn should only be done when $fn >= 5 ?
2 why not rotate the extrusion when $fn is odd so that the “joint” is at Y=0 and lies along the +X axis ?
like this - this first image is a 2 part child with $fn=4
and the same shapes but with $fn = 3 AND a 180 rotation around the Z axis on the extrude:
would this be a better solution?
i am looking at the code that processes the rotate_extrude node to fix [issue 6198](6198)
the relevant code in RotateExtrudeNode.cc\
I think it better to do all param validation in one place so i replace the check for convexity <=0 with this:
`// convexity for this module must be 2 or greater`\
`node->convexity = max( (`*`double`*`) 2.0, static_cast<`*`int`*`>( parameters["convexity"].toDouble() ) );`
Why does all this happen? would it not be better to simply have defaults of\
start = 0.0\
angle = 360\
or is protecting legacy behavior?\
\
`// If an angle is specified, use it, defaulting to starting at zero.`\
`// If no angle is specified, use 360 and default to starting at 180.`\
`// Regardless, if a start angle is specified, use it.`\
*`bool`*` hasAngle = parameters[{"angle","a"}].getFiniteDouble(node->angle);`\
`if (hasAngle) {`\
` node->start = 0;`\
` if ((node->angle <= -360) || (node->angle > 360)) node->angle = 360;`\
`} else {`\
` node->angle = 360;`\
` node->start = 180;`\
` }`\
*`bool`*` hasStart = parameters["start"].getFiniteDouble(node->start);`\
`if (!hasAngle && !hasStart && (`*`int`*`)node->fn % 2 != 0) {`\
` LOG(message_group::Deprecated, "In future releases, rotational extrusion without \"angle\" will start at zero, the +X axis. Set start=180 to explicitly start on the -X axis.");`\
`}`\
in that last if() statement the value of $fn is tested to be odd .. hummm
okay, i see it now. IF $fn > 0 globally then it controls the shape if the circle and the extrusion .. and for odd values of $fn the extrusion has a “joint” in the generated polygon along the -X axis .. is that the reason for starting at 180 degrees when a and start are not given?
in any case i think this check and the message are not needed - agree? disagree ?
And .. 2 points about when angle and start are not given:
1 the check for $fn being odd is not needed when $fn <=3 as that is the smallest non-zero value it can have .. so if legacy is important then $fn == 3 is not a special case .. the check for odd $fn should only be done when $fn >= 5 ?
2 why not rotate the extrusion when $fn is odd so that the “joint” is at Y=0 and lies along the +X axis ?
like this - this first image is a 2 part child with $fn=4
and the same shapes but with $fn = 3 AND a 180 rotation around the Z axis on the extrude:
would this be a better solution?
JB
Jordan Brown
Mon, Sep 15, 2025 4:01 PM
On 9/15/2025 5:09 AM, vulcan_--- via Discuss wrote:
i am looking at the code that processes the rotate_extrude node to fix
issue 6198 <6198>
the relevant code in RotateExtrudeNode.cc
I think it better to do all param validation in one place so i replace
the check for convexity <=0 with this:
|// convexity for this module must be 2 or greater
node->convexity = max( (|/|double|/|) 2.0, static_cast<|/|int|/|>(
parameters["convexity"].toDouble() ) );|
|Sure, though the "(double)" is unnecessary.|
||
|
|
Why does all this happen? would it not be better to simply have
defaults of
start = 0.0
angle = 360
or is protecting legacy behavior?
Protecting legacy behavior. Original rotate_extrude(), with no angle or
start, has a different starting point than circle() or rotate_extrude()
with angle.
$fn = 5;
color("blue") cylinder(h=1, r=3);
color("red") rotate_extrude() square([2,2]);
color("green") rotate_extrude(, angle=300) square([1,3]);
Try that in 2021.01, and note that the red pentagon starts on -X, while
the green and blue start on +X.
okay, i see it now. IF $fn > 0 globally then it controls the shape if
the circle and the extrusion .. and for odd values of $fn the
extrusion has a “joint” in the generated polygon along the -X axis ..
is that the reason for starting at 180 degrees when a and start are
not given?
Yes. That's the legacy behavior.
in any case i think this check and the message are not needed - agree?
disagree ?
Having just put that check and message in... disagree. Maybe at the
release after this one we can think about removing the special case and
the deprecation message.
And .. 2 points about when angle and start are not given:
1 the check for $fn being odd is not needed when $fn <=3 as that is
the smallest non-zero value it can have .. so if legacy is important
then $fn == 3 is not a special case .. the check for odd $fn should
only be done when $fn >= 5 ?
Hmm? You're right, 3 is not a special case. It has exactly the same
problem that 5, 7, ... have.
2 why not rotate the extrusion when $fn is odd so that the “joint” is
at Y=0 and lies along the +X axis ?
Who would rotate it, under what circumstances?
The goal is to have all of the variations of rotate_extrude be
consistent, and to have that be consistent with circle(), cylinder, et
cetera. Today, absent "angle" and "start", compatibility constrains us
to have the joint be on -X. We want to change that, but first we need
to warn people and give them a chance to fix their program before we
silently and subtly break their model.
On 9/15/2025 5:09 AM, vulcan_--- via Discuss wrote:
>
> i am looking at the code that processes the rotate_extrude node to fix
> issue 6198 <6198>
>
> the relevant code in RotateExtrudeNode.cc
> I think it better to do all param validation in one place so i replace
> the check for convexity <=0 with this:
>
> |// convexity for this module must be 2 or greater
> node->convexity = max( (|/|double|/|) 2.0, static_cast<|/|int|/|>(
> parameters["convexity"].toDouble() ) );|
>
|Sure, though the "(double)" is unnecessary.|
||
|
|
>
> Why does all this happen? would it not be better to simply have
> defaults of
> start = 0.0
> angle = 360
> or is protecting legacy behavior?
>
Protecting legacy behavior. Original rotate_extrude(), with no angle or
start, has a different starting point than circle() or rotate_extrude()
with angle.
$fn = 5;
color("blue") cylinder(h=1, r=3);
color("red") rotate_extrude() square([2,2]);
color("green") rotate_extrude(, angle=300) square([1,3]);
Try that in 2021.01, and note that the red pentagon starts on -X, while
the green and blue start on +X.
> okay, i see it now. IF $fn > 0 globally then it controls the shape if
> the circle and the extrusion .. and for odd values of $fn the
> extrusion has a “joint” in the generated polygon along the -X axis ..
> is that the reason for starting at 180 degrees when a and start are
> not given?
>
Yes. That's the legacy behavior.
> in any case i think this check and the message are not needed - agree?
> disagree ?
>
Having just put that check and message in... disagree. Maybe at the
release after this one we can think about removing the special case and
the deprecation message.
> And .. 2 points about when angle and start are not given:
>
> 1 the check for $fn being odd is not needed when $fn <=3 as that is
> the smallest non-zero value it can have .. so if legacy is important
> then $fn == 3 is not a special case .. the check for odd $fn should
> only be done when $fn >= 5 ?
>
Hmm? You're right, 3 is not a special case. It has exactly the same
problem that 5, 7, ... have.
> 2 why not rotate the extrusion when $fn is odd so that the “joint” is
> at Y=0 and lies along the +X axis ?
>
Who would rotate it, under what circumstances?
The goal is to have all of the variations of rotate_extrude be
consistent, and to have that be consistent with circle(), cylinder, et
cetera. Today, absent "angle" and "start", compatibility constrains us
to have the joint be on -X. We want to change that, but first we need
to warn people and give them a chance to fix their program before we
silently and subtly break their model.
MM
Michael Möller
Mon, Sep 15, 2025 6:23 PM
man. 15. sep. 2025, 18.02 skrev Jordan Brown via Discuss
" ... want to change that, but first we need to warn people and give them a
chance to fix their program before we silently and subtly break their
model."
That doesn't work. In my working life (Software engineer, Support,
Consultant - expensive highpower software) very few change their software
because of an announced incompatible change. Most surpress the warning and
will do the change "real soon". The day (after two years of warnings,
newsletters etc) when the incompatible upgrade rolled out was a busy
day(week/month) with surprised customers.
Engineering went soft and issued a patch with old function, so they could
migrate over the next few months. With the next update the patch was
nonfunctional - as had been announced - but almost the same panic/mess as
before.
This with professional organisations, IT departments "strategic importance"
...
The same goes when undocumented "features" (i.e. how the software reacts in
edge/invalid case) change. They changed the "stableness" of a sort
algorithm - the sort was still accurate, but the sideeffect had changed.
Sigh.
Do the change. People will scream regardless of your warning, e.t.c.
man. 15. sep. 2025, 18.02 skrev Jordan Brown via Discuss
" ... want to change that, but first we need to warn people and give them a
chance to fix their program before we silently and subtly break their
model."
That doesn't work. In my working life (Software engineer, Support,
Consultant - expensive highpower software) very few change their software
because of an announced incompatible change. Most surpress the warning and
will do the change "real soon". The day (after two years of warnings,
newsletters etc) when the incompatible upgrade rolled out was a busy
day(week/month) with surprised customers.
Engineering went soft and issued a patch with old function, so they could
migrate over the next few months. With the next update the patch was
nonfunctional - as had been announced - but almost the same panic/mess as
before.
This with professional organisations, IT departments "strategic importance"
...
The same goes when undocumented "features" (i.e. how the software reacts in
edge/invalid case) change. They changed the "stableness" of a sort
algorithm - the sort was still accurate, but the sideeffect had changed.
Sigh.
Do the change. People will scream regardless of your warning, e.t.c.
>
>
NH
nop head
Mon, Sep 15, 2025 6:28 PM
I have had to stop using the latest OpenSCAD because of two
incompatible changes that break all my previous designs, and there is no
simple fix. So I have no choice.
On Mon, 15 Sept 2025 at 19:24, Michael Möller via Discuss <
discuss@lists.openscad.org> wrote:
man. 15. sep. 2025, 18.02 skrev Jordan Brown via Discuss
" ... want to change that, but first we need to warn people and give them
a chance to fix their program before we silently and subtly break their
model."
That doesn't work. In my working life (Software engineer, Support,
Consultant - expensive highpower software) very few change their software
because of an announced incompatible change. Most surpress the warning and
will do the change "real soon". The day (after two years of warnings,
newsletters etc) when the incompatible upgrade rolled out was a busy
day(week/month) with surprised customers.
Engineering went soft and issued a patch with old function, so they could
migrate over the next few months. With the next update the patch was
nonfunctional - as had been announced - but almost the same panic/mess as
before.
This with professional organisations, IT departments "strategic
importance" ...
The same goes when undocumented "features" (i.e. how the software reacts
in edge/invalid case) change. They changed the "stableness" of a sort
algorithm - the sort was still accurate, but the sideeffect had changed.
Sigh.
Do the change. People will scream regardless of your warning, e.t.c.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
I have had to stop using the latest OpenSCAD because of two
incompatible changes that break all my previous designs, and there is no
simple fix. So I have no choice.
On Mon, 15 Sept 2025 at 19:24, Michael Möller via Discuss <
discuss@lists.openscad.org> wrote:
>
>
> man. 15. sep. 2025, 18.02 skrev Jordan Brown via Discuss
>
> " ... want to change that, but first we need to warn people and give them
> a chance to fix their program before we silently and subtly break their
> model."
>
> That doesn't work. In my working life (Software engineer, Support,
> Consultant - expensive highpower software) very few change their software
> because of an announced incompatible change. Most surpress the warning and
> will do the change "real soon". The day (after two years of warnings,
> newsletters etc) when the incompatible upgrade rolled out was a busy
> day(week/month) with surprised customers.
>
> Engineering went soft and issued a patch with old function, so they could
> migrate over the next few months. With the next update the patch was
> nonfunctional - as had been announced - but almost the same panic/mess as
> before.
>
> This with professional organisations, IT departments "strategic
> importance" ...
>
> The same goes when undocumented "features" (i.e. how the software reacts
> in edge/invalid case) change. They changed the "stableness" of a sort
> algorithm - the sort was still accurate, but the sideeffect had changed.
>
> Sigh.
>
> Do the change. People will scream regardless of your warning, e.t.c.
>
>>
>> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
GH
gene heskett
Mon, Sep 15, 2025 9:28 PM
On 9/15/25 14:40, nop head via Discuss wrote:
I have had to stop using the latest OpenSCAD because of two
incompatible changes that break all my previous designs, and there is no
simple fix. So I have no choice.
On Mon, 15 Sept 2025 at 19:24, Michael Möller via Discuss <
discuss@lists.openscad.org> wrote:
man. 15. sep. 2025, 18.02 skrev Jordan Brown via Discuss
" ... want to change that, but first we need to warn people and give them
a chance to fix their program before we silently and subtly break their
model."
That doesn't work. In my working life (Software engineer, Support,
Consultant - expensive highpower software) very few change their software
because of an announced incompatible change. Most surpress the warning and
will do the change "real soon". The day (after two years of warnings,
newsletters etc) when the incompatible upgrade rolled out was a busy
day(week/month) with surprised customers.
Engineering went soft and issued a patch with old function, so they could
migrate over the next few months. With the next update the patch was
nonfunctional - as had been announced - but almost the same panic/mess as
before.
This with professional organisations, IT departments "strategic
importance" ...
The same goes when undocumented "features" (i.e. how the software reacts
in edge/invalid case) change. They changed the "stableness" of a sort
algorithm - the sort was still accurate, but the sideeffect had changed.
Sigh.
Do the change. People will scream regardless of your warning, e.t.c.
Consider doing as linuxcnc has done when making a change that is needed
but disturbs the existing code base, which is the situation here I
believe, the initialization code grows a method to edit, in situ, so any
g-code src file is preinspected and made compatible with the new rules
and saved after making a backup copy of the old code. Not all users of
linuxcnc are coding gods but this has worked quite well several times in
past history. I may & probably will continue to crave my own g-codes,
but there are many more users using something that looks at the designer
programs output and translates to g-codes, usually very inefficiently
because they have zero knowledge about any of the ways linuxcnc can do a
loop. So it has to unwind the loop into gigabytes of repetitive g-code.
And it Just Works.
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 9/15/25 14:40, nop head via Discuss wrote:
> I have had to stop using the latest OpenSCAD because of two
> incompatible changes that break all my previous designs, and there is no
> simple fix. So I have no choice.
>
>
> On Mon, 15 Sept 2025 at 19:24, Michael Möller via Discuss <
> discuss@lists.openscad.org> wrote:
>
>>
>> man. 15. sep. 2025, 18.02 skrev Jordan Brown via Discuss
>>
>> " ... want to change that, but first we need to warn people and give them
>> a chance to fix their program before we silently and subtly break their
>> model."
>>
>> That doesn't work. In my working life (Software engineer, Support,
>> Consultant - expensive highpower software) very few change their software
>> because of an announced incompatible change. Most surpress the warning and
>> will do the change "real soon". The day (after two years of warnings,
>> newsletters etc) when the incompatible upgrade rolled out was a busy
>> day(week/month) with surprised customers.
>>
>> Engineering went soft and issued a patch with old function, so they could
>> migrate over the next few months. With the next update the patch was
>> nonfunctional - as had been announced - but almost the same panic/mess as
>> before.
>>
>> This with professional organisations, IT departments "strategic
>> importance" ...
>>
>> The same goes when undocumented "features" (i.e. how the software reacts
>> in edge/invalid case) change. They changed the "stableness" of a sort
>> algorithm - the sort was still accurate, but the sideeffect had changed.
>>
>> Sigh.
>>
>> Do the change. People will scream regardless of your warning, e.t.c.
Consider doing as linuxcnc has done when making a change that is needed
but disturbs the existing code base, which is the situation here I
believe, the initialization code grows a method to edit, in situ, so any
g-code src file is preinspected and made compatible with the new rules
and saved after making a backup copy of the old code. Not all users of
linuxcnc are coding gods but this has worked quite well several times in
past history. I may & probably will continue to crave my own g-codes,
but there are many more users using something that looks at the designer
programs output and translates to g-codes, usually very inefficiently
because they have zero knowledge about any of the ways linuxcnc can do a
loop. So it has to unwind the loop into gigabytes of repetitive g-code.
And it Just Works.
>>> _______________________________________________
>> 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
HL
Hans L
Tue, Sep 16, 2025 8:11 PM
Why does all this happen? would it not be better to simply have defaults of
start = 0.0
angle = 360
or is protecting legacy behavior?
Yes, there was a time when rotate_extrude existed without the angle
parameter. As the person who added the angle parameter to rotate_extrude,
it was decided at that time to keep legacy behavior in the case of full
rotation (which was previously the only option, obviously), so that results
would not differ in cases of $fn=3 etc.
>
> Why does all this happen? would it not be better to simply have defaults of
> start = 0.0
> angle = 360
> or is protecting legacy behavior?
>
Yes, there was a time when rotate_extrude existed without the angle
parameter. As the person who added the angle parameter to rotate_extrude,
it was decided at that time to keep legacy behavior in the case of full
rotation (which was previously the only option, obviously), so that results
would not differ in cases of $fn=3 etc.
CM
Curt McDowell
Wed, Sep 17, 2025 2:10 AM
On 9/15/25 09:01, Jordan Brown via Discuss wrote:
Maybe at the release after this one we can think about removing the
special case and the deprecation message.
Breaking compatibility, even in the smallest way, should never be
allowed. There must never be a case where you download an .scad file and
the thing that gets rendered is not what the author saw. We'd be
downloading .scad files from a few years ago on Thingiverse and getting
garbage out.
Think of how horrible Linux would be if Torvalds wasn't so exacting
about kernel API compatibility, to the point that even buggy behavior
must remain.
Python maintained strict compatibility. The only way they moved forward
was to collect all the incompatible changes and start a new language
dialect. Even going from Python 2 to Python 3 has been somewhat painful.
I use a music typesetting program LilyPond in which the language version
(= release version) must be specified at the top of the source file and
it comes with a conversion script that tries to upgrade source files.
That seems pretty close to ideal and music never fails to render
beautifully and correctly (which when you come down to it, is really the
only thing that matters).
OpenSCAD could support a dialect flag at the top of a file, like: //
[language-version: 2021.01]
Regards,
Curt
On 9/15/25 09:01, Jordan Brown via Discuss wrote:
> Maybe at the release after this one we can think about removing the
> special case and the deprecation message.
Breaking compatibility, even in the smallest way, should never be
allowed. There must never be a case where you download an .scad file and
the thing that gets rendered is not what the author saw. We'd be
downloading .scad files from a few years ago on Thingiverse and getting
garbage out.
Think of how horrible Linux would be if Torvalds wasn't so exacting
about kernel API compatibility, to the point that even buggy behavior
must remain.
Python maintained strict compatibility. The only way they moved forward
was to collect all the incompatible changes and start a new language
dialect. Even going from Python 2 to Python 3 has been somewhat painful.
I use a music typesetting program LilyPond in which the language version
(= release version) must be specified at the top of the source file and
it comes with a conversion script that tries to upgrade source files.
That seems pretty close to ideal and music never fails to render
beautifully and correctly (which when you come down to it, is really the
only thing that matters).
OpenSCAD could support a dialect flag at the top of a file, like: //
[language-version: 2021.01]
Regards,
Curt
JB
Jordan Brown
Wed, Sep 17, 2025 6:18 AM
On 9/16/2025 7:10 PM, Curt McDowell via Discuss wrote:
On 9/15/25 09:01, Jordan Brown via Discuss wrote:
Maybe at the release after this one we can think about removing the
special case and the deprecation message.
Breaking compatibility, even in the smallest way, should never be allowed.
"Never" is a very long time.
I work on enterprise-grade software. Compatibility is our bread and
butter, because people run their mission-critical applications on our
systems. We spend huge amounts of effort on it. And yet we
occasionally need to break things to make progress - and that's with
paying customers and paid staff.
Think of how horrible Linux would be if Torvalds wasn't so exacting
about kernel API compatibility, to the point that even buggy behavior
must remain.
I don't run Linux, so I don't know how well they've done on application
compatibility in that ecosystem. Based on what I've seen from the
fringes... not well.
Python maintained strict compatibility. The only way they moved
forward was to collect all the incompatible changes and start a new
language dialect. Even going from Python 2 to Python 3 has been
somewhat painful.
And yet... everybody seems to think that they need to precisely match
their Python install to their expectations. At work, for our product,
we for some reason feel compelled to include the last three or so Python
releases. The Python 2-to-3 upgrade was a huge project, and we're still
finding an occasional bug. I have no idea why we use it; it's a
compatibility disaster area.
OpenSCAD could support a dialect flag at the top of a file, like: //
[language-version: 2021.01]
If you really want to precisely support an old version... install the
old version.
On 9/16/2025 7:10 PM, Curt McDowell via Discuss wrote:
> On 9/15/25 09:01, Jordan Brown via Discuss wrote:
>> Maybe at the release after this one we can think about removing the
>> special case and the deprecation message.
> Breaking compatibility, even in the smallest way, should never be allowed.
"Never" is a very long time.
I work on enterprise-grade software. Compatibility is our bread and
butter, because people run their mission-critical applications on our
systems. We spend huge amounts of effort on it. And yet we
occasionally need to break things to make progress - and that's with
paying customers and paid staff.
> Think of how horrible Linux would be if Torvalds wasn't so exacting
> about kernel API compatibility, to the point that even buggy behavior
> must remain.
I don't run Linux, so I don't know how well they've done on application
compatibility in that ecosystem. Based on what I've seen from the
fringes... not well.
> Python maintained strict compatibility. The only way they moved
> forward was to collect all the incompatible changes and start a new
> language dialect. Even going from Python 2 to Python 3 has been
> somewhat painful.
And yet... everybody seems to think that they need to precisely match
their Python install to their expectations. At work, for our product,
we for some reason feel compelled to include the last three or so Python
releases. The Python 2-to-3 upgrade was a huge project, and we're still
finding an occasional bug. I have no idea why we use it; it's a
compatibility disaster area.
> OpenSCAD could support a dialect flag at the top of a file, like: //
> [language-version: 2021.01]
If you really want to precisely support an old version... install the
old version.
CM
Curt McDowell
Wed, Sep 17, 2025 7:06 AM
On 9/16/2025 11:18 PM, Jordan Brown via Discuss wrote:
"Never" is a very long time.
But "Never" is the answer. It should *never *break, and in particular,
it should be *impossible *to *ever *produce wrong results.
I work on enterprise-grade software. Compatibility is our bread and
butter, because people run their mission-critical applications on our
systems. We spend huge amounts of effort on it. And yet we
occasionally need to break things to make progress - and that's with
paying customers and paid staff.
You say you spend a huge amount of effort on it, yet here, basically no
effort. Printing a warning is no effort. And removing the warning after
one release cycle is actually diabolical.
I don't run Linux, so I don't know how well they've done on
application compatibility in that ecosystem. Based on what I've seen
from the fringes... not well.
If you don't run Linux, you shouldn't cast shade on it. I just ran some
old LMbench binaries from 2003 and they're quite fine. Windows has done
quite well in that regard, too. The commitment to compatibility lasts
decades, and wrong output is never acceptable.
OpenSCAD could support a dialect flag at the top of a file, like: //
[language-version: 2021.01]
If you really want to precisely support an old version... install the
old version.
What do you mean by this weasel word, "precisely"? That is a very low
standard. I'm trying to give you an out, because if the version were at
the top of the file, you could easy consult it and not be breaking
people's code.
In your proposal "install the old version", does everyone indicate what
version of OpenSCAD their .scad file needs, and how does that
information get through to the consumer? When they download a .scad from
Thingiverse, should they message the author asking why their print keeps
coming out weird, and will the author know why? How many version of
OpenSCAD should they expect to keep on hand? If they're reliant on an
older library, are they thereafter frozen on a particular version?
Developers need to deal with this properly, not thousands of frustrated
users improperly.
On 9/16/2025 11:18 PM, Jordan Brown via Discuss wrote:
> "Never" is a very long time.
But "Never" is the answer. It should *never *break, and in particular,
it should be *impossible *to *ever *produce wrong results.
> I work on enterprise-grade software. Compatibility is our bread and
> butter, because people run their mission-critical applications on our
> systems. We spend huge amounts of effort on it. And yet we
> occasionally need to break things to make progress - and that's with
> paying customers and paid staff.
You say you spend a huge amount of effort on it, yet here, basically no
effort. Printing a warning is no effort. And removing the warning after
one release cycle is actually diabolical.
> I don't run Linux, so I don't know how well they've done on
> application compatibility in that ecosystem. Based on what I've seen
> from the fringes... not well.
If you don't run Linux, you shouldn't cast shade on it. I just ran some
old LMbench binaries from 2003 and they're quite fine. Windows has done
quite well in that regard, too. The commitment to compatibility lasts
decades, and wrong output is never acceptable.
>> OpenSCAD could support a dialect flag at the top of a file, like: //
>> [language-version: 2021.01]
> If you really want to precisely support an old version... install the
> old version.
What do you mean by this weasel word, "precisely"? That is a very low
standard. I'm trying to give you an out, because if the version were at
the top of the file, you could easy consult it and not be breaking
people's code.
In your proposal "install the old version", does everyone indicate what
version of OpenSCAD their .scad file needs, and how does that
information get through to the consumer? When they download a .scad from
Thingiverse, should they message the author asking why their print keeps
coming out weird, and will the author know why? How many version of
OpenSCAD should they expect to keep on hand? If they're reliant on an
older library, are they thereafter frozen on a particular version?
Developers need to deal with this properly, not thousands of frustrated
users improperly.
RW
Raymond West
Wed, Sep 17, 2025 8:32 AM
If it is 'that necessary', have another function, 'rotate_extrude_2', or
'son_of_rotate_extrude' if you prefer. Change nothing, keep it pure.
On 17/09/2025 08:06, Curt McDowell via Discuss wrote:
On 9/16/2025 11:18 PM, Jordan Brown via Discuss wrote:
"Never" is a very long time.
But "Never" is the answer. It should *never *break, and in particular,
it should be *impossible *to *ever *produce wrong results.
I work on enterprise-grade software. Compatibility is our bread and
butter, because people run their mission-critical applications on our
systems. We spend huge amounts of effort on it. And yet we
occasionally need to break things to make progress - and that's with
paying customers and paid staff.
You say you spend a huge amount of effort on it, yet here, basically
no effort. Printing a warning is no effort. And removing the warning
after one release cycle is actually diabolical.
I don't run Linux, so I don't know how well they've done on
application compatibility in that ecosystem. Based on what I've seen
from the fringes... not well.
If you don't run Linux, you shouldn't cast shade on it. I just ran
some old LMbench binaries from 2003 and they're quite fine. Windows
has done quite well in that regard, too. The commitment to
compatibility lasts decades, and wrong output is never acceptable.
OpenSCAD could support a dialect flag at the top of a file, like: //
[language-version: 2021.01]
If you really want to precisely support an old version... install the
old version.
What do you mean by this weasel word, "precisely"? That is a very low
standard. I'm trying to give you an out, because if the version were
at the top of the file, you could easy consult it and not be breaking
people's code.
In your proposal "install the old version", does everyone indicate
what version of OpenSCAD their .scad file needs, and how does that
information get through to the consumer? When they download a .scad
from Thingiverse, should they message the author asking why their
print keeps coming out weird, and will the author know why? How many
version of OpenSCAD should they expect to keep on hand? If they're
reliant on an older library, are they thereafter frozen on a
particular version?
Developers need to deal with this properly, not thousands of
frustrated users improperly.
OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org
If it is 'that necessary', have another function, 'rotate_extrude_2', or
'son_of_rotate_extrude' if you prefer. Change nothing, keep it pure.
On 17/09/2025 08:06, Curt McDowell via Discuss wrote:
> On 9/16/2025 11:18 PM, Jordan Brown via Discuss wrote:
>> "Never" is a very long time.
> But "Never" is the answer. It should *never *break, and in particular,
> it should be *impossible *to *ever *produce wrong results.
>> I work on enterprise-grade software. Compatibility is our bread and
>> butter, because people run their mission-critical applications on our
>> systems. We spend huge amounts of effort on it. And yet we
>> occasionally need to break things to make progress - and that's with
>> paying customers and paid staff.
> You say you spend a huge amount of effort on it, yet here, basically
> no effort. Printing a warning is no effort. And removing the warning
> after one release cycle is actually diabolical.
>> I don't run Linux, so I don't know how well they've done on
>> application compatibility in that ecosystem. Based on what I've seen
>> from the fringes... not well.
> If you don't run Linux, you shouldn't cast shade on it. I just ran
> some old LMbench binaries from 2003 and they're quite fine. Windows
> has done quite well in that regard, too. The commitment to
> compatibility lasts decades, and wrong output is never acceptable.
>>> OpenSCAD could support a dialect flag at the top of a file, like: //
>>> [language-version: 2021.01]
>> If you really want to precisely support an old version... install the
>> old version.
>
> What do you mean by this weasel word, "precisely"? That is a very low
> standard. I'm trying to give you an out, because if the version were
> at the top of the file, you could easy consult it and not be breaking
> people's code.
>
> In your proposal "install the old version", does everyone indicate
> what version of OpenSCAD their .scad file needs, and how does that
> information get through to the consumer? When they download a .scad
> from Thingiverse, should they message the author asking why their
> print keeps coming out weird, and will the author know why? How many
> version of OpenSCAD should they expect to keep on hand? If they're
> reliant on an older library, are they thereafter frozen on a
> particular version?
>
> Developers need to deal with this properly, not thousands of
> frustrated users improperly.
>
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email todiscuss-leave@lists.openscad.org
Replying to:
Empathy v1.0
2025 ©emwd.com