Getting more information

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

Getting more information

DanS
I'm still trying to debug my own code but am frustrated in that I can't see where the problem exists.  I get some errors and other messages from OpenScad but unfortunately they don't point to what it was in my code that triggered it:

ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion violation! Expr: e_below != SHalfedge_handle() File: /opt/mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_3/SNC_FM_decorator.h Line: 426


Likewise, I sometimes get this warning:


DEPRECATED: Using ranges of the form [begin:end] with begin value greater than the end value is deprecated.


But I can't see any loop where the starting value is bigger than the end value.


Is there a way that I can get OpenSCAD to indicate where in my code is triggering these problems?

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

adrianv
DanS wrote

> I'm still trying to debug my own code but am frustrated in that I can't
> see
> where the problem exists.  I get some errors and other messages from
> OpenScad but unfortunately they don't point to what it was in my code that
> triggered it:
>
> ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion
> violation! Expr: e_below != SHalfedge_handle() File:
> /opt/mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_3/SNC_FM_decorator.h
> Line: 426

I don't recognize this error specifically, but typically if you get errors
relating to polyhedra it means you have constructed an invalid polyhedron
with the polyhedron module.  You can select View->Thrown Together in preview
which will show reversed faces.  But otherwise you just have to work through
your construction.  


> Likewise, I sometimes get this warning:
>
>
> DEPRECATED: Using ranges of the form [begin:end] with begin value greater
> than the end value is deprecated.

Yeah, this one is extremely annoying.  There appears to be no way to get
OpenSCAD to give you more information about this.  It can be anywhere in
your code, or anything that you include.  It could be a degenerate case, in
which case you can solve the problem by replacing every occurrence of [a:b]
in your code with [a:1:b].  But if it's a mistake in your code, that will
just cause the loop to not run---it won't tell you where the problem is.  




--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

DanS
Thanks for the tips!

I'm not sure I understand "It could be a degenerate case, in which case you can solve the problem by replacing every occurrence of [a:b] in your code with [a:1:b]"

I thought the way loops worked in openscad was [start:increment:end] or if two arguments were used they were assumed to be only start and end and increment was assumed to be 1.
I will try your suggestion but don't understand why it would sometimes be a problem and sometimes not.  I'd like to understand it since it would give me a better picture how to use OpenSCAD.  When you say "degenerate" do you mean in the case start = end; or do you mean the interpreter sometimes screws up and interprets two arguments as [start:increment] and gives end some weird garbage value?

On Thu, Jul 4, 2019 at 11:03 AM adrianv <[hidden email]> wrote:
DanS wrote
> I'm still trying to debug my own code but am frustrated in that I can't
> see
> where the problem exists.  I get some errors and other messages from
> OpenScad but unfortunately they don't point to what it was in my code that
> triggered it:
>
> ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion
> violation! Expr: e_below != SHalfedge_handle() File:
> /opt/mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_3/SNC_FM_decorator.h
> Line: 426

I don't recognize this error specifically, but typically if you get errors
relating to polyhedra it means you have constructed an invalid polyhedron
with the polyhedron module.  You can select View->Thrown Together in preview
which will show reversed faces.  But otherwise you just have to work through
your construction. 


> Likewise, I sometimes get this warning:
>
>
> DEPRECATED: Using ranges of the form [begin:end] with begin value greater
> than the end value is deprecated.

Yeah, this one is extremely annoying.  There appears to be no way to get
OpenSCAD to give you more information about this.  It can be anywhere in
your code, or anything that you include.  It could be a degenerate case, in
which case you can solve the problem by replacing every occurrence of [a:b]
in your code with [a:1:b].  But if it's a mistake in your code, that will
just cause the loop to not run---it won't tell you where the problem is. 




--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

DanS
In reply to this post by adrianv
I'm not sure how to use View->Thrown Together properly

If I do render.  I see this:

image.png

If right after that I go into View and select Thrown Together  I don't see anything in the console that indicates work is being done, my object entirely disappears.  I was expecting that if it will take some time it might indicate it is calculating.  Likewise, I thought the end result would be the same drawing but with some facets in a different color (indicating maybe missing / degenerate vertices caused things to be inside out).  What is the proper way to use View -> Throw Together

On Thu, Jul 4, 2019 at 11:03 AM adrianv <[hidden email]> wrote:
DanS wrote
> I'm still trying to debug my own code but am frustrated in that I can't
> see
> where the problem exists.  I get some errors and other messages from
> OpenScad but unfortunately they don't point to what it was in my code that
> triggered it:
>
> ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion
> violation! Expr: e_below != SHalfedge_handle() File:
> /opt/mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_3/SNC_FM_decorator.h
> Line: 426

I don't recognize this error specifically, but typically if you get errors
relating to polyhedra it means you have constructed an invalid polyhedron
with the polyhedron module.  You can select View->Thrown Together in preview
which will show reversed faces.  But otherwise you just have to work through
your construction. 


