feature request: plug-ins
Expanding on an idea I propose in non-linear transformation, and some private
discussion with Parkinbot. I think I hit on the best idea to address
"everyone's need" (caveat emptor).
A few people requested breaking the shackle of declarative language, others
want arbitrary manipulation of mesh points. Personally I don't mind more
powerful features on OpenSCAD but worry about negative impact on the dev
team and/or community.
I seem to have heard that kintel also speak Matlabese, so I think this
plug-in idea may be able to secure critical buy-in. The idea is this:
Rather than ask the dev team to change OpenSCAD in some radical way(s), just
open a way for end-users to write their own functions and module in C++ and
compile them to object code (DLL on Windows) and OpenSCAD would be able call
these routine seamlessly. To explain this， I quote wiki for MEX file:
When compiled, MEX files are dynamically loaded and allow external
functions to be invoked from within MATLAB or Octave as if they were
built-in functions. To support the development of MEX files, both MATLAB and
Octave offer external interface functions that facilitate the transfer of
data between MEX files and the workspace.
So let's say user (u) wish to write his madtransform() module, to make it
possible, dev team (d) has to provide some C function calls which lets u get
the data. So when madtransform.dll is ready and finish, u can access his
module from inside OpenSCAD by simply:
I.e. madtransform() is syntactically the same as any user-defined modules.
Any number of parameters can be passed as any legal OpenSCAD quantities, and
any 2D/3D objects can be passed as children. So NO need for de novo syntax
and data types.
Back in the C realm, u will access these parameters and children by some C
function calls provided by d. And the computation result (non-Affine
transform to u's hearts content) has to be a 2D/3D object, which is returned
to OpenSCAD via specific C function calls provided by d. Output to OpenSCAD
console should also be available with the C-version of echo().
The same should also be provided for OpenSCAD functions written in C++, that
is, instead of generating an 2D/3D object, some computation algorithm
written by u can be returned to OpenSCAD as long as it's legal OpenSCAD
quantities (values).
This proposal preserve the "sanctity" of OpenSCAD, letting users to
experiment with any loony idea he may have, without burdening the dev team
with feature requests and potential tsunami of bug reports. And if some
users come out with a gem, he could share it and maybe partition for
bundling it in the installation package. Further he could choose to share
only the object code or share the source code as well.
--
View this message in context: http://forum.openscad.org/feature-request-plug-ins-tp14663.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Thanks ctchin.
this a nice approach to keep the language sober affine on the object level
and allow for non affine extensions on everybodies own risk. I love the idea
to also interface console output, which allows for debugging and proper
error messages. Good point!
I propose that this plug-in architecture should also include support for
external function calls:
or in a better version even expand name resolving (and shadowing) to
plug-ins as you have proposed it:
--
View this message in context: http://forum.openscad.org/feature-request-plug-ins-tp14663p14667.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
and for those of us who do not program in C.
what about the first plugin being a C plugin that accepts a python, or
ruby, script?
--
Extra Ham Operator: K7AZJ
Registered Linux User: 275424
Raspberry Pi and Arduino developer
The most exciting phrase to hear in science - the one that heralds new
discoveries - is not "Eureka!" but "That's funny...".- Isaac. Asimov
I
*f you give someone a program, you will frustrate them for a day; if you
teach them how to program, you will frustrate them for a lifetime. *-
Anonymous
If writing good code requires very little comments, then writing really
excellent code requires no comments at all!- Ken Thompson
On Fri, Nov 20, 2015 at 5:50 AM, Parkinbot rudolf@parkinbot.com wrote:
Thanks ctchin.
this a nice approach to keep the language sober affine on the object level
and allow for non affine extensions on everybodies own risk. I love the
idea
to also interface console output, which allows for debugging and proper
error messages. Good point!
I propose that this plug-in architecture should also include support for
external function calls:
or in a better version even expand name resolving (and shadowing) to
plug-ins as you have proposed it:
--
View this message in context:
http://forum.openscad.org/feature-request-plug-ins-tp14663p14667.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
@jdawgaz
You are perfectly right! Once the system opens a door like this ajar, all
languages may be connected by specific connectors.
--
View this message in context: http://forum.openscad.org/feature-request-plug-ins-tp14663p14669.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Von: "Jerry Davis" jdawgaz@gmail.com
and for those of us who do not program in C.
what about the first plugin being a C plugin that accepts a python,
or ruby, script?
For that specific use case, I don't see much need for a plugin.
Pretty much any language is covered by some project that uses
OpenSCAD as backend.
Python -> See SolidPython
https://github.com/SolidCode/SolidPython
Ruby -> See CrystalScad
https://github.com/Joaz/CrystalScad
Clojure -> See scad-clj
https://github.com/farrellm/scad-clj
Talk about creating Keyboards using this:
https://www.youtube.com/watch?v=uk3A41U0iO4
(not sure the picking on some of the OpenSCAD pains was needed
to get the message across, still an interesting talk)
JavaScript -> ...
/me is skipping the JavaScript projects as there are just too many to mention ;-).
ciao,
Torsten.
Torsten:
yes, I have knowledge of solidpython, and am learning crystalscad.
But those aren't plugins, they are a module, and a gem that you can render
to "openscad" code, and paste into the editor later.
That is not the same thing as a plugin.
Jerry
--
Extra Ham Operator: K7AZJ
Registered Linux User: 275424
Raspberry Pi and Arduino developer
The most exciting phrase to hear in science - the one that heralds new
discoveries - is not "Eureka!" but "That's funny...".- Isaac. Asimov
I
*f you give someone a program, you will frustrate them for a day; if you
teach them how to program, you will frustrate them for a lifetime. *-
Anonymous
If writing good code requires very little comments, then writing really
excellent code requires no comments at all!- Ken Thompson
On Fri, Nov 20, 2015 at 7:41 AM, Torsten Paul Torsten.Paul@gmx.de wrote:
Von: "Jerry Davis" jdawgaz@gmail.com
and for those of us who do not program in C.
what about the first plugin being a C plugin that accepts a python,
or ruby, script?
For that specific use case, I don't see much need for a plugin.
Pretty much any language is covered by some project that uses
OpenSCAD as backend.
Python -> See SolidPython
https://github.com/SolidCode/SolidPython
Ruby -> See CrystalScad
https://github.com/Joaz/CrystalScad
Clojure -> See scad-clj
https://github.com/farrellm/scad-clj
Talk about creating Keyboards using this:
https://www.youtube.com/watch?v=uk3A41U0iO4
(not sure the picking on some of the OpenSCAD pains was needed
to get the message across, still an interesting talk)
JavaScript -> ...
/me is skipping the JavaScript projects as there are just too many to
mention ;-).
ciao,
Torsten.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
You talk about "reducing the burden on the dev team", and then you talk
about the extensive list of capabilities that this new plugin API will
have. Hmm.
There are lots of proposals on the horizon that involve rewriting the
internals of OpenSCAD, for example:
- OpenSCAD2 (me)
- speeding up the language interpreter using LLVM (me)
- replacing the renderer with a new geometry engine (marius)
- rewriting the previewer (marius)
Any of the above projects, which involve a significant rewrite of
internals, would break existing plugins, since the plugin API would have to
change. The plugin API is going to expose a lot of internals, you see.
If the dev team is allowed to break the plugin API on each new release,
then I agree that this proposal doesn't increase their burden. :-)
Doug.
On 20 November 2015 at 03:37, ctchin c.t.chin@szu.edu.cn wrote:
Expanding on an idea I propose in non-linear transformation, and some
private
discussion with Parkinbot. I think I hit on the best idea to address
"everyone's need" (caveat emptor).
A few people requested breaking the shackle of declarative language, others
want arbitrary manipulation of mesh points. Personally I don't mind more
powerful features on OpenSCAD but worry about negative impact on the dev
team and/or community.
I seem to have heard that kintel also speak Matlabese, so I think this
plug-in idea may be able to secure critical buy-in. The idea is this:
Rather than ask the dev team to change OpenSCAD in some radical way(s),
just
open a way for end-users to write their own functions and module in C++ and
compile them to object code (DLL on Windows) and OpenSCAD would be able
call
these routine seamlessly. To explain this， I quote wiki for MEX file:
When compiled, MEX files are dynamically loaded and allow external
functions to be invoked from within MATLAB or Octave as if they were
built-in functions. To support the development of MEX files, both MATLAB
and
Octave offer external interface functions that facilitate the transfer of
data between MEX files and the workspace.
So let's say user (u) wish to write his madtransform() module, to make it
possible, dev team (d) has to provide some C function calls which lets u
get
the data. So when madtransform.dll is ready and finish, u can access his
module from inside OpenSCAD by simply:
I.e. madtransform() is syntactically the same as any user-defined modules.
Any number of parameters can be passed as any legal OpenSCAD quantities,
and
any 2D/3D objects can be passed as children. So NO need for de novo syntax
and data types.
Back in the C realm, u will access these parameters and children by some C
function calls provided by d. And the computation result (non-Affine
transform to u's hearts content) has to be a 2D/3D object, which is
returned
to OpenSCAD via specific C function calls provided by d. Output to
OpenSCAD
console should also be available with the C-version of echo().
The same should also be provided for OpenSCAD functions written in C++,
that
is, instead of generating an 2D/3D object, some computation algorithm
written by u can be returned to OpenSCAD as long as it's legal OpenSCAD
quantities (values).
This proposal preserve the "sanctity" of OpenSCAD, letting users to
experiment with any loony idea he may have, without burdening the dev team
with feature requests and potential tsunami of bug reports. And if some
users come out with a gem, he could share it and maybe partition for
bundling it in the installation package. Further he could choose to share
only the object code or share the source code as well.
--
View this message in context:
http://forum.openscad.org/feature-request-plug-ins-tp14663.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I’ve been listening to requests for a plugin API many times :)
As Doug points out, this would significantly increase the amount of API we expose, which will definitely increase the dev and maintenance burden. Just look at the pain it is to maintain backwards compatibility with early design mistakes in the OpenSCAD language itself..
Now, if we were to support plugins, here are some ideas:
- DO NOT support native plugins. This will introduce huge requirements for authors to provide binaries for all supported platform, or splintering the user community by selectively making their plugin available only on certain platforms.
- Limit the API to perform operations with a very limited exposed API (e.g. implement user-defined functions/modules where the only API is how to call and how to return values and shapes).
- Allow plugins to generate OpenSCAD code from a UI dialog (i.e. using the built-in QtScript to create dialogs) -> i.e. separate the plugin from the language run-time.
- Use a plugin language which doesn’t require any OS-level infrastructure installed; i.e. make the plugin language fully embedded.
Another request I get relatively often is for OpenSCAD to efficiently be used with a different front-end language, allowing people to use one of the wrappers/generators directly in the OpenSCAD GUI, alternatively, plug the OpenSCAD viewer into their corresponding IDE or editor. Automatic Reload covers most use-cases for this though.
-Marius
On 11/20/2015 04:22 PM, Jerry Davis wrote:
yes, I have knowledge of solidpython, and am learning crystalscad.
But those aren't plugins, they are a module, and a gem that you
can render to "openscad" code, and paste into the editor later.
That is not the same thing as a plugin.
With OpenSCAD just running as "viewer" (with automatic reload enabled),
you can pretty much use the other language without even seeing the
actual scad code. Just have a look at the video I linked starting at
21m:40s. This shows the Clojure example using Emacs as editor +
OpenSCAD as viewer.
Yes, it's not a plug-in but you have 2 separate windows for editor
and the viewer and write the language of your choice in that editor.
There's not much to gain from a plug-in when just wanting to use
a different language.
Plug-ins could cover other use cases, like prototyping new features
and implementing very special things. But that's a much much bigger
can of worms. Marius already listed some ideas how to make it
manageable.
Also we already have a very simple framework to mark features as
experimental which disables those automatically for release builds. So
if someone wants to experiment with some C++ coding, that's quite easy
already without a plug-in API. This part is lacking documentation though.
Adding a new feature, e.g. to generate a very specific mesh is probably
easily done in an hour or so.
What makes things complicated is always the usage of external libraries
on various platforms and the definition of how the user visible API
(= the language extension -> names, parameters, ...) should look like.
ciao,
Torsten.
@doug: such an interface is not meant to be redefined for each release, and I
doubt it will have to at all, if it is well specified.
@Marius
user defined functions have a very limited foot print. As the OpenSCAD
syntax for functions is rather restrictive, and porting useful code to
OpenSCAD can be quite painful, the language could gain a lot from it.
object representation might be interfaced at a polyhedron basis. If the
polyhedron object allowed for a combined parameter like [points , faces],
e.g.
it even could be constructed by a user defined function as well.
object operators this is a more complex theme, as it requires to expose a
lot of information about internal representations. But I guess one could
easily expose a restricted interface for unary transform operators operating
over sets of xyz-points as already suggested in the "nonlinear
transformations" thread.
- Rudolf
kintel wrote
Now, if we were to support plugins, here are some ideas:
- DO NOT support native plugins. This will introduce huge requirements for
authors to provide binaries for all supported platform, or splintering the
user community by selectively making their plugin available only on
certain platforms. - Limit the API to perform operations with a very limited exposed API
(e.g. implement user-defined functions/modules where the only API is how
to call and how to return values and shapes). - Allow plugins to generate OpenSCAD code from a UI dialog (i.e. using the
built-in QtScript to create dialogs) -> i.e. separate the plugin from the
language run-time. - Use a plugin language which doesn’t require any OS-level infrastructure
installed; i.e. make the plugin language fully embedded.
Another request I get relatively often is for OpenSCAD to efficiently be
used with a different front-end language, allowing people to use one of
the wrappers/generators directly in the OpenSCAD GUI, alternatively, plug
the OpenSCAD viewer into their corresponding IDE or editor. Automatic
Reload covers most use-cases for this though.
-Marius
OpenSCAD mailing list
Discuss@.openscad
--
View this message in context: http://forum.openscad.org/feature-request-plug-ins-tp14663p14700.html
Sent from the OpenSCAD mailing list archive at Nabble.com.