What happened to booleans?
Locked
12345
12345
 
|
However, with an implementation that follows rules 1 and 2 of my previous
post, you still can do such a generic type check by writing: function is_same_type(op1, o2) = (op1==op2)!=(op1!=op2); -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
|
|
Another issue of allowing "undef" as result of a logical operation:
What is the value of (false == undef)? It obviously can't be "true", otherwise you could not distinguish between these two values, and if it is "false" you get the following contradiction. The expression (1 == "1") == false would evaluate to undef == false and this evalulates to false (or undef?). However "true" is expected. This is all a can of worms. -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
|
If I may add something to the discussion, I would really like booleans to be
booleans. Also, I LIKE error messages if I am doing something that just does not make sense. As someone once said, the language should talk to you (meaning the language gives useful error messages rather than assume nonsense and do unexpected things). 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. Microsoft languages like Visual Basic used to have a "feature" called "Null progagation". This meant that if you used a Null value (which would also be undef) anywhere in an expression, the outcome of that expression would also be Null. This off course broke all boolean operations, because Null would be treated as false. Yes, ("Some value" != null) would thus be treated as false and even (! null) would be treated the same as null, as false. This 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. -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
|
|
In reply to this post by Parkinbot
Parkinbot wrote
> Another issue of allowing "undef" as result of a logical operation: > > What is the value of > > (false == undef)? > > It obviously can't be "true", otherwise you could not distinguish between > these two values, and if it is "false" you get the following > contradiction. > The expression > > (1 == "1") == false > > would evaluate to > > undef == false > > and this evalulates to false (or undef?). However "true" is expected. > This is all a can of worms. I am not sure what gave you the idea that equality or inequality testing should result in undef under any circumstances. That would be very bad. Equality testing is well-defined for any pair of objects, they are either the same (in which case you return true) or they are different (in which case you return false). Things with different types are clearly different. Inequality tests are different. They are undefined (meaningless) when given arguments of different type. Hence my proposal was simply that inequality tests (<, >, <=, =>) result in undef when given mismatched types. I'd say printing an error message would be even better. -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
|
|
In reply to this post by MathLover
MathLover wrote
> Microsoft languages like Visual Basic used to have a "feature" called > "Null > progagation". This meant that if you used a Null value (which would also > be > undef) anywhere in an expression, the outcome of that expression would > also > be Null. This off course broke all boolean operations, because Null would > be > treated as false. > > Yes, ("Some value" != null) would thus be treated as false and even (! > null) > would be treated the same as null, as false. > > This 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. OpenSCAD already has this feature with undef. And yes indeed, it makes debugging a nightmare. Right now any invalid operation---except for a boolean comparison---returns undef. And any operation containing an undef---except for equality and inequality testing---produces an undef as a result. Index out of bounds? You get undef instead of an error. It would be a thousand times better if all of these things produced immediate error messages. So yes, it would make sense for boolean operations on mismatched types to produce an error message. The reason I didn't suggest that as a possibility is consistency: all the other bogus operations in OpenSCAD produce undef instead of an error. -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
|
|
In reply to this post by MathLover
Perhaps the solution is to have two types of boolean - a true boolean,
and a false boolean. The true boolean only has two members, true and false, a false boolean can have as many members as you wish, but you define them, and their relationship to each other. A true boolean can only have too operators '==' and '!=', a false boolean can have whatever operators you want. , but you'll need to define your own hierarchy. Basically, in this scenario, a false boolean is everything else, which may be further divided into strings, floating point numbers, colours, whatever. 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. I guess the real concern is that openscad programs are interpreted, not compiled, so older programs would not work properly in a newer interpreter. Perhaps an interpreter version number could be included in the data. (sort of like Microsoft .net asks for versions, but that is hopefully backwards compatible). Whatever is decided, not everybody will be happy, but at least we're trying. Best wishes, Ray On 27/07/2020 12:41, MathLover wrote: > If I may add something to the discussion, I would really like booleans to be > booleans. Also, I LIKE error messages if I am doing something that just does > not make sense. As someone once said, the language should talk to you > (meaning the language gives useful error messages rather than assume > nonsense and do unexpected things). > > 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. > > Microsoft languages like Visual Basic used to have a "feature" called "Null > progagation". This meant that if you used a Null value (which would also be > undef) anywhere in an expression, the outcome of that expression would also > be Null. This off course broke all boolean operations, because Null would be > treated as false. > > Yes, ("Some value" != null) would thus be treated as false and even (! null) > would be treated the same as null, as false. > > This 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. > > > > -- > 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 |
|
|
In reply to this post by adrianv
'undef' is a nightmare indeed. But it is not the only one: there are 'nan' and 'inf' too which can turn into undef in the next operation. Should they be eradicated? Certainly not, they have their place, at least 'undef' has. To avoid nightmares, to have peace of mind, we need discipline. And consistent emergence of these values in operations. What should be the result of a polygon triangulation function if the polygon has self-intersection? I would say that 'undef' (meaning "no solution possible") is the best option. To generate an error or an empty list (or some other signaling value) could be an alternative. The first seems radical because it is so hard to find whether a polygon has self-intersection as trying to triangulate it. The triangulation function would be the check! The other options are falsely safe because a careless coder may get in trouble later trying to access an element of an empty list, for instance. There is no way to protect a careless code.That means we need to always be careful with operations that might have "unusual" results. That is a place for 'undef'. Definitely an inequality expression involving pears and apples should result in 'undef' (as we don't have a complete type order). That is consistent with the result of trying to divide pears by a number or access an array component of a single value (and that doesn't mean 'undef' is another number value or another list) (*). But, yes, a test, either in an if() or in a ternary expression, of 'undef' should be an error. If you don't generate the error, the propagation will be uncontrollable. That is the devil's place. 'undef' should not be taken as 'false'. Why not allow the 'undef' value of an inequality be set to a variable? Or checked against 'undef' ? 'undef' is 'undef'. (*) Dividing or multiplying a numerical vector by a scalar is a well defined operation on linear algebra. There are good well defined exceptions to the rule that 'pears' can't mix with 'apples'. _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
|
If testing undef was an error it would break a lot of my code. I often use if(list[n]) to mean if the list has a non zero nth element. If the list doesn't have that element I get undef, which is false. I would have to guard the test with a check of the length, which is less efficient and more verbose. On Mon, 27 Jul 2020 at 15:37, Ronaldo Persiano <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
|
|
In reply to this post by Ronaldo
I agree that undef is a useful concept and would be great if OpenSCAD
operated with it differently. What should happen is that any operation involving an undef is an immediate fatal error, producing an error message---with the exception of the two tests x==undef and x!=undef. If OpenSCAD worked like this, then I would feel comfortable using undef to report a variety of results where "undefined" is actually the right answer, such as the previously mentioned intersection point of parallel lines, or the example below of self-intersecting polygons. Instead undef is actually the generic signal that the programmer made a mistake. In this case, I feel it is essential to avoid ever intentionally producing undef because then you can't distinguish between an error and a case of valid return. Suppose your triangulation code has a bug and sometimes returns undef as a result of this bug. You can't distinguish that situation from the case that the triangulation identified a self-intersection. If errors produced an error message and program halt then a mistake in your code is easily distinguished from the undef return, which happens in the self-intersecting polygon case. But since errors produce undef, it is critical that in any code, one tries to handle all the errors and never produce undef intentionally as an output. In this way we know that if we see undef, there's a programming bug. Otherwise, we can't distinguish the case of a programming bug from a valid "undefined" return value. Ronaldo wrote > 'undef' is a nightmare indeed. But it is not the only one: there are 'nan' > and 'inf' too which can turn into undef in the next operation. Should they > be eradicated? Certainly not, they have their place, at least 'undef' has. > To avoid nightmares, to have peace of mind, we need discipline. And > consistent emergence of these values in operations. > > What should be the result of a polygon triangulation function if the > polygon has self-intersection? I would say that 'undef' (meaning "no > solution possible") is the best option. To generate an error or an empty > list (or some other signaling value) could be an alternative. The first > seems radical because it is so hard to find whether a polygon has > self-intersection as trying to triangulate it. The triangulation function > would be the check! The other options are falsely safe because a careless > coder may get in trouble later trying to access an element of an empty > list, for instance. There is no way to protect a careless code.That means > we need to always be careful with operations that might have "unusual" > results. That is a place for 'undef'. > > Definitely an inequality expression involving pears and apples should > result in 'undef' (as we don't have a complete type order). That is > consistent with the result of trying to divide pears by a number or access > an array component of a single value (and that doesn't mean 'undef' is > another number value or another list) (*). But, yes, a test, either in an > if() or in a ternary expression, of 'undef' should be an error. If you > don't generate the error, the propagation will be uncontrollable. That is > the devil's place. 'undef' should not be taken as 'false'. Why not allow > the 'undef' value of an inequality be set to a variable? Or checked > against > 'undef' ? *'undef' is 'undef'*. -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
|
|
In reply to this post by nophead
The efficiency argument is weak in this case. I tested the run time for
len(foo) >=1001 ? foo[1000] : -1 compared to foo[1000] ? foo[1000] : -1 where foo had length smaller than 1001. I ran this 10 millions times. The run time for the length check was 1 microsecond. The undef test shaved this down to 0.7 microseconds. I cannot conceive of a way that a different of 0.3 microseconds is important in an OpenSCAD program. The problem of your code being broken is the serious one. Personally if I had a body of code written that way and the option to change OpenSCAD to produce errors with undef I'd jump for errors in a heartbeat. 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. nophead wrote > If testing undef was an error it would break a lot of my code. > > I often use if(list[n]) to mean if the list has a non zero nth element. If > the list doesn't have that element I get undef, which is false. I would > have to guard the test with a check of the length, which is less efficient > and more verbose. > > > On Mon, 27 Jul 2020 at 15:37, Ronaldo Persiano < > rcmpersiano@ > > > wrote: > >> 'undef' is a nightmare indeed. But it is not the only one: there are >> 'nan' >> and 'inf' too which can turn into undef in the next operation. Should >> they >> be eradicated? Certainly not, they have their place, at least 'undef' >> has. >> To avoid nightmares, to have peace of mind, we need discipline. And >> consistent emergence of these values in operations. >> >> What should be the result of a polygon triangulation function if the >> polygon has self-intersection? I would say that 'undef' (meaning "no >> solution possible") is the best option. To generate an error or an empty >> list (or some other signaling value) could be an alternative. The first >> seems radical because it is so hard to find whether a polygon has >> self-intersection as trying to triangulate it. The triangulation function >> would be the check! The other options are falsely safe because a careless >> coder may get in trouble later trying to access an element of an empty >> list, for instance. There is no way to protect a careless code.That means >> we need to always be careful with operations that might have "unusual" >> results. That is a place for 'undef'. >> >> Definitely an inequality expression involving pears and apples should >> result in 'undef' (as we don't have a complete type order). That is >> consistent with the result of trying to divide pears by a number or >> access >> an array component of a single value (and that doesn't mean 'undef' is >> another number value or another list) (*). But, yes, a test, either in an >> if() or in a ternary expression, of 'undef' should be an error. If you >> don't generate the error, the propagation will be uncontrollable. That is >> the devil's place. 'undef' should not be taken as 'false'. Why not allow >> the 'undef' value of an inequality be set to a variable? Or checked >> against >> 'undef' ? *'undef' is 'undef'*. >> >> (*) Dividing or multiplying a numerical vector by a scalar is a well >> defined operation on linear algebra. There are good well defined >> exceptions to the rule that 'pears' can't mix with 'apples'. >> >> _______________________________________________ >> 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 |
|
|
The amount of 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. _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
|
|
In reply to this post by MathLover
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:
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.
_______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
|
|
In reply to this post by mondo
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.) _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
|
|
In reply to this post by Ronaldo
On 7/27/2020 9:08 AM, Ronaldo Persiano
wrote:
$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". _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.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/ _______________________________________________ OpenSCAD mailing list [hidden email] 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, <[hidden email]> wrote: JordanBrown wrote _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
|
|
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/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
Administrator
|
In reply to this post by adrianv
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 [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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. |
|
|
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 <[hidden email]> wrote: The current undef behaviour allows you to handle errors. _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
|
Administrator
|
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/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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. |
«
Return to OpenSCAD
|
1 view|%1 views
| Free forum by Nabble | Edit this page |