Userspace extensibility of core modules, and minimalist OpenSCAD

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Userspace extensibility of core modules, and minimalist OpenSCAD

JordanBrown
Torsten says in issue #3552:
So instead of discussing as very narrow feature, my suggestion would be to look at more general strategies for solving this kind of issue. The first thing coming to mind is full support for customizing built-in module so user space code can really extend behavior of for example circle() while still being able to call built-in circle().

Userspace extensions to core modules seem incredibly powerful and incredibly likely to cause support problems.  You won't be able to tell from looking at a snippet whether they're using the stock versions of the core modules, or modified ones.

One variation on that is to *remove* stuff from the core, and put it into a library that's included by default.  (Perhaps with a switch.)

Perhaps "naked" OpenSCAD would, for instance, have only polygon and polyhedron, and anything else would be implemented in the standard library... and there would be a way to not include the standard library.

That would be incredibly powerful for the tinkerer.  Tinkerers could grab a copy of the standard library and customize it to their hearts' content.  It would have the dual advantage / disadvantage of making it easy for many more people to supply alternate implementations and to propose additions to or changes in the standard library.

But it too has the potential for being a support nightmare, since different people might be running with different implementations.  (Worst, they could have edited the standard library that came with OpenSCAD, so there wouldn't even be the evidence of an include<>... and they edited it six months ago, and have completely forgotten about the edit.)

Net, I suspect that the end result of either variation would be bad.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Userspace extensibility of core modules, and minimalist OpenSCAD

adrianv
JordanBrown wrote

> Torsten says in issue #3552:
>> So instead of discussing as very narrow feature, my suggestion would
>> be to look at more general strategies for solving this kind of issue.
>> The first thing coming to mind is full support for customizing
>> built-in module so user space code can really extend behavior of for
>> example |circle()| while still being able to call built-in |circle()|.
>
> Userspace extensions to core modules seem incredibly powerful and
> incredibly likely to cause support problems.  You won't be able to tell
> from looking at a snippet whether they're using the stock versions of
> the core modules, or modified ones.

We already have this situation, that you can redefine the core modules.  It
seems to me like it shouldn't really be a problem because people who
redefine these modules should also be posting the include or use statements
that redefined them.  


> One variation on that is to *remove* stuff from the core, and put it
> into a library that's included by default.  (Perhaps with a switch.)
>
> Perhaps "naked" OpenSCAD would, for instance, have only polygon and
> polyhedron, and anything else would be implemented in the standard
> library... and there would be a way to not include the standard library.

This will make things slower.  Though maybe not enough to really matter.
BOSL2 reimplements all the core modules, which is very tricky because
polygon rounds to 1/1024 and polyhedron only rounds to 2^-20, so you get
different results if you, for example, make a cube by extruding a square
instead of making a cube with cube().  The real win would be to make it
possible to call the original modules even if they've been redefined.  


>  
>
> That would be incredibly powerful for the tinkerer.  Tinkerers could
> grab a copy of the standard library and customize it to their hearts'
> content.  It would have the dual advantage / disadvantage of making it
> easy for many more people to supply alternate implementations and to
> propose additions to or changes in the standard library.

I really don't see the advantage of this idea compared to letting a
redefined module call the original.


>  
> But it too has the potential for being a support nightmare, since
> different people might be running with different implementations. 
> (Worst, they could have edited the standard library that came with
> OpenSCAD, so there wouldn't even be the evidence of an include<>... and
> they edited it six months ago, and have completely forgotten about the
> edit.)
>
> Net, I suspect that the end result of either variation would be bad.

I think that people who choose to edit the standard library in place in a
situation like you describe deserve what they get.  You can't worry about
that.  I think that the minimalist standard library is not a good idea.  It
takes things in the wrong direction.  For the most part, we need more
functionality in OpenSCAD and less in userspace, not the reverse.  

We already have redefinable core modules.  BOSL2 redefines many of them.  So
you're stuck with that.  It would be nice if we could do it more robustly.    





--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Userspace extensibility of core modules, and minimalist OpenSCAD

JordanBrown
On 12/26/2020 7:27 PM, adrianv wrote:
I think that people who choose to edit the standard library in place in a situation like you describe deserve what they get. You can't worry about that.

Support has a cost, even for freeware.

I think that the minimalist standard library is not a good idea. It  takes things in the wrong direction. For the most part, we need more functionality in OpenSCAD and less in userspace, not the reverse.

We need computationally expensive functionality to be in C++.

Computationally cheap stuff, like the circle-radius stuff that brought up the discussion, can be in userspace. Note that when you put, say, "center" in the C++ code, you risk bugs that crash the program, for negligible performance improvement.

One rough dividing line might be whether the operation is scaled by the number of points.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Userspace extensibility of core modules, and minimalist OpenSCAD

adrianv
JordanBrown wrote
> On 12/26/2020 7:27 PM, adrianv wrote:
>> I think that people who choose to edit the standard library in place
>> in a situation like you describe deserve what they get. You can't
>> worry about that.
>
> Support has a cost, even for freeware.

Are you concerned about the support issues for folks that hack the OpenSCAD
source to change behavior of core modules and then seek support for it?  Of
course, the idea of making the core callable in override modules avoids this
concern entirely.  And people who post support questions should be giving
their include/use statements.   Otherwise you may as well say that libraries
are a support disaster and shouldn't be encouraged.  (It's been said.)  


