Empathy List Archives

DM

doug moen

Sat, Jul 18, 2015 6:26 PM

Hi Runsun.

For point (1), I agree: I'd like to have a richer set of operations
available for geometric objects. Every geometric object is equivalent to a
set of disjoint polyhedra, represented as meshes, and it would be very cool
if you could programmatically access the mesh. Marius wants this too.
However, he wants to be cautious, because in the current implementation,
this would mean that CGAL operations are intermixed with general
evaluation, which would slow down preview so that F5 is no faster than F6.
So I think Marius wants to defer these kinds of changes until we replace
the geometry engine and maybe the preview engine with faster code that can
support this.

I have not done any significant design work on what these new geometric
operations will look like, although I've played around with ideas. I
imagine that the design will be affected by whatever new technology we
choose to replace CGAL.

For point (2), OpenSCAD2 already works this way. Underneath the
peculiarities of module call syntax, modules are really just functions that
return geometric objects, and module calls are expressions. So you can write
yourcube = rotate(45) mycube;

On 18 July 2015 at 13:03, runsun runsun@gmail.com wrote:

Doug (in other thread) wrote

In OpenSCAD2, the syntax {...} is an expression that returns a geometric
object.
For example, { size=10; cube(size); } is an expression.

You can give this expression a name:

mycube = {
   size=10;
   cube(size);
};

Now 'mycube' is the name of a geometric object.

echo(mycube.size); // ECHO: 10

rotate(45) mycube;

Doug.

I'd prefer that this geometric object has some built-in parameters,
for
example, like points:

echo( mycube.points );

So we can do these:

1.1) translate( mycube.points[3]) yourcube;

1.2) for( p= mycube.points ) translate( p ) sphere(...);

1.3) for( i= mycube.points[4:] ) // pick up the second half
mycube.points[i]= somefunc(i); // re-assign points to
change shape

1.4) Assuming we have a Line() module, draw a line to connect two
objects (at specified points):
```
     Line( mycube.points[0], yourcube.points[2] )
```
1.5) distance( mycube.points[0], yourcube.points[2] )
I'd prefer all those actions, like translate, rotate, union, etc, can
be*
functions*, too:
```
yourcube = rotate( mycube, 45 );
hiscube = translate( yourcube.points[2] );
```

All the ideas have one thing in mind: *keeping track of coordinates for
further operations. *

$ Runsun Pan, PhD

$ -- OpenScad_DocTest ( Thingiverse ), faces , Offliner

$ -- hash parameter model: here , here

$ -- Linux Mint 17.1 Rebecca x64 + OpenSCAD 2015.03.15/2015.04.01.nightly

--
View this message in context:
http://forum.openscad.org/OpenSCAD2-design-docs-tp13019p13232.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

