discuss@lists.openscad.org

OpenSCAD general discussion Mailing-list

View all threads

Preparing for the future - documenting objects and $this from Peter K's notes

V
vulcan_@mac.com
Tue, Aug 19, 2025 10:32 PM

Yes I am still interested in improving OpenSCAD docs .. but i have turned over a new leaf, I am going to ask for feedback before I make any large changes.

To that end .. in another thread i asked about documenting $this as a feature of objects (for use in member functions) and the answer from Peter K, and others, was “too soon“

I already had a prototype page for Objects in my sandbox and i opened a discussion page on it where anyone can give further feedback .. or use this thread

Of course i used Peter’s example code fragments to see what is already working in the dev snapshot and so i have some questions:

1  Y Combinator

I tried Peter’s Y Combinator suggestion as example 1 in the Functions as Members section but it only works when the member function is defined as a lambda and then assigned to a member when an object is being defined. The 2 lines at the end of the code fragment are commented out because they throw error messages about ‘f’ not being defined. So the combinator does not work using the form suggested by Peter

is this a bug? or just not a fully implemented feature?

2 Context and Scope section

where on the list of contexts should special variables be? Or should their use in a member function be documented separately because they are a whole nother sort of beastie?

3 Members may be referenced in either form; $this.name or $this["name"].

I state this as it makes sense that the implementation will offer both ways .. but is this going to be true?

4 Functions remain bound to the object until assigned to another object:

Does this text need more details to make sense? obviously the example code is only partial - but is the issue well enough covered that nothing more needs to be said?

I will be adding and updating this page using the input i have from Jordan Brown and others so it will get simpler and better in the near future .. but my curiosity about the $this feature drives this discussion

