Hello,

I asked for such a functionality in a previous thread.
Now only a "function" to check for the existence of a file is missing.
Please note that the code I presented then did not intend to be exact, it
was only to express an idea.

And the idea was the capability of some automation from within the code to
achieve a fluid view and manipulation of complex multi-part objects.
Explaining briefly: rendering a multi-part complex object can make us loose
many minutes if not hours every time we start an editing session. When we
start assembling a multi-part object it happens frequently that some
modules
are not at the right positions or that we forgot some details, so we need
to
look to the object from several angles to understand better what to do. If
not rendered the set is almost impossible to move or rotate on the
view-port, the time lag is enormous.
My solution would be: the modules that are important for the assembly would
verify for a previously exported .stl file with the same name of the
module.
If the file exist then that part is imported, else the code would be
compiled and exported as an .stl file. Since the code bellow is already
possible,

module ABC() {
import("ABC.stl");
}
ABC();

The only thing missing  after having the export functionality working would
be a function returning a flag signaling the existence of a file.

I know it is possible to have a fluid view  done from outside the script,
even to have a second instance of OpenSCAD open with all stls imported, but
it's not practical. It implies that the code is distributed into several
files and somehow the feel of unity of the object weakens.
Now with the OpenSCAD lexer presented by runsun (thank you runsun) for the
SinWrite editor, we have already the facility to better navigate in a more
"complex" code  and we do not need to separate the code into several files
if we are not planning for code reuse, for that I would build a library.

I read this comment by doug.moen a few hours ago.

"An export command with a file name argument permits a malicious OpenSCAD
script to clobber any file in the file system for which it has write
permissions. OpenSCAD is intentionally designed so that it isn't a general
purpose language like Python, and it doesn't suffer from this kind of
security issue."

What if limiting the file name parameter to a couple of known pacific
extensions?

As I said in thread above I'm not a software guy nor an OpenSCAD expert and
I'm not a native english speaker either, so please understand that.

Happy new year

jpmendes
<
http://forum.openscad.org/How-to-check-if-a-file-exist-Why-not-export-from-code-td14982.html#a14995

--
View this message in context:
http://forum.openscad.org/export-function-tp15428p15437.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

In https://github.com/openscad/openscad/issues/1437 clothbot and I
propose to add a persistent caching option to 'render'. This can address
both jpmendes and Mihail's problem.

If we add export and a function for testing file existence, then
openscad starts to become a scripting language for automating file
management workflow. The security problem becomes worse because now you can
determine what operating system is running, by testing for the existence of
system files, and now you know which files to clobber using 'export', for
maximum damage.

On Sunday, 3 January 2016, jpmendes jpmendes54@gmail.com wrote:

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

Yes persistent caching gets my vote as there are no changes to the
language, it just gets faster.

To export multiple objects from my files I simply call them
something_stl(). I have a python script that finds them and invokes the
command line to export them. That would also get much faster with a
persistent cache.

On 3 January 2016 at 20:26, doug moen doug@moens.org wrote:

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

Hi Mihail. Concerning your pull request for an export() command.

Torsten is a gatekeeper, I'm not. Torsten's response to your proposal was
more relevant and insightful than mine. The security problem is a side
issue, and the real problem is what Torsten said:

1. OpenSCAD is not a procedural programming language. It is a purely
declarative language for describing geometry. This is the primary issue.
2. You can't add a procedural, side effect causing 'export()' command
to the language because it doesn't make any sense to export a shape to a
file while the script is being evaluated: this would mess up preview
performance. Once again, this is a side issue, like security. It's a
technical issue which underlies the fundamental design decision that
OpenSCAD is a declarative language (see point 1 above).

Torsten asked a number of questions about "when does this side effect
occur", which are quite relevant, and which you didn't answer.

Then Torsten proposed a design which is consistent with the OpenSCAD
philosophy. Instead of an "export" function which has the semantics of
"write this shape to a file right now", there is a syntax for adding
metadata to a node of the CSG tree, which has the semantics: this branch of
the CSG tree should be exported to a separate file, at export time. It
could have the same syntax as your proposal.

This metadata is not interpreted until some GUI command is invoked. No
files are exported during preview, render or animation, which is as it
should be. For example, the GUI "Export" command can notice that there are
multiple exported subtrees tagged in the CSG tree. It could, for example,
ask you to specify a root directory, then write all of the exported files
relative to this directory. It should also be specified how to invoke
multiple export from the CLI.