Hi Runsun. For point (1), I agree: I'd like to have a richer set of operations available for geometric objects. Every geometric object is equivalent to a set of disjoint polyhedra, represented as meshes, and it would be very cool if you could programmatically access the mesh. Marius wants this too. However, he wants to be cautious, because in the current implementation, this would mean that CGAL operations are intermixed with general evaluation, which would slow down preview so that F5 is no faster than F6. So I think Marius wants to defer these kinds of changes until we replace the geometry engine and maybe the preview engine with faster code that can support this. I have not done any significant design work on what these new geometric operations will look like, although I've played around with ideas. I imagine that the design will be affected by whatever new technology we choose to replace CGAL. For point (2), OpenSCAD2 already works this way. Underneath the peculiarities of module call syntax, modules are really just functions that return geometric objects, and module calls are expressions. So you can write yourcube = rotate(45) mycube; On 18 July 2015 at 13:03, runsun <runsun@gmail.com> wrote: > Doug (in other thread) wrote > > > > In OpenSCAD2, the syntax {...} is an expression that returns a geometric > > object. > > For example, { size=10; cube(size); } is an expression. > > > > You can give this expression a name: > > > > mycube = { > > size=10; > > cube(size); > > }; > > > > Now 'mycube' is the name of a geometric object. > > > > echo(mycube.size); // ECHO: 10 > > > > rotate(45) mycube; > > > > Doug. > > 1) I'd prefer that this geometric object has some *built-in parameters*, > for > example, like *points*: > > echo( mycube.points ); > > So we can do these: > > 1.1) translate( mycube.points[3]) yourcube; > > 1.2) for( p= mycube.points ) translate( p ) sphere(...); > > 1.3) for( i= mycube.points[4:] ) // pick up the second half > mycube.points[i]= somefunc(i); // re-assign points to > change shape > > 1.4) Assuming we have a Line() module, draw a line to connect two > objects (at specified points): > > Line( mycube.points[0], yourcube.points[2] ) > > 1.5) distance( mycube.points[0], yourcube.points[2] ) > > 2) I'd prefer all those actions, like translate, rotate, union, etc, can > be* > functions*, too: > > yourcube = rotate( mycube, 45 ); > hiscube = translate( yourcube.points[2] ); > > All the ideas have one thing in mind: *keeping track of coordinates for > further operations. * > > > > ----- > > $ Runsun Pan, PhD > > $ -- OpenScad_DocTest ( Thingiverse ), faces , Offliner > > $ -- hash parameter model: here , here > > $ -- Linux Mint 17.1 Rebecca x64 + OpenSCAD 2015.03.15/2015.04.01.nightly > > > > > -- > View this message in context: > http://forum.openscad.org/OpenSCAD2-design-docs-tp13019p13232.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 > >

M

MichaelAtOz

Sat, Jul 18, 2015 9:20 PM

doug.moen wrote

At present, this is an incompatibility between the existing language and
OpenSCAD2 that I wasn't aware of.

The new OpenSCAD implementation will use heuristics to detect OpenSCAD1
code and run in backward compatibility mode. It should be capable of
detecting Michael's code and evaluating it correctly without breaking.
There will also be an upgrade tool that converts existing code to use the
new syntax, and we could convert top level {...} statements to 'include
{...};' as part of the upgrade.

Instead of compatibility mode, can't include{} be implicit, or does that
break something else?

Michael, do you think this is an acceptable solution to the problem that
you uncovered?

Yes.

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. This work is published globally via the internet. :) 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/

View this message in context: http://forum.openscad.org/OpenSCAD2-design-docs-tp13019p13239.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

doug.moen wrote > At present, this is an incompatibility between the existing language and > OpenSCAD2 that I wasn't aware of. > > The new OpenSCAD implementation will use heuristics to detect OpenSCAD1 > code and run in backward compatibility mode. It should be capable of > detecting Michael's code and evaluating it correctly without breaking. > There will also be an upgrade tool that converts existing code to use the > new syntax, and we could convert top level {...} statements to 'include > {...};' as part of the upgrade. Instead of compatibility mode, can't include{} be implicit, or does that break something else? > Michael, do you think this is an acceptable solution to the problem that > you uncovered? Yes. ----- 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. This work is published globally via the internet. :) 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/ -- View this message in context: http://forum.openscad.org/OpenSCAD2-design-docs-tp13019p13239.html Sent from the OpenSCAD mailing list archive at Nabble.com.

R

runsun

Sat, Jul 18, 2015 9:29 PM

Thx for the explanation, Doug. Guess we'll have to wait longer.

That seems to be what happens (i.e., F6 is as quick as F5 <== feel better
reading this way,lol ) using the lib that I wrote (using polyhedron
entirely).
I didn't know the current Openscad can do this: yourcube = rotate(45)
mycube

Learned lots of things reading forum :) :)

$ Runsun Pan, PhD

$ -- OpenScad_DocTest ( Thingiverse ), faces , Offliner

$ -- hash parameter model: here , here

$ -- Linux Mint 17.1 Rebecca x64 + OpenSCAD 2015.03.15/2015.04.01.nightly