Yes I am still interested in improving OpenSCAD docs .. but i have turned over a new leaf, I am going to ask for feedback *before* I make any large changes. To that end .. in another thread i asked about documenting $this as a feature of objects (for use in member functions) and the answer from Peter K, and others, was “too soon“ I already had a [prototype page for Objects in my sandbox](https://en.wikibooks.org/wiki/User:VulcanWikiEdit/sandbox/Objects#Functions_as_Members) and i opened a discussion page on it where anyone can give further feedback .. or use this thread Of course i used Peter’s example code fragments to see what is already working in the dev snapshot and so i have some questions: 1 Y Combinator I tried Peter’s Y Combinator suggestion as example 1 in the [Functions as Members](https://en.wikibooks.org/wiki/User:VulcanWikiEdit/sandbox/Objects#Functions_as_Members) section but it only works when the member function is defined as a lambda and then assigned to a member when an object is being defined. The 2 lines at the end of the code fragment are commented out because they throw error messages about ‘f’ not being defined. So the combinator does not work using the form suggested by Peter is this a bug? or just not a fully implemented feature? 2 Context and Scope section where on the list of contexts should special variables be? Or should their use in a member function be documented separately because they are a whole nother sort of beastie? 3 Members may be referenced in either form; $this.name or $this\["name"\]. I state this as it makes sense that the implementation will offer both ways .. but is this going to be true? 4 Functions remain bound to the object until assigned to another object: Does this text need more details to make sense? obviously the example code is only partial - but is the issue well enough covered that nothing more needs to be said? I will be adding and updating this page using the input i have from Jordan Brown and others so it will get simpler and better in the near future .. but my curiosity about the $this feature drives this discussion
JB
Jordan Brown
Tue, Aug 19, 2025 10:35 PM

On 8/20/2025 12:32 AM, vulcan_--- via Discuss wrote:

To that end .. in another thread i asked about documenting $this as a
feature of objects (for use in member functions) and the answer from
Peter K, and others, was “too soon“

In my opinion, still "too soon".

On 8/20/2025 12:32 AM, vulcan_--- via Discuss wrote: > > To that end .. in another thread i asked about documenting $this as a > feature of objects (for use in member functions) and the answer from > Peter K, and others, was “too soon“ > In my opinion, still "too soon".
JH
Jeffrey Hayes
Wed, Aug 20, 2025 8:54 AM

ok, the page is just going to sit there till the dust settles on objects

Jeff on the pad

On 20 Aug 2025, at 00:36, Jordan Brown openscad@jordan.maileater.net wrote:

In my opinion, still "too soon".

ok, the page is just going to sit there till the dust settles on objects Jeff on the pad > On 20 Aug 2025, at 00:36, Jordan Brown <openscad@jordan.maileater.net> wrote: > > In my opinion, still "too soon". > >
GH
gene heskett
Wed, Aug 20, 2025 3:08 PM

On 8/20/25 04:55, Jeffrey Hayes via Discuss wrote:

ok, the page is just going to sit there till the dust settles on objects

Jeff on the pad

On 20 Aug 2025, at 00:36, Jordan Brown openscad@jordan.maileater.net wrote:

In my opinion, still "too soon".

As a user who likes to use something from the bleeding edge, I would
like to see new stuff added to the bottom of the cheat sheet as they are
added to the monthly builds, so we A: know it there, and B: can
intelligently test the new code reporting successes and failures.

Since I am composing for 3d printing, a feature I'd love is a report
that when there are multiple parts, printed together, either in blank
space created by difference() cutouts or just separated on the bed,  a
check to warn about miss-matches at bed surface, aka the bottom of all
the parts being miss-matched, preferably giving the numerical output
that could be used in a translate([0.0.n]) statement to fix it for
printing. Doing that multiple parts thing matching often exceeds the
amount of time it took to design the parts.  It took hours just to make
the attached .png printable, which is intended to become a paper cutter
for making civil war cartridges. I've yet to do the overhead cutter
wheel assembly. The blue part is dovetail supports later removed. Not
too cleanly but that does not matter for this other than aesthetics, its
above the dovetail in the base part on the left when the right part is
flipped over and assembled into the left part. . .


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 8/20/25 04:55, Jeffrey Hayes via Discuss wrote: > ok, the page is just going to sit there till the dust settles on objects > > Jeff on the pad > >> On 20 Aug 2025, at 00:36, Jordan Brown <openscad@jordan.maileater.net> wrote: >> >> In my opinion, still "too soon". As a user who likes to use something from the bleeding edge, I would like to see new stuff added to the bottom of the cheat sheet as they are added to the monthly builds, so we A: know it there, and B: can intelligently test the new code reporting successes and failures. Since I am composing for 3d printing, a feature I'd love is a report that when there are multiple parts, printed together, either in blank space created by difference() cutouts or just separated on the bed,  a check to warn about miss-matches at bed surface, aka the bottom of all the parts being miss-matched, preferably giving the numerical output that could be used in a translate([0.0.n]) statement to fix it for printing. Doing that multiple parts thing matching often exceeds the amount of time it took to design the parts.  It took hours just to make the attached .png printable, which is intended to become a paper cutter for making civil war cartridges. I've yet to do the overhead cutter wheel assembly. The blue part is dovetail supports later removed. Not too cleanly but that does not matter for this other than aesthetics, its above the dovetail in the base part on the left when the right part is flipped over and assembled into the left part. . . > > _______________________________________________ > 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
MK
Marius Kintel
Wed, Aug 20, 2025 3:35 PM

On Aug 20, 2025, at 11:08, gene heskett via Discuss discuss@lists.openscad.org wrote:

As a user who likes to use something from the bleeding edge, I would like to see new stuff added to the bottom of the cheat sheet as they are added to the monthly builds, so we A: know it there, and B: can intelligently test the new code reporting successes and failures.

Yeah, that’s the ideal scenario. We’ve tried to push for this in the past, as a way of gatekeeping merging of new feature, but it often ends up stalling indefinitely as developers tend to have an aversion towards writing docs, so we’re more lenient now and allow docs to trail a bit.

The core team will still gatekeep experimental features by making sure docs are available before it graduated from experimental mode.

That said, doc contributions are open to everyone :)

