DEPRECATED: Using ranges of the form [begin:end] with begin value greater than the end value is deprecated.
Every so often I get this warning message.
DEPRECATED: Using ranges of the form [begin:end] with begin value greater
than the end value is deprecated.
It means my code has a bug, because I never write [5:0] to mean [0:5]---I
don't understand why anybody thought that was a good idea---so it means I'm
potentially getting some non-empty list when I should be getting the empty
list as a result.
The fix is easy: rewrite [a:b] as [a:1:b]. And I guess I should try to get
in the habit of never writing [a:b] and just always writing [a:1:b] to
prevent this problem in the future. But I get no hint as to where in my
code the problem is, which makes it kind of troublesome to track down. Is
there any way to get more information?
--
Sent from: http://forum.openscad.org/
I usually got this when I try to do a for loop over an empty list. I really
don't know why this case wasn't implemented properly in the first place, I
have to write every list iteration with a check for zero length first, when
that should just work...
On Wed, 22 May 2019, 07:46 adrianv, avm4@cornell.edu wrote:
Every so often I get this warning message.
DEPRECATED: Using ranges of the form [begin:end] with begin value greater
than the end value is deprecated.
It means my code has a bug, because I never write [5:0] to mean [0:5]---I
don't understand why anybody thought that was a good idea---so it means I'm
potentially getting some non-empty list when I should be getting the empty
list as a result.
The fix is easy: rewrite [a:b] as [a:1:b]. And I guess I should try to get
in the habit of never writing [a:b] and just always writing [a:1:b] to
prevent this problem in the future. But I get no hint as to where in my
code the problem is, which makes it kind of troublesome to track down. Is
there any way to get more information?
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
In my opinion, this is just a bug that should be fixed. I believe that there is a lot more code out there that is broken by this behaviour, than there is code that depends on this behaviour. So fixing the bug will fix more programs than it breaks.
On Wed, May 22, 2019, at 7:47 AM, adrianv wrote:
Every so often I get this warning message.
DEPRECATED: Using ranges of the form [begin:end] with begin value greater
than the end value is deprecated.
It means my code has a bug, because I never write [5:0] to mean [0:5]---I
don't understand why anybody thought that was a good idea---so it means I'm
potentially getting some non-empty list when I should be getting the empty
list as a result.
The fix is easy: rewrite [a:b] as [a:1:b]. And I guess I should try to get
in the habit of never writing [a:b] and just always writing [a:1:b] to
prevent this problem in the future. But I get no hint as to where in my
code the problem is, which makes it kind of troublesome to track down. Is
there any way to get more information?
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I can't actually think of a single use case for failing on a zero length
list. Most of the time I run across this writing various filter and
transformation functions usin list comprehensions, and they all start with
what should be an unnecessary :
len(v) == 0 ? [] :
[ for (o = v)...]
On Wed, 22 May 2019, 09:02 Doug Moen, doug@moens.org wrote:
In my opinion, this is just a bug that should be fixed. I believe that
there is a lot more code out there that is broken by this behaviour, than
there is code that depends on this behaviour. So fixing the bug will fix
more programs than it breaks.
On Wed, May 22, 2019, at 7:47 AM, adrianv wrote:
Every so often I get this warning message.
DEPRECATED: Using ranges of the form [begin:end] with begin value greater
than the end value is deprecated.
It means my code has a bug, because I never write [5:0] to mean
[0:5]---I
don't understand why anybody thought that was a good idea---so it means
I'm
potentially getting some non-empty list when I should be getting the
empty
list as a result.
The fix is easy: rewrite [a:b] as [a:1:b]. And I guess I should try to
get
in the habit of never writing [a:b] and just always writing [a:1:b] to
prevent this problem in the future. But I get no hint as to where in my
code the problem is, which makes it kind of troublesome to track down.
Is
there any way to get more information?
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 22.05.19 15:01, Doug Moen wrote:
In my opinion, this is just a bug that should be fixed. I
believe that there is a lot more code out there that is
broken by this behaviour, than there is code that depends
on this behaviour. So fixing the bug will fix more programs
than it breaks.
Yes, and the way to do it is to first deprecate and warn
about that and after people had a chance to fix the code
change it.
ciao,
Torsten.
At least in the case of empty lists, I can't even picture a way to write
code that would depend on this behaviour.
On Wed, 22 May 2019, 12:27 Torsten Paul, Torsten.Paul@gmx.de wrote:
On 22.05.19 15:01, Doug Moen wrote:
In my opinion, this is just a bug that should be fixed. I
believe that there is a lot more code out there that is
broken by this behaviour, than there is code that depends
on this behaviour. So fixing the bug will fix more programs
than it breaks.
Yes, and the way to do it is to first deprecate and warn
about that and after people had a chance to fix the code
change it.
ciao,
Torsten.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 22.05.19 15:15, A. Craig West wrote:
len(v) == 0 ? [] :
[ for (o = v)...]
This has nothing to do with ranges as far as I can see. Can
you elaborate on why that is needed? If there's a bug then
it can only be fixed if it's reported.
v = [];
echo([for (a = v) a]);
Works fine and reports an empty list which is what I would
expect. So in which case is that len() needed?
ciao,
Torsten.
It occurs to me that I haven't checked this since I switched to more recent
builds. It was certainly the behavior in the 2015 version, but that is much
less relevant now 😊.
I shall give this a try. Hopefully thingiverse will start using the new
version for their customiser, as that has been the only thing keeping me
back on that one...
On Wed, 22 May 2019, 12:32 Torsten Paul, Torsten.Paul@gmx.de wrote:
On 22.05.19 15:15, A. Craig West wrote:
len(v) == 0 ? [] :
[ for (o = v)...]
This has nothing to do with ranges as far as I can see. Can
you elaborate on why that is needed? If there's a bug then
it can only be fixed if it's reported.
v = [];
echo([for (a = v) a]);
Works fine and reports an empty list which is what I would
expect. So in which case is that len() needed?
ciao,
Torsten.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
The problem with OpenSCAD ranges is they include the last value, so you can
never have a loop that doesn't do any iterations, you have to check for
that first. When iterating over the indices of a list you need [0 :
len(list) -1] but then if the list is empty you get [0 : -1] which I think
warns and then iterates backwards. All other languages I know use half open
ranges, so can have zero elements and don't need the -1.
Using the new C style loops is a work around for that.
On Wed, 22 May 2019 at 17:41, A. Craig West acraigwest@gmail.com wrote:
It occurs to me that I haven't checked this since I switched to more
recent builds. It was certainly the behavior in the 2015 version, but that
is much less relevant now 😊.
I shall give this a try. Hopefully thingiverse will start using the new
version for their customiser, as that has been the only thing keeping me
back on that one...
On Wed, 22 May 2019, 12:32 Torsten Paul, Torsten.Paul@gmx.de wrote:
On 22.05.19 15:15, A. Craig West wrote:
len(v) == 0 ? [] :
[ for (o = v)...]
This has nothing to do with ranges as far as I can see. Can
you elaborate on why that is needed? If there's a bug then
it can only be fixed if it's reported.
v = [];
echo([for (a = v) a]);
Works fine and reports an empty list which is what I would
expect. So in which case is that len() needed?
ciao,
Torsten.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Many other languages support closed ranges.
In Haskell and Perl, the closed range [0 : -1] returns the empty range.
(Haskell and Perl use a different syntax for ranges than OpenSCAD, but that's not important to the point I'm making.)
On Wed, May 22, 2019, at 1:35 PM, nop head wrote:
The problem with OpenSCAD ranges is they include the last value, so you can never have a loop that doesn't do any iterations, you have to check for that first. When iterating over the indices of a list you need [0 : len(list) -1] but then if the list is empty you get [0 : -1] which I think warns and then iterates backwards. All other languages I know use half open ranges, so can have zero elements and don't need the -1.
Using the new C style loops is a work around for that.
On Wed, 22 May 2019 at 17:41, A. Craig West acraigwest@gmail.com wrote:
It occurs to me that I haven't checked this since I switched to more recent builds. It was certainly the behavior in the 2015 version, but that is much less relevant now 😊.
I shall give this a try. Hopefully thingiverse will start using the new version for their customiser, as that has been the only thing keeping me back on that one...
On Wed, 22 May 2019, 12:32 Torsten Paul, Torsten.Paul@gmx.de wrote:
On 22.05.19 15:15, A. Craig West wrote:
len(v) == 0 ? [] :
[ for (o = v)...]
This has nothing to do with ranges as far as I can see. Can
you elaborate on why that is needed? If there's a bug then
it can only be fixed if it's reported.
v = [];
echo([for (a = v) a]);
Works fine and reports an empty list which is what I would
expect. So in which case is that len() needed?
ciao,
Torsten.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org