--
View this message in context: http://forum.openscad.org/OpenSCAD2-design-docs-tp13019p13240.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Thx for the explanation, Doug. Guess we'll have to wait longer. 1) That seems to be what happens (i.e., F6 is as quick as F5 <== feel better reading this way,lol ) using the lib that I wrote (using polyhedron entirely). 2) I didn't know the current Openscad can do this: yourcube = rotate(45) mycube Learned lots of things reading forum :) :) ----- $ Runsun Pan, PhD $ -- OpenScad_DocTest ( Thingiverse ), faces , Offliner $ -- hash parameter model: here , here $ -- Linux Mint 17.1 Rebecca x64 + OpenSCAD 2015.03.15/2015.04.01.nightly -- View this message in context: http://forum.openscad.org/OpenSCAD2-design-docs-tp13019p13240.html Sent from the OpenSCAD mailing list archive at Nabble.com.

DM

doug moen

Sat, Jul 18, 2015 9:52 PM

I didn't know the current Openscad can do this:
yourcube = rotate(45) mycube;

Sorry, no, I meant that the OpenSCAD2 design document adds this as new
syntax.

On 18 July 2015 at 17:29, runsun runsun@gmail.com wrote:

Thx for the explanation, Doug. Guess we'll have to wait longer.

That seems to be what happens (i.e., F6 is as quick as F5 <== feel
better
reading this way,lol ) using the lib that I wrote (using polyhedron
entirely).
I didn't know the current Openscad can do this: yourcube = rotate(45)
mycube

Learned lots of things reading forum :) :)

$ Runsun Pan, PhD

$ -- OpenScad_DocTest ( Thingiverse ), faces , Offliner

$ -- hash parameter model: here , here

$ -- Linux Mint 17.1 Rebecca x64 + OpenSCAD 2015.03.15/2015.04.01.nightly

--
View this message in context:
http://forum.openscad.org/OpenSCAD2-design-docs-tp13019p13240.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

> 2) I didn't know the current Openscad can do this: > yourcube = rotate(45) mycube; Sorry, no, I meant that the OpenSCAD2 design document adds this as new syntax. On 18 July 2015 at 17:29, runsun <runsun@gmail.com> wrote: > Thx for the explanation, Doug. Guess we'll have to wait longer. > > 1) That seems to be what happens (i.e., F6 is as quick as F5 <== feel > better > reading this way,lol ) using the lib that I wrote (using polyhedron > entirely). > > 2) I didn't know the current Openscad can do this: yourcube = rotate(45) > mycube > > Learned lots of things reading forum :) :) > > > > > > ----- > > $ Runsun Pan, PhD > > $ -- OpenScad_DocTest ( Thingiverse ), faces , Offliner > > $ -- hash parameter model: here , here > > $ -- Linux Mint 17.1 Rebecca x64 + OpenSCAD 2015.03.15/2015.04.01.nightly > > > > > -- > View this message in context: > http://forum.openscad.org/OpenSCAD2-design-docs-tp13019p13240.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 > >

JL

Jean-Paul Louis

Sun, Jul 19, 2015 12:49 AM

What is the release schedule for OpenSCAD2? It seems to have features that I really need.

Just curious,
Jean-Paul
AC9GH

On Jul 18, 2015, at 5:52 PM, doug moen doug@moens.org wrote:

I didn't know the current Openscad can do this:
yourcube = rotate(45) mycube;

Sorry, no, I meant that the OpenSCAD2 design document adds this as new syntax.

On 18 July 2015 at 17:29, runsun runsun@gmail.com wrote:
Thx for the explanation, Doug. Guess we'll have to wait longer.

That seems to be what happens (i.e., F6 is as quick as F5 <== feel better
reading this way,lol ) using the lib that I wrote (using polyhedron
entirely).
I didn't know the current Openscad can do this: yourcube = rotate(45)
mycube

Learned lots of things reading forum :) :)

