dotSCAD 2.0 RELEASE
https://github.com/JustinSDK/dotSCAD
dotSCAD 2.0 is based on OpenSCAD 2019.05.
- Use new features of OpenSCAD-2019.05 to refactor internal implementation.
- Delete the
logmodule which is never used. - Directory changed.
-
m_cumulate,m_mirror,m_rotation,m_scaling,m_shearingandm_translationare moved into thematrixdirectory. -
turtle2dandturtle3dare moved into theturtledirectory. -
parse_number,split_strandsub_strare moved into theutil
directory.
-
- New modules and functions.
- pixel/px_line
- pixel/px_polyline
- pixel/px_circle
- pixel/px_cylinder
- pixel/px_sphere
- pixel/px_polygon
- util/reverse
- util/slice
- util/sort
http://openhome.cc
Sent from: http://forum.openscad.org/
caterpillar wrote
Hi caterpillr,
I just read the readme, it says
Some modules depend on other modules. For example, the polyline2d module
depends on the line2d module, so you also have to include
<line2d.scad>
; besides include
<polyline3d.scad>
;.
include
<line2d.scad>
;
include
<polyline3d.scad>
;
polyline2d(points = [[1, 2], [-5, -4], [-5, 3], [5, 5]], width = 1);
If OpenSCAD generates "WARNING: Ignoring unknown xxx function" or
"WARNING: Ignoring unknown xxx module" when using one module of dotSCAD.
Just try to include
<xxx.scad>
; or include
<
dir/xxx.scad
>
if xxx.scad exists in dir directory.
Too many dependencies? Because OpenSCAD doesn't provide namespace
management, I personally think that exposing dependencies is better than
hiding them.
Why don't you include the dependency in the library file, e.g. 'include
<line2.scad>' in polyline3d.scad?
With the directories, I believe 'include <../line2.scad>' & 'include
<../pixel/px_something.scad> work.
Admin - email* me if you need anything, or if I've done something stupid...
- click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Sent from: http://forum.openscad.org/
If OpenSCAD deals with module dependency diagrams, including in the library
file will be better. But I read the document of include:
include <filename> acts as if the contents of the included file were
written in the including file.
And, if I include the same file twice, the code on the top-level runs twice.
I guess OpenSCAD just merges all including files recursively into one
source. I don't like the result so I decided to expose dependencies. The way
gives more flexibility to users who want to define their commonly-used
modules.
In this way, if OpenSCAD provides a better namespace mechanism in the
future, moving dependencies into the library file will be easier.
https://openhome.cc
Sent from: http://forum.openscad.org/
If you use files instead of including them then they get cached and only
one copy is in memory regardless of how many times it is used. As you say
include just inserts the text so if it is included twice it gets parsed
twice.
In my library I have two files for each library module. The first is
included and has all the constants and then it uses the second file which
has all the functions and modules. If those function and modules depend on
another library file then it is used or included in the library,
The end result is there is only one copy of any function or module and
mostly only one copy of each constant.
On Sun, 29 Sep 2019 at 04:02, caterpillar caterpillar@openhome.cc wrote:
If OpenSCAD deals with module dependency diagrams, including in the library
file will be better. But I read the document of include:
include <filename> acts as if the contents of the included file were
written in the including file.
And, if I include the same file twice, the code on the top-level runs
twice.
I guess OpenSCAD just merges all including files recursively into one
source. I don't like the result so I decided to expose dependencies. The
way
gives more flexibility to users who want to define their commonly-used
modules.
In this way, if OpenSCAD provides a better namespace mechanism in the
future, moving dependencies into the library file will be easier.
https://openhome.cc
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
If you include them then you get multiple copies so I don't think that is a
good idea. If you use them there is very little overhead using them
multiple times. The file name is looked up in a cache and when it hits the
parsed AST of the file is reused. So it takes virtually no time and doesn't
use any more memory.
On Sun, 29 Sep 2019 at 13:02, caterpillar caterpillar@openhome.cc wrote:
If modules/functions get cached and only one copy is in memory, I have a
question.
Is it encouraged or not to include the same module/function more than one
time from the perspective of OpenSCAD?
https://openhome.cc
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
If modules/functions get cached and only one copy is in memory, I have a
question.
Is it encouraged or not to include the same module/function more than one
time from the perspective of OpenSCAD?
https://openhome.cc
Sent from: http://forum.openscad.org/
Really? If you include multiple copies the code doesn't just replace the
previous version? If I define a module and then define it again, do both
definitions stay in memory?
Regarding "use", it has some performance problems. You should make sure
that no file that gets "used" has any commands in it except function and
module definitions, because any assignments will be run in their entirety
any time any function or module in the file is executed. (This can slow
performance if you have slow assignments and call a module or function in a
loop.)
It also appeared in my tests that calling functions from a "used" module is
just slower in general. So this means that utility functions that get
called a lot should probably be "included" but higher level modules that do
more complex things are probably fine to "use".
nophead wrote
If you include them then you get multiple copies so I don't think that is
a
good idea. If you use them there is very little overhead using them
multiple times. The file name is looked up in a cache and when it hits the
parsed AST of the file is reused. So it takes virtually no time and
doesn't
use any more memory.
--
Sent from: http://forum.openscad.org/
My understanding is that if you include something twice it certainly gets
parsed twice. I am not sure if it replaces a previous definition in memory
or not. Certainly if you include a file into other files that are
themselves used then you will have multiple copies because used modules
have their own namespace.
Yes constant expressions in a used file get evaluated each time any
function or module in the same file is called. I wasted a lot time trying
to optimise the spring module in my library so that I can store the
polyhedron of the spring an reuse it. I did that because in my battery
module each battery is shown with battery clips that include a spring. I
found it is impossible to make one copy of that spiral spring in my library
and reuse it because assigning the mesh to a variable keeps re-evaluating
it over and over again making it slower instead of quicker.
On Sun, 29 Sep 2019 at 13:59, adrianv avm4@cornell.edu wrote:
Really? If you include multiple copies the code doesn't just replace the
previous version? If I define a module and then define it again, do both
definitions stay in memory?
Regarding "use", it has some performance problems. You should make sure
that no file that gets "used" has any commands in it except function and
module definitions, because any assignments will be run in their entirety
any time any function or module in the file is executed. (This can slow
performance if you have slow assignments and call a module or function in a
loop.)
It also appeared in my tests that calling functions from a "used" module is
just slower in general. So this means that utility functions that get
called a lot should probably be "included" but higher level modules that do
more complex things are probably fine to "use".
nophead wrote
If you include them then you get multiple copies so I don't think that is
a
good idea. If you use them there is very little overhead using them
multiple times. The file name is looked up in a cache and when it hits
the
parsed AST of the file is reused. So it takes virtually no time and
doesn't
use any more memory.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
The discussion reminds me of a long history of JavaScript module development.
Before ES6, there's no namespace management. Clever JS developers come up
with various ways to simulate their module system. No one is wrong because
all fit their concerns.
If there's no standard namespace mechanism, we can prefer our one due to
different considerations. (Although they match our requirements, problems
happen when you try to combine libraries from different authors.)
As for me ...
Small piece duplications are allowed in my library. Take arc_path for
example:
https://github.com/JustinSDK/dotSCAD/blob/master/src/arc_path.scad
include <comm/__frags.scad>;
include <comm/__ra_to_xy.scad>;
include <comm/__edge_r.scad>;
function arc_path(radius, angle) =...
But, I avoid duplicating public modules/functions if possible.
https://openhome.cc
Sent from: http://forum.openscad.org/
dotSCAD 2.1 RELEASE.
https://github.com/JustinSDK/dotSCAD
For changes, please see RELEASE
https://github.com/JustinSDK/dotSCAD/blob/master/RELEASE.md .
I also add examples
https://github.com/JustinSDK/dotSCAD/tree/master/examples based on
dotSCAD.
http://forum.openscad.org/file/t1825/gallery.jpg
https://openhome.cc
Sent from: http://forum.openscad.org/