>> I think that the minimalist standard library is not a good idea. It 
>> takes things in the wrong direction. For the most part, we need more
>> functionality in OpenSCAD and less in userspace, not the reverse.
>
> We need computationally expensive functionality to be in C++.
>
> Computationally cheap stuff, like the circle-radius stuff that brought
> up the discussion, can be in userspace. Note that when you put, say,
> "center" in the C++ code, you risk bugs that crash the program, for
> negligible performance improvement.
>
> One rough dividing line might be whether the operation is scaled by the
> number of points.

We were just benchmarking this:  the native sphere() implementation is 37
times faster (to preview) than a reimplementation in userspace.   This may
not be slow enough to matter, but it's a pretty significant difference.
Your minimalist idea would have us implement linear_extrude in userspace as
a polyhedron, for example, which I assume will also be a significant
performance hit.  The amount of functionality that is O(1) instead of O(n)
in the core modules is pretty limited.  The center operator is about it.  In
fact, the reason BOSL reimplements core modules is to provide relative
object anchoring in a consistent way across the library, so basically like a
fancier "center" operation.   That's O(1) so no issue with
performance---except that sphere is 37 times slower because it has to be
reimplemented.




--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Userspace extensibility of core modules, and minimalist OpenSCAD

JordanBrown
In reply to this post by JordanBrown
[  #!&(* I need to find a way to automate what address I send from. Thunderbird used to have a way, but then it broke...]

JordanBrown wrote
On 12/26/2020 7:27 PM, adrianv wrote:
I think that people who choose to edit the standard library in place
in a situation like you describe deserve what they get. You can't
worry about that.

Support has a cost, even for freeware.

Are you concerned about the support issues for folks that hack the OpenSCAD
source to change behavior of core modules and then seek support for it? Of
course, the idea of making the core callable in override modules avoids this
concern entirely. And people who post support questions should be giving
their include/use statements. Otherwise you may as well say that libraries
are a support disaster and shouldn't be encouraged. (It's been said.)

I think that the minimalist standard library is not a good idea. It 
takes things in the wrong direction. For the most part, we need more
functionality in OpenSCAD and less in userspace, not the reverse.

We need computationally expensive functionality to be in C++.

Computationally cheap stuff, like the circle-radius stuff that brought
up the discussion, can be in userspace. Note that when you put, say,
"center" in the C++ code, you risk bugs that crash the program, for
negligible performance improvement.

One rough dividing line might be whether the operation is scaled by the
number of points.