$ Runsun Pan, PhD

$ -- OpenScad_DocTest ( Thingiverse ), faces , Offliner

$ -- hash parameter model: here , here

$ -- Linux Mint 17.1 Rebecca x64 + OpenSCAD 2015.03.15/2015.04.01.nightly

--
View this message in context: http://forum.openscad.org/OpenSCAD2-design-docs-tp13019p13240.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

What is the release schedule for OpenSCAD2? It seems to have features that I really need. Just curious, Jean-Paul AC9GH > On Jul 18, 2015, at 5:52 PM, doug moen <doug@moens.org> wrote: > > > 2) I didn't know the current Openscad can do this: > > yourcube = rotate(45) mycube; > > Sorry, no, I meant that the OpenSCAD2 design document adds this as new syntax. > > On 18 July 2015 at 17:29, runsun <runsun@gmail.com> wrote: > Thx for the explanation, Doug. Guess we'll have to wait longer. > > 1) That seems to be what happens (i.e., F6 is as quick as F5 <== feel better > reading this way,lol ) using the lib that I wrote (using polyhedron > entirely). > > 2) I didn't know the current Openscad can do this: yourcube = rotate(45) > mycube > > Learned lots of things reading forum :) :) > > > > > > ----- > > $ Runsun Pan, PhD > > $ -- OpenScad_DocTest ( Thingiverse ), faces , Offliner > > $ -- hash parameter model: here , here > > $ -- Linux Mint 17.1 Rebecca x64 + OpenSCAD 2015.03.15/2015.04.01.nightly > > > > > -- > View this message in context: http://forum.openscad.org/OpenSCAD2-design-docs-tp13019p13240.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 > > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

DM

doug moen

Sun, Jul 19, 2015 7:05 PM

Hi Michael. I just noticed the naming convention in your code. You have a
large number of parameters, and you are using a naming convention to
simulate a hierarchical namespace.

OpenSCAD2 directly supports parameter hierarchies, and that might be the
best coding convention for your model. For example,

r = { // rECESS - the hollow holder where accessories are inserted
Tolerance=0.0; // adjust - originally the ID of the print was
marginally tight
2.05 2.75
OD=40;
ID=35.5;
Thick=2-r.Tolerance;
Deep=38; // was 45
};

rRidge = { // rECESS Ridge - the raised ridges running down inside the
holder
High=0.75-r.Tolerance;
Wide=3;
Wide0=6.2; // at mid-line parallel with slot at top
Num=6; // spacing, includes the one cut away by wide slot
};

This gives you names like r.Tolerance and rRidge.High, plus you can pass r
and rRidge as function arguments.

On 18 July 2015 at 14:01, doug moen doug@moens.org wrote:

MichaelAtOz notes that a top level compound statement, {...}, is
interpreted by OpenSCAD as if the braces aren't there. Michael uses this to
group sets of related definitions within a large script, so that they can
be collapsed by the folding tree editor.

This is new information for me: I didn't know that people are using this
design pattern "in the wild", as Michael says.

Right now, the idiomatic way to write this code in OpenSCAD2 is:

include { // rECESS - the hollow holder where accessories are inserted
rTolerance=0.0; // adjust - originally the ID of the print was marginally
tight 2.05 2.75
rOD=40;
rID=35.5;
rThick=2-rTolerance;
rDeep=38; // was 45
};

include { // rECESS Ridge - the raised ridges running down inside the
holder
rRidgeHigh=0.75-rTolerance;
rRidgeWide=3;
rRidgeWide0=6.2; // at mid-line parallel with slot at top
rRidgeNum=6; // spacing, includes the one cut away by wide slot
};

Explanation: the OpenSCAD2 'include' operator takes an object expression
as an argument, and {...} is an object literal.

Also, in OpenSCAD2, objects are the replacement for groups in the CSG
tree. Each non-leaf node in the CSG tree is an object. As a result, "top
level compound statements" could appear naturally in code as a
representation of nested objects in a CSG tree. And that conflicts with the
current use of that syntax that Michael reports.