-Marius

On Aug 20, 2025, at 11:08, gene heskett via Discuss <discuss@lists.openscad.org> wrote: > As a user who likes to use something from the bleeding edge, I would like to see new stuff added to the bottom of the cheat sheet as they are added to the monthly builds, so we A: know it there, and B: can intelligently test the new code reporting successes and failures. > Yeah, that’s the ideal scenario. We’ve tried to push for this in the past, as a way of gatekeeping merging of new feature, but it often ends up stalling indefinitely as developers tend to have an aversion towards writing docs, so we’re more lenient now and allow docs to trail a bit. The core team will still gatekeep experimental features by making sure docs are available before it graduated from experimental mode. That said, doc contributions are open to everyone :) -Marius
L
larry
Wed, Aug 20, 2025 3:59 PM

On Wed, 2025-08-20 at 11:08 -0400, gene heskett via Discuss wrote:

On 8/20/25 04:55, Jeffrey Hayes via Discuss wrote:

ok, the page is just going to sit there till the dust settles on objects

Jeff on the pad

On 20 Aug 2025, at 00:36, Jordan Brown openscad@jordan.maileater.net wrote:

In my opinion, still "too soon".

As a user who likes to use something from the bleeding edge, I would
like to see new stuff added to the bottom of the cheat sheet as they are
added to the monthly builds, so we A: know it there, and B: can
intelligently test the new code reporting successes and failures.

Great idea!
Mario points out a valid concern about docs trailing a bit, but I think
that just the addition of a section in the cheat sheet called 'New',
containing the name of a new thing, with or without a link to the docs
about the thing, would be helpful. It could serve as way for users to
to spot something coming or implemented without proper docs yet. It
might serve to attract people to work on the feature, or even to just
comment on it.

Since I am composing for 3d printing, a feature I'd love is a report
that when there are multiple parts, printed together, either in blank
space created by difference() cutouts or just separated on the bed,  a
check to warn about miss-matches at bed surface, aka the bottom of all
the parts being miss-matched, preferably giving the numerical output
that could be used in a translate([0.0.n]) statement to fix it for
printing. Doing that multiple parts thing matching often exceeds the
amount of time it took to design the parts.  It took hours just to make
the attached .png printable, which is intended to become a paper cutter
for making civil war cartridges. I've yet to do the overhead cutter
wheel assembly. The blue part is dovetail supports later removed. Not
too cleanly but that does not matter for this other than aesthetics, its
above the dovetail in the base part on the left when the right part is
flipped over and assembled into the left part. . .

I often use the '!' to render each part separately, and check the
positioning in the console.

On Wed, 2025-08-20 at 11:08 -0400, gene heskett via Discuss wrote: > > On 8/20/25 04:55, Jeffrey Hayes via Discuss wrote: > > ok, the page is just going to sit there till the dust settles on objects > > > > Jeff on the pad > > > > > On 20 Aug 2025, at 00:36, Jordan Brown <openscad@jordan.maileater.net> wrote: > > > > > > In my opinion, still "too soon". > As a user who likes to use something from the bleeding edge, I would > like to see new stuff added to the bottom of the cheat sheet as they are > added to the monthly builds, so we A: know it there, and B: can > intelligently test the new code reporting successes and failures. Great idea! Mario points out a valid concern about docs trailing a bit, but I think that just the addition of a section in the cheat sheet called 'New', containing the name of a new thing, with or without a link to the docs about the thing, would be helpful. It could serve as way for users to to spot something coming or implemented without proper docs yet. It might serve to attract people to work on the feature, or even to just comment on it. > Since I am composing for 3d printing, a feature I'd love is a report > that when there are multiple parts, printed together, either in blank > space created by difference() cutouts or just separated on the bed,  a > check to warn about miss-matches at bed surface, aka the bottom of all > the parts being miss-matched, preferably giving the numerical output > that could be used in a translate([0.0.n]) statement to fix it for > printing. Doing that multiple parts thing matching often exceeds the > amount of time it took to design the parts.  It took hours just to make > the attached .png printable, which is intended to become a paper cutter > for making civil war cartridges. I've yet to do the overhead cutter > wheel assembly. The blue part is dovetail supports later removed. Not > too cleanly but that does not matter for this other than aesthetics, its > above the dovetail in the base part on the left when the right part is > flipped over and assembled into the left part. . . > I often use the '!' to render each part separately, and check the positioning in the console.
GH
gene heskett
Wed, Aug 20, 2025 5:15 PM

