MF
Michael Frey
Sat, Mar 12, 2022 1:08 PM
On 12.03.22 03:19, Jordan Brown wrote:
It would be nice if warnings like these came with stack backtraces,
including the arguments to each call, identified by name.
That would be very verbose, so it would also be nice if those stack
backtraces were also collapsed by default and could be expanded by
clicking on the warning.
And I realize that this is probably a pretty tricky thing to do in
what's basically a log viewer. But it would still be nice.
Maybe in my copious free time...
By activating "stop on the first warning" you get at least a trace of
the calls:
Compiling design (CSG Tree generation)...
WARNING: undefined operation (number - undefined) in file , line 24
TRACE: called by 'cube' in file , line 24
TRACE: called by 'minkowski' in file , line 23
TRACE: called by 'difference' in file , line 22
TRACE: called by 'translate' in file , line 22
TRACE: called by 'BearingBlock' in file , line 35
TRACE: called by 'BlockSide' in file , line 44
Execution aborted
I wonder how hard it would be to output the argument(s) of the call.
In the openscad source, the starting points for such a feature would be
the methode print_trace and the class context.
I love the idea of making the log collapse - that sounds useful in general.
I wonder how hard that would be to implement.
An other idea might be to show the variables "on hover".
One complication is how to handle that on command line.
Collapsing is nice in a GUI software, but does not work on command line.
With kind regards,
Michael Frey
On 12.03.22 03:19, Jordan Brown wrote:
> It would be nice if warnings like these came with stack backtraces,
> including the arguments to each call, identified by name.
>
> That would be very verbose, so it would also be nice if those stack
> backtraces were also collapsed by default and could be expanded by
> clicking on the warning.
>
> And I realize that this is probably a pretty tricky thing to do in
> what's basically a log viewer. But it would still be nice.
>
> Maybe in my copious free time...
By activating "stop on the first warning" you get at least a trace of
the calls:
Compiling design (CSG Tree generation)...
WARNING: undefined operation (number - undefined) in file , line 24
TRACE: called by 'cube' in file , line 24
TRACE: called by 'minkowski' in file , line 23
TRACE: called by 'difference' in file , line 22
TRACE: called by 'translate' in file , line 22
TRACE: called by 'BearingBlock' in file , line 35
TRACE: called by 'BlockSide' in file , line 44
Execution aborted
I wonder how hard it would be to output the argument(s) of the call.
In the openscad source, the starting points for such a feature would be
the methode print_trace and the class context.
I love the idea of making the log collapse - that sounds useful in general.
I wonder how hard that would be to implement.
An other idea might be to show the variables "on hover".
One complication is how to handle that on command line.
Collapsing is nice in a GUI software, but does not work on command line.
With kind regards,
Michael Frey
J
jon
Sat, Mar 12, 2022 1:11 PM
I agree, but fear that this change would break a lot of code...
On 3/11/2022 9:49 PM, Jordan Brown wrote:
On 3/11/2022 6:32 PM, Bob Roos wrote:
I wish is said something like parameter count mismatch.
Yeah, that's kind of the difference between "strict" languages and
looser ones. Strict languages say "if you don't pass exactly the
right thing it's an error", while looser languages like JavaScript
silently populate missing arguments with "undefined" and ignore extra
arguments. OpenSCAD is kind of half strict; it complains about extra
arguments but populates missing arguments. That lets you have
optional arguments (that you can detect using is_undef()), but at the
expense of not detecting bugs like this.
I'm a "strict" kind of guy; I think that the "usability" win from
letting these constructs pass is dwarfed by the debugability win from
detecting these bugs. If you want to have a language with optional
arguments, have an explicit defaulting mechanism (even if the default
you specify is to set the variable to "undefined"). A missing
argument with no default should be an error.
OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org
I agree, but fear that this change would break a lot of code...
On 3/11/2022 9:49 PM, Jordan Brown wrote:
> On 3/11/2022 6:32 PM, Bob Roos wrote:
>> I wish is said something like parameter count mismatch.
>
> Yeah, that's kind of the difference between "strict" languages and
> looser ones. Strict languages say "if you don't pass exactly the
> right thing it's an error", while looser languages like JavaScript
> silently populate missing arguments with "undefined" and ignore extra
> arguments. OpenSCAD is kind of half strict; it complains about extra
> arguments but populates missing arguments. That lets you have
> optional arguments (that you can detect using is_undef()), but at the
> expense of not detecting bugs like this.
>
> I'm a "strict" kind of guy; I think that the "usability" win from
> letting these constructs pass is dwarfed by the debugability win from
> detecting these bugs. If you want to have a language with optional
> arguments, have an explicit defaulting mechanism (even if the default
> you specify is to set the variable to "undefined"). A missing
> argument with no default should be an error.
>
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email todiscuss-leave@lists.openscad.org
DM
Douglas Miller
Sat, Mar 12, 2022 1:23 PM
Case sensitivity isn't an issue here, Gene, since (e.g.) bod and BOD are
in different scopes. This is unrelated to the warnings Bob gets.
On 3/11/2022 10:45 PM, gene heskett wrote:
On Friday, 11 March 2022 20:51:54 EST Bob Roos wrote:
And OpenSCAD's variables are case sensitive, you are mixing case.
Cheers, Gene Heskett.
Case sensitivity isn't an issue here, Gene, since (e.g.) bod and BOD are
in different scopes. This is unrelated to the warnings Bob gets.
On 3/11/2022 10:45 PM, gene heskett wrote:
> On Friday, 11 March 2022 20:51:54 EST Bob Roos wrote:
>
> And OpenSCAD's variables are case sensitive, you are mixing case.
>
>
> Cheers, Gene Heskett.
DM
Douglas Miller
Sat, Mar 12, 2022 1:25 PM
That's not of much help in this specific case, though: since all of the
parameters are positional, not named, when one is missing the undefined
parameter is the /last/ one, not the one that's actually missing.
On 3/11/2022 9:19 PM, Father Horton wrote:
A general debugging tip: In situations like this, use echo() to show
the values of the variables. That will tell you which one is
undefined, and then you can look to figure out why.
That's not of much help in this specific case, though: since all of the
parameters are positional, not named, when one is missing the undefined
parameter is the /last/ one, not the one that's actually missing.
On 3/11/2022 9:19 PM, Father Horton wrote:
> A general debugging tip: In situations like this, use echo() to show
> the values of the variables. That will tell you which one is
> undefined, and then you can look to figure out why.
>
AM
Adrian Mariano
Sat, Mar 12, 2022 1:41 PM
Yeah, giving an error for not passing a parameter would definitely
break a lot of code. The fix would be relatively easy---just change
func(param) to func(param=undef), but that might not be the most
obvious thing. The main way to solve this problem with the current
OpenSCAD is to check the inputs when you write a function or module.
In other words, for a module:
module foo(length,width)
{
dummy = assert(is_num(length), "invalid length") // no semicolon here
assert(is_num(width), "invalid width");
// rest of module
}
Note that the above is the most robust way to run some asserts because
assigning their "output" makes it into a variable calculation, which
runs before modules. If you use the module version of assert then
module foo(length)
{
assert(is_num(length));
a=length+3;
}
will give a warning on the a=length+3 statement instead of the
assertion because a=length+3 runs first.
On Sat, Mar 12, 2022 at 8:11 AM jon jon@jonbondy.com wrote:
I agree, but fear that this change would break a lot of code...
On 3/11/2022 9:49 PM, Jordan Brown wrote:
On 3/11/2022 6:32 PM, Bob Roos wrote:
I wish is said something like parameter count mismatch.
Yeah, that's kind of the difference between "strict" languages and looser ones. Strict languages say "if you don't pass exactly the right thing it's an error", while looser languages like JavaScript silently populate missing arguments with "undefined" and ignore extra arguments. OpenSCAD is kind of half strict; it complains about extra arguments but populates missing arguments. That lets you have optional arguments (that you can detect using is_undef()), but at the expense of not detecting bugs like this.
I'm a "strict" kind of guy; I think that the "usability" win from letting these constructs pass is dwarfed by the debugability win from detecting these bugs. If you want to have a language with optional arguments, have an explicit defaulting mechanism (even if the default you specify is to set the variable to "undefined"). A missing argument with no default should be an error.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Yeah, giving an error for not passing a parameter would definitely
break a lot of code. The fix would be relatively easy---just change
func(param) to func(param=undef), but that might not be the most
obvious thing. The main way to solve this problem with the current
OpenSCAD is to check the inputs when you write a function or module.
In other words, for a module:
module foo(length,width)
{
dummy = assert(is_num(length), "invalid length") // no semicolon here
assert(is_num(width), "invalid width");
// rest of module
}
Note that the above is the most robust way to run some asserts because
assigning their "output" makes it into a variable calculation, which
runs before modules. If you use the module version of assert then
module foo(length)
{
assert(is_num(length));
a=length+3;
}
will give a warning on the a=length+3 statement instead of the
assertion because a=length+3 runs first.
On Sat, Mar 12, 2022 at 8:11 AM jon <jon@jonbondy.com> wrote:
>
> I agree, but fear that this change would break a lot of code...
>
>
> On 3/11/2022 9:49 PM, Jordan Brown wrote:
>
> On 3/11/2022 6:32 PM, Bob Roos wrote:
>
> I wish is said something like parameter count mismatch.
>
>
> Yeah, that's kind of the difference between "strict" languages and looser ones. Strict languages say "if you don't pass exactly the right thing it's an error", while looser languages like JavaScript silently populate missing arguments with "undefined" and ignore extra arguments. OpenSCAD is kind of half strict; it complains about extra arguments but populates missing arguments. That lets you have optional arguments (that you can detect using is_undef()), but at the expense of not detecting bugs like this.
>
> I'm a "strict" kind of guy; I think that the "usability" win from letting these constructs pass is dwarfed by the debugability win from detecting these bugs. If you want to have a language with optional arguments, have an explicit defaulting mechanism (even if the default you specify is to set the variable to "undefined"). A missing argument with no default should be an error.
>
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
GH
gene heskett
Sat, Mar 12, 2022 4:55 PM
On Saturday, 12 March 2022 08:23:27 EST Douglas Miller wrote:
Case sensitivity isn't an issue here, Gene, since (e.g.) bod and BOD
are in different scopes. This is unrelated to the warnings Bob gets.
I see that from later posts. My ancient wet ram doesn't always check
scope. Been too many years since I carved code in C. And I got bit. :(
And its one of the main reasons I don't differentiate scope in my own
code by changing case. I change the whole name. Too easy to hide problems
IMO.
Cheers, Gene Heskett.
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
On Saturday, 12 March 2022 08:23:27 EST Douglas Miller wrote:
> Case sensitivity isn't an issue here, Gene, since (e.g.) bod and BOD
> are in different scopes. This is unrelated to the warnings Bob gets.
I see that from later posts. My ancient wet ram doesn't always check
scope. Been too many years since I carved code in C. And I got bit. :(
And its one of the main reasons I don't differentiate scope in my own
code by changing case. I change the whole name. Too easy to hide problems
IMO.
Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
SP
Sanjeev Prabhakar
Sat, Mar 12, 2022 5:02 PM
generally, how i read these warnings to understand the issue:
e.g.
the warning says : (number - undefined) on line 24
when you check the line 24, you will see the
function: cube([w-ff,l-ff,h-ff],center=true);
and in this you can find that the variable "ff" is the only variable which
could be undefined.
thereafter go to the trace where this function is first referenced. e.g. TRACE:
called by 'BearingBlock' in file , line 35 <35,/>
That means the call for parameters in the line number 35 may not be
matching with the actual parameter in the module.
Most of the time, it works
On Sat, 12 Mar 2022 at 07:22, Bob Roos roosbob@wybatap.com wrote:
Hello Discuss,
I decided to try making a module since things will be repeating. I get
an error on every arithmetic operation.
for example:
WARNING: undefined operation (number - undefined) in file Spool
Holder.scad, line 24
WARNING: undefined operation (number - undefined) in file Spool
Holder.scad, line 24
WARNING: undefined operation (number - undefined) in file Spool
Holder.scad, line 24
WARNING: Unable to convert cube(size=[undef, undef, undef], ...) parameter
to a number or a vec3 of numbers in file Spool Holder.scad, line 24
Thank you for any insights.
Bob Roos
Here is the program:
// spool holder
// Bob Roos
// March 11, 2022
$fn = 48;
// bearing
BOD = 22;
BID = 8;
BW = 7;
// material
FF = 1; // fudge factor
FF2 = 2FF;
T = 1.5;
W = 2T+BW+FF;
L = 1.5BOD;
H = BOD.67 + T;
Sep = 105;
module BearingBlock (w,l,h,bod,bid,bw,ff){
translate([0,0,0])difference(){
minkowski(){
cube([w-ff,l-ff,h-ff],center=true);
sphere(ff);
}
translate([0,0,bod/4])rotate([0,90,0])cylinder(h=bw+ff,d=bod+ff*2,center=true);
translate([0,0,bod/4])rotate([0,0,0])cube([w+2ff,bod+2ff,h/2],center=true);
translate([0,0,bod/4])rotate([0,90,0])cylinder(h=w+ff,d=bid+2*ff,center=true);
}
}
module BlockSide (sep,w,l,h,bod,bid,bw,ff){
BearingBlock(w,l,bod,bid,bw,ff);
minkowski(){
translate([0,sep/2,-h/2+1])cube([w,sep-bod,ff],center=true);
sphere(ff);
}
BearingBlock(w,l,bod,bid,bw,ff);
}
//BlockSide(Sep,W,L,H,BOD,BID,BW,FF);
BlockSide(sep=Sep,w=W,l=L,h=H,bod=BOD,bid=BID,bw=BW,ff=FF);
--
Best regards,
Bob mailto:roosbob@wybatap.com
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
generally, how i read these warnings to understand the issue:
e.g.
the warning says : (number - undefined) on line 24
when you check the line 24, you will see the
function: cube([w-ff,l-ff,h-ff],center=true);
and in this you can find that the variable "ff" is the only variable which
could be undefined.
thereafter go to the trace where this function is first referenced. e.g. TRACE:
called by 'BearingBlock' in file , line 35 <35,/>
That means the call for parameters in the line number 35 may not be
matching with the actual parameter in the module.
Most of the time, it works
On Sat, 12 Mar 2022 at 07:22, Bob Roos <roosbob@wybatap.com> wrote:
> Hello Discuss,
>
> I decided to try making a module since things will be repeating. I get
> an error on every arithmetic operation.
> for example:
>
> WARNING: undefined operation (number - undefined) in file Spool
> Holder.scad, line 24
> WARNING: undefined operation (number - undefined) in file Spool
> Holder.scad, line 24
> WARNING: undefined operation (number - undefined) in file Spool
> Holder.scad, line 24
> WARNING: Unable to convert cube(size=[undef, undef, undef], ...) parameter
> to a number or a vec3 of numbers in file Spool Holder.scad, line 24
>
> Thank you for any insights.
>
> Bob Roos
>
> Here is the program:
>
> // spool holder
> // Bob Roos
> // March 11, 2022
>
> $fn = 48;
>
> // bearing
> BOD = 22;
> BID = 8;
> BW = 7;
>
> // material
> FF = 1; // fudge factor
> FF2 = 2*FF;
> T = 1.5;
> W = 2*T+BW+FF;
> L = 1.5*BOD;
> H = BOD*.67 + T;
> Sep = 105;
>
> module BearingBlock (w,l,h,bod,bid,bw,ff){
> translate([0,0,0])difference(){
> minkowski(){
> cube([w-ff,l-ff,h-ff],center=true);
> sphere(ff);
> }
>
> translate([0,0,bod/4])rotate([0,90,0])cylinder(h=bw+ff,d=bod+ff*2,center=true);
>
> translate([0,0,bod/4])rotate([0,0,0])cube([w+2*ff,bod+2*ff,h/2],center=true);
>
> translate([0,0,bod/4])rotate([0,90,0])cylinder(h=w+ff,d=bid+2*ff,center=true);
>
> }
> }
>
> module BlockSide (sep,w,l,h,bod,bid,bw,ff){
> BearingBlock(w,l,bod,bid,bw,ff);
> minkowski(){
> translate([0,sep/2,-h/2+1])cube([w,sep-bod,ff],center=true);
> sphere(ff);
> }
> BearingBlock(w,l,bod,bid,bw,ff);
> }
>
> //BlockSide(Sep,W,L,H,BOD,BID,BW,FF);
> BlockSide(sep=Sep,w=W,l=L,h=H,bod=BOD,bid=BID,bw=BW,ff=FF);
>
> --
> Best regards,
> Bob mailto:roosbob@wybatap.com
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
MF
Michael Frey
Sat, Mar 12, 2022 7:17 PM
I am now in the technical details, so I can now respond in details.
On 12.03.22 03:19, Jordan Brown wrote:
It would be nice if warnings like these came with stack backtraces,
including the arguments to each call, identified by name.
You need to activate "stop on the first warning".
The core root for this is, that I want to minimize impact on normal
execution.
On the other side: With "stop on first warning" active and a warning is
issued,
I can make expensive calls with disregard to runtime implications.
It is safe to assume, that the user will spend more time to read the
messages then the computer needs to generate the messages.
If on the other side people ignore warnings, then having a backtrace
will not help.
This category of users needs fast run times for "trial and error".
(And all users want fast run time when everything is fine)
The the technical implementation is, that this throws a C++ exception.
The stack back traces is implemented in the exception handling.
This also forces a "one error is fatal/enough" mind set.
That would be very verbose, so it would also be nice if those stack
backtraces were also collapsed by default and could be expanded by
clicking on the warning.
One more reason to only support one backtrack
Coming back to this:
... including the arguments to each call,
That is easier then I thought:
WARNING: undefined operation (number - undefined) in file
spoolholder.scad, line 25
TRACE: called by 'cube([undef, undef, undef], center=true)' in file
spoolholder.scad, line 25
TRACE: called by 'minkowski()' in file spoolholder.scad, line 24
TRACE: called by 'difference()' in file spoolholder.scad, line 23
TRACE: called by 'translate([0, 0, 0])' in file spoolholder.scad, line 23
TRACE: called by 'BearingBlock(11, 33, 22, 8, 7, 1)' in file
spoolholder.scad, line 36
TRACE: called by 'BlockSide(sep=105, w=11, l=33, h=16.24, bod=22, bid=8,
bw=7, ff=1)' in file spoolholder.scad, line 45
Execution aborted
The trickiest part will be to update the automatic tests - but that is
just reading the documentation.
This is trickier then it sounds.
I have the arguments of the call, but not the arguments of the
function/module.
So if the call uses argument position, then I currently to not have the
name.
Maybe in my copious free time...
Or you just happen to catch the interest of the person that last work in
that domain ;-)
With kind regards,
Michael Frey
I am now in the technical details, so I can now respond in details.
On 12.03.22 03:19, Jordan Brown wrote:
> It would be nice if warnings like these came with stack backtraces,
> including the arguments to each call, identified by name.
You need to activate "stop on the first warning".
The core root for this is, that I want to minimize impact on normal
execution.
On the other side: With "stop on first warning" active and a warning is
issued,
I can make expensive calls with disregard to runtime implications.
It is safe to assume, that the user will spend more time to read the
messages then the computer needs to generate the messages.
If on the other side people ignore warnings, then having a backtrace
will not help.
This category of users needs fast run times for "trial and error".
(And all users want fast run time when everything is fine)
The the technical implementation is, that this throws a C++ exception.
The stack back traces is implemented in the exception handling.
This also forces a "one error is fatal/enough" mind set.
> That would be very verbose, so it would also be nice if those stack
> backtraces were also collapsed by default and could be expanded by
> clicking on the warning.
One more reason to only support one backtrack
Coming back to this:
> ... including the arguments to each call,
That is easier then I thought:
WARNING: undefined operation (number - undefined) in file
spoolholder.scad, line 25
TRACE: called by 'cube([undef, undef, undef], center=true)' in file
spoolholder.scad, line 25
TRACE: called by 'minkowski()' in file spoolholder.scad, line 24
TRACE: called by 'difference()' in file spoolholder.scad, line 23
TRACE: called by 'translate([0, 0, 0])' in file spoolholder.scad, line 23
TRACE: called by 'BearingBlock(11, 33, 22, 8, 7, 1)' in file
spoolholder.scad, line 36
TRACE: called by 'BlockSide(sep=105, w=11, l=33, h=16.24, bod=22, bid=8,
bw=7, ff=1)' in file spoolholder.scad, line 45
Execution aborted
The trickiest part will be to update the automatic tests - but that is
just reading the documentation.
> identified by name.
This is trickier then it sounds.
I have the arguments of the call, but not the arguments of the
function/module.
So if the call uses argument position, then I currently to not have the
name.
> Maybe in my copious free time...
Or you just happen to catch the interest of the person that last work in
that domain ;-)
With kind regards,
Michael Frey
AM
Adrian Mariano
Sat, Mar 12, 2022 8:34 PM
How does listing the variables work if you pass an array of 1000 values?
On Sat, Mar 12, 2022 at 2:17 PM Michael Frey michael.frey@gmx.ch wrote:
I am now in the technical details, so I can now respond in details.
On 12.03.22 03:19, Jordan Brown wrote:
It would be nice if warnings like these came with stack backtraces, including the arguments to each call, identified by name.
You need to activate "stop on the first warning".
The core root for this is, that I want to minimize impact on normal execution.
On the other side: With "stop on first warning" active and a warning is issued,
I can make expensive calls with disregard to runtime implications.
It is safe to assume, that the user will spend more time to read the messages then the computer needs to generate the messages.
If on the other side people ignore warnings, then having a backtrace will not help.
This category of users needs fast run times for "trial and error".
(And all users want fast run time when everything is fine)
The the technical implementation is, that this throws a C++ exception.
The stack back traces is implemented in the exception handling.
This also forces a "one error is fatal/enough" mind set.
That would be very verbose, so it would also be nice if those stack backtraces were also collapsed by default and could be expanded by clicking on the warning.
One more reason to only support one backtrack
Coming back to this:
... including the arguments to each call,
That is easier then I thought:
WARNING: undefined operation (number - undefined) in file spoolholder.scad, line 25
TRACE: called by 'cube([undef, undef, undef], center=true)' in file spoolholder.scad, line 25
TRACE: called by 'minkowski()' in file spoolholder.scad, line 24
TRACE: called by 'difference()' in file spoolholder.scad, line 23
TRACE: called by 'translate([0, 0, 0])' in file spoolholder.scad, line 23
TRACE: called by 'BearingBlock(11, 33, 22, 8, 7, 1)' in file spoolholder.scad, line 36
TRACE: called by 'BlockSide(sep=105, w=11, l=33, h=16.24, bod=22, bid=8, bw=7, ff=1)' in file spoolholder.scad, line 45
Execution aborted
The trickiest part will be to update the automatic tests - but that is just reading the documentation.
identified by name.
This is trickier then it sounds.
I have the arguments of the call, but not the arguments of the function/module.
So if the call uses argument position, then I currently to not have the name.
Maybe in my copious free time...
Or you just happen to catch the interest of the person that last work in that domain ;-)
With kind regards,
Michael Frey
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
How does listing the variables work if you pass an array of 1000 values?
On Sat, Mar 12, 2022 at 2:17 PM Michael Frey <michael.frey@gmx.ch> wrote:
>
> I am now in the technical details, so I can now respond in details.
>
>
> On 12.03.22 03:19, Jordan Brown wrote:
>
> It would be nice if warnings like these came with stack backtraces, including the arguments to each call, identified by name.
>
> You need to activate "stop on the first warning".
>
> The core root for this is, that I want to minimize impact on normal execution.
>
> On the other side: With "stop on first warning" active and a warning is issued,
>
> I can make expensive calls with disregard to runtime implications.
>
> It is safe to assume, that the user will spend more time to read the messages then the computer needs to generate the messages.
>
> If on the other side people ignore warnings, then having a backtrace will not help.
>
> This category of users needs fast run times for "trial and error".
>
> (And all users want fast run time when everything is fine)
>
>
> The the technical implementation is, that this throws a C++ exception.
>
> The stack back traces is implemented in the exception handling.
>
> This also forces a "one error is fatal/enough" mind set.
>
>
> That would be very verbose, so it would also be nice if those stack backtraces were also collapsed by default and could be expanded by clicking on the warning.
>
> One more reason to only support one backtrack
>
>
> Coming back to this:
>
> ... including the arguments to each call,
>
> That is easier then I thought:
>
>
> WARNING: undefined operation (number - undefined) in file spoolholder.scad, line 25
>
> TRACE: called by 'cube([undef, undef, undef], center=true)' in file spoolholder.scad, line 25
>
> TRACE: called by 'minkowski()' in file spoolholder.scad, line 24
>
> TRACE: called by 'difference()' in file spoolholder.scad, line 23
>
> TRACE: called by 'translate([0, 0, 0])' in file spoolholder.scad, line 23
>
> TRACE: called by 'BearingBlock(11, 33, 22, 8, 7, 1)' in file spoolholder.scad, line 36
>
> TRACE: called by 'BlockSide(sep=105, w=11, l=33, h=16.24, bod=22, bid=8, bw=7, ff=1)' in file spoolholder.scad, line 45
>
> Execution aborted
>
> The trickiest part will be to update the automatic tests - but that is just reading the documentation.
>
> identified by name.
>
> This is trickier then it sounds.
>
> I have the arguments of the call, but not the arguments of the function/module.
>
> So if the call uses argument position, then I currently to not have the name.
>
> Maybe in my copious free time...
>
> Or you just happen to catch the interest of the person that last work in that domain ;-)
>
> With kind regards,
>
> Michael Frey
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
JB
Jordan Brown
Sat, Mar 12, 2022 9:23 PM
On 3/12/2022 5:25 AM, Douglas Miller wrote:
On 3/11/2022 9:19 PM, Father Horton wrote:
A general debugging tip: In situations like this, use echo() to show
the values of the variables. That will tell you which one is
undefined, and then you can look to figure out why.
That's not of much help in this specific case, though: since all of
the parameters are positional, not named, when one is missing the
undefined parameter is the /last/ one, not the one that's actually
missing.
At least you can confirm that "ff" is in trouble, for whatever reason.
And you can confirm that it is OK before the call, and thus isolate the
problem to that one call.
On 3/12/2022 5:25 AM, Douglas Miller wrote:
> On 3/11/2022 9:19 PM, Father Horton wrote:
>> A general debugging tip: In situations like this, use echo() to show
>> the values of the variables. That will tell you which one is
>> undefined, and then you can look to figure out why.
> That's not of much help in this specific case, though: since all of
> the parameters are positional, not named, when one is missing the
> undefined parameter is the /last/ one, not the one that's actually
> missing.
At least you can confirm that "ff" is in trouble, for whatever reason.
And you can confirm that it is OK before the call, and thus isolate the
problem to that one call.