At present, this is an incompatibility between the existing language and
OpenSCAD2 that I wasn't aware of.

The new OpenSCAD implementation will use heuristics to detect OpenSCAD1
code and run in backward compatibility mode. It should be capable of
detecting Michael's code and evaluating it correctly without breaking.
There will also be an upgrade tool that converts existing code to use the
new syntax, and we could convert top level {...} statements to 'include
{...};' as part of the upgrade.

Michael, do you think this is an acceptable solution to the problem that
you uncovered?

Doug.

On 18 July 2015 at 01:10, MichaelAtOz oz.at.michael@gmail.com wrote:

Re scope rules for v2.

I have used this layout

{ // rECESS - the hollow holder where accessories are inserted
rTolerance=0.0; // adjust - originally the ID of the print was marginally
tight 2.05 2.75
rOD=40;
rID=35.5;
rThick=2-rTolerance;
rDeep=38; // was 45
}

{ // rECESS Ridge - the raised ridges running down inside the holder
rRidgeHigh=0.75-rTolerance;
rRidgeWide=3;
rRidgeWide0=6.2; // at mid-line parallel with slot at top
rRidgeNum=6; // spacing, includes the one cut away by wide slot
}

To group the definitions but mainly to allow me to collapse them in the
editor.

I think I have seen other code in the wild doing so too.

Is that going to be problematic in v2 scoping?

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. This work is
published globally via the internet. :) 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/

View this message in context:
http://forum.openscad.org/OpenSCAD2-design-docs-tp13019p13225.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

Hi Michael. I just noticed the naming convention in your code. You have a large number of parameters, and you are using a naming convention to simulate a hierarchical namespace. OpenSCAD2 directly supports parameter hierarchies, and that might be the best coding convention for your model. For example, r = { // rECESS - the hollow holder where accessories are inserted Tolerance=0.0; // adjust - originally the ID of the print was marginally tight 2.05 2.75 OD=40; ID=35.5; Thick=2-r.Tolerance; Deep=38; // was 45 }; rRidge = { // rECESS Ridge - the raised ridges running down inside the holder High=0.75-r.Tolerance; Wide=3; Wide0=6.2; // at mid-line parallel with slot at top Num=6; // spacing, includes the one cut away by wide slot }; This gives you names like r.Tolerance and rRidge.High, plus you can pass r and rRidge as function arguments. On 18 July 2015 at 14:01, doug moen <doug@moens.org> wrote: > MichaelAtOz notes that a top level compound statement, {...}, is > interpreted by OpenSCAD as if the braces aren't there. Michael uses this to > group sets of related definitions within a large script, so that they can > be collapsed by the folding tree editor. > > This is new information for me: I didn't know that people are using this > design pattern "in the wild", as Michael says. > > Right now, the idiomatic way to write this code in OpenSCAD2 is: > > include { // rECESS - the hollow holder where accessories are inserted > rTolerance=0.0; // adjust - originally the ID of the print was marginally > tight 2.05 2.75 > rOD=40; > rID=35.5; > rThick=2-rTolerance; > rDeep=38; // was 45 > }; > > include { // rECESS Ridge - the raised ridges running down inside the > holder > rRidgeHigh=0.75-rTolerance; > rRidgeWide=3; > rRidgeWide0=6.2; // at mid-line parallel with slot at top > rRidgeNum=6; // spacing, includes the one cut away by wide slot > }; > > > Explanation: the OpenSCAD2 'include' operator takes an object expression > as an argument, and {...} is an object literal. > > Also, in OpenSCAD2, objects are the replacement for groups in the CSG > tree. Each non-leaf node in the CSG tree is an object. As a result, "top > level compound statements" could appear naturally in code as a > representation of nested objects in a CSG tree. And that conflicts with the > current use of that syntax that Michael reports. > > At present, this is an incompatibility between the existing language and > OpenSCAD2 that I wasn't aware of. > > The new OpenSCAD implementation will use heuristics to detect OpenSCAD1 > code and run in backward compatibility mode. It should be capable of > detecting Michael's code and evaluating it correctly without breaking. > There will also be an upgrade tool that converts existing code to use the > new syntax, and we could convert top level {...} statements to 'include > {...};' as part of the upgrade. > > Michael, do you think this is an acceptable solution to the problem that > you uncovered? > > Doug. > > On 18 July 2015 at 01:10, MichaelAtOz <oz.at.michael@gmail.com> wrote: > >> Re scope rules for v2. >> >> I have used this layout >> >> >> { // rECESS - the hollow holder where accessories are inserted >> rTolerance=0.0; // adjust - originally the ID of the print was marginally >> tight 2.05 2.75 >> rOD=40; >> rID=35.5; >> rThick=2-rTolerance; >> rDeep=38; // was 45 >> } >> >> { // rECESS Ridge - the raised ridges running down inside the holder >> rRidgeHigh=0.75-rTolerance; >> rRidgeWide=3; >> rRidgeWide0=6.2; // at mid-line parallel with slot at top >> rRidgeNum=6; // spacing, includes the one cut away by wide slot >> } >> >> To group the definitions but mainly to allow me to collapse them in the >> editor. >> >> I think I have seen other code in the wild doing so too. >> >> Is that going to be problematic in v2 scoping? >> >> >> >> >> ----- >> 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. This work is >> published globally via the internet. :) 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/ >> -- >> View this message in context: >> http://forum.openscad.org/OpenSCAD2-design-docs-tp13019p13225.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 >> > >

M

MichaelAtOz

Sun, Jul 19, 2015 10:59 PM

Yeh, that look good. Also the { & } should collapse in the editor too.

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. This work is published globally via the internet. :) 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/

