RP
Ronaldo Persiano
Mon, Jul 27, 2020 4:08 PM
The amount of
time it would take me to fix a megabyte of code would be less than the time
I've wasted already debugging undefs that propagate through my code. But
the backward compatibility problem is a definite problem. Perhaps a
setting could be introduced to optionally make undefs into fatal errors,
similar to the setting that makes warnings into fatal errors.
That already came to my mind. An alternative is to have a global variable,
like $safe_mode, that would control the system reaction to an 'undef'
result: no errors would be generated iff it is false, its default value. It
could be set locally if needed.
>
> The amount of
> time it would take me to fix a megabyte of code would be less than the time
> I've wasted already debugging undefs that propagate through my code. But
> the backward compatibility problem is a definite problem. Perhaps a
> setting could be introduced to optionally make undefs into fatal errors,
> similar to the setting that makes warnings into fatal errors.
That already came to my mind. An alternative is to have a global variable,
like $safe_mode, that would control the system reaction to an 'undef'
result: no errors would be generated iff it is false, its default value. It
could be set locally if needed.
JB
Jordan Brown
Mon, Jul 27, 2020 4:38 PM
On 7/27/2020 4:41 AM, MathLover wrote:
So if I would compare a boolean with greater or lesser operators, I expect
an error message. True is not more or less than false.
Sorting by a boolean makes sense, and the straightforward ways to sort
want to have a greater/less concept. Does that matter for OpenSCAD?
Don't know.
[null propagation] made programming visual basic and other languages that had this
"feature" a minefield when dealing with booleans. So please don't go that
route. I have been there, and I really do not want to go back.
Yeah... many years ago I implemented a similar concept in dBASE III. I
was adding date support, and it was clear that we needed blank dates,
which in turn meant we had to define how comparisons worked on blank
dates. My answer was to move to ternary logic, so that the result of a
comparison could be yes, no, or maybe. It ... did not turn out well.
It made working with blank dates difficult, and had no redeeming value.
For those familiar with dBASE III and this issue... sorry about that.
I come up with four basic options for how to do mixed-type comparisons:
- Coerce them to match. Convert everything to strings, or to numbers,
or some other scheme. "1" == 1; "true" == true.
- Mixed types are different values and so are never equal. (You could
define an ordering of the types, so that greater and less are
defined and mixed-type lists are sortable.)
- Mixed-type comparisons yield undef.
- Mixed-type comparisons are errors.
Several languages (e.g. JavaScript) use the coercion. scheme. C is
partially coercion, for numeric types and maybe a few other cases, and
errors for other.
I don't think the undef scheme offers any value. It's basically saying
that it's an error, without making the error be immediately visible. I
don't immediately come up with any value to it.
I'm not a big fan of coercion. It provides opportunities for errors to
go undetected, while providing little value.
That leaves "error" and "never equal".
"Never equal" is appealing. It is "correct", in a sense, and allows for
sortability. On the other hand, it allows errors to go undetected. On
the whole, I think the cost (undetected errors) exceeds the value
(sortability).
I guess that leaves me with a preferred answer of "error".
Special note: undef should get special attention. Comparing against
undef should always be acceptable, and should yield true if both values
are undef and false otherwise.
Now, note that that's all about comparison operators. Boolean operators
and contexts (e.g. "if") are a different question. I'm OK with either
being strict (require boolean values) or loose (define what "truth"
means for each type individually). If I was to start from zero, I'd
probably define undef and false itself as false and all other values as
true. That would let you easily say "if the value is present, then..."
and that seems more useful than having an easy way to test for zero and
the empty string. (And I'm obsessive and think the empty string is a
perfectly good string, and that an empty list is not the same thing as
no list at all.) But we're not starting from zero; OpenSCAD uses a
true/not-empty/non-zero style of truth and, shrug, that's OK.
On 7/27/2020 4:41 AM, MathLover wrote:
> So if I would compare a boolean with greater or lesser operators, I expect
> an error message. True is not more or less than false.
Sorting by a boolean makes sense, and the straightforward ways to sort
want to have a greater/less concept. Does that matter for OpenSCAD?
Don't know.
> [null propagation] made programming visual basic and other languages that had this
> "feature" a minefield when dealing with booleans. So please don't go that
> route. I have been there, and I really do not want to go back.
Yeah... many years ago I implemented a similar concept in dBASE III. I
was adding date support, and it was clear that we needed blank dates,
which in turn meant we had to define how comparisons worked on blank
dates. My answer was to move to ternary logic, so that the result of a
comparison could be yes, no, or maybe. It ... did not turn out well.
It made working with blank dates difficult, and had no redeeming value.
For those familiar with dBASE III and this issue... sorry about that.
I come up with four basic options for how to do mixed-type comparisons:
* Coerce them to match. Convert everything to strings, or to numbers,
or some other scheme. "1" == 1; "true" == true.
* Mixed types are different values and so are never equal. (You could
define an ordering of the types, so that greater and less are
defined and mixed-type lists are sortable.)
* Mixed-type comparisons yield undef.
* Mixed-type comparisons are errors.
Several languages (e.g. JavaScript) use the coercion. scheme. C is
partially coercion, for numeric types and maybe a few other cases, and
errors for other.
I don't think the undef scheme offers any value. It's basically saying
that it's an error, without making the error be immediately visible. I
don't immediately come up with any value to it.
I'm not a big fan of coercion. It provides opportunities for errors to
go undetected, while providing little value.
That leaves "error" and "never equal".
"Never equal" is appealing. It is "correct", in a sense, and allows for
sortability. On the other hand, it allows errors to go undetected. On
the whole, I think the cost (undetected errors) exceeds the value
(sortability).
I guess that leaves me with a preferred answer of "error".
Special note: undef should get special attention. Comparing against
undef should always be acceptable, and should yield true if both values
are undef and false otherwise.
Now, note that that's all about comparison operators. Boolean operators
and contexts (e.g. "if") are a different question. I'm OK with either
being strict (require boolean values) or loose (define what "truth"
means for each type individually). If I was to start from zero, I'd
probably define undef and false itself as false and all other values as
true. That would let you easily say "if the value is present, then..."
and that seems more useful than having an easy way to test for zero and
the empty string. (And I'm obsessive and think the empty string is a
perfectly good string, and that an empty list is not the same thing as
no list at all.) But we're not starting from zero; OpenSCAD uses a
true/not-empty/non-zero style of truth and, shrug, that's OK.
JB
Jordan Brown
Mon, Jul 27, 2020 4:50 PM
On 7/27/2020 6:23 AM, Ray West wrote:
Historically, There has been a lot of misunderstanding about the true
nature of boolean, by folk who should have known better. Just because
digital computers work the way they do, they bypassed they forgot
about what the ones and zeros truly represented, and manipulated them
in the ways that ones and zeros would be manipulated as normal
bits/bytes/whatever. I blame their parents.
A lot of that comes from C, and it's important to remember that C is
just a small step up from assembly language. (The ++ and -- features,
for instance, came directly from PDP-11 autoincrement and autodecrement
instructions.)
On 7/27/2020 6:23 AM, Ray West wrote:
> Historically, There has been a lot of misunderstanding about the true
> nature of boolean, by folk who should have known better. Just because
> digital computers work the way they do, they bypassed they forgot
> about what the ones and zeros truly represented, and manipulated them
> in the ways that ones and zeros would be manipulated as normal
> bits/bytes/whatever. I blame their parents.
A lot of that comes from C, and it's important to remember that C is
just a small step up from assembly language. (The ++ and -- features,
for instance, came directly from PDP-11 autoincrement and autodecrement
instructions.)
JB
Jordan Brown
Mon, Jul 27, 2020 4:53 PM
On 7/27/2020 9:08 AM, Ronaldo Persiano wrote:
That already came to my mind. An alternative is to have a global
variable, like $safe_mode, that would control the system reaction to
an 'undef' result: no errors would be generated iff it is false, its
default value. It could be set locally if needed.
$something would have the wrong scope. You want lexical scoping.
You want a file, module, or function to say "I want/don't-want safe
mode" without having that affect other unrelated files, modules, or
functions that it might call. You want to let a library say, one time
at the top, "I want safe mode".
But which is "safe", generating errors (and thus protecting you from
bugs) or not (and thus "protecting" you from errors)?
Suggest something with a more definitive meaning, e.g.
"allow_mixed_type_comparisons".
On 7/27/2020 9:08 AM, Ronaldo Persiano wrote:
> That already came to my mind. An alternative is to have a global
> variable, like $safe_mode, that would control the system reaction to
> an 'undef' result: no errors would be generated iff it is false, its
> default value. It could be set locally if needed.
$something would have the wrong scope. You want lexical scoping.
You want a file, module, or function to say "I want/don't-want safe
mode" without having that affect other unrelated files, modules, or
functions that it might call. You want to let a library say, one time
at the top, "I want safe mode".
But which is "safe", generating errors (and thus protecting you from
bugs) or not (and thus "protecting" you from errors)?
Suggest something with a more definitive meaning, e.g.
"allow_mixed_type_comparisons".
A
adrianv
Mon, Jul 27, 2020 5:22 PM
But which is "safe", generating errors (and thus protecting you from
bugs) or not (and thus "protecting" you from errors)?
Suggest something with a more definitive meaning, e.g.
"allow_mixed_type_comparisons".
Who cares about mixed type comparisons??? Does anybody ever use them? If
we banned them outright would anybody's code break? Anybody have an example
of a use for a mixed type comparison?
The topic has drifted to the broader topic of undef in general. I suggested
mixed type comparisons should return undef because that would be consistent
(and the whole issue seemed to be a case of worrying a lot about
consistency). But this leads to the question of undef in general, which is
a real problem that arises all the time. And that's what Ronaldo was
talking about. Perhaps "$return_undefs" would be a better name?
It does seem like the scoping is bit of a problem, but the simple solution
is that any (library) code that relies on computations with undefs would
need to explicitly set the variable to true anywhere that it mattered. This
seems kind of messy to me. Also there is no precedent for this type of
control variable in OpenSCAD.
It seems to me that if there's an interest in making OpenSCAD more usable it
makes more sense to make more of a break. Introduce a new version where
errors are errors, similar to some of the breaking changes made in 2019.05.
If you need to run old code, you run it in compatibility mode where your
whole program runs in the old way, similar to how you can change the setting
to make warnings into fatal errors. New code will still run in
compatibility mode. You can just work entirely in compatibility mode if
undefs don't bother you. This approach is straight forward and doesn't lead
to some complicated mess of people running code where parts of it need a
different mode than other parts. It also directly deprecates the old style
and encourages better coding practice moving forward.
Another option would be to make operations on undef issue a warning. Then
old code will still run, but if you want to you can enable the option that
makes warnings into errors.
--
Sent from: http://forum.openscad.org/
JordanBrown wrote
>
> But which is "safe", generating errors (and thus protecting you from
> bugs) or not (and thus "protecting" you from errors)?
>
> Suggest something with a more definitive meaning, e.g.
> "allow_mixed_type_comparisons".
Who cares about mixed type comparisons??? Does anybody ever use them? If
we banned them outright would anybody's code break? Anybody have an example
of a use for a mixed type comparison?
The topic has drifted to the broader topic of undef in general. I suggested
mixed type comparisons should return undef because that would be consistent
(and the whole issue seemed to be a case of worrying a lot about
consistency). But this leads to the question of undef in general, which is
a real problem that arises all the time. And that's what Ronaldo was
talking about. Perhaps "$return_undefs" would be a better name?
It does seem like the scoping is bit of a problem, but the simple solution
is that any (library) code that relies on computations with undefs would
need to explicitly set the variable to true anywhere that it mattered. This
seems kind of messy to me. Also there is no precedent for this type of
control variable in OpenSCAD.
It seems to me that if there's an interest in making OpenSCAD more usable it
makes more sense to make more of a break. Introduce a new version where
errors are errors, similar to some of the breaking changes made in 2019.05.
If you need to run old code, you run it in compatibility mode where your
whole program runs in the old way, similar to how you can change the setting
to make warnings into fatal errors. New code will still run in
compatibility mode. You can just work entirely in compatibility mode if
undefs don't bother you. This approach is straight forward and doesn't lead
to some complicated mess of people running code where parts of it need a
different mode than other parts. It also directly deprecates the old style
and encourages better coding practice moving forward.
Another option would be to make operations on undef issue a warning. Then
old code will still run, but if you want to you can enable the option that
makes warnings into errors.
--
Sent from: http://forum.openscad.org/
AC
A. Craig West
Mon, Jul 27, 2020 5:39 PM
As was mentioned by somebody, mixed type comparisons for equality are well
defined, so undef isn't really necessary for that.
On Mon, 27 Jul 2020, 13:22 adrianv, avm4@cornell.edu wrote:
But which is "safe", generating errors (and thus protecting you from
bugs) or not (and thus "protecting" you from errors)?
Suggest something with a more definitive meaning, e.g.
"allow_mixed_type_comparisons".
Who cares about mixed type comparisons??? Does anybody ever use them? If
we banned them outright would anybody's code break? Anybody have an
example
of a use for a mixed type comparison?
The topic has drifted to the broader topic of undef in general. I
suggested
mixed type comparisons should return undef because that would be consistent
(and the whole issue seemed to be a case of worrying a lot about
consistency). But this leads to the question of undef in general, which
is
a real problem that arises all the time. And that's what Ronaldo was
talking about. Perhaps "$return_undefs" would be a better name?
It does seem like the scoping is bit of a problem, but the simple solution
is that any (library) code that relies on computations with undefs would
need to explicitly set the variable to true anywhere that it mattered.
This
seems kind of messy to me. Also there is no precedent for this type of
control variable in OpenSCAD.
It seems to me that if there's an interest in making OpenSCAD more usable
it
makes more sense to make more of a break. Introduce a new version where
errors are errors, similar to some of the breaking changes made in
2019.05.
If you need to run old code, you run it in compatibility mode where your
whole program runs in the old way, similar to how you can change the
setting
to make warnings into fatal errors. New code will still run in
compatibility mode. You can just work entirely in compatibility mode if
undefs don't bother you. This approach is straight forward and doesn't
lead
to some complicated mess of people running code where parts of it need a
different mode than other parts. It also directly deprecates the old style
and encourages better coding practice moving forward.
Another option would be to make operations on undef issue a warning. Then
old code will still run, but if you want to you can enable the option that
makes warnings into errors.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
As was mentioned by somebody, mixed type comparisons for equality are well
defined, so undef isn't really necessary for that.
On Mon, 27 Jul 2020, 13:22 adrianv, <avm4@cornell.edu> wrote:
> JordanBrown wrote
> >
> > But which is "safe", generating errors (and thus protecting you from
> > bugs) or not (and thus "protecting" you from errors)?
> >
> > Suggest something with a more definitive meaning, e.g.
> > "allow_mixed_type_comparisons".
>
> Who cares about mixed type comparisons??? Does anybody ever use them? If
> we banned them outright would anybody's code break? Anybody have an
> example
> of a use for a mixed type comparison?
>
> The topic has drifted to the broader topic of undef in general. I
> suggested
> mixed type comparisons should return undef because that would be consistent
> (and the whole issue seemed to be a case of worrying a lot about
> consistency). But this leads to the question of undef in general, which
> is
> a real problem that arises all the time. And that's what Ronaldo was
> talking about. Perhaps "$return_undefs" would be a better name?
>
> It does seem like the scoping is bit of a problem, but the simple solution
> is that any (library) code that relies on computations with undefs would
> need to explicitly set the variable to true anywhere that it mattered.
> This
> seems kind of messy to me. Also there is no precedent for this type of
> control variable in OpenSCAD.
>
> It seems to me that if there's an interest in making OpenSCAD more usable
> it
> makes more sense to make more of a break. Introduce a new version where
> errors are errors, similar to some of the breaking changes made in
> 2019.05.
> If you need to run old code, you run it in compatibility mode where your
> whole program runs in the old way, similar to how you can change the
> setting
> to make warnings into fatal errors. New code will still run in
> compatibility mode. You can just work entirely in compatibility mode if
> undefs don't bother you. This approach is straight forward and doesn't
> lead
> to some complicated mess of people running code where parts of it need a
> different mode than other parts. It also directly deprecates the old style
> and encourages better coding practice moving forward.
>
> Another option would be to make operations on undef issue a warning. Then
> old code will still run, but if you want to you can enable the option that
> makes warnings into errors.
>
>
>
>
> --
> Sent from: http://forum.openscad.org/
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
A
adrianv
Mon, Jul 27, 2020 6:38 PM
That we me, actually. I wasn't clear in my last post when I was talking
about comparisons. I meant relative comparisons: <, >, <= and =>. These
are not meaningful between different types (and not necessarily even for
matched types).
And just to be clear, the kinds of operations I'm talking about that produce
undef and frustrate debugging:
list[val] where val>=len(list) or val<0
x[val] where x is not a list
x+y where x and y are different types (including the case that either
argument is undef)
x*y where x and y are incompatible
and so on. All of these things should be errors.
acwest wrote
As was mentioned by somebody, mixed type comparisons for equality are well
defined, so undef isn't really necessary for that.
On Mon, 27 Jul 2020, 13:22 adrianv, <
But which is "safe", generating errors (and thus protecting you from
bugs) or not (and thus "protecting" you from errors)?
Suggest something with a more definitive meaning, e.g.
"allow_mixed_type_comparisons".
Who cares about mixed type comparisons??? Does anybody ever use them?
If
we banned them outright would anybody's code break? Anybody have an
example
of a use for a mixed type comparison?
The topic has drifted to the broader topic of undef in general. I
suggested
mixed type comparisons should return undef because that would be
consistent
(and the whole issue seemed to be a case of worrying a lot about
consistency). But this leads to the question of undef in general, which
is
a real problem that arises all the time. And that's what Ronaldo was
talking about. Perhaps "$return_undefs" would be a better name?
It does seem like the scoping is bit of a problem, but the simple
solution
is that any (library) code that relies on computations with undefs would
need to explicitly set the variable to true anywhere that it mattered.
This
seems kind of messy to me. Also there is no precedent for this type of
control variable in OpenSCAD.
It seems to me that if there's an interest in making OpenSCAD more usable
it
makes more sense to make more of a break. Introduce a new version where
errors are errors, similar to some of the breaking changes made in
2019.05.
If you need to run old code, you run it in compatibility mode where your
whole program runs in the old way, similar to how you can change the
setting
to make warnings into fatal errors. New code will still run in
compatibility mode. You can just work entirely in compatibility mode if
undefs don't bother you. This approach is straight forward and doesn't
lead
to some complicated mess of people running code where parts of it need a
different mode than other parts. It also directly deprecates the old
style
and encourages better coding practice moving forward.
Another option would be to make operations on undef issue a warning.
Then
old code will still run, but if you want to you can enable the option
that
makes warnings into errors.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
That we me, actually. I wasn't clear in my last post when I was talking
about comparisons. I meant relative comparisons: <, >, <= and =>. These
are not meaningful between different types (and not necessarily even for
matched types).
And just to be clear, the kinds of operations I'm talking about that produce
undef and frustrate debugging:
list[val] where val>=len(list) or val<0
x[val] where x is not a list
x+y where x and y are different types (including the case that either
argument is undef)
x*y where x and y are incompatible
and so on. All of these things should be errors.
acwest wrote
> As was mentioned by somebody, mixed type comparisons for equality are well
> defined, so undef isn't really necessary for that.
>
> On Mon, 27 Jul 2020, 13:22 adrianv, <
> avm4@
> > wrote:
>
>> JordanBrown wrote
>> >
>> > But which is "safe", generating errors (and thus protecting you from
>> > bugs) or not (and thus "protecting" you from errors)?
>> >
>> > Suggest something with a more definitive meaning, e.g.
>> > "allow_mixed_type_comparisons".
>>
>> Who cares about mixed type comparisons??? Does anybody ever use them?
>> If
>> we banned them outright would anybody's code break? Anybody have an
>> example
>> of a use for a mixed type comparison?
>>
>> The topic has drifted to the broader topic of undef in general. I
>> suggested
>> mixed type comparisons should return undef because that would be
>> consistent
>> (and the whole issue seemed to be a case of worrying a lot about
>> consistency). But this leads to the question of undef in general, which
>> is
>> a real problem that arises all the time. And that's what Ronaldo was
>> talking about. Perhaps "$return_undefs" would be a better name?
>>
>> It does seem like the scoping is bit of a problem, but the simple
>> solution
>> is that any (library) code that relies on computations with undefs would
>> need to explicitly set the variable to true anywhere that it mattered.
>> This
>> seems kind of messy to me. Also there is no precedent for this type of
>> control variable in OpenSCAD.
>>
>> It seems to me that if there's an interest in making OpenSCAD more usable
>> it
>> makes more sense to make more of a break. Introduce a new version where
>> errors are errors, similar to some of the breaking changes made in
>> 2019.05.
>> If you need to run old code, you run it in compatibility mode where your
>> whole program runs in the old way, similar to how you can change the
>> setting
>> to make warnings into fatal errors. New code will still run in
>> compatibility mode. You can just work entirely in compatibility mode if
>> undefs don't bother you. This approach is straight forward and doesn't
>> lead
>> to some complicated mess of people running code where parts of it need a
>> different mode than other parts. It also directly deprecates the old
>> style
>> and encourages better coding practice moving forward.
>>
>> Another option would be to make operations on undef issue a warning.
>> Then
>> old code will still run, but if you want to you can enable the option
>> that
>> makes warnings into errors.
>>
>>
>>
>>
>> --
>> 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/
M
MichaelAtOz
Tue, Jul 28, 2020 8:31 AM
The current undef behaviour allows you to handle errors.
You can detect that the result is undef and take appropriate action.
This is particularly useful when you don't have predefined data, or optional
parameters.
undef causing an error would prevent that, even a warning, it is already
problematic with warnings in for() loops or recursive code flooding the
console.
Loaded design 'C:/Users/MeB/Documents/3D-REPRAP/Things/My
Things/badge.scad'.
Parsing design (AST generation)...
WARNING: Letter_height was assigned on line 7 but was overwritten on line 78
WARNING: kh was assigned on line 8 but was overwritten on line 128
Compiling design (CSG Tree generation)...
ECHO: "OS V=20190500"
ECHO: "OSLIB/Write/write.scad"
WARNING: search term not found: "B", in file badge.scad, line 93
WARNING: search term not found: "l", in file badge.scad, line 93
WARNING: search term not found: "a", in file badge.scad, line 93
WARNING: search term not found: "c", in file badge.scad, line 93
WARNING: search term not found: "k", in file badge.scad, line 93
WARNING: search term not found: "o", in file badge.scad, line 93
WARNING: search term not found: "s", in file badge.scad, line 93
WARNING: search term not found: "e", in file badge.scad, line 93
Compiling design (CSG Products generation)...
Geometries in cache: 129
Geometry cache size in bytes: 852176
CGAL Polyhedrons in cache: 1
CGAL cache size in bytes: 1650000
Compiling design (CSG Products normalization)...
Compiling background (1 CSG Trees)...
Normalized CSG tree has 93 elements
Compile and preview finished.
Total rendering time: 0 hours, 0 minutes, 23 seconds
The first two are valid overwrites to overcome a include<> default
assignment.
The using search to not find something is perfectly valid logic, just lucky
in this case the text is short.
Admin - email* me if you need anything, or if I've done something stupid...
- click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
--
Sent from: http://forum.openscad.org/
The current undef behaviour allows you to handle errors.
You can detect that the result is undef and take appropriate action.
This is particularly useful when you don't have predefined data, or optional
parameters.
undef causing an error would prevent that, even a warning, it is already
problematic with warnings in for() loops or recursive code flooding the
console.
-------------------------------
Loaded design 'C:/Users/MeB/Documents/3D-REPRAP/Things/My
Things/badge.scad'.
Parsing design (AST generation)...
WARNING: Letter_height was assigned on line 7 but was overwritten on line 78
WARNING: kh was assigned on line 8 but was overwritten on line 128
Compiling design (CSG Tree generation)...
ECHO: "OS V=20190500"
ECHO: "OSLIB/Write/write.scad"
WARNING: search term not found: "B", in file badge.scad, line 93
WARNING: search term not found: "l", in file badge.scad, line 93
WARNING: search term not found: "a", in file badge.scad, line 93
WARNING: search term not found: "c", in file badge.scad, line 93
WARNING: search term not found: "k", in file badge.scad, line 93
WARNING: search term not found: "o", in file badge.scad, line 93
WARNING: search term not found: "s", in file badge.scad, line 93
WARNING: search term not found: "e", in file badge.scad, line 93
Compiling design (CSG Products generation)...
Geometries in cache: 129
Geometry cache size in bytes: 852176
CGAL Polyhedrons in cache: 1
CGAL cache size in bytes: 1650000
Compiling design (CSG Products normalization)...
Compiling background (1 CSG Trees)...
Normalized CSG tree has 93 elements
Compile and preview finished.
Total rendering time: 0 hours, 0 minutes, 23 seconds
-----------------------------
The first two are valid overwrites to overcome a include<> default
assignment.
The using search to not find something is perfectly valid logic, just lucky
in this case the text is short.
-----
Admin - email* me if you need anything, or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
--
Sent from: http://forum.openscad.org/
NH
nop head
Tue, Jul 28, 2020 8:52 AM
Overwriting a value from an include should not generate a warning. You
should only get them if you assign twice in the same file and it looks like
that is what you have.
I do find with new versions of OpenSCAD I have to add more code to get rid
of warnings. It used to be OK to have zero or negative dimensions for
primitives, they just disappeared, now I have to guard then with ifs.
It used to be OK to pass a scalar to len() and was documented to return
undef, now it gives a warning and I have to guard it with is_list() and
make my code not compatible with older versions.
There is current PR to make accesses off the end of a list a warning, so I
would have to guard all my if(list[n]) statements because I have variable
length object descriptions.
Perhaps I am just lazy but I like brief languages and it doesn't seem like
progress to have to add more and more code to do the same thing.
On Tue, 28 Jul 2020 at 09:32, MichaelAtOz oz.at.michael@gmail.com wrote:
The current undef behaviour allows you to handle errors.
You can detect that the result is undef and take appropriate action.
This is particularly useful when you don't have predefined data, or
optional
parameters.
undef causing an error would prevent that, even a warning, it is already
problematic with warnings in for() loops or recursive code flooding the
console.
Loaded design 'C:/Users/MeB/Documents/3D-REPRAP/Things/My
Things/badge.scad'.
Parsing design (AST generation)...
WARNING: Letter_height was assigned on line 7 but was overwritten on line
78
WARNING: kh was assigned on line 8 but was overwritten on line 128
Compiling design (CSG Tree generation)...
ECHO: "OS V=20190500"
ECHO: "OSLIB/Write/write.scad"
WARNING: search term not found: "B", in file badge.scad, line 93
WARNING: search term not found: "l", in file badge.scad, line 93
WARNING: search term not found: "a", in file badge.scad, line 93
WARNING: search term not found: "c", in file badge.scad, line 93
WARNING: search term not found: "k", in file badge.scad, line 93
WARNING: search term not found: "o", in file badge.scad, line 93
WARNING: search term not found: "s", in file badge.scad, line 93
WARNING: search term not found: "e", in file badge.scad, line 93
Compiling design (CSG Products generation)...
Geometries in cache: 129
Geometry cache size in bytes: 852176
CGAL Polyhedrons in cache: 1
CGAL cache size in bytes: 1650000
Compiling design (CSG Products normalization)...
Compiling background (1 CSG Trees)...
Normalized CSG tree has 93 elements
Compile and preview finished.
Total rendering time: 0 hours, 0 minutes, 23 seconds
The first two are valid overwrites to overcome a include<> default
assignment.
The using search to not find something is perfectly valid logic, just lucky
in this case the text is short.
Admin - email* me if you need anything, or if I've done something
stupid...
- click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the
Public Domain; to the extent possible under law, I have waived all
copyright and related or neighbouring rights to this work. Obviously
inclusion of works of previous authors is not included in the above.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Overwriting a value from an include should not generate a warning. You
should only get them if you assign twice in the same file and it looks like
that is what you have.
I do find with new versions of OpenSCAD I have to add more code to get rid
of warnings. It used to be OK to have zero or negative dimensions for
primitives, they just disappeared, now I have to guard then with ifs.
It used to be OK to pass a scalar to len() and was documented to return
undef, now it gives a warning and I have to guard it with is_list() and
make my code not compatible with older versions.
There is current PR to make accesses off the end of a list a warning, so I
would have to guard all my if(list[n]) statements because I have variable
length object descriptions.
Perhaps I am just lazy but I like brief languages and it doesn't seem like
progress to have to add more and more code to do the same thing.
On Tue, 28 Jul 2020 at 09:32, MichaelAtOz <oz.at.michael@gmail.com> wrote:
> The current undef behaviour allows you to handle errors.
> You can detect that the result is undef and take appropriate action.
> This is particularly useful when you don't have predefined data, or
> optional
> parameters.
>
> undef causing an error would prevent that, even a warning, it is already
> problematic with warnings in for() loops or recursive code flooding the
> console.
>
> -------------------------------
>
> Loaded design 'C:/Users/MeB/Documents/3D-REPRAP/Things/My
> Things/badge.scad'.
> Parsing design (AST generation)...
> WARNING: Letter_height was assigned on line 7 but was overwritten on line
> 78
> WARNING: kh was assigned on line 8 but was overwritten on line 128
> Compiling design (CSG Tree generation)...
> ECHO: "OS V=20190500"
> ECHO: "OSLIB/Write/write.scad"
> WARNING: search term not found: "B", in file badge.scad, line 93
> WARNING: search term not found: "l", in file badge.scad, line 93
> WARNING: search term not found: "a", in file badge.scad, line 93
> WARNING: search term not found: "c", in file badge.scad, line 93
> WARNING: search term not found: "k", in file badge.scad, line 93
> WARNING: search term not found: "o", in file badge.scad, line 93
> WARNING: search term not found: "s", in file badge.scad, line 93
> WARNING: search term not found: "e", in file badge.scad, line 93
> Compiling design (CSG Products generation)...
> Geometries in cache: 129
> Geometry cache size in bytes: 852176
> CGAL Polyhedrons in cache: 1
> CGAL cache size in bytes: 1650000
> Compiling design (CSG Products normalization)...
> Compiling background (1 CSG Trees)...
> Normalized CSG tree has 93 elements
> Compile and preview finished.
> Total rendering time: 0 hours, 0 minutes, 23 seconds
>
> -----------------------------
>
> The first two are valid overwrites to overcome a include<> default
> assignment.
> The using search to not find something is perfectly valid logic, just lucky
> in this case the text is short.
>
>
>
> -----
> Admin - email* me if you need anything, or if I've done something
> stupid...
>
> * click on my MichaelAtOz label, there is a link to email me.
>
> Unless specifically shown otherwise above, my contribution is in the
> Public Domain; to the extent possible under law, I have waived all
> copyright and related or neighbouring rights to this work. Obviously
> inclusion of works of previous authors is not included in the above.
>
> --
> Sent from: http://forum.openscad.org/
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
M
MichaelAtOz
Tue, Jul 28, 2020 9:09 AM
Overwriting a value from an include should not generate a warning. You
should only get them if you assign twice in the same file and it looks
like
that is what you have.
If I want to overwrite the default var 't' which is set in the include<>.
with an expression in the main program, such as
t=Letter_height+kh-0.1;
then Letter_height & kh must be in scope before the include<>, hence they
need to be assigned.
But they are assigned real values after the include<> in the main body of a
customizer, after the user selects a value.
Admin - email* me if you need anything, or if I've done something stupid...
- click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
--
Sent from: http://forum.openscad.org/
nophead wrote
> Overwriting a value from an include should not generate a warning. You
> should only get them if you assign twice in the same file and it looks
> like
> that is what you have.
If I want to overwrite the default var 't' which is set in the include<>.
with an expression in the main program, such as
t=Letter_height+kh-0.1;
then Letter_height & kh must be in scope before the include<>, hence they
need to be assigned.
But they are assigned real values after the include<> in the main body of a
customizer, after the user selects a value.
-----
Admin - email* me if you need anything, or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
--
Sent from: http://forum.openscad.org/