We were just benchmarking this: the native sphere() implementation is 37
times faster (to preview) than a reimplementation in userspace. This may
not be slow enough to matter, but it's a pretty significant difference. Your minimalist idea would have us implement linear_extrude in userspace as
a polyhedron, for example, which I assume will also be a significant
performance hit. The amount of functionality that is O(1) instead of O(n)
in the core modules is pretty limited. The center operator is about it. In
fact, the reason BOSL reimplements core modules is to provide relative
object anchoring in a consistent way across the library, so basically like a
fancier "center" operation. That's O(1) so no issue with
performance---except that sphere is 37 times slower because it has to be
reimplemented.




--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Userspace extensibility of core modules, and minimalist OpenSCAD

Troberg
In reply to this post by JordanBrown
I'm pretty fine with the core being what it is, but it would be nice to have
some kind of "plugin framework" where we could write extensions in a more
capable language and with full access to the geometries of the objects.

For example, I've discussed a 3D version of offset() in a separate thread,
something which can't be done in OpenSCAD code (theoretically, one could do
at least parts of it with minkowski(), but it would be like modelling
continental drift in real-time), and the possibility to low level code stuff
to extend the language would make stuff like that possible.



--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Userspace extensibility of core modules, and minimalist OpenSCAD

JordanBrown
In reply to this post by adrianv
On 12/26/2020 8:17 PM, adrianv wrote:
JordanBrown wrote
Support has a cost, even for freeware.

Are you concerned about the support issues for folks that hack the OpenSCAD source to change behavior of core modules and then seek support for it? Of course, the idea of making the core callable in override modules avoids this concern entirely. And people who post support questions should be giving their include/use statements. Otherwise you may as well say that libraries are a support disaster and shouldn't be encouraged. (It's been said.)


I'm concerned about somebody who naïvely goes and tweaks their standard library because they can, then six months later, having forgotten that tweak, runs into trouble and asks for help.  They give their entire source file, with no include/use statements (or with "use <stdlib.scad>", depending on how the standard library works), and everybody is mystified.

And yeah... it's not exactly "libraries are a support disaster".  It's "sources are a support disaster".  And maybe that's just part of the cost of doing business in the FOSS world, so to speak.

The C++ stuff is relatively immune, because it's a *lot* more work to build the C++ than it would be to tweak a source library.  Fewer people build the C++, and they'd be more likely to remember that they're running a private build.

One rough dividing line might be whether the operation is scaled by the number of points.

We were just benchmarking this: the native sphere() implementation is 37 times faster (to preview) than a reimplementation in userspace. This may not be slow enough to matter, but it's a pretty significant difference.


That's plenty slow to matter.  And sphere is one of the "scales by the number of points" cases, so would fall on the C++ side of my rough dividing line.

Your minimalist idea would have us implement linear_extrude in userspace as
a polyhedron, for example, which I assume will also be a significant
performance hit.

I wouldn't have thought of implementing linear_extrude in userspace.  Eww, yuck.  And it's on the "scales by number of points" side of the dividing line.

But maybe the "center" functionality would be, so that the userspace function looks like
module linear_extrude(height, center=false, convexity, twist, slices) {
    z = center ? -height/2 : 0;
    translate([0,0,z]) real_linear_extrude(height, convexity, twist, slices);
}
The amount of functionality that is O(1) instead of O(n) in the core modules is pretty limited.

Depends on how minimalist you want to go.  cube() and cylinder() are straightforward linear_extrudes of 2D objects, and that implementation is O(1).  (That is, the userspace portion is O(1), on top of an O(n) implementation in C++.)  square() is iffy; in theory it's O(n) when implemented on top of polygon(), but n is a constant 4.  Not that I'm claiming that it would be a significant win to replace any of those.

As you say, there's a fair amount of additional functionality that can be added in O(1).  Your anchor stuff (which I think is the same as my justify stuff) is one.  The circle radius adjustment stuff from another thread is another.  That stuff could all be added in userspace shims on top of the C++ core.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Userspace extensibility of core modules, and minimalist OpenSCAD

adrianv
JordanBrown wrote