Notice how the security problem goes away when the feature is properly
designed. We are no longer invisibly exporting files without the user's
knowledge, in the case of a downloaded SCAD file. Export only happens
explicitly.

This design addresses the goal of exporting multiple files from a single
*.scad file, but it doesn't address jpmendes' problem, because his goal is
for OpenSCAD to run faster, and he wants to achieve this by persistent
caching of specified subtrees. So we've proposed an extension to the
render() operator to solve his problem.

On 4 January 2016 at 16:31, Mihail Vasiliev mickvav@gmail.com wrote:

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

On 01/06/2016 08:57 PM, Mihail Vasiliev wrote:

AbstractNode.

So it would try to generate the full mesh (aka. F6) for this part
of the model for each preview and export the file. I don't think
this is a good way of handling it. See below for more details...

Ok, that might be useful in some rare cases, but it looks a bit like
misusing the animation feature.

I would not say it's impossible to use some language feature to declare
what to export. The main issue is the immediate execution which the
code is compiled.

Trying to find the analogy to C++ here, we only have the compilation
step where you do "gcc -o program.exe file.c" and the analog part would
be "openscad -o model.stl file.scad".
So mapping the immediate execution of export() to gcc would be like
exporting another file while the compiler is running via #export file.out
or something similar.

Actually running as program does not really happen with OpenSCAD models,
as they are essentially a data structure that is evaluated by different
things.

Those things can be:

• F5 preview renderer in OpenSCAD GUI
• F6 mesh calculation in OpenSCAD GUI or command line
• various exports to different formats in OpenSCAD GUI or command line
• import into other programs, namely FreeCAD

Most notably here is the last point which highlights the interpretation
of SCAD (or it's simplified form CSG) files as data. What would FreeCAD
do with an export() node when reading the file?

It's true that echo() is also fitting into that problem area, it mainly
has the argument that there would be almost no debugging possibility
without it.

I think having some capabilities to markup/annotate parts of a model
to tell the OpenSCAD GUI what to do when interpreting the data could
cover both issues: a) leaving the scad script as a data description
while still b) allowing the user to export multiple parts at once.
All this without interfering with other programs that might want to
import the file or making the preview slow due to forced mesh generation.
Also annotations allow more control about export details, as for
instance the DXF export would benefit from defining model parts
as different layer while still exporting into a single file.

Maybe we can work together moving into that direction? The actual
feature for exporting multiple files / multiple layer would be
awesome to have and surely welcomed by a number of people.

ciao,
Torsten.

OpenSCAD mailing list
Discuss@lists.openscad.org javascript:;
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

The animate feature doesn't create an output file for each frame unless
you select the "dump images" option. There's currently no option to export
each frame as stl. If we added such a feature, only then would it make
sense to export tagged subtrees as stl for each frame.

On Friday, 8 January 2016, Torsten Paul Torsten.Paul@gmx.de wrote:

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

May be it's better to leave this decision to end user, whether to use
export keyword or not?

On compatibility with other software-I'm not sure, how FreeCAD parses
unknown predicates, but if it behaves like OpenSCAD - just ignores
corresponding subtree, everythings should be fine - it will just show
the same - nothing.