> Likewise, I sometimes get this warning:
>
>
> DEPRECATED: Using ranges of the form [begin:end] with begin value greater
> than the end value is deprecated.

Yeah, this one is extremely annoying.  There appears to be no way to get
OpenSCAD to give you more information about this.  It can be anywhere in
your code, or anything that you include.  It could be a degenerate case, in
which case you can solve the problem by replacing every occurrence of [a:b]
in your code with [a:1:b].  But if it's a mistake in your code, that will
just cause the loop to not run---it won't tell you where the problem is. 




--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

adrianv
In reply to this post by DanS
If you write [a:1:b] then this steps from a to be in increments of 1.  If b<a
then you get zero steps and nothing happens.  This is exactly what you
expect this syntax to do.  It is always correct and it won't produce any
warnings. If you write general code (such as might be in a library) it may
encounter degenerate cases where a>b and you want the loop to do nothing.
If, on the other hand, you're coding up a specific model, you probably don't
want to write a loop that does nothing.  

If you write [a:b] then it steps from min(a,b) to max(a,b) in steps of 1.
If a>b most likely you have a bug in your code.  The latest version of
OpenSCAD warns about this but doesn't tell you where the problem is.  

So by changing all occurrences of [a:b] to [a:1:b] you will make your code
behave in what is arguably the correct manner.  But it doesn't mean you code
is actually correct.  It depends on why you had a>b.   Does that clear
things up?


DanS wrote

> Thanks for the tips!
>
> I'm not sure I understand "It could be a degenerate case, in which case
> you
> can solve the problem by replacing every occurrence of [a:b] in your code
> with [a:1:b]"
>
> I thought the way loops worked in openscad was [start:increment:end] or if
> two arguments were used they were assumed to be only start and end and
> increment was assumed to be 1.
> I will try your suggestion but don't understand why it would sometimes be
> a
> problem and sometimes not.  I'd like to understand it since it would give
> me a better picture how to use OpenSCAD.  When you say "degenerate" do you
> mean in the case start = end; or do you mean the interpreter sometimes
> screws up and interprets two arguments as [start:increment] and gives end
> some weird garbage value?
>
> On Thu, Jul 4, 2019 at 11:03 AM adrianv &lt;

> avm4@

> &gt; wrote:
>
>> DanS wrote
>> > I'm still trying to debug my own code but am frustrated in that I can't
>> > see
>> > where the problem exists.  I get some errors and other messages from
>> > OpenScad but unfortunately they don't point to what it was in my code
>> that
>> > triggered it:
>> >
>> > ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion
>> > violation! Expr: e_below != SHalfedge_handle() File:
>> >
>> /opt/mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_3/SNC_FM_decorator.h
>> > Line: 426
>>
>> I don't recognize this error specifically, but typically if you get
>> errors
>> relating to polyhedra it means you have constructed an invalid polyhedron
>> with the polyhedron module.  You can select View->Thrown Together in
>> preview
>> which will show reversed faces.  But otherwise you just have to work
>> through
>> your construction.
>>
>>
>> > Likewise, I sometimes get this warning:
>> >
>> >
>> > DEPRECATED: Using ranges of the form [begin:end] with begin value
>> greater
>> > than the end value is deprecated.
>>
>> Yeah, this one is extremely annoying.  There appears to be no way to get
>> OpenSCAD to give you more information about this.  It can be anywhere in
>> your code, or anything that you include.  It could be a degenerate case,
>> in
>> which case you can solve the problem by replacing every occurrence of
>> [a:b]
>> in your code with [a:1:b].  But if it's a mistake in your code, that will
>> just cause the loop to not run---it won't tell you where the problem is.
>>
>>
>>
>>
>> --
>> Sent from: http://forum.openscad.org/
>>
>> _______________________________________________
>> OpenSCAD mailing list
>>

> Discuss@.openscad

>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>
> _______________________________________________
> OpenSCAD mailing list

> Discuss@.openscad

> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org





--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

adrianv
In reply to this post by DanS
The typical behavior when a polyhedron is invalid is that it works in preview
but fails in render.  Use the "thrown together" option with preview, not
render.  Faces that are incorrectly oriented will appear in purple.  

There's an example here, along with other advice on debugging polyhedra:

https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/The_OpenSCAD_Language#Debugging_polyhedra


DanS wrote

> I'm not sure how to use View->Thrown Together properly
>
> If I do render.  I see this:
>
> [image: image.png]
>
> If right after that I go into View and select Thrown Together  I don't see
> anything in the console that indicates work is being done, my object
> entirely disappears.  I was expecting that if it will take some time it
> might indicate it is calculating.  Likewise, I thought the end result
> would
> be the same drawing but with some facets in a different color (indicating
> maybe missing / degenerate vertices caused things to be inside out).  What
> is the proper way to use View -> Throw Together
>
> On Thu, Jul 4, 2019 at 11:03 AM adrianv &lt;

