PPA for OpenSCAD 2021

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

PPA for OpenSCAD 2021

julianstirling
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 the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: PPA for OpenSCAD 2021

Chow 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
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: PPA for OpenSCAD 2021

julianstirling
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 the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
tp3
Reply | Threaded
Open this post in threaded view
|

Re: PPA for OpenSCAD 2021

tp3
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.
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: PPA for OpenSCAD 2021

julianstirling
I need to work out exactly what failed. I'll let you know.

Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: PPA for OpenSCAD 2021

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];
 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 at Nabble.com.

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: PPA for OpenSCAD 2021

Ronaldo
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]> 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 at Nabble.com.
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: PPA for OpenSCAD 2021

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];
 echo(a);


Em dom., 25 de abr. de 2021 às 12:50, julianstirling <
[hidden email]> 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]
>

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]


Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: PPA for OpenSCAD 2021

nophead
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 <[hidden email]> 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]> 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]
>

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]


Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: PPA for OpenSCAD 2021

adrianv
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 <[hidden email]> 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 [hidden email]
>

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]


Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: PPA for OpenSCAD 2021

nophead
The only mutable variables in OpenSCAD are the C style loop variables, so if you want to iterate over an array and accumulate the result you can't do it with the classic OpenSCAD loop. You can do it with the C style loop but making operations on undef a warning has pretty much broken that as you have to add an ugly guard condition that is pointless. There is no problem with the final value becoming undefined because it is never used. I only want to be told a value is undef when I try and use it for something that needs a definite value, such as cube().

I agree recursion is much cleaner.

On Sun, 25 Apr 2021 at 18:45, adrianv <[hidden email]> wrote:
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 <[hidden email]> 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 [hidden email]
>

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]


Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
tp3
Reply | Threaded
Open this post in threaded view
|

Re: PPA for OpenSCAD 2021

tp3
In reply to this post by julianstirling
On 25.04.21 13:50, julianstirling wrote:
> 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.

No, as Ronaldo already mentioned, it's more an issue with the
implementation of the c-style loop. As the discussion in the
linked issue indicates it might be possible to fix without
bad side effect, specifically as this extra evaluation is not
supposed to have meaningful side effects (it could have an
echo() embedded, but skipping that seems ok too).

As you have a bigger project with a nice CI setup, it would be
great to set that up as reference for the nightly builds of
OpenSCAD. There's a couple of sorely needed but still slightly
tricky changes in progress that will help fixing some of the
strange corner cases of OpenSCAD. Having a couple of reference
projects could help catching potential issues in a more
automated way early and not only after a full release.

Do you think that makes sense? I would not ask much of your time,
maybe just a question here and there when setting things up.
I'm not sure when I'll have the time to get that going, but I
believe it might be quite useful.

ciao,
  Torsten.
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
-- Torsten