J
julianstirling
Thu, Apr 1, 2021 5:40 PM
Do you know when the OpenSCAD PPA will be updated with OpenSCAD 2021? We
generally do a lot of testing and rendering on our CI which instals from the
PPA. Would be great to think about moving.
Julian
--
Sent from: http://forum.openscad.org/
Do you know when the OpenSCAD PPA will be updated with OpenSCAD 2021? We
generally do a lot of testing and rendering on our CI which instals from the
PPA. Would be great to think about moving.
Julian
--
Sent from: http://forum.openscad.org/
CL
Chow Loong Jin
Fri, Apr 2, 2021 4:36 AM
On Thu, Apr 01, 2021 at 10:40:36AM -0700, julianstirling wrote:
Do you know when the OpenSCAD PPA will be updated with OpenSCAD 2021? We
generally do a lot of testing and rendering on our CI which instals from the
PPA. Would be great to think about moving.
Whoops, this slipped my notice entirely, sorry. Working on it now.
--
Kind regards,
Loong Jin
On Thu, Apr 01, 2021 at 10:40:36AM -0700, julianstirling wrote:
> Do you know when the OpenSCAD PPA will be updated with OpenSCAD 2021? We
> generally do a lot of testing and rendering on our CI which instals from the
> PPA. Would be great to think about moving.
Whoops, this slipped my notice entirely, sorry. Working on it now.
--
Kind regards,
Loong Jin
J
julianstirling
Fri, Apr 2, 2021 6:13 PM
Fantastic!! It is all online and broke my CI pipeline . Careful what you wish
for . I now need to fix my OpenSCAD unit tests.
--
Sent from: http://forum.openscad.org/
Fantastic!! It is all online and broke my CI pipeline . Careful what you wish
for . I now need to fix my OpenSCAD unit tests.
--
Sent from: http://forum.openscad.org/
TP
Torsten Paul
Fri, Apr 2, 2021 7:34 PM
On 02.04.21 20:13, julianstirling wrote:
I now need to fix my OpenSCAD unit tests.
What fixes are needed? Is there anything that could go on a
checklist of things that should not change across releases?
ciao,
Torsten.
On 02.04.21 20:13, julianstirling wrote:
> I now need to fix my OpenSCAD unit tests.
What fixes are needed? Is there anything that could go on a
checklist of things that should not change across releases?
ciao,
Torsten.
J
julianstirling
Fri, Apr 2, 2021 8:39 PM
I need to work out exactly what failed. I'll let you know.
--
Sent from: http://forum.openscad.org/
I need to work out exactly what failed. I'll let you know.
--
Sent from: http://forum.openscad.org/
J
julianstirling
Sun, Apr 25, 2021 11:50 AM
Hi @tp3, we now know what happened in our unit tests so I thought I would
report back.
We have our own OpenSCAD dictionary library inside the OpenFlexure
Micrsocope project, and we test it really carefully because I am worried
about edge cases causing things to fail. We also always have hardwarnings
on, so it must run without warnings.
We use the C-style for loop list comprehensions quite a bit, iterating more
than one value in the last section. An dummy example of some code that
generates the warnings we were getting is:
Here on the last iteration i becomes equal to b, so the loop will exit. But
the next value of j is calculated before the loop exits. This means that
OpenSCAD 2021 throws a the warning:
We have just adjusted our library so we no longer set off this warning. Our
resulting code is actually nicer.
I am not sure if I would class this as unexpected behaviour from OpenSCAD.
Warning about undef in arithmetic is so important, but then it does make it
slightly harder to iterate over all values in an array. But perhaps there is
a nicer way that I am missing.
--
Sent from: http://forum.openscad.org/
Hi @tp3, we now know what happened in our unit tests so I thought I would
report back.
We have our own OpenSCAD dictionary library inside the OpenFlexure
Micrsocope project, and we test it really carefully because I am worried
about edge cases causing things to fail. We also always have hardwarnings
on, so it must run without warnings.
We use the C-style for loop list comprehensions quite a bit, iterating more
than one value in the last section. An dummy example of some code that
generates the warnings we were getting is:
Here on the last iteration i becomes equal to b, so the loop will exit. But
the next value of j is calculated before the loop exits. This means that
OpenSCAD 2021 throws a the warning:
We have just adjusted our library so we no longer set off this warning. Our
resulting code is actually nicer.
I am not sure if I would class this as unexpected behaviour from OpenSCAD.
Warning about undef in arithmetic is so important, but then it does make it
slightly harder to iterate over all values in an array. But perhaps there is
a nicer way that I am missing.
--
Sent from: http://forum.openscad.org/
RP
Ronaldo Persiano
Sun, Apr 25, 2021 4:48 PM
That is a well-known design issue of the C-like for. The last iteration is
useless. See: https://github.com/openscad/openscad/issues/3227
The only way I know to handle the issue is to protect the expressions in
the loop avoiding illegal operations in the last iteration.
b= [1,2,3];
a = [for (i=-1, j=0; i<len(b); i=i+1, j= (i==len(b)) ? j : j+b[i]) j];
echo(a);
Em dom., 25 de abr. de 2021 às 12:50, julianstirling <
julian@julianstirling.co.uk> escreveu:
Hi @tp3, we now know what happened in our unit tests so I thought I would
report back.
We have our own OpenSCAD dictionary library inside the OpenFlexure
Micrsocope project, and we test it really carefully because I am worried
about edge cases causing things to fail. We also always have hardwarnings
on, so it must run without warnings.
We use the C-style for loop list comprehensions quite a bit, iterating
more than one value in the last section. An dummy example of some code that
generates the warnings we were getting is:
b= [1,2,3];
a = [for (i=-1, j=0; i<len(b); i=i+1, j=j+b[i]) j];
echo(a);
Here on the last iteration i becomes equal to b, so the loop will exit.
But the next value of j is calculated before the loop exits. This means
that OpenSCAD 2021 throws a the warning:
WARNING: undefined operation (number + undefined)
We have just adjusted our library so we no longer set off this warning.
Our resulting code is actually nicer.
I am not sure if I would class this as unexpected behaviour from OpenSCAD.
Warning about undef in arithmetic is so important, but then it does make it
slightly harder to iterate over all values in an array. But perhaps there
is a nicer way that I am missing.
Sent from the OpenSCAD mailing list archive http://forum.openscad.org/
at Nabble.com.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
That is a well-known design issue of the C-like for. The last iteration is
useless. See: https://github.com/openscad/openscad/issues/3227
The only way I know to handle the issue is to protect the expressions in
the loop avoiding illegal operations in the last iteration.
b= [1,2,3];
a = [for (i=-1, j=0; i<len(b); i=i+1, j= (i==len(b)) ? j : j+b[i]) j];
echo(a);
Em dom., 25 de abr. de 2021 às 12:50, julianstirling <
julian@julianstirling.co.uk> escreveu:
> Hi @tp3, we now know what happened in our unit tests so I thought I would
> report back.
>
> We have our own OpenSCAD dictionary library inside the OpenFlexure
> Micrsocope project, and we test it really carefully because I am worried
> about edge cases causing things to fail. We also always have hardwarnings
> on, so it must run without warnings.
>
> We use the C-style for loop list comprehensions quite a bit, iterating
> more than one value in the last section. An dummy example of some code that
> generates the warnings we were getting is:
>
> b= [1,2,3];
> a = [for (i=-1, j=0; i<len(b); i=i+1, j=j+b[i]) j];
> echo(a);
>
>
> Here on the last iteration i becomes equal to b, so the loop will exit.
> But the next value of j is calculated before the loop exits. This means
> that OpenSCAD 2021 throws a the warning:
>
> WARNING: undefined operation (number + undefined)
>
>
> We have just adjusted our library so we no longer set off this warning.
> Our resulting code is actually nicer.
>
> I am not sure if I would class this as unexpected behaviour from OpenSCAD.
> Warning about undef in arithmetic is so important, but then it does make it
> slightly harder to iterate over all values in an array. But perhaps there
> is a nicer way that I am missing.
> ------------------------------
> Sent from the OpenSCAD mailing list archive <http://forum.openscad.org/>
> at Nabble.com.
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
A
adrianv
Sun, Apr 25, 2021 5:09 PM
I did some timing tests with C-like for vs recursion and found that actually
C-like for was slower. I don't know how broadly applicable those test
results were, but it seems like in many cases (most cases?) it's better to
just use recursion.
I do not understand how undef in arithmetic makes it "slightly harder to
iterate over all values in an array". I don't even see any connection
between these things. To iterate over all values in an array you do
for(entry=array) ....
Ronaldo wrote
That is a well-known design issue of the C-like for. The last iteration is
useless. See: https://github.com/openscad/openscad/issues/3227
The only way I know to handle the issue is to protect the expressions in
the loop avoiding illegal operations in the last iteration.
b= [1,2,3];
a = [for (i=-1, j=0; i<len(b); i=i+1, j= (i==len(b)) ? j : j+b[i]) j];
echo(a);
Em dom., 25 de abr. de 2021 às 12:50, julianstirling <
Hi @tp3, we now know what happened in our unit tests so I thought I would
report back.
We have our own OpenSCAD dictionary library inside the OpenFlexure
Micrsocope project, and we test it really carefully because I am worried
about edge cases causing things to fail. We also always have hardwarnings
on, so it must run without warnings.
We use the C-style for loop list comprehensions quite a bit, iterating
more than one value in the last section. An dummy example of some code
that
generates the warnings we were getting is:
b= [1,2,3];
a = [for (i=-1, j=0; i<len(b); i=i+1, j=j+b[i]) j];
Here on the last iteration i becomes equal to b, so the loop will exit.
But the next value of j is calculated before the loop exits. This means
that OpenSCAD 2021 throws a the warning:
WARNING: undefined operation (number + undefined)
We have just adjusted our library so we no longer set off this warning.
Our resulting code is actually nicer.
I am not sure if I would class this as unexpected behaviour from
OpenSCAD.
Warning about undef in arithmetic is so important, but then it does make
it
slightly harder to iterate over all values in an array. But perhaps there
is a nicer way that I am missing.
Sent from the OpenSCAD mailing list archive
<http://forum.openscad.org/>
at Nabble.com.
OpenSCAD mailing list
To unsubscribe send an email to
OpenSCAD mailing list
To unsubscribe send an email to
I did some timing tests with C-like for vs recursion and found that actually
C-like for was slower. I don't know how broadly applicable those test
results were, but it seems like in many cases (most cases?) it's better to
just use recursion.
I do not understand how undef in arithmetic makes it "slightly harder to
iterate over all values in an array". I don't even see any connection
between these things. To iterate over all values in an array you do
for(entry=array) ....
Ronaldo wrote
> That is a well-known design issue of the C-like for. The last iteration is
> useless. See: https://github.com/openscad/openscad/issues/3227
> The only way I know to handle the issue is to protect the expressions in
> the loop avoiding illegal operations in the last iteration.
>
> b= [1,2,3];
> a = [for (i=-1, j=0; i<len(b); i=i+1, j= (i==len(b)) ? j : j+b[i]) j];
> echo(a);
>
>
> Em dom., 25 de abr. de 2021 às 12:50, julianstirling <
> julian@.co
> > escreveu:
>
>> Hi @tp3, we now know what happened in our unit tests so I thought I would
>> report back.
>>
>> We have our own OpenSCAD dictionary library inside the OpenFlexure
>> Micrsocope project, and we test it really carefully because I am worried
>> about edge cases causing things to fail. We also always have hardwarnings
>> on, so it must run without warnings.
>>
>> We use the C-style for loop list comprehensions quite a bit, iterating
>> more than one value in the last section. An dummy example of some code
>> that
>> generates the warnings we were getting is:
>>
>> b= [1,2,3];
>> a = [for (i=-1, j=0; i<len(b); i=i+1, j=j+b[i]) j];
> > echo(a);
>>
>>
>> Here on the last iteration i becomes equal to b, so the loop will exit.
>> But the next value of j is calculated before the loop exits. This means
>> that OpenSCAD 2021 throws a the warning:
>>
>> WARNING: undefined operation (number + undefined)
>>
>>
>> We have just adjusted our library so we no longer set off this warning.
>> Our resulting code is actually nicer.
>>
>> I am not sure if I would class this as unexpected behaviour from
>> OpenSCAD.
>> Warning about undef in arithmetic is so important, but then it does make
>> it
>> slightly harder to iterate over all values in an array. But perhaps there
>> is a nicer way that I am missing.
>> ------------------------------
>> Sent from the OpenSCAD mailing list archive
>> <http://forum.openscad.org/>
>> at Nabble.com.
>> _______________________________________________
>> OpenSCAD mailing list
>> To unsubscribe send an email to
> discuss-leave@.openscad
>>
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to
> discuss-leave@.openscad
--
Sent from: http://forum.openscad.org/
NH
nop head
Sun, Apr 25, 2021 5:15 PM
You need to use the C style loop to be able to accumulate j in the loop. Or
use recursion.
On Sun, 25 Apr 2021 at 18:10, adrianv avm4@cornell.edu wrote:
I did some timing tests with C-like for vs recursion and found that
actually C-like for was slower. I don't know how broadly applicable those
test results were, but it seems like in many cases (most cases?) it's
better to just use recursion.
I do not understand how undef in arithmetic makes it "slightly harder to
iterate over all values in an array". I don't even see any connection
between these things. To iterate over all values in an array you do
for(entry=array) ....
Ronaldo wrote
That is a well-known design issue of the C-like for. The last iteration is
useless. See: https://github.com/openscad/openscad/issues/3227
The only way I know to handle the issue is to protect the expressions in
the loop avoiding illegal operations in the last iteration.
b= [1,2,3];
a = [for (i=-1, j=0; i<len(b); i=i+1, j= (i==len(b)) ? j : j+b[i]) j];
echo(a);
Em dom., 25 de abr. de 2021 às 12:50, julianstirling <
[hidden email] http:///user/SendEmail.jtp?type=email&email=julian%40.co>
escreveu:
Hi @tp3, we now know what happened in our unit tests so I thought I
report back.
We have our own OpenSCAD dictionary library inside the OpenFlexure
Micrsocope project, and we test it really carefully because I am worried
about edge cases causing things to fail. We also always have
on, so it must run without warnings.
We use the C-style for loop list comprehensions quite a bit, iterating
more than one value in the last section. An dummy example of some code
generates the warnings we were getting is:
b= [1,2,3];
a = [for (i=-1, j=0; i<len(b); i=i+1, j=j+b[i]) j];
echo(a);
Here on the last iteration i becomes equal to b, so the loop will exit.
But the next value of j is calculated before the loop exits. This means
that OpenSCAD 2021 throws a the warning:
WARNING: undefined operation (number + undefined)
We have just adjusted our library so we no longer set off this warning.
Our resulting code is actually nicer.
I am not sure if I would class this as unexpected behaviour from
Warning about undef in arithmetic is so important, but then it does make
slightly harder to iterate over all values in an array. But perhaps
is a nicer way that I am missing.
Sent from the OpenSCAD mailing list archive http://forum.openscad.org/
at Nabble.com.
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
You need to use the C style loop to be able to accumulate j in the loop. Or
use recursion.
On Sun, 25 Apr 2021 at 18:10, adrianv <avm4@cornell.edu> wrote:
> I did some timing tests with C-like for vs recursion and found that
> actually C-like for was slower. I don't know how broadly applicable those
> test results were, but it seems like in many cases (most cases?) it's
> better to just use recursion.
>
> I do not understand how undef in arithmetic makes it "slightly harder to
> iterate over all values in an array". I don't even see any connection
> between these things. To iterate over all values in an array you do
>
> for(entry=array) ....
>
> Ronaldo wrote
> That is a well-known design issue of the C-like for. The last iteration is
> useless. See: https://github.com/openscad/openscad/issues/3227
> The only way I know to handle the issue is to protect the expressions in
> the loop avoiding illegal operations in the last iteration.
>
> b= [1,2,3];
> a = [for (i=-1, j=0; i<len(b); i=i+1, j= (i==len(b)) ? j : j+b[i]) j];
> echo(a);
>
>
> Em dom., 25 de abr. de 2021 às 12:50, julianstirling <
> [hidden email] <http:///user/SendEmail.jtp?type=email&email=julian%40.co>>
> escreveu:
>
> > Hi @tp3, we now know what happened in our unit tests so I thought I
> would
> > report back.
> >
> > We have our own OpenSCAD dictionary library inside the OpenFlexure
> > Micrsocope project, and we test it really carefully because I am worried
> > about edge cases causing things to fail. We also always have
> hardwarnings
> > on, so it must run without warnings.
> >
> > We use the C-style for loop list comprehensions quite a bit, iterating
> > more than one value in the last section. An dummy example of some code
> that
> > generates the warnings we were getting is:
> >
> > b= [1,2,3];
> > a = [for (i=-1, j=0; i<len(b); i=i+1, j=j+b[i]) j];
> > echo(a);
> >
> >
> > Here on the last iteration i becomes equal to b, so the loop will exit.
> > But the next value of j is calculated before the loop exits. This means
> > that OpenSCAD 2021 throws a the warning:
> >
> > WARNING: undefined operation (number + undefined)
> >
> >
> > We have just adjusted our library so we no longer set off this warning.
> > Our resulting code is actually nicer.
> >
> > I am not sure if I would class this as unexpected behaviour from
> OpenSCAD.
> > Warning about undef in arithmetic is so important, but then it does make
> it
> > slightly harder to iterate over all values in an array. But perhaps
> there
> > is a nicer way that I am missing.
> > ------------------------------
> > Sent from the OpenSCAD mailing list archive <http://forum.openscad.org/>
> > at Nabble.com.
> > _______________________________________________
> > OpenSCAD mailing list
> > To unsubscribe send an email to [hidden email]
> <http:///user/SendEmail.jtp?type=email&email=discuss-leave%40.openscad>
> >
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to [hidden email]
> <http:///user/SendEmail.jtp?type=email&email=discuss-leave%40.openscad>
>
>
> ------------------------------
> Sent from the OpenSCAD mailing list archive <http://forum.openscad.org/>
> at Nabble.com.
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
A
adrianv
Sun, Apr 25, 2021 5:45 PM
Are you saying that has something to do with iterating over all the elements
in an array?
The problem with the orphan iteration in for loops is almost always a
problem that requires some special handling, whether or not undef is silent
in arithmetic. The problem is the stupid behavior of c-style for, not
undefs. And in my experience the code is harder to read for c-style for
than for recursion. I think the quoted example, a vector sum code, is
harder to read than a basic recursive version. And also, vector sum can be
done non-recursively by vector multiplication: b * [for(x=b) 1]
nophead wrote
You need to use the C style loop to be able to accumulate j in the loop.
Or
use recursion.
On Sun, 25 Apr 2021 at 18:10, adrianv <
I did some timing tests with C-like for vs recursion and found that
actually C-like for was slower. I don't know how broadly applicable
those
test results were, but it seems like in many cases (most cases?) it's
better to just use recursion.
I do not understand how undef in arithmetic makes it "slightly harder to
iterate over all values in an array". I don't even see any connection
between these things. To iterate over all values in an array you do
for(entry=array) ....
Ronaldo wrote
That is a well-known design issue of the C-like for. The last iteration
is
useless. See: https://github.com/openscad/openscad/issues/3227
The only way I know to handle the issue is to protect the expressions in
the loop avoiding illegal operations in the last iteration.
b= [1,2,3];
a = [for (i=-1, j=0; i<len(b); i=i+1, j= (i==len(b)) ? j : j+b[i])
j];
Em dom., 25 de abr. de 2021 às 12:50, julianstirling <
[hidden email]
<http:///user/SendEmail.jtp?type=email&email=julian%40.co>>
escreveu:
Hi @tp3, we now know what happened in our unit tests so I thought I
report back.
We have our own OpenSCAD dictionary library inside the OpenFlexure
Micrsocope project, and we test it really carefully because I am
about edge cases causing things to fail. We also always have
on, so it must run without warnings.
We use the C-style for loop list comprehensions quite a bit, iterating
more than one value in the last section. An dummy example of some code
generates the warnings we were getting is:
b= [1,2,3];
a = [for (i=-1, j=0; i<len(b); i=i+1, j=j+b[i]) j];
Here on the last iteration i becomes equal to b, so the loop will exit.
But the next value of j is calculated before the loop exits. This means
that OpenSCAD 2021 throws a the warning:
WARNING: undefined operation (number + undefined)
We have just adjusted our library so we no longer set off this warning.
Our resulting code is actually nicer.
I am not sure if I would class this as unexpected behaviour from
Warning about undef in arithmetic is so important, but then it does
slightly harder to iterate over all values in an array. But perhaps
is a nicer way that I am missing.
Sent from the OpenSCAD mailing list archive
<http://forum.openscad.org/>
at Nabble.com.
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
<http:///user/SendEmail.jtp?type=email&email=discuss-leave%40.openscad>
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
<http:///user/SendEmail.jtp?type=email&email=discuss-leave%40.openscad>
Sent from the OpenSCAD mailing list archive
<http://forum.openscad.org/>
at Nabble.com.
OpenSCAD mailing list
To unsubscribe send an email to
OpenSCAD mailing list
To unsubscribe send an email to
Are you saying that has something to do with iterating over all the elements
in an array?
The problem with the orphan iteration in for loops is almost always a
problem that requires some special handling, whether or not undef is silent
in arithmetic. The problem is the stupid behavior of c-style for, not
undefs. And in my experience the code is harder to read for c-style for
than for recursion. I think the quoted example, a vector sum code, is
harder to read than a basic recursive version. And also, vector sum can be
done non-recursively by vector multiplication: b * [for(x=b) 1]
nophead wrote
> You need to use the C style loop to be able to accumulate j in the loop.
> Or
> use recursion.
>
> On Sun, 25 Apr 2021 at 18:10, adrianv <
> avm4@
> > wrote:
>
>> I did some timing tests with C-like for vs recursion and found that
>> actually C-like for was slower. I don't know how broadly applicable
>> those
>> test results were, but it seems like in many cases (most cases?) it's
>> better to just use recursion.
>>
>> I do not understand how undef in arithmetic makes it "slightly harder to
>> iterate over all values in an array". I don't even see any connection
>> between these things. To iterate over all values in an array you do
>>
>> for(entry=array) ....
>>
>> Ronaldo wrote
>> That is a well-known design issue of the C-like for. The last iteration
>> is
>> useless. See: https://github.com/openscad/openscad/issues/3227
>> The only way I know to handle the issue is to protect the expressions in
>> the loop avoiding illegal operations in the last iteration.
>>
>> b= [1,2,3];
>> a = [for (i=-1, j=0; i<len(b); i=i+1, j= (i==len(b)) ? j : j+b[i])
>> j];
> > echo(a);
>>
>>
>> Em dom., 25 de abr. de 2021 às 12:50, julianstirling <
>> [hidden email]
>> <http:///user/SendEmail.jtp?type=email&email=julian%40.co>>
>> escreveu:
>>
>> > Hi @tp3, we now know what happened in our unit tests so I thought I
>> would
>> > report back.
>> >
>> > We have our own OpenSCAD dictionary library inside the OpenFlexure
>> > Micrsocope project, and we test it really carefully because I am
>> worried
>> > about edge cases causing things to fail. We also always have
>> hardwarnings
>> > on, so it must run without warnings.
>> >
>> > We use the C-style for loop list comprehensions quite a bit, iterating
>> > more than one value in the last section. An dummy example of some code
>> that
>> > generates the warnings we were getting is:
>> >
>> > b= [1,2,3];
>> > a = [for (i=-1, j=0; i<len(b); i=i+1, j=j+b[i]) j];
> > > echo(a);
>> >
>> >
>> > Here on the last iteration i becomes equal to b, so the loop will exit.
>> > But the next value of j is calculated before the loop exits. This means
>> > that OpenSCAD 2021 throws a the warning:
>> >
>> > WARNING: undefined operation (number + undefined)
>> >
>> >
>> > We have just adjusted our library so we no longer set off this warning.
>> > Our resulting code is actually nicer.
>> >
>> > I am not sure if I would class this as unexpected behaviour from
>> OpenSCAD.
>> > Warning about undef in arithmetic is so important, but then it does
>> make
>> it
>> > slightly harder to iterate over all values in an array. But perhaps
>> there
>> > is a nicer way that I am missing.
>> > ------------------------------
>> > Sent from the OpenSCAD mailing list archive
>> <http://forum.openscad.org/>
>> > at Nabble.com.
>> > _______________________________________________
>> > OpenSCAD mailing list
>> > To unsubscribe send an email to [hidden email]
>> <http:///user/SendEmail.jtp?type=email&email=discuss-leave%40.openscad>
>> >
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> To unsubscribe send an email to [hidden email]
>> <http:///user/SendEmail.jtp?type=email&email=discuss-leave%40.openscad>
>>
>>
>> ------------------------------
>> Sent from the OpenSCAD mailing list archive
>> <http://forum.openscad.org/>
>> at Nabble.com.
>> _______________________________________________
>> OpenSCAD mailing list
>> To unsubscribe send an email to
> discuss-leave@.openscad
>>
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to
> discuss-leave@.openscad
--
Sent from: http://forum.openscad.org/