OpenSCAD language - replace it with Python3
Can you point me to that example, please, Paul?
Thanks!
Jon
On 12/1/2020 2:49 PM, Torsten Paul wrote:
Since there's no way to create structures with named fields
and no way to return multiple values from a function one is
forced to return multiple values as a list, which means you
have a list where you have to refer to "the item at index 2"
instead of "length".'
The infrastructure for that already exists by now which I
have shown in an example that imports a JSON file as data
structure with named fields.
ciao,
Torsten.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 01.12.20 20:52, jon wrote:
Can you point me to that example, please, Paul?
https://github.com/openscad/openscad/pull/3087
Unfortunately binary builds related to this are gone
by now as they only retain builds for 6 month.
ciao,
Torsten.
On Tue, Dec 1, 2020 at 1:58 PM adrianv avm4@cornell.edu wrote:
This is one of the biggest failures of OpenSCAD. Since there's no way to
create structures with named fields and no way to return multiple values
from a function one is forced to return multiple values as a list, which
means you have a list where you have to refer to "the item at index 2"
instead of "length".
I have a bit of a kludgy way of doing this:
FOO_LENGTH_INDEX = 1;
FOO_WIDTH_INDEX = 2;
...
length = foo[FOO_LENGTH_INDEX];
width = foo[FOO_WIDTH_INDEX];
It's brutal, but it works
On 12/1/2020 11:20 AM, Daniel Shriver wrote:
I'd agree that some of the limitations can be a big pain. Could users
get the same end results (varied data-structures, known language to
use) if, instead of replacing the core OpenSCAD, either one made calls
to it from inside another language (python, javascript, java,
whatever), or had a code generator in those languages to generate the
corresponding OpenSCAD?
Only kind of.
First, it wouldn't be integrated. I want to be able to type little more
than "cube(10);", press a button, and get a 3D view. You might be able
to get something sort of similar using the automatic reload mechanisms,
but that's still cobbling together pieces.
Second, 95%+ of the time I want the simplicity of OpenSCAD. I only want
to inject some more complicated stuff every once in a while. Although I
think that one can build a similarly simple infrastructure on top of
Python or JavaScript, if you build that... then what's the advantage of
having OpenSCAD language as an intermediate form? It's not horrible for
the purpose, but it's not all that well-suited either. Carsten's xcsg
seems like a more appropriate intermediate form.
And of course... if you're using some other language, you have
replaced OpenSCAD, from a user perspective.
acwest wrote
On Tue, Dec 1, 2020 at 1:58 PM adrianv <
avm4@
> wrote:
This is one of the biggest failures of OpenSCAD. Since there's no way to
create structures with named fields and no way to return multiple values
from a function one is forced to return multiple values as a list, which
means you have a list where you have to refer to "the item at index 2"
instead of "length".
I have a bit of a kludgy way of doing this:
FOO_LENGTH_INDEX = 1;
FOO_WIDTH_INDEX = 2;
...
length = foo[FOO_LENGTH_INDEX];
width = foo[FOO_WIDTH_INDEX];
It's brutal, but it works
I've done this. But in a library context it only works if you use include
instead of use (which, at the moment, is necessary anyway for performance
reasons), but it also results in serious namespace clutter. And
furthermore, you can't inspect the result and tell what it is. With real
structures the field names are part of the structure and so you can inspect
the output from foo and understand it.
--
Sent from: http://forum.openscad.org/
I wrap structure offsets with functions, so they do work with use. E.g.
function screw_washer(type) = type[9]; //! Default washer
A bit tedious to type but it works like screw.washer.
I don't have a performance problem with using library modules as they don't
generally have any constants that get re-evaluated. I only get the constant
re-evaluation problem with bg projects that use modules that do have lots
of constants in them.
On Tue, 1 Dec 2020 at 21:04, adrianv avm4@cornell.edu wrote:
acwest wrote
On Tue, Dec 1, 2020 at 1:58 PM adrianv <
avm4@
> wrote:
This is one of the biggest failures of OpenSCAD. Since there's no way
to
create structures with named fields and no way to return multiple
values
from a function one is forced to return multiple values as a list, which
means you have a list where you have to refer to "the item at index 2"
instead of "length".
I have a bit of a kludgy way of doing this:
FOO_LENGTH_INDEX = 1;
FOO_WIDTH_INDEX = 2;
...
length = foo[FOO_LENGTH_INDEX];
width = foo[FOO_WIDTH_INDEX];
It's brutal, but it works
I've done this. But in a library context it only works if you use include
instead of use (which, at the moment, is necessary anyway for performance
reasons), but it also results in serious namespace clutter. And
furthermore, you can't inspect the result and tell what it is. With real
structures the field names are part of the structure and so you can inspect
the output from foo and understand it.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On Tue, Dec 1, 2020 at 4:04 PM adrianv avm4@cornell.edu wrote:
I've done this. But in a library context it only works if you use include
instead of use (which, at the moment, is necessary anyway for performance
reasons), but it also results in serious namespace clutter. And
furthermore, you can't inspect the result and tell what it is. With real
structures the field names are part of the structure and so you can inspect
the output from foo and understand it.
My solution for this is for libraries I have a .h file for includes,
and a .scad file for uses. Rge performance issues for .use are a
separate issue...
acwest wrote
On Tue, Dec 1, 2020 at 4:04 PM adrianv <
avm4@
> wrote:
I've done this. But in a library context it only works if you use
include
instead of use (which, at the moment, is necessary anyway for performance
reasons), but it also results in serious namespace clutter. And
furthermore, you can't inspect the result and tell what it is. With real
structures the field names are part of the structure and so you can
inspect
the output from foo and understand it.
My solution for this is for libraries I have a .h file for includes,
and a .scad file for uses. Rge performance issues for .use are a
separate issue...
Your solution doesn't solve the problem of inspecting the output from foo.
The choice between use and include basically has to do with two things:
performance issues and namespace management, so it seems a little hard to
ignore performance in the discussion. Yes, splitting off things that must
be included into separate files is a reasonable strategy to gain the
performance benefits of "use" (fast animations) as well as local namespces
when you need to include constants. It's a mess from a code organization
perspective, though, to have the structure indices in a separate file from
the code. And of course you still have the namespace clutter. Personally
I wouldn't use .h for included .scad files because then they look like C
include files.
I wrote a structure library that provides structures, but I usually only use
it when I need dynamic field names.
--
Sent from: http://forum.openscad.org/
Not sure why you would need structure introspection in OpenSCAD. You
can't even do that in C++ the last time I used it. I once emulated it with
macros and templates, so I could write structures as XML.
I have .scad files full of constants that I include and they in turn use
the file that has functions and modules to act on those constants. For
example screws.scad defines all the screws and uses screw.scad that will
draw a screw, etc.
When the project is a single file that includes the library files, such as
screws.scad, it is performant because all the constants are included and
defined once and everything else is used.
On Tue, 1 Dec 2020 at 22:06, adrianv avm4@cornell.edu wrote:
acwest wrote
On Tue, Dec 1, 2020 at 4:04 PM adrianv <
avm4@
> wrote:
I've done this. But in a library context it only works if you use
include
instead of use (which, at the moment, is necessary anyway for
performance
reasons), but it also results in serious namespace clutter. And
furthermore, you can't inspect the result and tell what it is. With
real
structures the field names are part of the structure and so you can
inspect
the output from foo and understand it.
My solution for this is for libraries I have a .h file for includes,
and a .scad file for uses. Rge performance issues for .use are a
separate issue...
Your solution doesn't solve the problem of inspecting the output from
foo.
The choice between use and include basically has to do with two things:
performance issues and namespace management, so it seems a little hard to
ignore performance in the discussion. Yes, splitting off things that must
be included into separate files is a reasonable strategy to gain the
performance benefits of "use" (fast animations) as well as local namespces
when you need to include constants. It's a mess from a code organization
perspective, though, to have the structure indices in a separate file from
the code. And of course you still have the namespace clutter. Personally
I wouldn't use .h for included .scad files because then they look like C
include files.
I wrote a structure library that provides structures, but I usually only
use
it when I need dynamic field names.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
You'd want it for debugging and for understanding behavior of code that
perhaps you didn't write. In other words, it's easier to be able to examine
the output of a function and immediately know what it means than have to
look it up in a document somewhere.
Not sure how C++ is relevant here. It's a very different kind of language,
where data types are general declared in advance. Does the STL (or some
other standard library) even define structures with dynamic field names?
Without that, it doesn't even make sense. If your debugger isn't showing
you struct field names...get a better debugger. But I wouldn't hold C++ up
as the ultimate in programming languages.
nophead wrote
Not sure why you would need structure introspection in OpenSCAD. You
can't even do that in C++ the last time I used it. I once emulated it with
macros and templates, so I could write structures as XML.
I have .scad files full of constants that I include and they in turn use
the file that has functions and modules to act on those constants. For
example screws.scad defines all the screws and uses screw.scad that will
draw a screw, etc.
When the project is a single file that includes the library files, such as
screws.scad, it is performant because all the constants are included and
defined once and everything else is used.
On Tue, 1 Dec 2020 at 22:06, adrianv <
avm4@
> wrote:
acwest wrote
On Tue, Dec 1, 2020 at 4:04 PM adrianv <
avm4@
> wrote:
I've done this. But in a library context it only works if you use
include
instead of use (which, at the moment, is necessary anyway for
performance
reasons), but it also results in serious namespace clutter. And
furthermore, you can't inspect the result and tell what it is. With
real
structures the field names are part of the structure and so you can
inspect
the output from foo and understand it.
My solution for this is for libraries I have a .h file for includes,
and a .scad file for uses. Rge performance issues for .use are a
separate issue...
Your solution doesn't solve the problem of inspecting the output from
foo.
The choice between use and include basically has to do with two things:
performance issues and namespace management, so it seems a little hard to
ignore performance in the discussion. Yes, splitting off things that
must
be included into separate files is a reasonable strategy to gain the
performance benefits of "use" (fast animations) as well as local
namespces
when you need to include constants. It's a mess from a code organization
perspective, though, to have the structure indices in a separate file
from
the code. And of course you still have the namespace clutter.
Personally
I wouldn't use .h for included .scad files because then they look like C
include files.
I wrote a structure library that provides structures, but I usually only
use
it when I need dynamic field names.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@.openscad
Discuss@.openscad
--
Sent from: http://forum.openscad.org/