On 8/20/25 11:59, larry via Discuss wrote:

On Wed, 2025-08-20 at 11:08 -0400, gene heskett via Discuss wrote:

On 8/20/25 04:55, Jeffrey Hayes via Discuss wrote:

ok, the page is just going to sit there till the dust settles on objects

Jeff on the pad

On 20 Aug 2025, at 00:36, Jordan Brown openscad@jordan.maileater.net wrote:

In my opinion, still "too soon".

As a user who likes to use something from the bleeding edge, I would
like to see new stuff added to the bottom of the cheat sheet as they are
added to the monthly builds, so we A: know it there, and B: can
intelligently test the new code reporting successes and failures.

Great idea!
Mario points out a valid concern about docs trailing a bit, but I think
that just the addition of a section in the cheat sheet called 'New',
containing the name of a new thing, with or without a link to the docs
about the thing, would be helpful. It could serve as way for users to
to spot something coming or implemented without proper docs yet. It
might serve to attract people to work on the feature, or even to just
comment on it.

Since I am composing for 3d printing, a feature I'd love is a report
that when there are multiple parts, printed together, either in blank
space created by difference() cutouts or just separated on the bed,  a
check to warn about miss-matches at bed surface, aka the bottom of all
the parts being miss-matched, preferably giving the numerical output
that could be used in a translate([0.0.n]) statement to fix it for
printing. Doing that multiple parts thing matching often exceeds the
amount of time it took to design the parts.  It took hours just to make
the attached .png printable, which is intended to become a paper cutter
for making civil war cartridges. I've yet to do the overhead cutter
wheel assembly. The blue part is dovetail supports later removed. Not
too cleanly but that does not matter for this other than aesthetics, its
above the dovetail in the base part on the left when the right part is
flipped over and assembled into the left part. . .

I often use the '!' to render each part separately, and check the
positioning in the console.

More than 1 way to skin that cat, I commonly set a local s var to
separate the parts, putting them about 5mm at closest, but reduce it
till only .5mm apart and blow it up till something breaks to magnify the
error. That of course isn't usable in proportional view settings


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 8/20/25 11:59, larry via Discuss wrote: > On Wed, 2025-08-20 at 11:08 -0400, gene heskett via Discuss wrote: >> On 8/20/25 04:55, Jeffrey Hayes via Discuss wrote: >>> ok, the page is just going to sit there till the dust settles on objects >>> >>> Jeff on the pad >>> >>>> On 20 Aug 2025, at 00:36, Jordan Brown <openscad@jordan.maileater.net> wrote: >>>> >>>> In my opinion, still "too soon". >> As a user who likes to use something from the bleeding edge, I would >> like to see new stuff added to the bottom of the cheat sheet as they are >> added to the monthly builds, so we A: know it there, and B: can >> intelligently test the new code reporting successes and failures. > Great idea! > Mario points out a valid concern about docs trailing a bit, but I think > that just the addition of a section in the cheat sheet called 'New', > containing the name of a new thing, with or without a link to the docs > about the thing, would be helpful. It could serve as way for users to > to spot something coming or implemented without proper docs yet. It > might serve to attract people to work on the feature, or even to just > comment on it. > >> Since I am composing for 3d printing, a feature I'd love is a report >> that when there are multiple parts, printed together, either in blank >> space created by difference() cutouts or just separated on the bed,  a >> check to warn about miss-matches at bed surface, aka the bottom of all >> the parts being miss-matched, preferably giving the numerical output >> that could be used in a translate([0.0.n]) statement to fix it for >> printing. Doing that multiple parts thing matching often exceeds the >> amount of time it took to design the parts.  It took hours just to make >> the attached .png printable, which is intended to become a paper cutter >> for making civil war cartridges. I've yet to do the overhead cutter >> wheel assembly. The blue part is dovetail supports later removed. Not >> too cleanly but that does not matter for this other than aesthetics, its >> above the dovetail in the base part on the left when the right part is >> flipped over and assembled into the left part. . . >> > I often use the '!' to render each part separately, and check the > positioning in the console. More than 1 way to skin that cat, I commonly set a local s var to separate the parts, putting them about 5mm at closest, but reduce it till only .5mm apart and blow it up till something breaks to magnify the error. That of course isn't usable in proportional view settings > _______________________________________________ > 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
BC
Bob Carlson
Wed, Aug 20, 2025 8:15 PM