View this message in context: http://forum.openscad.org/OpenSCAD2-design-docs-tp13019p13251.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Yeh, that look good. Also the { & } should collapse in the editor too. ----- 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. This work is published globally via the internet. :) 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/ -- View this message in context: http://forum.openscad.org/OpenSCAD2-design-docs-tp13019p13251.html Sent from the OpenSCAD mailing list archive at Nabble.com.

DM

doug moen

Mon, Jul 20, 2015 2:07 PM

I have very little time to spare for this right now. I hope to have time to
start writing code in August or September.

At the moment, I've got a first draft of parser.y, and I've planned out
some algorithms and data structures, but that's it.

I was hoping to get more feedback from Marius, but he's gone off and
started a new company, so he's busy.

There is no "release schedule", but the general plan is:

get feedback from the community, update the design based on feedback
carve up the design into smaller pieces that can be implemented
independently, or in phases
recruit people to write code for the various pieces
start coding

Doug Moen

On 18 July 2015 at 20:49, Jean-Paul Louis louijp@yahoo.com wrote:

What is the release schedule for OpenSCAD2? It seems to have features that
I really need.

Just curious,
Jean-Paul
AC9GH

On Jul 18, 2015, at 5:52 PM, doug moen doug@moens.org wrote:

I didn't know the current Openscad can do this:
yourcube = rotate(45) mycube;

Sorry, no, I meant that the OpenSCAD2 design document adds this as new

syntax.

On 18 July 2015 at 17:29, runsun runsun@gmail.com wrote:
Thx for the explanation, Doug. Guess we'll have to wait longer.

That seems to be what happens (i.e., F6 is as quick as F5 <== feel

better

reading this way,lol ) using the lib that I wrote (using polyhedron
entirely).

I didn't know the current Openscad can do this: yourcube = rotate(45)
mycube

Learned lots of things reading forum :) :)

$ Runsun Pan, PhD

$ -- OpenScad_DocTest ( Thingiverse ), faces , Offliner

$ -- hash parameter model: here , here