8 янв. 2016 г. 9:58 PM пользователь "doug moen" <doug@moens.org
mailto:doug@moens.org> написал:

 The animate feature doesn't create an output file for each frame
 *unless* you select the "dump images" option. There's currently no
 option to export each frame as stl. *If* we added such a feature,
 only then would it make sense to export tagged subtrees as stl for
 each frame.

 On Friday, 8 January 2016, Torsten Paul <Torsten.Paul@gmx.de
 <mailto:Torsten.Paul@gmx.de>> wrote:

     On 01/06/2016 08:57 PM, Mihail Vasiliev wrote:

     handled with

     does.

     AbstractNode.

     So it would try to generate the full mesh (aka. F6) for this part
     of the model for each preview and export the file. I don't think
     this is a good way of handling it. See below for more details...

     create series

     cube([10,10,10]);

     Ok, that might be useful in some rare cases, but it looks a bit like
     misusing the animation feature.

     purely

     primary issue.

     be declared

     I would not say it's impossible to use some language feature to
     declare
     what to export. The main issue is the immediate execution which the
     code is compiled.

     Trying to find the analogy to C++ here, we _only_ have the
     compilation
     step where you do "gcc -o program.exe file.c" and the analog
     part would
     be "openscad -o model.stl file.scad".
     So mapping the immediate execution of export() to gcc would be like
     exporting another file while the compiler is running via #export
     file.out
     or something similar.

     Actually running as program does not really happen with OpenSCAD
     models,
     as they are essentially a data structure that is evaluated by
     different
     things.

     Those things can be:
     * F5 preview renderer in OpenSCAD GUI
     * F6 mesh calculation in OpenSCAD GUI or command line
     * various exports to different formats in OpenSCAD GUI or
     command line
     * import into other programs, namely FreeCAD

     Most notably here is the last point which highlights the
     interpretation
     of SCAD (or it's simplified form CSG) files as data. What would
     FreeCAD
     do with an export() node when reading the file?

     It's true that echo() is also fitting into that problem area, it
     mainly
     has the argument that there would be almost no debugging possibility
     without it.

     I think having some capabilities to markup/annotate parts of a model
     to tell the OpenSCAD GUI what to do when interpreting the data could
     cover both issues: a) leaving the scad script as a data description
     while still b) allowing the user to export multiple parts at once.
     All this without interfering with other programs that might want to
     import the file or making the preview slow due to forced mesh
     generation.
     Also annotations allow more control about export details, as for
     instance the DXF export would benefit from defining model parts
     as different layer while still exporting into a single file.

     Maybe we can work together moving into that direction? The actual
     feature for exporting multiple files / multiple layer would be
     awesome to have and surely welcomed by a number of people.

     ciao,
        Torsten.


     _______________________________________________
     OpenSCAD mailing list
     Discuss@lists.openscad.org
     http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



 _______________________________________________
 OpenSCAD mailing list
 Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org>
 http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

Ezra Reynolds mailto:shadowwynd@gmail.com
January 8, 2016 at 18:59
I wouldn't use FreeCAD as a barometer of compatibility, as it doesn't
support hull() or offset() as of the most current version (hull is
split into its components, offset throws nasty errors).

I have created many designs that have multiple subassemblies.  They
are all inter-related pieces of the same design (e.g. top, bottom,
middle, with matching screw-holes, standoffs, etc.)  Since they share
variables, it is logical for them to to share a .SCAD file.  Yes, I
know how to use a batch file or script to do all this, but I would say
it is more

I normally arrange the pieces in OpenSCAD for 3D printing (many
discrete volumes as a single STL).  This works up to the point where I
have a single part, or several parts, fail during printing /
derafting/assembly.  It is an error-prone thing to manually isolate
each part, render as an STL, save it with the correct name, rinse and
repeat.  Not a problem with a three-part assembly, but could be a
problem with file that generates two dozen variations on a theme.

For my needs, an export("part1.stl") {subtree}  approach would work,
where the subtree is rendered to screen/cache (exactly like render()),
but is also exported to disk as the last step of the process.

For example:
export("top.stl") top();
translate ([20, 0, 0]) export("middle.stl") middle ();
translate ([-20, 0, 0]) export("bottom.stl") bottom();

F5 Preview - no difference, objects are rendered and shown

F6 Render - objects are rendered, displayed on screen.  Export
subtrees are written to disk, allowing user to still save whole render
as .STL or .AMF or whatever.  This guarantees I have a current (top,
middle, bottom) and not a top from two revisions ago.

Or maybe have a "Super F6" (shift+F6?) that handles the export()
commands or whatever other metadata functions we need.  I like
doug.moen's suggestion about handling this as metadata; you could
implement as a post-process function.

From my vantage point, export is still "Object Description" and not
"general programming"; it is describing the shape of the sub object,
and how it stored on the disk.

One potential problem that hasn't been mentioned is that if export()
triggers a render+write RIGHT NOW that can lead to a race condition;
if I export "X.stl" and use "X.stl" in other parts of the same file -
does it use the previous "X.stl" or the just-rendered version....

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Mihail Vasiliev mailto:mickvav@gmail.com
January 8, 2016 at 15:22

May be it's better to leave this decision to end user, whether to use
export keyword or not?

On compatibility with other software-I'm not sure, how FreeCAD parses
unknown predicates, but if it behaves like OpenSCAD - just ignores
corresponding subtree, everythings should be fine - it will just show
the same - nothing.

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
doug moen mailto:doug@moens.org
January 8, 2016 at 10:57
The animate feature doesn't create an output file for each frame
unless you select the "dump images" option. There's currently no
option to export each frame as stl. If we added such a feature, only
then would it make sense to export tagged subtrees as stl for each frame.

