On 9/17/25 02:18, Jordan Brown via Discuss wrote: > [...] >> 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. That then assumes the old version is available for download for many years.  How likely is that to happen? > > > _______________________________________________ > 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/17/25 03:07, 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? First, downloading a .scad from Thingiverse? All I find are useless .stl's, not editable in most senses of the word.  I use precisely one thing from Thingiverse, the hot end air duct from the early prusa mk3s, printed in polycarb it works great on my homemade hotends. > > Developers need to deal with this properly, not thousands of > frustrated users improperly. Very well said.  Now, I have no clue where to squawk, but until I hit reply-list in the beta tbird, I had no clue who wrote this. Please compose yourself a sig so we  can see who wrote the msg, Curt M. 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

You haven’t looked hard enough. There are lots of OpenSCAD files on Thingiverse. It even implements the customizer, IIRC. On Wed, Sep 17, 2025 at 7:42 AM gene heskett via Discuss < discuss@lists.openscad.org> wrote: > On 9/17/25 03:07, 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? > First, downloading a .scad from Thingiverse? All I find are useless > .stl's, not editable in most senses of the word. I use precisely one > thing from Thingiverse, the hot end air duct from the early prusa mk3s, > printed in polycarb it works great on my homemade hotends. > > > > Developers need to deal with this properly, not thousands of > > frustrated users improperly. > Very well said. Now, I have no clue where to squawk, but until I hit > reply-list in the beta tbird, I had no clue who wrote this. Please > compose yourself a sig so we can see who wrote the msg, Curt M. > > 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

in that vein .. i was already writing something to suggest this idea: i have a suggestion: lets say we leave the legacy rotate_extrude() module in place .. forever, but emit a deprecation message to console so that folks loading an old script, or writing a new one, get told about a new module called (choose one): \- \[ \] rotational_extrude() \- \[ \] rotary_form() or any other name starting with "rota" so it will be suggested by name completion in the editor then we leave all the funky code as it is in rotate_extrude() so that really old code that depends on legacy behaviour, AND recent code that depends on the new behaviour, of the existing module keep on working .. but folks writing new code get a shape defined by the \`angle\` and \`start\` params in simple way we would like them to become accustomed to. the new module should start extruding from the +X axis *when start is not given* in all cases, which might mean changing how the extrusion is “drawn” for odd values of $fn ? after looking at the code i don’t think that needs to be changed because explicitly setting the angle like this: `rotate_extrude( 360, $fn=rotfn ) base_shape();` where rotfn is a Customizer variable .. spinning it through even and odd values the start of the extrusion stays at the default of zero\ so using the existing code, minus the special case handling of $fn, will work nicely .. we just need a name for the new module and FYI … `rotate_extrude( $fn=rotfn ) base_shape();` flips the start from -X when $fn is odd and +X when even .. which i think is a bug in the current rotate_extrude() as changing shape based on the $fn value should not (IMHO) be intended bahaviour.

It doesn't change on fn being odd or even. It simply is rotated 180 degrees. If you don't want that then pass 360 for the angle. Much better than having two modules. On Wed, 17 Sept 2025, 17:28 vulcan_--- via Discuss, < discuss@lists.openscad.org> wrote: > in that vein .. i was already writing something to suggest this idea: > > i have a suggestion: lets say we leave the legacy rotate_extrude() module > in place .. forever, but emit a deprecation message to console so that > folks loading an old script, or writing a new one, get told about a new > module called (choose one): > > - [ ] rotational_extrude() > > - [ ] rotary_form() > > or any other name starting with "rota" so it will be suggested by name > completion in the editor > > then we leave all the funky code as it is in rotate_extrude() so that > really old code that depends on legacy behaviour, AND recent code that > depends on the new behaviour, of the existing module keep on working .. but > folks writing new code get a shape defined by the `angle` and `start` > params in simple way we would like them to become accustomed to. > > the new module should start extruding from the +X axis *when start is not > given* in all cases, which might mean changing how the extrusion is > “drawn” for odd values of $fn ? after looking at the code i don’t think > that needs to be changed because explicitly setting the angle like this: > > rotate_extrude( 360, $fn=rotfn ) base_shape(); > > where rotfn is a Customizer variable .. spinning it through even and odd > values the start of the extrusion stays at the default of zero > so using the existing code, minus the special case handling of $fn, will > work nicely .. we just need a name for the new module > > and FYI … > > rotate_extrude( $fn=rotfn ) base_shape(); > > flips the start from -X when $fn is odd and +X when even .. which i think > is a bug in the current rotate_extrude() as changing shape based on the $fn > value should not (IMHO) be intended bahaviour. > > > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org

yep .. as i said .. explicitly setting the angle to anything prevents the value of $fn affecting the start point for the extrusion but the flip side of that is that when angle is not given, but is now set to the default of 360, that $fn being even or odd changes the shape of the extrusion is that expected behavior? to me that screams “side effect” and is undesirable at best

I'm not going to engage further on this philosophical debate. I eagerly await your fork where you maintain perfect compatibility forever, while fixing the bugs that make behavior inconsistent and while keeping the documentation clean enough for new readers.

On 9/17/2025 9:48 AM, vulcan_--- via Discuss wrote: > > yep .. as i said .. explicitly setting the angle to anything prevents > the value of $fn affecting the start point for the extrusion > > but the flip side of that is that when angle is not given, but is now > set to the default of 360, that $fn being even or odd changes the > shape of the extrusion > > is that expected behavior? > > to me that screams “side effect” and is undesirable at best > Example, please?  The only thing that the even/oddness of $fn controls is whether you get the deprecation message. Other than, of course, the number of sides. rotate_extrude() with no "angle" and no "start" always starts on -X, no matter what $fn/$fs/$fa are set to.

Jordan Brown wrote: > On 9/17/2025 9:48 AM, vulcan_--- via Discuss wrote: > > > but the flip side of that is that when angle is not given, but is now > > set to the default of 360, that $fn being even or odd changes the > > shape of the extrusion > > Example, please?  The only thing that the even/oddness of $fn controls > is whether you get the deprecation message. oh .. wait .. i was saying that wrong. It is not flipping on the value of $fn .. it is flipping on\ one of my Customizer values flipping true/false. this is the trimmed down code i was using to explore rotate_extrude() https://pastebin.com/RhGk0Bfy looking down the Z axis :  the red shapes are the base 2D child on the X-Y plane, and the Yellow are the rotated basis for the extrude so what i think is a bug will be seen flipping the “rotgiv“ value between true and false the angle and start are the same both ways, 360 and 0, but when $fn is odd you can see the shape\ starting at +X when angle and start are given, and at -X . so .. i get that this is a feature that preserves legacy behavior but different shapes get generated with\ default values from when they are explicitly given just sayin’

On 9/17/2025 11:42 AM, vulcan_--- via Discuss wrote: > > the angle and start are the same both ways, 360 and 0, but when $fn is > odd you can see the shape > starting at +X when angle and start are given, and at -X . > Indeed, for a compete 360° extrusion the difference between starting at 0 and starting at 180 is only visible when $fn is odd. > so .. i get that this is a feature that preserves legacy behavior but > different shapes get generated with > default values from when they are explicitly given > Yes.  Explicitly setting "angle" triggers a different behavior than leaving it unspecified.