JB
Jordan Brown
Tue, Oct 1, 2019 8:30 PM
On 10/1/2019 1:08 AM, Robin2 wrote:
But then I got tired of all the typing and realised that I can have
the best of both worlds. I don't want to discourage the people who
prefer to type in their code. But I think that a front-end that allows
the lazy (like me) to avoid it would be a benefit.
I'm not understanding how to have the user describe geometries in a way
that isn't more onerous than the current scheme.
In your user interface, how would you do this?
cylinder(h=10);
translate([0,0,10]) {
rotate([0,90,0]) cylinder(h=10,center=true);
rotate([90,0,0]) cylinder(h=10,center=true);
}
And even more so, how would the user describe what I would really do, to
automatically retain the relationship between the components:
size=10;
cylinder(h=size);
translate([0,0,size]) {
rotate([0,90,0]) cylinder(h=size,center=true);
rotate([90,0,0]) cylinder(h=size,center=true);
}
On 10/1/2019 1:08 AM, Robin2 wrote:
> But then I got tired of all the typing and realised that I can have
> the best of both worlds. I don't want to discourage the people who
> prefer to type in their code. But I think that a front-end that allows
> the lazy (like me) to avoid it would be a benefit.
I'm not understanding how to have the user describe geometries in a way
that isn't more onerous than the current scheme.
In your user interface, how would you do this?
cylinder(h=10);
translate([0,0,10]) {
rotate([0,90,0]) cylinder(h=10,center=true);
rotate([90,0,0]) cylinder(h=10,center=true);
}
And even more so, how would the user describe what I would really do, to
automatically retain the relationship between the components:
size=10;
cylinder(h=size);
translate([0,0,size]) {
rotate([0,90,0]) cylinder(h=size,center=true);
rotate([90,0,0]) cylinder(h=size,center=true);
}
TP
Torsten Paul
Tue, Oct 1, 2019 9:34 PM
- Haskell has generalized tail recursion optimization. The
corresponding feature in OpenSCAD is restricted to one specific
code pattern, and only works for self-recursive functions,
not mutually recursive functions.
On Tue, 1 Oct 2019 at 16:09, Doug Moen <doug@moens.org> wrote:
> 0. Haskell has generalized tail recursion optimization. The
> corresponding feature in OpenSCAD is restricted to one specific
> code pattern, and only works for self-recursive functions,
> not mutually recursive functions.
As of https://github.com/openscad/openscad/pull/3020 the first
part is not true anymore.
ciao,
Torsten.
AC
Alan Cox
Tue, Oct 1, 2019 11:10 PM
I'm kind of puzzled about this. To me the whole reason to use OpenSCAD, and
its big strength, is that I can construct my model by writing code. Aren't
there other packages like Blender or SketchUp that are designed from the
ground up for people who prefer a GUI interface?
Blender has a python interface.
Alan
> I'm kind of puzzled about this. To me the whole reason to use OpenSCAD, and
> its big strength, is that I can construct my model by writing code. Aren't
> there other packages like Blender or SketchUp that are designed from the
> ground up for people who prefer a GUI interface?
Blender has a python interface.
Alan
M
MichaelAtOz
Wed, Oct 2, 2019 1:15 AM
One of the benefits of OpenSCAD is the quicker preview.
One of the deficits is the lengthy render.
It is the mix that makes it more usable.
The problem with render is it is single threaded, while there have been
attempts at multi-threading, the latest sometimes/often works (on Windows)
or frequently doesn't (Linux). Hopefully this will be workable in the
future.
Even with working multi-threading it will not speed-up render to be
comparable to preview.
So we need to retain the two-phase approach.
Any language redesign needs to factor how the workload stays efficient in
preview but can also be allocated across threads in (future) render.
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/
One of the benefits of OpenSCAD is the quicker preview.
One of the deficits is the lengthy render.
It is the mix that makes it more usable.
The problem with render is it is single threaded, while there have been
attempts at multi-threading, the latest sometimes/often works (on Windows)
or frequently doesn't (Linux). Hopefully this will be workable in the
future.
Even with working multi-threading it will not speed-up render to be
comparable to preview.
So we need to retain the two-phase approach.
Any language redesign needs to factor how the workload stays efficient in
preview but can also be allocated across threads in (future) render.
-----
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/
A
arnholm@arnholm.org
Wed, Oct 2, 2019 4:52 AM
On 2019-10-02 03:15, MichaelAtOz wrote:
The problem with render is it is single threaded, while there have been
attempts at multi-threading, the latest sometimes/often works (on
Windows)
or frequently doesn't (Linux). Hopefully this will be workable in the
future.
There is no fundamental reason why multi-treading should not work on
Linux. I have done it, it works the same on Windows and Linux.
Carsten Arnholm
On 2019-10-02 03:15, MichaelAtOz wrote:
> The problem with render is it is single threaded, while there have been
> attempts at multi-threading, the latest sometimes/often works (on
> Windows)
> or frequently doesn't (Linux). Hopefully this will be workable in the
> future.
There is no fundamental reason why multi-treading should not work on
Linux. I have done it, it works the same on Windows and Linux.
Carsten Arnholm
M
MichaelAtOz
Wed, Oct 2, 2019 5:28 AM
I'm not having a go at Linux, I was being specific, the last OpenSCAD
Multi-thread approach, seems to work much of the time on Windows (but did
produce bad geometry sometimes), when I ran it on Debian, it crashed most of
the time.
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/
I'm not having a go at Linux, I was being specific, the last OpenSCAD
Multi-thread approach, seems to work much of the time on Windows (but did
produce bad geometry sometimes), when I ran it on Debian, it crashed most of
the time.
-----
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/
R
Robin2
Wed, Oct 2, 2019 7:40 AM
In your user interface, how would you do this?
cylinder(h=10);
translate([0,0,10]) {
rotate([0,90,0]) cylinder(h=10,center=true);
rotate([90,0,0]) cylinder(h=10,center=true);
}
The end product will be essentially the same but rather than remembering the
syntax for (say) rotate() the user just CLICKS to select a ROTATE and
provides the numbers 0, 90, 0 and the then CLICKS to select the object (the
cylinder) it is to be applied to.
All the text for the code then gets written by the Python program without
any typos.
Yours is a useful example of something I have noticed with Openscad.
Developing a model involves a lot of re-tracing of steps.
For example, I create a cylinder.
Then I say "oops, I need to go back and rotate the cylinder".
Then "I now need to go back and translate the rotated cylinder".
Maybe your mind is capable of envisaging the entire process and writing it
directly from top to bottom, but mine certainly is not.
...R
--
Sent from: http://forum.openscad.org/
JordanBrown wrote
> In your user interface, how would you do this?
>
> cylinder(h=10);
> translate([0,0,10]) {
> rotate([0,90,0]) cylinder(h=10,center=true);
> rotate([90,0,0]) cylinder(h=10,center=true);
> }
The end product will be essentially the same but rather than remembering the
syntax for (say) rotate() the user just CLICKS to select a ROTATE and
provides the numbers 0, 90, 0 and the then CLICKS to select the object (the
cylinder) it is to be applied to.
All the text for the code then gets written by the Python program without
any typos.
Yours is a useful example of something I have noticed with Openscad.
Developing a model involves a lot of re-tracing of steps.
For example, I create a cylinder.
Then I say "oops, I need to go back and rotate the cylinder".
Then "I now need to go back and translate the rotated cylinder".
Maybe your mind is capable of envisaging the entire process and writing it
directly from top to bottom, but mine certainly is not.
...R
--
Sent from: http://forum.openscad.org/
SD
Steven Dick
Wed, Oct 2, 2019 11:33 AM
I've often dreamed of a GUI for OpenSCAD that would work seamlessly
with the OpenSCAD programming capability.
I've been afraid that adding mutable variables would make this difficult.
What I imagine for a GUI would be that basic shapes (like cylinder,
cube, etc.) are offered on a tool panel, and a customizer like
interface is used to adjust them. Placing the object generates code.
New object types are created by making modules (as we have now) and
the parameters of the module are customizer parameters as would work
with a built in object.
This simplistic view doesn't address how to handle relations between
objects or how to express modules that operate on other objects. To
be complete, this would need to be handled.
The other feature that OpenSCAD is missing from a traditional cad
package is the equivalent of snap... Simple snaps can be done just by
drawing objects relative to each other, but more complex snaps (like
attaching at the corner formed by intersecting two objects) sometimes
requires me to do trigonometry to find the snap location or
calculating the tangent or something worse. As someone stated in
another thread, fixing this would require primitives to "ask
questions" about the resulting object.
I've often dreamed of a GUI for OpenSCAD that would work seamlessly
with the OpenSCAD programming capability.
I've been afraid that adding mutable variables would make this difficult.
What I imagine for a GUI would be that basic shapes (like cylinder,
cube, etc.) are offered on a tool panel, and a customizer like
interface is used to adjust them. Placing the object generates code.
New object types are created by making modules (as we have now) and
the parameters of the module are customizer parameters as would work
with a built in object.
This simplistic view doesn't address how to handle relations between
objects or how to express modules that operate on other objects. To
be complete, this would need to be handled.
The other feature that OpenSCAD is missing from a traditional cad
package is the equivalent of snap... Simple snaps can be done just by
drawing objects relative to each other, but more complex snaps (like
attaching at the corner formed by intersecting two objects) sometimes
requires me to do trigonometry to find the snap location or
calculating the tangent or something worse. As someone stated in
another thread, fixing this would require primitives to "ask
questions" about the resulting object.
A
arnholm@arnholm.org
Wed, Oct 2, 2019 11:39 AM
On 2019-10-02 07:28, MichaelAtOz wrote:
I'm not having a go at Linux, I was being specific, the last OpenSCAD
Multi-thread approach, seems to work much of the time on Windows (but
did
produce bad geometry sometimes), when I ran it on Debian, it crashed
most of
the time.
I am not implying you are having a go at Linux. What you are describing
is likely a software design/implemntation issue, and not an operating
system issue.
Carsten Arnholm
On 2019-10-02 07:28, MichaelAtOz wrote:
> I'm not having a go at Linux, I was being specific, the last OpenSCAD
> Multi-thread approach, seems to work much of the time on Windows (but
> did
> produce bad geometry sometimes), when I ran it on Debian, it crashed
> most of
> the time.
I am not implying you are having a go at Linux. What you are describing
is likely a software design/implemntation issue, and not an operating
system issue.
Carsten Arnholm
NH
nop head
Wed, Oct 2, 2019 11:49 AM
If you run multiple threads through code that is not threadsafe then you
get undefined results. Not surprising they are different on different OSes.
On Wed, 2 Oct 2019 at 12:41, arnholm@arnholm.org wrote:
On 2019-10-02 07:28, MichaelAtOz wrote:
I'm not having a go at Linux, I was being specific, the last OpenSCAD
Multi-thread approach, seems to work much of the time on Windows (but
did
produce bad geometry sometimes), when I ran it on Debian, it crashed
most of
the time.
If you run multiple threads through code that is not threadsafe then you
get undefined results. Not surprising they are different on different OSes.
On Wed, 2 Oct 2019 at 12:41, <arnholm@arnholm.org> wrote:
> On 2019-10-02 07:28, MichaelAtOz wrote:
> > I'm not having a go at Linux, I was being specific, the last OpenSCAD
> > Multi-thread approach, seems to work much of the time on Windows (but
> > did
> > produce bad geometry sometimes), when I ran it on Debian, it crashed
> > most of
> > the time.
>
> I am not implying you are having a go at Linux. What you are describing
> is likely a software design/implemntation issue, and not an operating
> system issue.
>
> Carsten Arnholm
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