I would never try to compose multiple parts to be printed together. I export (F7) each part then compose the print in the slicer. I use the the Prusa slicer.

-Bob
Tucson AZ

On Aug 20, 2025, at 11:08, gene heskett via Discuss discuss@lists.openscad.org wrote:

On 8/20/25 04:55, Jeffrey Hayes via Discuss wrote:

ok, the page is just going to sit there till the dust settles on objects

Jeff on the pad

On 20 Aug 2025, at 00:36, Jordan Brown openscad@jordan.maileater.net wrote:

In my opinion, still "too soon".

As a user who likes to use something from the bleeding edge, I would like to see new stuff added to the bottom of the cheat sheet as they are added to the monthly builds, so we A: know it there, and B: can intelligently test the new code reporting successes and failures.

Since I am composing for 3d printing, a feature I'd love is a report that when there are multiple parts, printed together, either in blank space created by difference() cutouts or just separated on the bed,  a check to warn about miss-matches at bed surface, aka the bottom of all the parts being miss-matched, preferably giving the numerical output that could be used in a translate([0.0.n]) statement to fix it for printing. Doing that multiple parts thing matching often exceeds the amount of time it took to design the parts.  It took hours just to make the attached .png printable, which is intended to become a paper cutter for making civil war cartridges. I've yet to do the overhead cutter wheel assembly. The blue part is dovetail supports later removed. Not too cleanly but that does not matter for this other than aesthetics, its above the dovetail in the base part on the left when the right part is flipped over and assembled into the left part. . .


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

<small_paper_cutter.png>_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org

I would never try to compose multiple parts to be printed together. I export (F7) each part then compose the print in the slicer. I use the the Prusa slicer. -Bob Tucson AZ > On Aug 20, 2025, at 11:08, gene heskett via Discuss <discuss@lists.openscad.org> wrote: > > > > On 8/20/25 04:55, Jeffrey Hayes via Discuss wrote: >> ok, the page is just going to sit there till the dust settles on objects >> >> Jeff on the pad >> >>> On 20 Aug 2025, at 00:36, Jordan Brown <openscad@jordan.maileater.net> wrote: >>> >>> In my opinion, still "too soon". > As a user who likes to use something from the bleeding edge, I would like to see new stuff added to the bottom of the cheat sheet as they are added to the monthly builds, so we A: know it there, and B: can intelligently test the new code reporting successes and failures. > > Since I am composing for 3d printing, a feature I'd love is a report that when there are multiple parts, printed together, either in blank space created by difference() cutouts or just separated on the bed, a check to warn about miss-matches at bed surface, aka the bottom of all the parts being miss-matched, preferably giving the numerical output that could be used in a translate([0.0.n]) statement to fix it for printing. Doing that multiple parts thing matching often exceeds the amount of time it took to design the parts. It took hours just to make the attached .png printable, which is intended to become a paper cutter for making civil war cartridges. I've yet to do the overhead cutter wheel assembly. The blue part is dovetail supports later removed. Not too cleanly but that does not matter for this other than aesthetics, its above the dovetail in the base part on the left when the right part is flipped over and assembled into the left part. . . >> >> _______________________________________________ >> 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 > > <small_paper_cutter.png>_______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org
GH
gene heskett
Wed, Aug 20, 2025 9:54 PM