> avm4@

> &gt; wrote:
>
>> DanS wrote
>> > I'm still trying to debug my own code but am frustrated in that I can't
>> > see
>> > where the problem exists.  I get some errors and other messages from
>> > OpenScad but unfortunately they don't point to what it was in my code
>> that
>> > triggered it:
>> >
>> > ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion
>> > violation! Expr: e_below != SHalfedge_handle() File:
>> >
>> /opt/mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_3/SNC_FM_decorator.h
>> > Line: 426
>>
>> I don't recognize this error specifically, but typically if you get
>> errors
>> relating to polyhedra it means you have constructed an invalid polyhedron
>> with the polyhedron module.  You can select View->Thrown Together in
>> preview
>> which will show reversed faces.  But otherwise you just have to work
>> through
>> your construction.
>>
>>
>> > Likewise, I sometimes get this warning:
>> >
>> >
>> > DEPRECATED: Using ranges of the form [begin:end] with begin value
>> greater
>> > than the end value is deprecated.
>>
>> Yeah, this one is extremely annoying.  There appears to be no way to get
>> OpenSCAD to give you more information about this.  It can be anywhere in
>> your code, or anything that you include.  It could be a degenerate case,
>> in
>> which case you can solve the problem by replacing every occurrence of
>> [a:b]
>> in your code with [a:1:b].  But if it's a mistake in your code, that will
>> just cause the loop to not run---it won't tell you where the problem is.
>>
>>
>>
>>
>> --
>> Sent from: http://forum.openscad.org/
>>
>> _______________________________________________
>> OpenSCAD mailing list
>>

> Discuss@.openscad

>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>
> _______________________________________________
> OpenSCAD mailing list

> Discuss@.openscad

> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
> image.png (27K)
> &lt;http://forum.openscad.org/attachment/26707/0/image.png&gt;





--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

DanS
In reply to this post by adrianv

Thanks.
Ok that makes sense if you meant start>end is degenerate; I typically thought of "degenerate" as in more than one thing being the same such as start = end.  I have changed all my loops to have increment specified as 1.

On the preview:
If I do render before preview does that mess things up? And if so how do I fix it?  I have now done preview; thrown together; preview and find I can still see my object but when I try to rotate it or zoom in and out things aren't behaving like they did with render.  For instance, zoom in and out the X Y Z axis get bigger and smaller but the object stays the same size.  Rotating around also doesn't seem to behave the same as it did for render.
 
The manual page you sent has this tidbit

"When you select 'Thrown together' from the view menu and compile the design (not compile and render!) you will see a preview with the mis-oriented polygons highlighted. Unfortunately this highlighting is not possible in the OpenCSG preview mode because it would interfere with the way the OpenCSG preview mode is implemented.)"

I did select Thrown Together and I did a preview before and after.  I'm assuming compile is included in both render and preview.

On Thu, Jul 4, 2019 at 11:44 AM adrianv <[hidden email]> wrote:
If you write [a:1:b] then this steps from a to be in increments of 1.  If b<a
then you get zero steps and nothing happens.  This is exactly what you
expect this syntax to do.  It is always correct and it won't produce any
warnings. If you write general code (such as might be in a library) it may
encounter degenerate cases where a>b and you want the loop to do nothing.
If, on the other hand, you're coding up a specific model, you probably don't
want to write a loop that does nothing. 

If you write [a:b] then it steps from min(a,b) to max(a,b) in steps of 1.
If a>b most likely you have a bug in your code.  The latest version of
OpenSCAD warns about this but doesn't tell you where the problem is. 

So by changing all occurrences of [a:b] to [a:1:b] you will make your code
behave in what is arguably the correct manner.  But it doesn't mean you code
is actually correct.  It depends on why you had a>b.   Does that clear
things up?


DanS wrote
> Thanks for the tips!
>
> I'm not sure I understand "It could be a degenerate case, in which case
> you
> can solve the problem by replacing every occurrence of [a:b] in your code
> with [a:1:b]"
>
> I thought the way loops worked in openscad was [start:increment:end] or if
> two arguments were used they were assumed to be only start and end and
> increment was assumed to be 1.
> I will try your suggestion but don't understand why it would sometimes be
> a
> problem and sometimes not.  I'd like to understand it since it would give
> me a better picture how to use OpenSCAD.  When you say "degenerate" do you
> mean in the case start = end; or do you mean the interpreter sometimes
> screws up and interprets two arguments as [start:increment] and gives end
> some weird garbage value?
>
> On Thu, Jul 4, 2019 at 11:03 AM adrianv &lt;

> avm4@