On Friday, 8 January 2016, Torsten Paul <Torsten.Paul@gmx.de
mailto:Torsten.Paul@gmx.de> wrote:

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Torsten Paul mailto:Torsten.Paul@gmx.de
January 8, 2016 at 09:42
On 01/06/2016 08:57 PM, Mihail Vasiliev wrote:

So it would try to generate the full mesh (aka. F6) for this part
of the model for each preview and export the file. I don't think
this is a good way of handling it. See below for more details...

Ok, that might be useful in some rare cases, but it looks a bit like
misusing the animation feature.

I would not say it's impossible to use some language feature to declare
what to export. The main issue is the immediate execution which the
code is compiled.

Trying to find the analogy to C++ here, we only have the compilation
step where you do "gcc -o program.exe file.c" and the analog part would
be "openscad -o model.stl file.scad".
So mapping the immediate execution of export() to gcc would be like
exporting another file while the compiler is running via #export file.out
or something similar.

Actually running as program does not really happen with OpenSCAD models,
as they are essentially a data structure that is evaluated by different
things.

Those things can be:

• F5 preview renderer in OpenSCAD GUI
• F6 mesh calculation in OpenSCAD GUI or command line
• various exports to different formats in OpenSCAD GUI or command line
• import into other programs, namely FreeCAD

Most notably here is the last point which highlights the interpretation
of SCAD (or it's simplified form CSG) files as data. What would FreeCAD
do with an export() node when reading the file?

It's true that echo() is also fitting into that problem area, it mainly
has the argument that there would be almost no debugging possibility
without it.

I think having some capabilities to markup/annotate parts of a model
to tell the OpenSCAD GUI what to do when interpreting the data could
cover both issues: a) leaving the scad script as a data description
while still b) allowing the user to export multiple parts at once.
All this without interfering with other programs that might want to
import the file or making the preview slow due to forced mesh generation.
Also annotations allow more control about export details, as for
instance the DXF export would benefit from defining model parts
as different layer while still exporting into a single file.

Maybe we can work together moving into that direction? The actual
feature for exporting multiple files / multiple layer would be
awesome to have and surely welcomed by a number of people.

ciao,
Torsten.

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Mihail Vasiliev mailto:mickvav@gmail.com
January 6, 2016 at 11:57
Hi, Doug, Torsten.

I'll try to answer Torsten's questions first.

1. How is the difference between preview and render mode handled with
   export()?

The very exact way another side-effecting operation - "echo" does.
It does it's dirty job on "instantiate" call to corresponding
AbstractNode.

2. Will that always force the mesh generation and export the
   file on F5?