On 8/20/25 16:15, Bob Carlson wrote:

I would never try to compose multiple parts to be printed together. I export (F7) each part then compose the print in the slicer. I use the the Prusa slicer.

So do I, but its the 2.8.2 version, I've not been able to make the
flatpak's run w/o locking up my machine. So tight the only recovery is
the power plug. No response to the front panel reset button.

-Bob
Tucson AZ

On Aug 20, 2025, at 11:08, gene heskett via Discuss discuss@lists.openscad.org wrote:

On 8/20/25 04:55, Jeffrey Hayes via Discuss wrote:

ok, the page is just going to sit there till the dust settles on objects

Jeff on the pad

On 20 Aug 2025, at 00:36, Jordan Brown openscad@jordan.maileater.net wrote:

In my opinion, still "too soon".

As a user who likes to use something from the bleeding edge, I would like to see new stuff added to the bottom of the cheat sheet as they are added to the monthly builds, so we A: know it there, and B: can intelligently test the new code reporting successes and failures.

Since I am composing for 3d printing, a feature I'd love is a report that when there are multiple parts, printed together, either in blank space created by difference() cutouts or just separated on the bed,  a check to warn about miss-matches at bed surface, aka the bottom of all the parts being miss-matched, preferably giving the numerical output that could be used in a translate([0.0.n]) statement to fix it for printing. Doing that multiple parts thing matching often exceeds the amount of time it took to design the parts.  It took hours just to make the attached .png printable, which is intended to become a paper cutter for making civil war cartridges. I've yet to do the overhead cutter wheel assembly. The blue part is dovetail supports later removed. Not too cleanly but that does not matter for this other than aesthetics, its above the dovetail in the base part on the left when the right part is flipped over and assembled into the left part. . .


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

<small_paper_cutter.png>_______________________________________________
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 8/20/25 16:15, Bob Carlson wrote: > I would never try to compose multiple parts to be printed together. I export (F7) each part then compose the print in the slicer. I use the the Prusa slicer. So do I, but its the 2.8.2 version, I've not been able to make the flatpak's run w/o locking up my machine. So tight the only recovery is the power plug. No response to the front panel reset button. > -Bob > Tucson AZ > > > >> On Aug 20, 2025, at 11:08, gene heskett via Discuss <discuss@lists.openscad.org> wrote: >> >> >> >> On 8/20/25 04:55, Jeffrey Hayes via Discuss wrote: >>> ok, the page is just going to sit there till the dust settles on objects >>> >>> Jeff on the pad >>> >>>> On 20 Aug 2025, at 00:36, Jordan Brown <openscad@jordan.maileater.net> wrote: >>>> >>>> In my opinion, still "too soon". >> As a user who likes to use something from the bleeding edge, I would like to see new stuff added to the bottom of the cheat sheet as they are added to the monthly builds, so we A: know it there, and B: can intelligently test the new code reporting successes and failures. >> >> Since I am composing for 3d printing, a feature I'd love is a report that when there are multiple parts, printed together, either in blank space created by difference() cutouts or just separated on the bed, a check to warn about miss-matches at bed surface, aka the bottom of all the parts being miss-matched, preferably giving the numerical output that could be used in a translate([0.0.n]) statement to fix it for printing. Doing that multiple parts thing matching often exceeds the amount of time it took to design the parts. It took hours just to make the attached .png printable, which is intended to become a paper cutter for making civil war cartridges. I've yet to do the overhead cutter wheel assembly. The blue part is dovetail supports later removed. Not too cleanly but that does not matter for this other than aesthetics, its above the dovetail in the base part on the left when the right part is flipped over and assembled into the left part. . . >>> _______________________________________________ >>> 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 >> >> <small_paper_cutter.png>_______________________________________________ >> 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