$ -- Linux Mint 17.1 Rebecca x64 + OpenSCAD

2015.03.15/2015.04.01.nightly

--
View this message in context:

http://forum.openscad.org/OpenSCAD2-design-docs-tp13019p13240.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 have very little time to spare for this right now. I hope to have time to start writing code in August or September. At the moment, I've got a first draft of parser.y, and I've planned out some algorithms and data structures, but that's it. I was hoping to get more feedback from Marius, but he's gone off and started a new company, so he's busy. There is no "release schedule", but the general plan is: * get feedback from the community, update the design based on feedback * carve up the design into smaller pieces that can be implemented independently, or in phases * recruit people to write code for the various pieces * start coding Doug Moen On 18 July 2015 at 20:49, Jean-Paul Louis <louijp@yahoo.com> wrote: > What is the release schedule for OpenSCAD2? It seems to have features that > I really need. > > Just curious, > Jean-Paul > AC9GH > > > > On Jul 18, 2015, at 5:52 PM, doug moen <doug@moens.org> wrote: > > > > > 2) I didn't know the current Openscad can do this: > > > yourcube = rotate(45) mycube; > > > > Sorry, no, I meant that the OpenSCAD2 design document adds this as new > syntax. > > > > On 18 July 2015 at 17:29, runsun <runsun@gmail.com> wrote: > > Thx for the explanation, Doug. Guess we'll have to wait longer. > > > > 1) That seems to be what happens (i.e., F6 is as quick as F5 <== feel > better > > reading this way,lol ) using the lib that I wrote (using polyhedron > > entirely). > > > > 2) I didn't know the current Openscad can do this: yourcube = rotate(45) > > mycube > > > > Learned lots of things reading forum :) :) > > > > > > > > > > > > ----- > > > > $ Runsun Pan, PhD > > > > $ -- OpenScad_DocTest ( Thingiverse ), faces , Offliner > > > > $ -- hash parameter model: here , here > > > > $ -- Linux Mint 17.1 Rebecca x64 + OpenSCAD > 2015.03.15/2015.04.01.nightly > > > > > > > > > > -- > > View this message in context: > http://forum.openscad.org/OpenSCAD2-design-docs-tp13019p13240.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 > > > > > > _______________________________________________ > > OpenSCAD mailing list > > 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 > >

MK

Marius Kintel

Tue, Sep 1, 2015 7:05 PM

Hi Doug,

I was out traveling for a long while, but back again now.
Catching up on OpenSCAD issues, but hopefully able to contribute to this again soon.
Drop me a note if there are anything in particular you’re looking for now, or if I should just start reviewing it top-down.

-Marius

On Jul 20, 2015, at 10:07 AM, doug moen doug@moens.org wrote:

I have very little time to spare for this right now. I hope to have time to start writing code in August or September.

At the moment, I've got a first draft of parser.y, and I've planned out some algorithms and data structures, but that's it.

I was hoping to get more feedback from Marius, but he's gone off and started a new company, so he's busy.

There is no "release schedule", but the general plan is:

get feedback from the community, update the design based on feedback
carve up the design into smaller pieces that can be implemented independently, or in phases
recruit people to write code for the various pieces
start coding

Doug Moen

Hi Doug, I was out traveling for a long while, but back again now. Catching up on OpenSCAD issues, but hopefully able to contribute to this again soon. Drop me a note if there are anything in particular you’re looking for now, or if I should just start reviewing it top-down. -Marius On Jul 20, 2015, at 10:07 AM, doug moen <doug@moens.org> wrote: > I have very little time to spare for this right now. I hope to have time to start writing code in August or September. > > At the moment, I've got a first draft of parser.y, and I've planned out some algorithms and data structures, but that's it. > > I was hoping to get more feedback from Marius, but he's gone off and started a new company, so he's busy. > > There is no "release schedule", but the general plan is: > * get feedback from the community, update the design based on feedback > * carve up the design into smaller pieces that can be implemented independently, or in phases > * recruit people to write code for the various pieces > * start coding > > Doug Moen