> &gt; wrote:
>
>> DanS wrote
>> > I'm still trying to debug my own code but am frustrated in that I can't
>> > see
>> > where the problem exists.  I get some errors and other messages from
>> > OpenScad but unfortunately they don't point to what it was in my code
>> that
>> > triggered it:
>> >
>> > ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion
>> > violation! Expr: e_below != SHalfedge_handle() File:
>> >
>> /opt/mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_3/SNC_FM_decorator.h
>> > Line: 426
>>
>> I don't recognize this error specifically, but typically if you get
>> errors
>> relating to polyhedra it means you have constructed an invalid polyhedron
>> with the polyhedron module.  You can select View->Thrown Together in
>> preview
>> which will show reversed faces.  But otherwise you just have to work
>> through
>> your construction.
>>
>>
>> > Likewise, I sometimes get this warning:
>> >
>> >
>> > DEPRECATED: Using ranges of the form [begin:end] with begin value
>> greater
>> > than the end value is deprecated.
>>
>> Yeah, this one is extremely annoying.  There appears to be no way to get
>> OpenSCAD to give you more information about this.  It can be anywhere in
>> your code, or anything that you include.  It could be a degenerate case,
>> in
>> which case you can solve the problem by replacing every occurrence of
>> [a:b]
>> in your code with [a:1:b].  But if it's a mistake in your code, that will
>> just cause the loop to not run---it won't tell you where the problem is.
>>
>>
>>
>>
>> --
>> Sent from: http://forum.openscad.org/
>>
>> _______________________________________________
>> OpenSCAD mailing list
>>

> Discuss@.openscad

>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>
> _______________________________________________
> OpenSCAD mailing list

> Discuss@.openscad

> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org





--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

Ronaldo
In reply to this post by DanS
My suggestion is not very clever but it is a debugging aid that will point the problematic 'for' out. The function:

function checkLimits(a,b,i) =
  a>b ? echo(a=a, b=b, for_number=i) 0 : 0;

may be called just before each suspicious 'for' in a module:

for203 = checkLimits(a,b, 203);
for(i=[a:b]) dosomething ;

or in a function:

