reporting errors and warnings
It appears that when writing my own functions, I have two ways of creating
error or warning messages. I can use assert to make an error by writing:
dummy_variable = assert(condition, "Error message text"),
which sort of works. It's annoying that I need the dummy variable. And
it's also clutter that the condition gets displayed to the user. But for
warning messages, it appears that the advice is to use echo() and make the
text yellow. This seems ineffective because the statistics at the end of a
render always scroll off any text actually produced by the code, so I'm
reliant on that report at the top that tells me I had warnings so I know to
go look for them.
It would be nice if there was a way to make real error and warning messages,
e.g. as a flag to the echo() command, or as a new command that could
generate errors and warnings. Is there any plan to add this feature?
--
Sent from: http://forum.openscad.org/
On 16.03.19 16:13, adrianv wrote:
It's annoying that I need the dummy variable.
Why would you need that?
module fail() {
assert(false, "meh");
cube();
}
fail();
gives me a very nice
ERROR: Assertion 'false': "meh" failed in file tp, line 2
TRACE: called by 'assert', in file tp, line 2.
TRACE: called by 'fail', in file tp, line 6.
ciao,
Torsten.
It isn't ideal but we may get a warning count with something like:
xpto = condition ? echo( xpto, "your warning message") 0: 0
where xpto isn't used anywhere.
A sábado, 16/03/2019, 15:14, adrianv avm4@cornell.edu escreveu:
It appears that when writing my own functions, I have two ways of creating
error or warning messages. I can use assert to make an error by writing:
dummy_variable = assert(condition, "Error message text"),
which sort of works. It's annoying that I need the dummy variable. And
it's also clutter that the condition gets displayed to the user. But for
warning messages, it appears that the advice is to use echo() and make the
text yellow. This seems ineffective because the statistics at the end of a
render always scroll off any text actually produced by the code, so I'm
reliant on that report at the top that tells me I had warnings so I know to
go look for them.
It would be nice if there was a way to make real error and warning
messages,
e.g. as a flag to the echo() command, or as a new command that could
generate errors and warnings. Is there any plan to add this feature?
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3 wrote
On 16.03.19 16:13, adrianv wrote:
It's annoying that I need the dummy variable.
Why would you need that?
module fail() {
assert(false, "meh");
cube();
}
fail();
gives me a very nice
ERROR: Assertion 'false': "meh" failed in file tp, line 2
TRACE: called by 'assert', in file tp, line 2.
TRACE: called by 'fail', in file tp, line 6.
You don't get the message because you wrote a module instead of a function.
If I write a function:
function fail() = let(
assert(true, "It failed"))
0;
a=fail();
then I get
Loaded design '/home/adrian/scad/a.scad'.
Compiling design (CSG Tree generation)...
WARNING: Assignment without variable name undef, in file a.scad, line 1
Compiling design (CSG Products generation)...
Geometries in cache: 1
Geometry cache size in bytes: 1360
CGAL Polyhedrons in cache: 0
CGAL cache size in bytes: 0
Compiling design (CSG Products normalization)...
Normalized CSG tree has 0 elements
Compile and preview finished.
Total rendering time: 0 hours, 0 minutes, 0 seconds
The warning appears even when the assert succeeds---I just always get that
warning. So I need a dummy variable on every assert call. I need them on
echo calls within function as well.
--
Sent from: http://forum.openscad.org/
function fail() = let(
assert(true, "It failed"))
0;
a=fail();
WARNING: Assignment without variable name undef, in file a.scad, line 1
Yes, you get a warning because that code is assigning a
positional variable in let which is useless as there is
no way to access it afterwards.
I would use the function assert() like that:
function f(i) = let(x = assert(i > 1, "It failed") i) x * x;
echo(f1 = f(3));
echo(f2 = f(-3));
ciao,
Torsten.
tp3 wrote
Yes, you get a warning because that code is assigning a
positional variable in let which is useless as there is
no way to access it afterwards.
I would use the function assert() like that:
function f(i) = let(x = assert(i > 1, "It failed") i) x * x;
echo(f1 = f(3));
echo(f2 = f(-3));
I understand the behavior. But it's still annoying.
I'm not sure I understand your suggestion. It looks like you're suggesting
entangling the assert statement up with a nearby assignment. I think from a
readability and maintainability perspective, this is worse than using dummy
variables.
Code example:
function roundcorners(path, curve, type, all=undef, closed=true) =
let(
default_curvature = 1, // default curvature for "smooth" curves
dummy1=assert(curve=="smooth" || curve=="circle", "Unknown curve type in
roundcorners"),
typeok = type == "cut" || (curve=="circle" && type=="radius") ||
(curve=="smooth" && type=="joint"),
dummy2=assert(typeok, curve=="circle" ? "In roundcorners 'circle' curve
requires 'type' of 'radius' or 'cut'":
"In roundcorners 'smooth' curve
requires 'type' of 'joint' or 'cut'"),
<many more lines of code follow>
Having to use the dummy variables is a nuisance but if I had to take my pick
I'd prefer a real warning/error generating command over a workaround for
this, which seems like it might be syntactically complex. The best idea I
had for a workaround would be an official reusable dummy variable that
doesn't produce the "ignoring duplicate variable" warning, because the main
complication here is having to make sure all the dummy variables have unique
names.
--
Sent from: http://forum.openscad.org/
You don't need a dummy variable because assert can prefix an expression.
E.g.
let (nb = norm(binormal), x = assert(nb > 0.00001, "first three
points are colinear") nb))
On Sat, 16 Mar 2019 at 16:24, adrianv avm4@cornell.edu wrote:
tp3 wrote
Yes, you get a warning because that code is assigning a
positional variable in let which is useless as there is
no way to access it afterwards.
I would use the function assert() like that:
function f(i) = let(x = assert(i > 1, "It failed") i) x * x;
echo(f1 = f(3));
echo(f2 = f(-3));
I understand the behavior. But it's still annoying.
I'm not sure I understand your suggestion. It looks like you're suggesting
entangling the assert statement up with a nearby assignment. I think from
a
readability and maintainability perspective, this is worse than using dummy
variables.
Code example:
function roundcorners(path, curve, type, all=undef, closed=true) =
let(
default_curvature = 1, // default curvature for "smooth" curves
dummy1=assert(curve=="smooth" || curve=="circle", "Unknown curve type
in
roundcorners"),
typeok = type == "cut" || (curve=="circle" && type=="radius") ||
(curve=="smooth" && type=="joint"),
dummy2=assert(typeok, curve=="circle" ? "In roundcorners 'circle' curve
requires 'type' of 'radius' or 'cut'":
"In roundcorners 'smooth' curve
requires 'type' of 'joint' or 'cut'"),
<many more lines of code follow>
Having to use the dummy variables is a nuisance but if I had to take my
pick
I'd prefer a real warning/error generating command over a workaround for
this, which seems like it might be syntactically complex. The best idea I
had for a workaround would be an official reusable dummy variable that
doesn't produce the "ignoring duplicate variable" warning, because the main
complication here is having to make sure all the dummy variables have
unique
names.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Yes, like nophead wrote, you should not need that.
Here's a more detailed example:
function f(a, b) =
assert(a < 0, "wrong a") // assert input
assert(b > 0, "wrong b") // assert input
let (c = a + b) // derive a new value from input
assert(c != 0, "wrong c") // assert derived value
a * b; // calculate
echo(f(-3, 5)); // ECHO: -15
//echo(f(3, 6)); // ERROR: Assertion '(a < 0)': "wrong a" failed in file tp, line 3
//echo(f(-4, -3)); // ERROR: Assertion '(b > 0)': "wrong b" failed in file tp, line 4
//echo(f(-1, 1)); // ERROR: Assertion '(c != 0)': "wrong c" failed in file tp, line 6
ciao,
Torsten.
tp3 wrote
Yes, like nophead wrote, you should not need that.
Here's a more detailed example:
function f(a, b) =
assert(a < 0, "wrong a") // assert input
assert(b > 0, "wrong b") // assert input
let (c = a + b) // derive a new value from input
assert(c != 0, "wrong c") // assert derived value
a * b; // calculate
This is a great solution to the problem. I don't like nophead's solution
because it mingles the computation into the assert in a way that's hard to
read, but this approach is clear. It didn't occur to me that assert could
take children. (This isn't mentioned in the manual at all.) I do wish
that let would allow a dangling comma on the last expression, which would
make it easier to insert and delete assignments.
But regarding the other issue, I still think it would be nice if there was a
way to generate warning and error messages from my code, without funny
business. It would be more clear to a user to see
ERROR: Value 'a' must be larger than zero in file tp, line 3
than
ERROR: Assertion '(a>0)': "Value 'a' must be larger than zero" failed in
file tp, line 3.
And of course there's no mechanism at all to generate a warning.
--
Sent from: http://forum.openscad.org/
Perhaps assert should be changed to a warning and if you want it to stop
like an error then you select stop on first warning.
On Sat, 16 Mar 2019 at 17:59, adrianv avm4@cornell.edu wrote:
tp3 wrote
Yes, like nophead wrote, you should not need that.
Here's a more detailed example:
function f(a, b) =
assert(a < 0, "wrong a") // assert input
assert(b > 0, "wrong b") // assert input
let (c = a + b) // derive a new value from input
assert(c != 0, "wrong c") // assert derived value
a * b; // calculate
This is a great solution to the problem. I don't like nophead's solution
because it mingles the computation into the assert in a way that's hard to
read, but this approach is clear. It didn't occur to me that assert could
take children. (This isn't mentioned in the manual at all.) I do wish
that let would allow a dangling comma on the last expression, which would
make it easier to insert and delete assignments.
But regarding the other issue, I still think it would be nice if there was
a
way to generate warning and error messages from my code, without funny
business. It would be more clear to a user to see
ERROR: Value 'a' must be larger than zero in file tp, line 3
than
ERROR: Assertion '(a>0)': "Value 'a' must be larger than zero" failed in
file tp, line 3.
And of course there's no mechanism at all to generate a warning.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Are there any other languages that use assert like you propose? I can't
think of any where assert doesn't bring things to a full stop. I don't
think OpenSCAD should be the first.
On 3/16/19 1:58 PM, nop head wrote:
Perhaps assert should be changed to a warning and if you want it to
stop like an error then you select stop on first warning.
On Sat, 16 Mar 2019 at 17:59, adrianv <avm4@cornell.edu
mailto:avm4@cornell.edu> wrote:
tp3 wrote
Yes, like nophead wrote, you should not need that.
Here's a more detailed example:
function f(a, b) =
assert(a < 0, "wrong a") // assert input
assert(b > 0, "wrong b") // assert input
let (c = a + b) // derive a new value from input
assert(c != 0, "wrong c") // assert derived value
a * b; // calculate
This is a great solution to the problem. I don't like nophead's
solution
because it mingles the computation into the assert in a way that's
hard to
read, but this approach is clear. It didn't occur to me that
assert could
take children. (This isn't mentioned in the manual at all.) I do
wish
that let would allow a dangling comma on the last expression,
which would
make it easier to insert and delete assignments.
But regarding the other issue, I still think it would be nice if
there was a
way to generate warning and error messages from my code, without funny
business. It would be more clear to a user to see
ERROR: Value 'a' must be larger than zero in file tp, line 3
than
ERROR: Assertion '(a>0)': "Value 'a' must be larger than zero"
failed in
file tp, line 3.
And of course there's no mechanism at all to generate a warning.
--
Sent from: http://forum.openscad.org/
_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org>
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Well I suppose the alternative is to add a warning statement and function,
which duplicates all the same logic.
On Sat, 16 Mar 2019 at 19:15, Joe Francis joe@lostapathy.com wrote:
Are there any other languages that use assert like you propose? I can't
think of any where assert doesn't bring things to a full stop. I don't
think OpenSCAD should be the first.
On 3/16/19 1:58 PM, nop head wrote:
Perhaps assert should be changed to a warning and if you want it to stop
like an error then you select stop on first warning.
On Sat, 16 Mar 2019 at 17:59, adrianv avm4@cornell.edu wrote:
tp3 wrote
Yes, like nophead wrote, you should not need that.
Here's a more detailed example:
function f(a, b) =
assert(a < 0, "wrong a") // assert input
assert(b > 0, "wrong b") // assert input
let (c = a + b) // derive a new value from input
assert(c != 0, "wrong c") // assert derived value
a * b; // calculate
This is a great solution to the problem. I don't like nophead's solution
because it mingles the computation into the assert in a way that's hard to
read, but this approach is clear. It didn't occur to me that assert could
take children. (This isn't mentioned in the manual at all.) I do wish
that let would allow a dangling comma on the last expression, which would
make it easier to insert and delete assignments.
But regarding the other issue, I still think it would be nice if there
was a
way to generate warning and error messages from my code, without funny
business. It would be more clear to a user to see
ERROR: Value 'a' must be larger than zero in file tp, line 3
than
ERROR: Assertion '(a>0)': "Value 'a' must be larger than zero" failed in
file tp, line 3.
And of course there's no mechanism at all to generate a warning.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing listDiscuss@lists.openscad.orghttp://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I think that makes a lot more sense.
If a library author needs a way to bail out if something is hopelessly
wrong, that capability shouldn't get taken away because a user
preference says "just treat asserts like warnings". Even if that
library author is just me from 6 months ago :).
I do this all the time to verify the relationship between parameters.
If something won't work, I want it to fail immediately rather than spend
a couple minutes rendering something that doesn't make any sense.
Putting together a warning() method like that should be doable in
userspace, too.
On 3/16/19 2:17 PM, nop head wrote:
Well I suppose the alternative is to add a warning statement and
function, which duplicates all the same logic.
On Sat, 16 Mar 2019 at 19:15, Joe Francis <joe@lostapathy.com
mailto:joe@lostapathy.com> wrote:
Are there any other languages that use assert like you propose? I
can't think of any where assert doesn't bring things to a full
stop. I don't think OpenSCAD should be the first.
On 3/16/19 1:58 PM, nop head wrote:
Perhaps assert should be changed to a warning and if you want it
to stop like an error then you select stop on first warning.
On Sat, 16 Mar 2019 at 17:59, adrianv <avm4@cornell.edu
<mailto:avm4@cornell.edu>> wrote:
tp3 wrote
Yes, like nophead wrote, you should not need that.
Here's a more detailed example:
function f(a, b) =
assert(a < 0, "wrong a") // assert input
assert(b > 0, "wrong b") // assert input
let (c = a + b) // derive a new value from input
assert(c != 0, "wrong c") // assert derived value
a * b; // calculate
This is a great solution to the problem. I don't like
nophead's solution
because it mingles the computation into the assert in a way
that's hard to
read, but this approach is clear. It didn't occur to me that
assert could
take children. (This isn't mentioned in the manual at all.)
I do wish
that let would allow a dangling comma on the last expression,
which would
make it easier to insert and delete assignments.
But regarding the other issue, I still think it would be nice
if there was a
way to generate warning and error messages from my code,
without funny
business. It would be more clear to a user to see
ERROR: Value 'a' must be larger than zero in file tp, line 3
than
ERROR: Assertion '(a>0)': "Value 'a' must be larger than
zero" failed in
file tp, line 3.
And of course there's no mechanism at all to generate a warning.
--
Sent from: http://forum.openscad.org/
_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org>
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org>
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org>
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
You can echo warnings in user space but I don't think they will stop on
first warning.
On Sat, 16 Mar 2019 at 19:27, Joe Francis joe@lostapathy.com wrote:
I think that makes a lot more sense.
If a library author needs a way to bail out if something is hopelessly
wrong, that capability shouldn't get taken away because a user preference
says "just treat asserts like warnings". Even if that library author is
just me from 6 months ago :).
I do this all the time to verify the relationship between parameters. If
something won't work, I want it to fail immediately rather than spend a
couple minutes rendering something that doesn't make any sense.
Putting together a warning() method like that should be doable in
userspace, too.
On 3/16/19 2:17 PM, nop head wrote:
Well I suppose the alternative is to add a warning statement and function,
which duplicates all the same logic.
On Sat, 16 Mar 2019 at 19:15, Joe Francis joe@lostapathy.com wrote:
Are there any other languages that use assert like you propose? I can't
think of any where assert doesn't bring things to a full stop. I don't
think OpenSCAD should be the first.
On 3/16/19 1:58 PM, nop head wrote:
Perhaps assert should be changed to a warning and if you want it to stop
like an error then you select stop on first warning.
On Sat, 16 Mar 2019 at 17:59, adrianv avm4@cornell.edu wrote:
tp3 wrote
Yes, like nophead wrote, you should not need that.
Here's a more detailed example:
function f(a, b) =
assert(a < 0, "wrong a") // assert input
assert(b > 0, "wrong b") // assert input
let (c = a + b) // derive a new value from input
assert(c != 0, "wrong c") // assert derived value
a * b; // calculate
This is a great solution to the problem. I don't like nophead's solution
because it mingles the computation into the assert in a way that's hard
to
read, but this approach is clear. It didn't occur to me that assert
could
take children. (This isn't mentioned in the manual at all.) I do wish
that let would allow a dangling comma on the last expression, which would
make it easier to insert and delete assignments.
But regarding the other issue, I still think it would be nice if there
was a
way to generate warning and error messages from my code, without funny
business. It would be more clear to a user to see
ERROR: Value 'a' must be larger than zero in file tp, line 3
than
ERROR: Assertion '(a>0)': "Value 'a' must be larger than zero" failed in
file tp, line 3.
And of course there's no mechanism at all to generate a warning.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing listDiscuss@lists.openscad.orghttp://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing listDiscuss@lists.openscad.orghttp://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nophead wrote
Perhaps assert should be changed to a warning and if you want it to stop
like an error then you select stop on first warning.
I don't think so. Some situations just call for warnings. And some are
errors. The first warning isn't an error.
I edited the manual to add the example of using assert in a function. I'm
not sure I correctly stated how assert works, though, so someone might want
to check. It looks like it returns the union of its children if you give
it children--is there any reason you'd ever want to do this? But is using
it in an expression context different?
Well I suppose the alternative is to add a warning statement and function,
which duplicates all the same logic.
I think it would be better to add an error statement that has a flag for
severity and which doesn't include all the extra verbiage, so you could
write
error(c<=0,"Must set c>0"); // Displays: ERROR: Must set c>0, in file
foo.scad, line 3
error(check_bounds(c),"c is close to zero",warning=true); // Displays:
WARNING: c is close to zero, in file foo.scad, line 25
Note there is no word "failed" and no assertion condition displayed on
output, and no extra quote characters. I have already found it necessary to
save condition results into variables so I don't put a long condition into
the assert because I don't want that complicated condition test to display
to the user.
lostapathy wrote
Putting together a warning() method like that should be doable in
userspace,
too.
You can't create warnings in userspace if there's no way to actually make a
real warning. You can just make yellow text. But it's not the same.
--
Sent from: http://forum.openscad.org/
In the Curv language, I have 4 operations called 'print', 'assert', 'warning' and 'error', and none of them can be replaced by the others.
'print' is like 'echo' in OpenSCAD.
'assert(condition)' aborts the program if condition is false, printing an error message and a stack trace.
'error(message)' aborts the program, printing the message and a stack trace. Unlike 'assert', you can use error in either a statement context or an expression context. That is, you can write 'x < 0 ? error("negative x") : f(x)'.
'warning(message)' prints the message followed by a stack trace, and the program keeps running.
So, based on this experience, I think it is useful to have separate 'warning' and 'error' operations.
Doug Moen.
On Sat, Mar 16, 2019, at 3:38 PM, adrianv wrote:
nophead wrote
Perhaps assert should be changed to a warning and if you want it to stop
like an error then you select stop on first warning.
I don't think so. Some situations just call for warnings. And some are
errors. The first warning isn't an error.
I edited the manual to add the example of using assert in a function. I'm
not sure I correctly stated how assert works, though, so someone might want
to check. It looks like it returns the union of its children if you give
it children--is there any reason you'd ever want to do this? But is using
it in an expression context different?
Well I suppose the alternative is to add a warning statement and function,
which duplicates all the same logic.
I think it would be better to add an error statement that has a flag for
severity and which doesn't include all the extra verbiage, so you could
write
error(c<=0,"Must set c>0"); // Displays: ERROR: Must set c>0, in file
foo.scad, line 3
error(check_bounds(c),"c is close to zero",warning=true); // Displays:
WARNING: c is close to zero, in file foo.scad, line 25
Note there is no word "failed" and no assertion condition displayed on
output, and no extra quote characters. I have already found it necessary to
save condition results into variables so I don't put a long condition into
the assert because I don't want that complicated condition test to display
to the user.
lostapathy wrote
Putting together a warning() method like that should be doable in
userspace,
too.
You can't create warnings in userspace if there's no way to actually make a
real warning. You can just make yellow text. But it's not the same.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Having just written functions and modules to emulate error() and warning(), that only really output colored text, I agree that there should be builtins that stop compilation or trigger the warnings popup.
- Revar
On Mar 16, 2019, at 1:54 PM, Doug Moen doug@moens.org wrote:
In the Curv language, I have 4 operations called 'print', 'assert', 'warning' and 'error', and none of them can be replaced by the others.
'print' is like 'echo' in OpenSCAD.
'assert(condition)' aborts the program if condition is false, printing an error message and a stack trace.
'error(message)' aborts the program, printing the message and a stack trace. Unlike 'assert', you can use error in either a statement context or an expression context. That is, you can write 'x < 0 ? error("negative x") : f(x)'.
'warning(message)' prints the message followed by a stack trace, and the program keeps running.
So, based on this experience, I think it is useful to have separate 'warning' and 'error' operations.
Doug Moen.
On Sat, Mar 16, 2019, at 3:38 PM, adrianv wrote:
nophead wrote
Perhaps assert should be changed to a warning and if you want it to stop
like an error then you select stop on first warning.
I don't think so. Some situations just call for warnings. And some are
errors. The first warning isn't an error.
I edited the manual to add the example of using assert in a function. I'm
not sure I correctly stated how assert works, though, so someone might want
to check. It looks like it returns the union of its children if you give
it children--is there any reason you'd ever want to do this? But is using
it in an expression context different?
Well I suppose the alternative is to add a warning statement and function,
which duplicates all the same logic.
I think it would be better to add an error statement that has a flag for
severity and which doesn't include all the extra verbiage, so you could
write
error(c<=0,"Must set c>0"); // Displays: ERROR: Must set c>0, in file
foo.scad, line 3
error(check_bounds(c),"c is close to zero",warning=true); // Displays:
WARNING: c is close to zero, in file foo.scad, line 25
Note there is no word "failed" and no assertion condition displayed on
output, and no extra quote characters. I have already found it necessary to
save condition results into variables so I don't put a long condition into
the assert because I don't want that complicated condition test to display
to the user.
lostapathy wrote
Putting together a warning() method like that should be doable in
userspace,
too.
You can't create warnings in userspace if there's no way to actually make a
real warning. You can just make yellow text. But it's not the same.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
How would I write a modular code that checks for an error condition and
prints a message that I can use without dummy variables? Is this possible?
Could it be possible with a new error() function?
function do_something(x,y,mode) =
check_valid(mode,"mode", ["fast","slow","big","tall","purple"])
<function calculation>;
where check_valid checks() checks whether mode is on the list and if it's
not constructs a message like "Input 'mode' was set to <garbage>; it must be
one of 'fast', 'slow', 'big', 'tall', 'purple'") and calls assert() or
error().
I would rather avoid having to write a custom assert every time where I have
to repeat the list of options. But if I write a function, then it needs to
be part of an assignment, so then I need the dummy variable. Is there a way
around this?
--
Sent from: http://forum.openscad.org/
function do_something(x,y,mode) =
assert(check_valid(mode,"mode", ["fast","slow","big","tall","purple"]),
"bad mode")
<function calculation>;
On Mon, 25 Mar 2019 at 13:13, adrianv avm4@cornell.edu wrote:
How would I write a modular code that checks for an error condition and
prints a message that I can use without dummy variables? Is this
possible?
Could it be possible with a new error() function?
function do_something(x,y,mode) =
check_valid(mode,"mode", ["fast","slow","big","tall","purple"])
<function calculation>;
where check_valid checks() checks whether mode is on the list and if it's
not constructs a message like "Input 'mode' was set to <garbage>; it must
be
one of 'fast', 'slow', 'big', 'tall', 'purple'") and calls assert() or
error().
I would rather avoid having to write a custom assert every time where I
have
to repeat the list of options. But if I write a function, then it needs to
be part of an assignment, so then I need the dummy variable. Is there a
way
around this?
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nophead wrote
function do_something(x,y,mode) =
assert(check_valid(mode,"mode",
["fast","slow","big","tall","purple"]),
"bad mode")
My initial reaction was that this doesn't solve the problem, since the
actual error message text says "bad mode" instead of actually giving the
informative content. But in fact it might actually be better than the
status quo if the check_valid function displays its error in red text so it
looks like part of the error message. I'd call it a hack, but a decent one.
--
Sent from: http://forum.openscad.org/
The assert message can be an expression, so you could also separate out
the informative content from check_valid into another function and call it
to provide the second argument to assert.
On Tue, 26 Mar 2019 at 00:14, adrianv avm4@cornell.edu wrote:
nophead wrote
function do_something(x,y,mode) =
assert(check_valid(mode,"mode",
["fast","slow","big","tall","purple"]),
"bad mode")
My initial reaction was that this doesn't solve the problem, since the
actual error message text says "bad mode" instead of actually giving the
informative content. But in fact it might actually be better than the
status quo if the check_valid function displays its error in red text so it
looks like part of the error message. I'd call it a hack, but a decent
one.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nophead wrote
The assert message can be an expression, so you could also separate out
the informative content from check_valid into another function and call it
to provide the second argument to assert.
I can't think of a reason this would be useful. I don't want to write:
assert(check_valid(parameter, big_long_list), generate_message(parameter,
parametername, big_long_list))
It means repeating code, which was what I wanted to avoid. I suppose
let( result = check_valid(......) )
assert(result[0],result[1])
would be an option that gets the message entirely into the assert().
--
Sent from: http://forum.openscad.org/
Yes, or put the assert into check_valid() and rely on the the stack trace
to know where it is called from.
On Tue, 26 Mar 2019 at 09:52, adrianv avm4@cornell.edu wrote:
nophead wrote
The assert message can be an expression, so you could also separate out
the informative content from check_valid into another function and call
it
to provide the second argument to assert.
I can't think of a reason this would be useful. I don't want to write:
assert(check_valid(parameter, big_long_list), generate_message(parameter,
parametername, big_long_list))
It means repeating code, which was what I wanted to avoid. I suppose
let( result = check_valid(......) )
assert(result[0],result[1])
would be an option that gets the message entirely into the assert().
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nophead wrote
Yes, or put the assert into check_valid() and rely on the the stack trace
to know where it is called from.
If I do this then I need to use a dummy variable when I call assert, which
was basically the whole thing I was trying to work around. If I could
define my own "function" that works like assert that would be the natural
way to do it, but assert is not a function and it works in a fashion that is
different from user definable commands. If it's basically impossible to
avoid dummy variables then we should propose a dummy variable mechanism be
added to OpenSCAD.
--
Sent from: http://forum.openscad.org/
I don't understand where you need a dummy variable?
On Tue, 26 Mar 2019 at 12:03, adrianv avm4@cornell.edu wrote:
nophead wrote
Yes, or put the assert into check_valid() and rely on the the stack trace
to know where it is called from.
If I do this then I need to use a dummy variable when I call assert, which
was basically the whole thing I was trying to work around. If I could
define my own "function" that works like assert that would be the natural
way to do it, but assert is not a function and it works in a fashion that
is
different from user definable commands. If it's basically impossible to
avoid dummy variables then we should propose a dummy variable mechanism be
added to OpenSCAD.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
function check(x) = assert(x >= 0, str(x, " is not a square")) x;
function do_something(x) = sqrt(check(x));
echo(do_something(-4));
ERROR: Assertion '(x >= 0)' failed: "-4 is not a square" in file tests,
line 2
TRACE: called by 'check', in file tests, line 4.
TRACE: called by 'sqrt', in file tests, line 4.
TRACE: called by 'do_something', in file tests, line 6.
TRACE: called by 'echo', in file tests, line 6.
On Tue, 26 Mar 2019 at 12:05, nop head nop.head@gmail.com wrote:
I don't understand where you need a dummy variable?
On Tue, 26 Mar 2019 at 12:03, adrianv avm4@cornell.edu wrote:
nophead wrote
Yes, or put the assert into check_valid() and rely on the the stack
trace
to know where it is called from.
If I do this then I need to use a dummy variable when I call assert, which
was basically the whole thing I was trying to work around. If I could
define my own "function" that works like assert that would be the natural
way to do it, but assert is not a function and it works in a fashion that
is
different from user definable commands. If it's basically impossible to
avoid dummy variables then we should propose a dummy variable mechanism be
added to OpenSCAD.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Generally I think it's cryptic code and bad practice to mix the error
checking in with the computation, though to be honest, the example you have
below isn't terrible.
But in the case I was pondering, we are checking validity of user input, not
doing a computation. The subsquent computation may be quite complex, and
there's no assignment that it makes sense to entangle the check with. So
the code will end up looking like:
dummy = check_parameter(parameter, 'parameter',
["long","list","of","options"]),
somewhere in the let() statement. I mean, I guess it could be
renamed_parameter = check_parameter(....),
and the check_parameter function returns the parameter value. But being
compelled to rename all the parameters isn't ideal either.
nophead wrote
function check(x) = assert(x >= 0, str(x, " is not a square")) x;
function do_something(x) = sqrt(check(x));
echo(do_something(-4));
ERROR: Assertion '(x >= 0)' failed: "-4 is not a square" in file tests,
line 2
TRACE: called by 'check', in file tests, line 4.
TRACE: called by 'sqrt', in file tests, line 4.
TRACE: called by 'do_something', in file tests, line 6.
TRACE: called by 'echo', in file tests, line 6.
On Tue, 26 Mar 2019 at 12:05, nop head <
nop.head@
> wrote:
I don't understand where you need a dummy variable?
--
Sent from: http://forum.openscad.org/
Hello List,
when i update my old OpenSCAD Linux Appimage to the new RC4 Release
Appimage i miss a feature.
When i have rendered a object and double click on the yellow surface in
the old version the center of the camera moved exactly to that point of
the surface. In the new version nothing happens.
Is this feature gone ? Is there a way to enable it ? Is this a bug ?
Best reguards
Corpsman
It still works on Windows, so looks like a bug.
On Wed, 27 Mar 2019 at 18:49, corpsman corpsman@corpsman.de wrote:
Hello List,
when i update my old OpenSCAD Linux Appimage to the new RC4 Release
Appimage i miss a feature.
When i have rendered a object and double click on the yellow surface in
the old version the center of the camera moved exactly to that point of
the surface. In the new version nothing happens.
Is this feature gone ? Is there a way to enable it ? Is this a bug ?
Best reguards
Corpsman
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 27.03.19 20:06, nop head wrote:
It still works on Windows, so looks like a bug.
Yes, but unfortunately it's a bit unclear what's wrong. Someone
tried to get it working again but there seems to be some driver
issues too -> https://github.com/openscad/openscad/pull/2466
ciao,
Torsten.