DM

doug moen

Tue, Sep 1, 2015 7:57 PM

I haven't touched this since July 9; I had started to make some changes to
fix design flaws in the scoping rules, but ran out of steam before I
finished incorporating that change and cleaning up the document. The worst
problem is that I started writing a new RFC called "Scoping Rules for
Scripts" but ran out of energy before I finished it. The missing text is
where I prove that the design is sound.

However, this is a small problem, relatively speaking. You are welcome to
read the document and provide feedback. I did get feedback from 2 other
people who read the whole thing (in a previous version), but none of that
feedback was transformative, in the sense of pointing out real problems, or
pointing out fundamentally better approaches. The only good transformative
feedback I've ever received was from you. So I'm interested in hearing what
you have to say.

Right now I'm working through some medical issues, and don't have a lot of
energy: mostly the problem is that my arm hurts, so I can't do large
amounts of typing right now. But I can still read, think and answer
questions.

On 1 September 2015 at 15:05, Marius Kintel marius@kintel.net wrote:

Hi Doug,

I was out traveling for a long while, but back again now.
Catching up on OpenSCAD issues, but hopefully able to contribute to this
again soon.
Drop me a note if there are anything in particular you’re looking for now,
or if I should just start reviewing it top-down.

-Marius

On Jul 20, 2015, at 10:07 AM, doug moen doug@moens.org wrote:

I have very little time to spare for this right now. I hope to have time

to start writing code in August or September.

At the moment, I've got a first draft of parser.y, and I've planned out

some algorithms and data structures, but that's it.

I was hoping to get more feedback from Marius, but he's gone off and

started a new company, so he's busy.

There is no "release schedule", but the general plan is:

get feedback from the community, update the design based on feedback
carve up the design into smaller pieces that can be implemented

independently, or in phases

recruit people to write code for the various pieces
start coding

Doug Moen

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

I haven't touched this since July 9; I had started to make some changes to fix design flaws in the scoping rules, but ran out of steam before I finished incorporating that change and cleaning up the document. The worst problem is that I started writing a new RFC called "Scoping Rules for Scripts" but ran out of energy before I finished it. The missing text is where I prove that the design is sound. However, this is a small problem, relatively speaking. You are welcome to read the document and provide feedback. I did get feedback from 2 other people who read the whole thing (in a previous version), but none of that feedback was transformative, in the sense of pointing out real problems, or pointing out fundamentally better approaches. The only good transformative feedback I've ever received was from you. So I'm interested in hearing what you have to say. Right now I'm working through some medical issues, and don't have a lot of energy: mostly the problem is that my arm hurts, so I can't do large amounts of typing right now. But I can still read, think and answer questions. On 1 September 2015 at 15:05, Marius Kintel <marius@kintel.net> wrote: > Hi Doug, > > I was out traveling for a long while, but back again now. > Catching up on OpenSCAD issues, but hopefully able to contribute to this > again soon. > Drop me a note if there are anything in particular you’re looking for now, > or if I should just start reviewing it top-down. > > -Marius > > On Jul 20, 2015, at 10:07 AM, doug moen <doug@moens.org> wrote: > > > I have very little time to spare for this right now. I hope to have time > to start writing code in August or September. > > > > At the moment, I've got a first draft of parser.y, and I've planned out > some algorithms and data structures, but that's it. > > > > I was hoping to get more feedback from Marius, but he's gone off and > started a new company, so he's busy. > > > > There is no "release schedule", but the general plan is: > > * get feedback from the community, update the design based on feedback > > * carve up the design into smaller pieces that can be implemented > independently, or in phases > > * recruit people to write code for the various pieces > > * start coding > > > > Doug Moen > > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > > >

discuss@lists.openscad.org

OpenSCAD2 design docs

The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/

The TPP is no simple “trade agreement.” Fight it!
http://www.ourfairdeal.org/

The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/