It's action is triggered at the same times as echo's.
As for now, it actually calls instantiateChildren on it's children
nodes. (I don't know, whether this function it use caches internally.
I can dig it, if it's necessary.)
Than it applies freshly-created GeometryEvaluator on the first of
these children and exports resulted geometry in supplied file,
determining it's type by it's name.
3. How will that interact with animation?

Yes, I regenerates file on each frame, and can be used to create
series of exported files of each time step.
e.g. the code:

export(file=str("gg",$t,".stl")) rotate([$t*50,0,0]) cube([10,10,10]);

generates several stl files with different names, as expected.

Now on Doug's questions:

1. OpenSCAD is not a procedural programming language. It is a purely
   declarative language for describing geometry. This is the primary issue.

And why the way to output for this geometry is obligated to be
declared in command line, not in the language itself?

2. You can't add a procedural, side effect causing 'export()' command
   to the language because it doesn't make any sense to export a shape to
   a file while the script is being evaluated: this would mess up preview
   performance. Once again, this is a side issue, like security. It's a
   technical issue which underlies the fundamental design decision that
   OpenSCAD is a declarative language (see point 1 above).

This technocal issue can be addressed by adding some extra argument to
export to make it skip it's operation in preview mode, for example. I
can do it, as well as security restrictions, regression tests and so
on, if the community is interested in the feature itself.

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

I create modules for each part, list them at the bottom of the script,
and then use ! to create the geometry for the part that I wish to print.

On 1/8/2016 9:59 PM, Ezra Reynolds wrote:

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

I do the same, many of my files have a list of

 *!module1Name();
 *!module2Name();

at the bottom so that I can easily turn pieces off and on.

However, if using a generator:
for (i=[0 : 10])
{
for (j=[0 : 10])
{
translate ([i20, j20, 0]) smallPartGenerator(i, j);

 }

}

I then have 100 individual volumes on a build plate  which is NOT as
easy to toggle.

If we had an export command, then I could have an
export("R"+str(i) + "C"+str(j) + ".STL");
in the mix and get 100 STL files out of the deal; this makes it easier
to get a specific replacement without reprinting all 100.

On 1/9/2016 6:07 AM, jon wrote:

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2016.0.7294 / Virus Database: 4489/11360 - Release Date:
01/09/16

I agree that this would be a useful improvement!

On 1/9/2016 7:38 AM, Ezra Reynolds wrote:

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

Sounds pretty much exactly like what I'm looking for -- in addition to being able to preview just one component from a drop-down menu post
render.

at the bottom so that I can easily turn pieces off and on.

However, if using a generator:
for (i=[0 : 10])
{
for (j=[0 : 10])
{
translate ([i20, j20, 0]) smallPartGenerator(i, j);

  }

}

I then have 100 individual volumes on a build plate  which is NOT as
easy to toggle.

If we had an export command, then I could have an
export("R"+str(i) + "C"+str(j) + ".STL");
in the mix and get 100 STL files out of the deal; this makes it
easier to get a specific replacement without reprinting all 100.

On 1/9/2016 6:07 AM, jon wrote:

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

On 10 Jan 2016, at 5:31 am, "G. Wade Johnson" gwadej@anomaly.org wrote:

On Sat, 09 Jan 2016 07:38:30 -0500
Ezra Reynolds shadowwynd@gmail.com wrote:

I like that approach.

In many of my more complicated designs I have something like:

plate="combined";
if( plate == "part1" )
{
module1Name();
}
if( plate == "part2" )
{
module2Name();
}
if( plate == "combined" )
{
translate([-20,-20, 0]) module1Name();
translate([ 20, 20, 0]) module2Name();
}

This makes it easy to generate specific versions using openscad on the
command line. It works particularly well driven by make.

G. Wade

--
You need at least two viewpoints to have perspective.
-- Rick Hoselton

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

What if instead of export(), you could just tag a part of the tree with a
name. Then when you do export, there could be an option to export subtrees
where you give a base name for the export and each tagged subtree is
exported with a filename constructed by appending the subtree's name to the
base name.

You would have to think about what to do if two things were tagged with
the same name.

Greg Frost

wrote:

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

Ok, let's try to create a short resume of the discussion.

1. The feature itself is expected by at least some (or even most of)
   people, who posted their opinions here.

2. People are interested in having options to control, when export is
   performing it's action - preview or render mode.

3. There are security and unpredicted behavior issues:
   3a when exporting to arbitrary file.
   3b when importing and exporting from/to the same file.

4. There is a separate, but extremely interesting idea on giving
   names/tags to subtrees. I think it's worth separate discussion. Like having
   a function, which fetches such name from subtree to be able to do something
   like:
   module mymod(){
   name("My Super Module");
   ...
   };

export(file=nameofchild()+".stl") mymod();

Or even place texts with module names on top of the modules themself
(seems fun, but not sure, whether it is needed by someone at all).

If I have missed something, correct me please.

So, I have a simple question to maintainers - if I address the issues 1-3,
will these patches be accepted (after technical review, cleanup, whatever)?

What I'm planing to do:
2. Add options to export()
onrender=true|false, default - true
onpreview=true|false, default - true
// At this point I want to add undiscussed option
show=true|false, default - true, to control, whether just-exported subtree
should be shown on screen.
3a. Limit export operations to current working directory. Limit
characters, allowed in filenames to some known-safe set.
3b. Store all export/import filenames in some common (global?) data
structure to prevent loops.
10 янв. 2016 г. 12:26 AM пользователь "Greg Frost" <
gregorybartonfrost@gmail.com> написал:

What if instead of export(), you could just tag a part of the tree with a

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

On 01/10/2016 01:13 PM, nop head wrote:

Ok, we also have https://github.com/openscad/openscad/issues/1044
which asks for a way to control the layers that will be exported
to DXF. And there's a number of other similar requests already. How
would you do that with multiple file exports? Put all the various
possible inputs as parameters into one single export() which is then
called sometimes with parameterset A (for dxf layers) and sometimes
for parameterset B (for defining a file export)? This would also
mean the export() calls would need to be nested as the layers belong
into a single file.

With just tagging the subtrees, it leaves the interpretation to
the actual export function which could even show that information
to the user and allow changing it.

Note1: The syntax is just the Java one, lots of other languages
have adopted this feature with a different syntax, we would be
free to choose.

Note2: The prototype implementing this is already there and it's
actually not very complicated. The complex part is as always the
GUI. I also like to point out how this prototype is for a completely
different feature (https://github.com/openscad/openscad/issues/722)
and that would also be covered using the same syntax, maybe at
other places in the code, like the module definition instead of
the module instantiation.

module something(s) {
square(s * 10);
}

module part(r) {
@DxfLayer("layer1")
rotate(r) something(10);

     @DxfLayer("layer2")
     rotate(r) something(20);

}

@Export(name = "part1")
part1(0);

@Export(name = "part2")
part1(45);

Basically this simply attaches a set of key/value pairs to the
nodes which then can be interpreted when traversing the models
node tree.

Slic3r supports annotations in AMF files, to define some
properties for slicing a model. Even that could be handled
like @AMFMetaData(name = "slic3r.extruder", value = 1) and
would be silently ignore for STL export which does not have
any means to store this information.

ciao,
Torsten.

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

On 01/10/2016 05:47 PM, nop head wrote:

Interesting, even Python has similar features for functions.
http://python-future.org/func_annotations.html

And when looking at python decorators, the syntax almost matches
the Java syntax, I've used as example:
http://thecodeship.com/patterns/guide-to-python-function-decorators/
Although those are serving a bit different purpose, I think.

As I said, the specific syntax is just a prototype so far. It
does not really matter. Unfortunately C does not have annotations
so we can't borrow that syntax. But you could also argue that SCAD
looks like C# and we could try to use that syntax.

I think the key word here is attach. And that's precisely what
color() right now does not do. It creates a new tree node, so
if you traverse the node tree, there's a separate color node.
This actually makes things more complicated internally.

ciao,
Torsten.

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

On 01/10/2016 06:46 PM, nop head wrote:

In some respects, yes, that's true. But there's one thing that
does make it relevant. When using "normal" builtin modules to
define meta-data, we will capture all those names. Part of that
might be fixable if there's ever an implementation for namespaces,
but that's a bigger project in itself.
I've seen quite some cases where trying to unify everything into
the same logic resulted in problems.

Yes, color() is obviously existing as node already as there is
currently no other means. It certainly could be an annotation too.
I'm not really convinced that because we currently only have
hammers^H^H^H^H^H^H^Hnodes we need to shape every new problem
into nails^H^H^H^H^Hnodes if there are other options too.

Well, actually that's not totally true that we only have nodes.
In fact the ! # and % modifiers already behave like an annotation
for the module they are written before. This explains why this is
a parse error:

! { cube(); sphere(); }

And if we are talking about how hugely complicated things look
with annotations, let me, just for illustration purposes, use _
instead of that scary @ and reformat a bit

module part(r) {
_layer("layer1") rotate(r) something(10);
_layer("layer2") rotate(r) something(20);
}

_export(name = "part1") part1(0);
_export(name = "part2") part1(45);

Hmm, I really don't see how that's more complicated. Although
export is probably a bad name anyway. Something like Volume
would probably be ok, or even better something that applies
nicely to both 3D and 2D objects. (That's basically the HTML
discussion: Do logical instead of presentational description
and leave the interpretation to the processor/browser).

In essence, I think the only real difference between using a
module and something special whatever it's called is that it
introduces a different global namespace that does not collide
with the other existing ones and is not evaluated in the
script itself but in the renderer/exporter/external-tool.

ciao,
Torsten.

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

I think your last point is implementation details, which should not really
dictate language syntax.  From the outside I don't see any logical
difference between color and material and isn't everything a tree node in
openscad? It is however a big subject when you consider what happens with
respect to CGS ops (that isn't even right for colours yet). I don't think
it should hold up this or have any bearing on it.

I would prefer to keep the syntax as small as possible and not grabbed
from other, far more complicated, languages. Otherwise you might as well
write in those languages and generate scad files, as many people do.

module mydx() {
layer("outlines") { // note I have no idea what DXF layers names look
like.
...
}
layer("engrave") {
...
}
}

export("my.xdf) mydxf();

module myamf() {
material("PLA") {.....};
material("TEP") {.....};
}

export("my.amf") myamf();

Why does it need to be more complicated?

On 10 January 2016 at 17:23, Torsten Paul Torsten.Paul@gmx.de wrote:

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org