"Too many unnamed arguments "
Baffled. OpenSCAD version 2019.01-RC4
This:
bottle_dia = 26.64;
fudgefac = .5;
test_dia();
module test_dia() {
difference() {
cube([bottle_dia+5,bottle_dia+5,2],center = true);
translate(0,0,-.001)
cylinder(h=2.1,d=bottle_dia + fudgefac);
}
}
Gives me this:
Compiling design (CSG Tree generation)...
WARNING: Too many unnamed arguments supplied, in file OpenSCAD, line 9
TRACE: called by 'translate', in file OpenSCAD, line 9.
TRACE: called by 'difference', in file OpenSCAD, line 7.
TRACE: called by 'test_dia', in file OpenSCAD, line 4.
--
Sent from: http://forum.openscad.org/
Put square brackets around the arguments in translate
On Tue, 14 May 2019, 10:16 lar3ry, lar3ry@sasktel.net wrote:
Baffled. OpenSCAD version 2019.01-RC4
This:
bottle_dia = 26.64;
fudgefac = .5;
test_dia();
module test_dia() {
difference() {
cube([bottle_dia+5,bottle_dia+5,2],center = true);
translate(0,0,-.001)
cylinder(h=2.1,d=bottle_dia + fudgefac);
}
}
Gives me this:
Compiling design (CSG Tree generation)...
WARNING: Too many unnamed arguments supplied, in file OpenSCAD, line 9
TRACE: called by 'translate', in file OpenSCAD, line 9.
TRACE: called by 'difference', in file OpenSCAD, line 7.
TRACE: called by 'test_dia', in file OpenSCAD, line 4.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 5/14/2019 7:44 AM, A. Craig West wrote:
Put square brackets around the arguments in translate
Yes, but a little more precisely: translate takes a single argument, a
vector containing two or three numbers. What the original poster passed
was three individual numbers, not a vector.
(Note that a vector is what some languages call an array.)
On Tue, 14 May 2019, 10:16 lar3ry, <lar3ry@sasktel.net
mailto:lar3ry@sasktel.net> wrote:
translate(0,0,-.001)
cylinder(h=2.1,d=bottle_dia + fudgefac);
[...]
Compiling design (CSG Tree generation)...
WARNING: Too many unnamed arguments supplied, in file OpenSCAD, line 9
TRACE: called by 'translate', in file OpenSCAD, line 9.
TRACE: called by 'difference', in file OpenSCAD, line 7.
TRACE: called by 'test_dia', in file OpenSCAD, line 4.
Of course! Rookie mistake.
In my defense, I will say that what got me confused was the change in
behaviour from my previous rev of OpenSCAD. Previously, the only result of
that error would have been that the translate would not have given an error
message, but would have shown up as a failure to do the translation.
I think I prefer the old way, but that error message will not throw me
again.
Thanks, guys.
--
Sent from: http://forum.openscad.org/
I'd say at this point I'm past the rookie stage and yet I still sometimes
screw up and pass 3 parameters instead of a vector to some modules.
I'm curious why you think silent failure is preferred to an error message.
I find that it is difficult to debug OpenSCAD code in many cases because
errors produce "undef" and the undefs propagate through the code, undef
begetting undef, possibly quite a distance before some routine finally
refuses to function and produces a diagnostic message. It sure would be
nice to know where that first failure point is rather than having to start
inserting echo() after echo() to try to track it down.
lar3ry wrote
Of course! Rookie mistake.
In my defense, I will say that what got me confused was the change in
behaviour from my previous rev of OpenSCAD. Previously, the only result of
that error would have been that the translate would not have given an
error
message, but would have shown up as a failure to do the translation.
I think I prefer the old way, but that error message will not throw me
again.
Thanks, guys.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@.openscad
--
Sent from: http://forum.openscad.org/
adrianv wrote
I'd say at this point I'm past the rookie stage and yet I still sometimes
screw up and pass 3 parameters instead of a vector to some modules.
I'm curious why you think silent failure is preferred to an error message.
I find that it is difficult to debug OpenSCAD code in many cases because
errors produce "undef" and the undefs propagate through the code, undef
begetting undef, possibly quite a distance before some routine finally
refuses to function and produces a diagnostic message. It sure would be
nice to know where that first failure point is rather than having to start
inserting echo() after echo() to try to track it down.
I didn't mean that I prefer the old way in a general case, but only in this
particular instance. Much of my debugging consists of looking at the result
and figuring out where I went wrong. With translate() it was particularly
easy because if the translate didn't work, the result would be that whatever
I was translating would be in the wrong place.
I'll definitely get used to the new way it shows up. What really threw me
was that I really wasn't sure what that error meant. I thought it was
pointing out the line above the translate, and never thought to look closely
at the translate statement.
--
Sent from: http://forum.openscad.org/