> On 12/26/2020 8:17 PM, adrianv wrote:
>> JordanBrown wrote
>>> Support has a cost, even for freeware.
>>
>> Are you concerned about the support issues for folks that hack the
>> OpenSCAD source to change behavior of core modules and then seek
>> support for it? Of course, the idea of making the core callable in
>> override modules avoids this concern entirely. And people who post
>> support questions should be giving their include/use statements.
>> Otherwise you may as well say that libraries are a support disaster
>> and shouldn't be encouraged. (It's been said.)
>>
>
> I'm concerned about somebody who naïvely goes and tweaks their standard
> library because they can, then six months later, having forgotten that
> tweak, runs into trouble and asks for help.  They give their entire
> source file, with no include/use statements (or with "use
> <stdlib.scad>
> ", depending on how the standard library works), and
> everybody is mystified.
>
> And yeah... it's not exactly "libraries are a support disaster".  It's
> "sources are a support disaster".  And maybe that's just part of the
> cost of doing business in the FOSS world, so to speak.

This just seems like a really bizarre concern to me.  Have you had this
problem in some other context?  

I mean, if you are really worried about it, have OpenSCAD verify a checksum
on its library file and print some kind of warning message.  


>>> One rough dividing line might be whether the operation is scaled by
>>> the number of points.
>>>
>> We were just benchmarking this: the native sphere() implementation is
>> 37 times faster (to preview) than a reimplementation in userspace.
>> This may not be slow enough to matter, but it's a pretty significant
>> difference.
>>
>
> That's plenty slow to matter.  And sphere is one of the "scales by the
> number of points" cases, so would fall on the C++ side of my rough
> dividing line.

Maybe, maybe not.  Time to preview 100000 spheres natively is 0.5 s.  So
times 37 means you're waiting 18s to preview with a user space
implementation, which yeah, is arguably annoying.  But render time is
probably 10 days---well, it would just crash OpenSCAD---so is a model with
10000 spheres a concern?   I suppose for applications that don't involve
rendering?  


>> Your minimalist idea would have us implement linear_extrude in userspace
>> as
>> a polyhedron, for example, which I assume will also be a significant
>> performance hit.
>
> I wouldn't have thought of implementing linear_extrude in userspace. 
> Eww, yuck.  And it's on the "scales by number of points" side of the
> dividing line.

Since we have to implement sweep operations (which are *much* harder than
linear extrude) in user space, really, why not linear_extrude?  (My skin
implementation seems to be 45 times slower than linear_extrude when used to
duplicate linear_extrude functionality.  But if I save the polyhedron data
then it's only a tiny bit slower.  The skin function, since it handles a
much more generic case, may be introducing overhead.  Or maybe the
computation to identify the polyhedron faces is just unavoidably slow.  I
don't know which.)  


> But maybe the "center" functionality would be, so that the userspace
> function looks like
>
>     module linear_extrude(height, center=false, convexity, twist, slices)
> {
>         z = center ? -height/2 : 0;
>         translate([0,0,z]) real_linear_extrude(height, convexity, twist,
> slices);
>     }
>
>> The amount of functionality that is O(1) instead of O(n) in the core
>> modules is pretty limited.
>
> Depends on how minimalist you want to go.  cube() and cylinder() are
> straightforward linear_extrudes of 2D objects, and that implementation
> is O(1).  (That is, the userspace portion is O(1), on top of an O(n)
> implementation in C++.)  square() is iffy; in theory it's O(n) when
> implemented on top of polygon(), but n is a constant 4.  Not that I'm
> claiming that it would be a significant win to replace any of those.
>
> As you say, there's a fair amount of additional functionality that can
> be added in O(1).  Your anchor stuff (which I think is the same as my
> justify stuff) is one.  The circle radius adjustment stuff from another
> thread is another.  That stuff could all be added in userspace shims on
> top of the C++ core.

Right now it seems like the *only* thing you could move out of core into
userspace would be the centering.  Is it worth it?  Note also that if you
want to keep everything that is O(n) or worse then you still need a way to
call the actual core module.  Right now, there is almost no O(1)
functionality in the core modules that could be removed, so the advantage of
removing it is small.  To do this you need a way to call the core module,
which is something that's been wished for before.  

One thing that this proposal opens the door to is more people trying to
submit changes to the core.  Unlike the bizarre hack concern above, I think
if it was easy to extend the core then people would be proposing all sorts
of changes.  I think it makes more sense to keep things as they are and
allow libraries to extend the core (as is already basically possible). That
is, the various extensions you're talking about can be provided by
libraries, not in the core.  

Note that cube and cylinder are *not* necessarily straight forward linear
extrudes of 2d objects because polygon quantizes to 1/1024 whereas 3d
objects are quantized to 2^-20.  We've run into this discrepancy, where we
redefined some core modules and then they don't agree with the core under
certain circumstances.  (If I recall correctly, an extruded square isn't the
same as a cube due to the differential quantization.)  This is why it would
be nice to have a way to redefine a core module and be able to call the core
module in the redefinition.   That, of course, and the factor of 37 speed
gain and guaranteed consistency in behavior.  




--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Userspace extensibility of core modules, and minimalist OpenSCAD

Tim Hawkins
THave folks considered a c++ based plugin system that allows the creation of new object types and operators on them, or new functions. Ie being able to drop a plug in and extend the object types, and add new functionality, with the right mechanism, it could allow overrides. 

On Mon, Dec 28, 2020, 23:33 adrianv <[hidden email]> wrote:
JordanBrown wrote
> On 12/26/2020 8:17 PM, adrianv wrote:
>> JordanBrown wrote
>>> Support has a cost, even for freeware.
>>
>> Are you concerned about the support issues for folks that hack the
>> OpenSCAD source to change behavior of core modules and then seek
>> support for it? Of course, the idea of making the core callable in
>> override modules avoids this concern entirely. And people who post
>> support questions should be giving their include/use statements.
>> Otherwise you may as well say that libraries are a support disaster
>> and shouldn't be encouraged. (It's been said.)
>>
>
> I'm concerned about somebody who naïvely goes and tweaks their standard
> library because they can, then six months later, having forgotten that
> tweak, runs into trouble and asks for help.  They give their entire
> source file, with no include/use statements (or with "use
> <stdlib.scad>
> ", depending on how the standard library works), and
> everybody is mystified.
>
> And yeah... it's not exactly "libraries are a support disaster".  It's
> "sources are a support disaster".  And maybe that's just part of the
> cost of doing business in the FOSS world, so to speak.

This just seems like a really bizarre concern to me.  Have you had this
problem in some other context? 

I mean, if you are really worried about it, have OpenSCAD verify a checksum
on its library file and print some kind of warning message. 


>>> One rough dividing line might be whether the operation is scaled by
>>> the number of points.
>>>
>> We were just benchmarking this: the native sphere() implementation is
>> 37 times faster (to preview) than a reimplementation in userspace.
>> This may not be slow enough to matter, but it's a pretty significant
>> difference.
>>
>
> That's plenty slow to matter.  And sphere is one of the "scales by the
> number of points" cases, so would fall on the C++ side of my rough
> dividing line.

Maybe, maybe not.  Time to preview 100000 spheres natively is 0.5 s.  So
times 37 means you're waiting 18s to preview with a user space
implementation, which yeah, is arguably annoying.  But render time is
probably 10 days---well, it would just crash OpenSCAD---so is a model with
10000 spheres a concern?   I suppose for applications that don't involve
rendering? 


>> Your minimalist idea would have us implement linear_extrude in userspace
>> as
>> a polyhedron, for example, which I assume will also be a significant
>> performance hit.
>
> I wouldn't have thought of implementing linear_extrude in userspace. 
> Eww, yuck.  And it's on the "scales by number of points" side of the
> dividing line.

Since we have to implement sweep operations (which are *much* harder than
linear extrude) in user space, really, why not linear_extrude?  (My skin
implementation seems to be 45 times slower than linear_extrude when used to
duplicate linear_extrude functionality.  But if I save the polyhedron data
then it's only a tiny bit slower.  The skin function, since it handles a
much more generic case, may be introducing overhead.  Or maybe the
computation to identify the polyhedron faces is just unavoidably slow.  I
don't know which.) 


> But maybe the "center" functionality would be, so that the userspace
> function looks like
>
>     module linear_extrude(height, center=false, convexity, twist, slices)
> {
>         z = center ? -height/2 : 0;
>         translate([0,0,z]) real_linear_extrude(height, convexity, twist,
> slices);
>     }
>
>> The amount of functionality that is O(1) instead of O(n) in the core
>> modules is pretty limited.
>
> Depends on how minimalist you want to go.  cube() and cylinder() are
> straightforward linear_extrudes of 2D objects, and that implementation
> is O(1).  (That is, the userspace portion is O(1), on top of an O(n)
> implementation in C++.)  square() is iffy; in theory it's O(n) when
> implemented on top of polygon(), but n is a constant 4.  Not that I'm
> claiming that it would be a significant win to replace any of those.
>
> As you say, there's a fair amount of additional functionality that can
> be added in O(1).  Your anchor stuff (which I think is the same as my
> justify stuff) is one.  The circle radius adjustment stuff from another
> thread is another.  That stuff could all be added in userspace shims on
> top of the C++ core.

Right now it seems like the *only* thing you could move out of core into
userspace would be the centering.  Is it worth it?  Note also that if you
want to keep everything that is O(n) or worse then you still need a way to
call the actual core module.  Right now, there is almost no O(1)
functionality in the core modules that could be removed, so the advantage of
removing it is small.  To do this you need a way to call the core module,
which is something that's been wished for before. 

One thing that this proposal opens the door to is more people trying to
submit changes to the core.  Unlike the bizarre hack concern above, I think
if it was easy to extend the core then people would be proposing all sorts
of changes.  I think it makes more sense to keep things as they are and
allow libraries to extend the core (as is already basically possible). That
is, the various extensions you're talking about can be provided by
libraries, not in the core. 

Note that cube and cylinder are *not* necessarily straight forward linear
extrudes of 2d objects because polygon quantizes to 1/1024 whereas 3d
objects are quantized to 2^-20.  We've run into this discrepancy, where we
redefined some core modules and then they don't agree with the core under
certain circumstances.  (If I recall correctly, an extruded square isn't the
same as a cube due to the differential quantization.)  This is why it would
be nice to have a way to redefine a core module and be able to call the core
module in the redefinition.   That, of course, and the factor of 37 speed
gain and guaranteed consistency in behavior. 




--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org t

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Userspace extensibility of core modules, and minimalist OpenSCAD

doug.moen
A C++ based plugin system would likely require a large amount of effort to implement. The core might need to be refactored to support the new C++ extension API. And then there is the issue of maintaining backward compatibility with old plugins as the core evolves. For example, I imagine the new nested list representation in the latest RC (for O(1) concat) would break plugins, if they existed.

Compared to this, it's probably easier to extend the OpenSCAD language from within the language itself, extending the language to make it more extensible. For example, add a language primitive that gives you direct access to the underlying representation of a primitive shape (its polygon mesh).

On Mon, Dec 28, 2020, at 1:07 PM, Tim Hawkins wrote:
THave folks considered a c++ based plugin system that allows the creation of new object types and operators on them, or new functions. Ie being able to drop a plug in and extend the object types, and add new functionality, with the right mechanism, it could allow overrides. 

On Mon, Dec 28, 2020, 23:33 adrianv <[hidden email]> wrote:
JordanBrown wrote
> On 12/26/2020 8:17 PM, adrianv wrote:
>> JordanBrown wrote
>>> Support has a cost, even for freeware.
>>
>> Are you concerned about the support issues for folks that hack the
>> OpenSCAD source to change behavior of core modules and then seek
>> support for it? Of course, the idea of making the core callable in
>> override modules avoids this concern entirely. And people who post
>> support questions should be giving their include/use statements.
>> Otherwise you may as well say that libraries are a support disaster
>> and shouldn't be encouraged. (It's been said.)
>>
>
> I'm concerned about somebody who naïvely goes and tweaks their standard
> library because they can, then six months later, having forgotten that
> tweak, runs into trouble and asks for help.  They give their entire
> source file, with no include/use statements (or with "use
> <stdlib.scad>
> ", depending on how the standard library works), and
> everybody is mystified.
>
> And yeah... it's not exactly "libraries are a support disaster".  It's
> "sources are a support disaster".  And maybe that's just part of the
> cost of doing business in the FOSS world, so to speak.

This just seems like a really bizarre concern to me.  Have you had this
problem in some other context? 

I mean, if you are really worried about it, have OpenSCAD verify a checksum
on its library file and print some kind of warning message. 


>>> One rough dividing line might be whether the operation is scaled by
>>> the number of points.
>>>
>> We were just benchmarking this: the native sphere() implementation is
>> 37 times faster (to preview) than a reimplementation in userspace.
>> This may not be slow enough to matter, but it's a pretty significant
>> difference.
>>
>
> That's plenty slow to matter.  And sphere is one of the "scales by the
> number of points" cases, so would fall on the C++ side of my rough
> dividing line.

Maybe, maybe not.  Time to preview 100000 spheres natively is 0.5 s.  So
times 37 means you're waiting 18s to preview with a user space
implementation, which yeah, is arguably annoying.  But render time is
probably 10 days---well, it would just crash OpenSCAD---so is a model with
10000 spheres a concern?   I suppose for applications that don't involve
rendering? 


>> Your minimalist idea would have us implement linear_extrude in userspace
>> as
>> a polyhedron, for example, which I assume will also be a significant
>> performance hit.
>
> I wouldn't have thought of implementing linear_extrude in userspace. 
> Eww, yuck.  And it's on the "scales by number of points" side of the
> dividing line.

Since we have to implement sweep operations (which are *much* harder than
linear extrude) in user space, really, why not linear_extrude?  (My skin
implementation seems to be 45 times slower than linear_extrude when used to
duplicate linear_extrude functionality.  But if I save the polyhedron data
then it's only a tiny bit slower.  The skin function, since it handles a
much more generic case, may be introducing overhead.  Or maybe the
computation to identify the polyhedron faces is just unavoidably slow.  I
don't know which.) 


> But maybe the "center" functionality would be, so that the userspace
> function looks like
>
>     module linear_extrude(height, center=false, convexity, twist, slices)
> {
>         z = center ? -height/2 : 0;
>         translate([0,0,z]) real_linear_extrude(height, convexity, twist,
> slices);
>     }
>
>> The amount of functionality that is O(1) instead of O(n) in the core
>> modules is pretty limited.
>
> Depends on how minimalist you want to go.  cube() and cylinder() are
> straightforward linear_extrudes of 2D objects, and that implementation
> is O(1).  (That is, the userspace portion is O(1), on top of an O(n)
> implementation in C++.)  square() is iffy; in theory it's O(n) when
> implemented on top of polygon(), but n is a constant 4.  Not that I'm
> claiming that it would be a significant win to replace any of those.
>
> As you say, there's a fair amount of additional functionality that can
> be added in O(1).  Your anchor stuff (which I think is the same as my
> justify stuff) is one.  The circle radius adjustment stuff from another
> thread is another.  That stuff could all be added in userspace shims on
> top of the C++ core.

Right now it seems like the *only* thing you could move out of core into
userspace would be the centering.  Is it worth it?  Note also that if you
want to keep everything that is O(n) or worse then you still need a way to
call the actual core module.  Right now, there is almost no O(1)
functionality in the core modules that could be removed, so the advantage of
removing it is small.  To do this you need a way to call the core module,
which is something that's been wished for before. 

One thing that this proposal opens the door to is more people trying to
submit changes to the core.  Unlike the bizarre hack concern above, I think
if it was easy to extend the core then people would be proposing all sorts
of changes.  I think it makes more sense to keep things as they are and
allow libraries to extend the core (as is already basically possible). That
is, the various extensions you're talking about can be provided by
libraries, not in the core. 

Note that cube and cylinder are *not* necessarily straight forward linear
extrudes of 2d objects because polygon quantizes to 1/1024 whereas 3d
objects are quantized to 2^-20.  We've run into this discrepancy, where we
redefined some core modules and then they don't agree with the core under
certain circumstances.  (If I recall correctly, an extruded square isn't the
same as a cube due to the differential quantization.)  This is why it would
be nice to have a way to redefine a core module and be able to call the core
module in the redefinition.   That, of course, and the factor of 37 speed
gain and guaranteed consistency in behavior. 




--

_______________________________________________
OpenSCAD mailing list
_______________________________________________
OpenSCAD mailing list



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Userspace extensibility of core modules, and minimalist OpenSCAD

JordanBrown
In reply to this post by adrianv
On 12/28/2020 7:32 AM, adrianv wrote:

> JordanBrown wrote
>>
>> I'm concerned about somebody who naïvely goes and tweaks their
>> standard library because they can, then six months later, having
>> forgotten that tweak, runs into trouble and asks for help.  They give
>> their entire source file, with no include/use statements (or with
>> "use <stdlib.scad> ", depending on how the standard library works),
>> and everybody is mystified. And yeah... it's not exactly "libraries
>> are a support disaster".  It's "sources are a support disaster".
>>
>> And maybe that's just part of the cost of doing business in the FOSS
>> world, so to speak.
>>
> This just seems like a really bizarre concern to me. Have you had this
> problem in some other context?
>
Yes and no.  Perhaps I'm just being paranoid.

In a work context (Oracle's Solaris Operating System), customers do the
strangest things, and then call for support.

I've personally hacked FOSS when it didn't work right (Western Digital
bookshelf server did NTP wrong).

I've overridden OpenSCAD builtins when they didn't work, and then
forgotten that I'd done so.  (I don't remember the details, but rotate
was doing something very slightly wrong on 90 degree angles, so I
replaced it with a version that was correct.)

---Changing gears to a minimalist OpenSCAD ---

First, to be clear, it was a thought experiment, not a proposal. What
would the advantages and disadvantages be of aggressively pushing
non-performance-critical stuff out into userspace, as part of the
standard environment that you get without any use/include?

Advantage:  Many more people could contribute to the "standard"
language.  Bugs would be less likely, and less likely to be fatal.

Disadvantage:  Many more people could contribute to the "standard"
language :-).  There would be more push for including everybody's pet
feature.  There would be more 70% solutions that sort of work being
pushed for inclusion.  There would be the possibility of the "forgotten
tweak" that I discussed above.


> Since we have to implement sweep operations (which are *much* harder
> than linear extrude) in user space, really, why not linear_extrude?

Sweep sure seems like a candidate for moving into C++.


> One thing that this proposal opens the door to is more people trying to
> submit changes to the core.  Unlike the bizarre hack concern above, I think
> if it was easy to extend the core then people would be proposing all sorts
> of changes.  I think it makes more sense to keep things as they are and
> allow libraries to extend the core (as is already basically possible). That
> is, the various extensions you're talking about can be provided by
> libraries, not in the core.

Yes, though, again as a thought experiment... does this mean that we
*don't* add O(1) features to the default environment?  Or that they must
be added as C++?

If we had the ability to override a C++ module from userspace, while
still being able to invoke it when needed, and we decided that we wanted
the "control whether the polygon approximation of a circle is inside or
outside the theoretical circle" feature discussed in another thread,
what would we do?  Would we say "nope, must go in a library that you
explicitly use/include"? Would we say "OK, but has to be implemented in
C++"?  Or would we implement it in userspace in a library that is
automatically included?

That last sure seems like the right answer, *if* there's a serious
throttle on the flow of features.

And with the concerns I mentioned about supporting people when they do
their own tweaks.



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org