let( ...
      for24 = checkLimits(a,b,24),
      x = [for(i=[a:b} ...],
     ...

Em qui, 4 de jul de 2019 às 16:20, Dan Shriver <[hidden email]> escreveu:
I'm not sure I understand "It could be a degenerate case, in which case you can solve the problem by replacing every occurrence of [a:b] in your code with [a:1:b]"

I thought the way loops worked in openscad was [start:increment:end] or if two arguments were used they were assumed to be only start and end and increment was assumed to be 1.
I will try your suggestion but don't understand why it would sometimes be a problem and sometimes not.  I'd like to understand it since it would give me a better picture how to use OpenSCAD.  When you say "degenerate" do you mean in the case start = end; or do you mean the interpreter sometimes screws up and interprets two arguments as [start:increment] and gives end some weird garbage value?


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

DanS
In reply to this post by adrianv
When I finally get to view things in preview, it looks like the whole structure has yellow or black facets with all the edges being purple.  I find this confusing.  Shouldn't some of the facets be yellow or black and others be purple.  Why should any of the edges be purple?  I'm not understanding this.

image.png

On Thu, Jul 4, 2019 at 11:51 AM adrianv <[hidden email]> wrote:
The typical behavior when a polyhedron is invalid is that it works in preview
but fails in render.  Use the "thrown together" option with preview, not
render.  Faces that are incorrectly oriented will appear in purple. 

There's an example here, along with other advice on debugging polyhedra:

https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/The_OpenSCAD_Language#Debugging_polyhedra


DanS wrote
> I'm not sure how to use View->Thrown Together properly
>
> If I do render.  I see this:
>
> [image: image.png]
>
> If right after that I go into View and select Thrown Together  I don't see
> anything in the console that indicates work is being done, my object
> entirely disappears.  I was expecting that if it will take some time it
> might indicate it is calculating.  Likewise, I thought the end result
> would
> be the same drawing but with some facets in a different color (indicating
> maybe missing / degenerate vertices caused things to be inside out).  What
> is the proper way to use View -> Throw Together
>
> On Thu, Jul 4, 2019 at 11:03 AM adrianv &lt;

> avm4@

> &gt; wrote:
>
>> DanS wrote
>> > I'm still trying to debug my own code but am frustrated in that I can't
>> > see
>> > where the problem exists.  I get some errors and other messages from
>> > OpenScad but unfortunately they don't point to what it was in my code
>> that
>> > triggered it:
>> >
>> > ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion
>> > violation! Expr: e_below != SHalfedge_handle() File:
>> >
>> /opt/mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_3/SNC_FM_decorator.h
>> > Line: 426
>>
>> I don't recognize this error specifically, but typically if you get
>> errors
>> relating to polyhedra it means you have constructed an invalid polyhedron
>> with the polyhedron module.  You can select View->Thrown Together in
>> preview
>> which will show reversed faces.  But otherwise you just have to work
>> through
>> your construction.
>>
>>
>> > Likewise, I sometimes get this warning:
>> >
>> >
>> > DEPRECATED: Using ranges of the form [begin:end] with begin value
>> greater
>> > than the end value is deprecated.
>>
>> Yeah, this one is extremely annoying.  There appears to be no way to get
>> OpenSCAD to give you more information about this.  It can be anywhere in
>> your code, or anything that you include.  It could be a degenerate case,
>> in
>> which case you can solve the problem by replacing every occurrence of
>> [a:b]
>> in your code with [a:1:b].  But if it's a mistake in your code, that will
>> just cause the loop to not run---it won't tell you where the problem is.
>>
>>
>>
>>
>> --
>> Sent from: http://forum.openscad.org/
>>
>> _______________________________________________
>> OpenSCAD mailing list
>>

> Discuss@.openscad

>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>
> _______________________________________________
> OpenSCAD mailing list

> Discuss@.openscad

> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
> image.png (27K)
> &lt;http://forum.openscad.org/attachment/26707/0/image.png&gt;





--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

acwest
In reply to this post by DanS
On Thu, 4 Jul 2019, 10:28 Dan Shriver, <[hidden email]> wrote:
Likewise, I sometimes get this warning:


DEPRECATED: Using ranges of the form [begin:end] with begin value greater than the end value is deprecated.


But I can't see any loop where the starting value is bigger than the end value.


I mostly get this message when I do a for over an empty array. I consider this behaviour to be a bug, really

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

adrianv
acwest wrote
> On Thu, 4 Jul 2019, 10:28 Dan Shriver, &lt;

> tabbydan@

> &gt; wrote:
>
>> Likewise, I sometimes get this warning:
>>
>>
>> DEPRECATED: Using ranges of the form [begin:end] with begin value greater
>> than the end value is deprecated.
>>
>>
>> But I can't see any loop where the starting value is bigger than the end
>> value.
>>
>
> I mostly get this message when I do a for over an empty array. I consider
> this behaviour to be a bug, really

To loop over an empty array you want to write for(i=[0:-1]) and because of
how ranges work, this range is the same as [-1:0], so it will give you -1
and 0.  I'm not sure how anybody thought it could ever be desirable for a
range [a:b] to be interpreted as [b:a], but that's the situation.  My
understanding is that the warning is a preliminary step to changing the
behavior.  

But if you just always write [a:1:b] then everything will work the way it
should.  The loop for(i=[0:1:-1]) will correctly loop over an empty array,
giving no loop steps.  



--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

acwest
I think I based my answer on an older version of the code, the case I had in mind works properly now. 

On Thu, 4 Jul 2019, 13:41 adrianv, <[hidden email]> wrote:
acwest wrote
> On Thu, 4 Jul 2019, 10:28 Dan Shriver, &lt;

> tabbydan@

> &gt; wrote:
>
>> Likewise, I sometimes get this warning:
>>
>>
>> DEPRECATED: Using ranges of the form [begin:end] with begin value greater
>> than the end value is deprecated.
>>
>>
>> But I can't see any loop where the starting value is bigger than the end
>> value.
>>
>
> I mostly get this message when I do a for over an empty array. I consider
> this behaviour to be a bug, really

To loop over an empty array you want to write for(i=[0:-1]) and because of
how ranges work, this range is the same as [-1:0], so it will give you -1
and 0.  I'm not sure how anybody thought it could ever be desirable for a
range [a:b] to be interpreted as [b:a], but that's the situation.  My
understanding is that the warning is a preliminary step to changing the
behavior. 

But if you just always write [a:1:b] then everything will work the way it
should.  The loop for(i=[0:1:-1]) will correctly loop over an empty array,
giving no loop steps. 



--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

adrianv
The warning is new in a recent version of the code.  But the code behavior is
the same.  If v=[] and you write for(i=[0:len(v)-1]) then the loop will go
over -1 and 0.  


acwest wrote
> I think I based my answer on an older version of the code, the case I had
> in mind works properly now.
>
> On Thu, 4 Jul 2019, 13:41 adrianv, &lt;

> avm4@

> &gt; wrote:
>
>> acwest wrote
>> > On Thu, 4 Jul 2019, 10:28 Dan Shriver, &lt;
>>
>> > tabbydan@
>>
>> > &gt; wrote:
>> >
>> >> Likewise, I sometimes get this warning:
>> >>
>> >>
>> >> DEPRECATED: Using ranges of the form [begin:end] with begin value
>> greater
>> >> than the end value is deprecated.
>> >>
>> >>
>> >> But I can't see any loop where the starting value is bigger than the
>> end
>> >> value.
>> >>
>> >
>> > I mostly get this message when I do a for over an empty array. I
>> consider
>> > this behaviour to be a bug, really
>>
>> To loop over an empty array you want to write for(i=[0:-1]) and because
>> of
>> how ranges work, this range is the same as [-1:0], so it will give you -1
>> and 0.  I'm not sure how anybody thought it could ever be desirable for a
>> range [a:b] to be interpreted as [b:a], but that's the situation.  My
>> understanding is that the warning is a preliminary step to changing the
>> behavior.
>>
>> But if you just always write [a:1:b] then everything will work the way it
>> should.  The loop for(i=[0:1:-1]) will correctly loop over an empty
>> array,
>> giving no loop steps.
>>
>>
>>
>> --
>> Sent from: http://forum.openscad.org/
>>
>> _______________________________________________
>> OpenSCAD mailing list
>>

> Discuss@.openscad

>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>
> _______________________________________________
> OpenSCAD mailing list

> Discuss@.openscad

> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org





--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

acwest
I'm sure I used to get the same warning with for (i = v) as well, but I can no longer replicate that behaviour (even in 2015.03)

On Thu, 4 Jul 2019, 14:07 adrianv, <[hidden email]> wrote:
The warning is new in a recent version of the code.  But the code behavior is
the same.  If v=[] and you write for(i=[0:len(v)-1]) then the loop will go
over -1 and 0. 


acwest wrote
> I think I based my answer on an older version of the code, the case I had
> in mind works properly now.
>
> On Thu, 4 Jul 2019, 13:41 adrianv, &lt;

> avm4@

> &gt; wrote:
>
>> acwest wrote
>> > On Thu, 4 Jul 2019, 10:28 Dan Shriver, &lt;
>>
>> > tabbydan@
>>
>> > &gt; wrote:
>> >
>> >> Likewise, I sometimes get this warning:
>> >>
>> >>
>> >> DEPRECATED: Using ranges of the form [begin:end] with begin value
>> greater
>> >> than the end value is deprecated.
>> >>
>> >>
>> >> But I can't see any loop where the starting value is bigger than the
>> end
>> >> value.
>> >>
>> >
>> > I mostly get this message when I do a for over an empty array. I
>> consider
>> > this behaviour to be a bug, really
>>
>> To loop over an empty array you want to write for(i=[0:-1]) and because
>> of
>> how ranges work, this range is the same as [-1:0], so it will give you -1
>> and 0.  I'm not sure how anybody thought it could ever be desirable for a
>> range [a:b] to be interpreted as [b:a], but that's the situation.  My
>> understanding is that the warning is a preliminary step to changing the
>> behavior.
>>
>> But if you just always write [a:1:b] then everything will work the way it
>> should.  The loop for(i=[0:1:-1]) will correctly loop over an empty
>> array,
>> giving no loop steps.
>>
>>
>>
>> --
>> Sent from: http://forum.openscad.org/
>>
>> _______________________________________________
>> OpenSCAD mailing list
>>

> Discuss@.openscad

>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>
> _______________________________________________
> OpenSCAD mailing list

> Discuss@.openscad

> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org





--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

DanS
So it seems like I only get the:

DEPRECATED: Using ranges of the form [begin:end] with begin value greater than the end value is deprecated. 

warning under a special case:
and the message appears partway through a bunch of other debug messages (suggesting it built one structure, and then later hits the error doing the difference or the later mirror.  Also nothing is drawn because there is a problem somewhere. 
I should mention I DO have loops where start is greater than end, but in the cases I intend to be that way, I have an index value of -1.   I have also recoded things so the other case [start: end] always uses [start: 1: end] when end is intended to be >  start.

difference() {
    arches2(16);
    mirror([0,0,1]) {
       arches2(16,true); //subtract a SOLID version
    }
}
mirror([0,0,1]) {
       arches2(16);
    }

If I do arches2(16)  I can render the object and it looks fine.  Likewise when I preview -> thrown together that I don't see any purple / pink facets only purple pink edges.

If I union arches2(16) with a cube I get the: "ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion violation! Expr: e_below != SHalfedge_handle() File: /opt/mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_3/SNC_FM_decorator.h Line: 426" message
I also get that message (twice) if I simply do this:


    arches2(16,2);
mirror([0,0,1]) {
       arches2(16,2);
    } 


arches2(16) does a skin over a bunch of 16 vertex polygons (that you can roughly view as being horsehoes, wishbones, arches).  The second numeric argument represents a thickness (it has a default value), a boolean argument (default false) determines if the object is "solid" (that is not horseshoe shaped but a convex polygon with no concavity, also with fewer vertices)

So I'm confused how to approach debugging this.

On Thu, Jul 4, 2019 at 2:12 PM A. Craig West <[hidden email]> wrote:
I'm sure I used to get the same warning with for (i = v) as well, but I can no longer replicate that behaviour (even in 2015.03)

On Thu, 4 Jul 2019, 14:07 adrianv, <[hidden email]> wrote:
The warning is new in a recent version of the code.  But the code behavior is
the same.  If v=[] and you write for(i=[0:len(v)-1]) then the loop will go
over -1 and 0. 


acwest wrote
> I think I based my answer on an older version of the code, the case I had
> in mind works properly now.
>
> On Thu, 4 Jul 2019, 13:41 adrianv, &lt;

> avm4@

> &gt; wrote:
>
>> acwest wrote
>> > On Thu, 4 Jul 2019, 10:28 Dan Shriver, &lt;
>>
>> > tabbydan@
>>
>> > &gt; wrote:
>> >
>> >> Likewise, I sometimes get this warning:
>> >>
>> >>
>> >> DEPRECATED: Using ranges of the form [begin:end] with begin value
>> greater
>> >> than the end value is deprecated.
>> >>
>> >>
>> >> But I can't see any loop where the starting value is bigger than the
>> end
>> >> value.
>> >>
>> >
>> > I mostly get this message when I do a for over an empty array. I
>> consider
>> > this behaviour to be a bug, really
>>
>> To loop over an empty array you want to write for(i=[0:-1]) and because
>> of
>> how ranges work, this range is the same as [-1:0], so it will give you -1
>> and 0.  I'm not sure how anybody thought it could ever be desirable for a
>> range [a:b] to be interpreted as [b:a], but that's the situation.  My
>> understanding is that the warning is a preliminary step to changing the
>> behavior.
>>
>> But if you just always write [a:1:b] then everything will work the way it
>> should.  The loop for(i=[0:1:-1]) will correctly loop over an empty
>> array,
>> giving no loop steps.
>>
>>
>>
>> --
>> Sent from: http://forum.openscad.org/
>>
>> _______________________________________________
>> OpenSCAD mailing list
>>

> Discuss@.openscad

>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>
> _______________________________________________
> OpenSCAD mailing list

> Discuss@.openscad

> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org





--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

adrianv
DanS wrote

> So it seems like I only get the:
>
> DEPRECATED: Using ranges of the form [begin:end] with begin value greater
> than the end value is deprecated.
>
> warning under a special case:
> and the message appears partway through a bunch of other debug messages
> (suggesting it built one structure, and then later hits the error doing
> the
> difference or the later mirror.  

I have seen behavior with regards to debug message that suggest to me that
the code is not necessarily executed in order.   Does anybody know?  

> Also nothing is drawn because there is a
> problem somewhere.
> I should mention I DO have loops where start is greater than end, but in
> the cases I intend to be that way, I have an index value of -1.

You mean a step value of -1?  Like you wrote [10:-1:0]?  Nothing wrong with
that, and it should not trigger the message.  The warning message is just
for ranges that look like [a:b] where a>b.  Note also that it is only a
warning message.  You can still run your code to completion.  OpenSCAD will
count such a range starting at b and ascending to a.  (It will not start at
a and go by steps of -1 down to b.)  


> If I union arches2(16) with a cube I get the: "ERROR: CGAL error in
> CGAL_Nef_polyhedron3(): CGAL ERROR: assertion violation! Expr: e_below !=
> SHalfedge_handle() File:
> /opt/mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_3/SNC_FM_decorator.h
> Line: 426" message

Unioning with a cube is supposed to be a test of validity of your
polyhedron.  I recall previously someone else said it might have to do with
rounding errors.  Have you tried simplifying your model until it works?  It
sounds like arches2(16) is producing an invalid result.  

> arches2(16) does a skin over a bunch of 16 vertex polygons (that you can
> roughly view as being horsehoes, wishbones, arches).  The second numeric
> argument represents a thickness (it has a default value), a boolean
> argument (default false) determines if the object is "solid" (that is not
> horseshoe shaped but a convex polygon with no concavity, also with fewer
> vertices)
>
> So I'm confused how to approach debugging this.

You said it's a skin over "a bunch" of 16 vertex polygons.  So what happens
if you skin the first two only.  Can you union the result with a cube?  Does
it look ok in thrown together mode?  

I do not know what it means that you got pink edges in "thrown together"
view.  I haven't seen that.  




--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

DanS
yes, I've simplified it to where it seems to work.  So I know it breaks down where I do "wave" which interpolates between one curve and another using sin() (to give a smooth curve rather than a linear transition).

I'll try a smaller set of interpolations that might be easier for me to view completely.

Earlier in the email thread I took a snapshot of the pink edges

image.png

moving around the model I didn't see any pink / purple facets.  There may have been some present, I find it hard to investigate the whole thing because it is big and as I rotate or zoom in / out sometimes I can't see anything; I do know if there are pink/purple facets they are in the vast minority as I think I viewed most of the facets

On Thu, Jul 4, 2019 at 5:42 PM adrianv <[hidden email]> wrote:
DanS wrote
> So it seems like I only get the:
>
> DEPRECATED: Using ranges of the form [begin:end] with begin value greater
> than the end value is deprecated.
>
> warning under a special case:
> and the message appears partway through a bunch of other debug messages
> (suggesting it built one structure, and then later hits the error doing
> the
> difference or the later mirror. 

I have seen behavior with regards to debug message that suggest to me that
the code is not necessarily executed in order.   Does anybody know? 

> Also nothing is drawn because there is a
> problem somewhere.
> I should mention I DO have loops where start is greater than end, but in
> the cases I intend to be that way, I have an index value of -1.

You mean a step value of -1?  Like you wrote [10:-1:0]?  Nothing wrong with
that, and it should not trigger the message.  The warning message is just
for ranges that look like [a:b] where a>b.  Note also that it is only a
warning message.  You can still run your code to completion.  OpenSCAD will
count such a range starting at b and ascending to a.  (It will not start at
a and go by steps of -1 down to b.) 


> If I union arches2(16) with a cube I get the: "ERROR: CGAL error in
> CGAL_Nef_polyhedron3(): CGAL ERROR: assertion violation! Expr: e_below !=
> SHalfedge_handle() File:
> /opt/mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_3/SNC_FM_decorator.h
> Line: 426" message

Unioning with a cube is supposed to be a test of validity of your
polyhedron.  I recall previously someone else said it might have to do with
rounding errors.  Have you tried simplifying your model until it works?  It
sounds like arches2(16) is producing an invalid result. 

> arches2(16) does a skin over a bunch of 16 vertex polygons (that you can
> roughly view as being horsehoes, wishbones, arches).  The second numeric
> argument represents a thickness (it has a default value), a boolean
> argument (default false) determines if the object is "solid" (that is not
> horseshoe shaped but a convex polygon with no concavity, also with fewer
> vertices)
>
> So I'm confused how to approach debugging this.

You said it's a skin over "a bunch" of 16 vertex polygons.  So what happens
if you skin the first two only.  Can you union the result with a cube?  Does
it look ok in thrown together mode?   

I do not know what it means that you got pink edges in "thrown together"
view.  I haven't seen that. 




--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

adrianv
DanS wrote
> yes, I've simplified it to where it seems to work.  So I know it breaks
> down where I do "wave" which interpolates between one curve and another
> using sin() (to give a smooth curve rather than a linear transition).

Is it possible that you have very skinny facets showing up in pink between
larger facets?   It just takes a single bad facet to ruin your entire model.  

If the interpolation process is at fault can you use a simpler polygon as
the base for the interpolation?




--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

DanS
So I was taking your idea of doing less.  Instead of 105 transition steps I did 15.
If I union it with a cube it only works if they don't touch at all, if they do touch it seems to blow up and render nothing.

If I take the more simple version and do Preview -> Thrown together I don't see any pink / purple facets (but the edges are all pink purple) the one thing that strikes me as very odd is that each arch should be planar.  I would intuitively expect no triangles on the ends yet all the vertices on the ends are part of triangles.  Of course, it might also do those triangles if all the vertexes are planar, I just don't know.

image.png

On Thu, Jul 4, 2019 at 6:39 PM adrianv <[hidden email]> wrote:
DanS wrote
> yes, I've simplified it to where it seems to work.  So I know it breaks
> down where I do "wave" which interpolates between one curve and another
> using sin() (to give a smooth curve rather than a linear transition).

Is it possible that you have very skinny facets showing up in pink between
larger facets?   It just takes a single bad facet to ruin your entire model. 

If the interpolation process is at fault can you use a simpler polygon as
the base for the interpolation?




--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

nophead
I don't think you should see purple edges. Do they meet or is there a hole through which you can see the purple interior?


On Thu, 4 Jul 2019, 23:51 Dan Shriver, <[hidden email]> wrote:
So I was taking your idea of doing less.  Instead of 105 transition steps I did 15.
If I union it with a cube it only works if they don't touch at all, if they do touch it seems to blow up and render nothing.

If I take the more simple version and do Preview -> Thrown together I don't see any pink / purple facets (but the edges are all pink purple) the one thing that strikes me as very odd is that each arch should be planar.  I would intuitively expect no triangles on the ends yet all the vertices on the ends are part of triangles.  Of course, it might also do those triangles if all the vertexes are planar, I just don't know.

image.png

On Thu, Jul 4, 2019 at 6:39 PM adrianv <[hidden email]> wrote:
DanS wrote
> yes, I've simplified it to where it seems to work.  So I know it breaks
> down where I do "wave" which interpolates between one curve and another
> using sin() (to give a smooth curve rather than a linear transition).

Is it possible that you have very skinny facets showing up in pink between
larger facets?   It just takes a single bad facet to ruin your entire model. 

If the interpolation process is at fault can you use a simpler polygon as
the base for the interpolation?




--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
12