function signatures (new thread)

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

function signatures (new thread)

Peter Falke
Hi Chrysn, hi all
 
I second the quest for a listing of all commands with their possible parameters and their order directly from the code.
 
Chrysn, could you or any other people explain to me how I get the sorce code and in what files I have to look and what for I have to look to find them myself.
 
Could someone please explain how the overloading of a command with parameters works (e.g. cube(100,true), cube([0,1,2]), cube([0,1,]) ). See also these examples:
 
// TestCube v1_0

// GPLv2

// (c) 2012 TakeItAndRun


xaxis=[1,0,0];

yaxis=[0,1,0];

zaxis=[0,0,1];


xshift=12;


// x is NOT defined to throug a warning

//x=5;

color("cyan")translate(00*xshift*yaxis)cube ([1,1,2]);

translate(0.2*xshift*yaxis)cube ([1,1,3],center=true);

color("cyan")translate(0.4*xshift*yaxis)cube (center=true,[1,1,4]);

translate(0.6*xshift*yaxis)cube(true,[1,2,5]);

color("cyan")translate(0.8*xshift*yaxis)cube(true,[1,2,5]);

translate(01.0*xshift*yaxis)cube();

color("cyan")translate(01.2*xshift*yaxis)cube(true);

translate(1.4*xshift*yaxis)cube(center=true);

color("cyan")translate(1.6*xshift*yaxis)cube(1,true);

translate(1.8*xshift*yaxis)cube(x);

color("cyan")translate(2*xshift*yaxis)cube([2,2,2]);

translate(2.2*xshift*yaxis)cube([2,2]);

color("cyan")translate(2.4*xshift*yaxis)cube([2]);

translate(2.6*xshift*yaxis)cube([2,2,2]);

color("cyan")translate(2.8*xshift*yaxis)cube([2,2,2,]);

translate(3.0*xshift*yaxis)cube([2,2,2,2]);

color("cyan")translate(3.2*xshift*yaxis)cube([2,2,2,2,]);

translate(3.4*xshift*yaxis)cube(.5);



for(i=[0:17]){

color("lime")translate(-.4*xshift*xaxis+i*0.2*xshift*yaxis)cube(1,true);

color("grey")rotate(90,yaxis)translate(i*.2*xshift*yaxis)cylinder(xshift,.05,.05,true);

}

 
gives the following output:
 
Inline-Bild 1
 
 
 
It seems 'cube([1,1,1],center=false)' is used to indicate an error, but sometimes nothing at all is generated.
IMHO, 'cube' should trough a warning as well in the case the parameters are different from what it expects.
 
I use OpenSCAD a lot, love it, for modeling complex designs.
 
Thanxs,
 
TakeItAndRun
 


 
2012/5/24 chrysn <[hidden email]>
hi developers,

openscad crashes when dxf_cross gets called with an invalid file name or
no file name at all.

i suppose there should be some errorhandling around src/dxfdim.cc:147,
or something else should take care of such things:

> Qt has caught an exception thrown from an event handler. Throwing
> exceptions from an event handler is not supported in Qt. You must
> reimplement QApplication::notify() and catch all exceptions there.
>
> terminate called after throwing an instance of
> 'boost::filesystem3::filesystem_error' what():
> boost::filesystem::file_size: No such file or directory

----------

by the way, there was some confusion about the arguments to dxf_cross in
the wiki[1] (and probably will still be until someone signs off the latest
changes).

is there any way we might get openscad function signatures out of the
source code? it seems there isn't as of now; the only ideas i have about
it are

* dangerous regular expressions to pseudoparse the source code
 (looking for Builtins::init for the function names and argnames loops
 / if statements for the arguments)

 (yuck) and

* adding doxygen-style comments or similar to every declaration of an
 openscad function

 (lots of work too).

the current situation (documentation very far from the code) seems to
make it very easy for problems to come up.

what are your ideas on this?


best regards
chrysn

[1] http://en.wikibooks.org/wiki/OpenSCAD_User_Manual/General#Getting_input

--
To use raw power is to make yourself infinitely vulnerable to greater powers.
 -- Bene Gesserit axiom

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad




--
[hidden email]

P.S. Falls meine E-Mail kürzer ausfällt als Dir angenehm ist:
Ich probiere gerade aus kurze Antworten statt gar keine Antworten zu schreiben.
Wenn Du gerne mehr lesen möchtest, dann lass es mich bitte wissen.

P.S. In case my e-mail is shorter than you enjoy:
I am currently trying short replies instead of no replies at all.
Please let me know, if you like to read more.

Enjoy!


TestCube v1_0.png (16K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: function signatures (new thread)

donbright
Hi Peter,

From what I have seen basically OpenSCAD uses 'intelligent guessing' to parse parameters. Let's take cube() for example, it is done inside src/primitives.cc

Imagine we say 'cube(0.5)'. You didn't say 'cube( size = 0.5 )'. But the code guesses that that is what you meant. It sets the 'Value' (see value.cc) of size to be 0.5 and type of NUMBER. Now, you didn't say what you want the 3 dimensions of the cube to be, you just fed a single number. So it assumes you want the dimensions all to be the same - 0.5. It creates a new Cube Node with x,y,z=0.5. 

What about cube([4,2,6])? Again, you didn't say "size", but it assumes you intended it.  The 'Value' of size is given (pseudocode) [4,2,6] and sets the type of the Value to VECTOR. The code detects this VECTOR type, and then it assumes you want your new Cube Node to have dimensions taken from the vector. x=4, y=2, z=6. 

The same is true of pretty much any function, from cube() to sphere() to color(), it is doing educated guessing about what people will write as arguments. For example, consider color([0.4,0.5,0.5]) sphere();. The code in transform.cc detects that you gave color() a VECTOR type Value, and modifies the transformation matrix accordingly. But if you have color("red"), it detects this is a STRING type Value, and does the table lookup. 

This makes it relatively easy to add and improve functions and the way they handle arguments, because there is no strict formal grammar to deal with. On the other hand, it makes it hard to use an automated documentation tool like doxygen, because there is no strict formal grammar to deal with. 

-DB



On Fri, May 25, 2012 at 11:23 AM, Peter Falke <[hidden email]> wrote:
Hi Chrysn, hi all
 
I second the quest for a listing of all commands with their possible parameters and their order directly from the code.
 
Chrysn, could you or any other people explain to me how I get the sorce code and in what files I have to look and what for I have to look to find them myself.
 
Could someone please explain how the overloading of a command with parameters works (e.g. cube(100,true), cube([0,1,2]), cube([0,1,]) ). See also these examples:
 
// TestCube v1_0

// GPLv2

// (c) 2012 TakeItAndRun


xaxis=[1,0,0];

yaxis=[0,1,0];

zaxis=[0,0,1];


xshift=12;


// x is NOT defined to throug a warning

//x=5;

color("cyan")translate(00*xshift*yaxis)cube ([1,1,2]);

translate(0.2*xshift*yaxis)cube ([1,1,3],center=true);

color("cyan")translate(0.4*xshift*yaxis)cube (center=true,[1,1,4]);

translate(0.6*xshift*yaxis)cube(true,[1,2,5]);

color("cyan")translate(0.8*xshift*yaxis)cube(true,[1,2,5]);

translate(01.0*xshift*yaxis)cube();

color("cyan")translate(01.2*xshift*yaxis)cube(true);

translate(1.4*xshift*yaxis)cube(center=true);

color("cyan")translate(1.6*xshift*yaxis)cube(1,true);

translate(1.8*xshift*yaxis)cube(x);

color("cyan")translate(2*xshift*yaxis)cube([2,2,2]);

translate(2.2*xshift*yaxis)cube([2,2]);

color("cyan")translate(2.4*xshift*yaxis)cube([2]);

translate(2.6*xshift*yaxis)cube([2,2,2]);

color("cyan")translate(2.8*xshift*yaxis)cube([2,2,2,]);

translate(3.0*xshift*yaxis)cube([2,2,2,2]);

color("cyan")translate(3.2*xshift*yaxis)cube([2,2,2,2,]);

translate(3.4*xshift*yaxis)cube(.5);



for(i=[0:17]){

color("lime")translate(-.4*xshift*xaxis+i*0.2*xshift*yaxis)cube(1,true);

color("grey")rotate(90,yaxis)translate(i*.2*xshift*yaxis)cylinder(xshift,.05,.05,true);

}

 
gives the following output:
 
Inline-Bild 1
 
 
 
It seems 'cube([1,1,1],center=false)' is used to indicate an error, but sometimes nothing at all is generated.
IMHO, 'cube' should trough a warning as well in the case the parameters are different from what it expects.
 
I use OpenSCAD a lot, love it, for modeling complex designs.
 
Thanxs,
 
TakeItAndRun
 


 
2012/5/24 chrysn <[hidden email]>
hi developers,

openscad crashes when dxf_cross gets called with an invalid file name or
no file name at all.

i suppose there should be some errorhandling around src/dxfdim.cc:147,
or something else should take care of such things:

> Qt has caught an exception thrown from an event handler. Throwing
> exceptions from an event handler is not supported in Qt. You must
> reimplement QApplication::notify() and catch all exceptions there.
>
> terminate called after throwing an instance of
> 'boost::filesystem3::filesystem_error' what():
> boost::filesystem::file_size: No such file or directory

----------

by the way, there was some confusion about the arguments to dxf_cross in
the wiki[1] (and probably will still be until someone signs off the latest
changes).

is there any way we might get openscad function signatures out of the
source code? it seems there isn't as of now; the only ideas i have about
it are

* dangerous regular expressions to pseudoparse the source code
 (looking for Builtins::init for the function names and argnames loops
 / if statements for the arguments)

 (yuck) and

* adding doxygen-style comments or similar to every declaration of an
 openscad function

 (lots of work too).

the current situation (documentation very far from the code) seems to
make it very easy for problems to come up.

what are your ideas on this?


best regards
chrysn

[1] http://en.wikibooks.org/wiki/OpenSCAD_User_Manual/General#Getting_input

--
To use raw power is to make yourself infinitely vulnerable to greater powers.
 -- Bene Gesserit axiom

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad




--
[hidden email]

P.S. Falls meine E-Mail kürzer ausfällt als Dir angenehm ist:
Ich probiere gerade aus kurze Antworten statt gar keine Antworten zu schreiben.
Wenn Du gerne mehr lesen möchtest, dann lass es mich bitte wissen.

P.S. In case my e-mail is shorter than you enjoy:
I am currently trying short replies instead of no replies at all.
Please let me know, if you like to read more.

Enjoy!


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad


Reply | Threaded
Open this post in threaded view
|

Re: function signatures (new thread)

clothbot
Something I've been meaning to implement (lack of time being the critical factor) is have the primitives and functions echo their usage and arguments when they are instantiated without any arguments.

That way when you're in doubt about what the arguments are and/or can't get to the webdocs, they'll always be easy to access in-program.

Andrew.

On 2012-05-26, at 2:49 PM, Don Bright wrote:

Hi Peter,

From what I have seen basically OpenSCAD uses 'intelligent guessing' to parse parameters. Let's take cube() for example, it is done inside src/primitives.cc

Imagine we say 'cube(0.5)'. You didn't say 'cube( size = 0.5 )'. But the code guesses that that is what you meant. It sets the 'Value' (see value.cc) of size to be 0.5 and type of NUMBER. Now, you didn't say what you want the 3 dimensions of the cube to be, you just fed a single number. So it assumes you want the dimensions all to be the same - 0.5. It creates a new Cube Node with x,y,z=0.5. 

What about cube([4,2,6])? Again, you didn't say "size", but it assumes you intended it.  The 'Value' of size is given (pseudocode) [4,2,6] and sets the type of the Value to VECTOR. The code detects this VECTOR type, and then it assumes you want your new Cube Node to have dimensions taken from the vector. x=4, y=2, z=6. 

The same is true of pretty much any function, from cube() to sphere() to color(), it is doing educated guessing about what people will write as arguments. For example, consider color([0.4,0.5,0.5]) sphere();. The code in transform.cc detects that you gave color() a VECTOR type Value, and modifies the transformation matrix accordingly. But if you have color("red"), it detects this is a STRING type Value, and does the table lookup. 

This makes it relatively easy to add and improve functions and the way they handle arguments, because there is no strict formal grammar to deal with. On the other hand, it makes it hard to use an automated documentation tool like doxygen, because there is no strict formal grammar to deal with. 

-DB



On Fri, May 25, 2012 at 11:23 AM, Peter Falke <[hidden email]> wrote:
Hi Chrysn, hi all
 
I second the quest for a listing of all commands with their possible parameters and their order directly from the code.
 
Chrysn, could you or any other people explain to me how I get the sorce code and in what files I have to look and what for I have to look to find them myself.
 
Could someone please explain how the overloading of a command with parameters works (e.g. cube(100,true), cube([0,1,2]), cube([0,1,]) ). See also these examples:
 
// TestCube v1_0
// GPLv2
// (c) 2012 TakeItAndRun

xaxis=[1,0,0];
yaxis=[0,1,0];
zaxis=[0,0,1];

xshift=12;

// x is NOT defined to throug a warning
//x=5;
color("cyan")translate(00*xshift*yaxis)cube ([1,1,2]);
translate(0.2*xshift*yaxis)cube ([1,1,3],center=true);
color("cyan")translate(0.4*xshift*yaxis)cube (center=true,[1,1,4]);
translate(0.6*xshift*yaxis)cube(true,[1,2,5]);
color("cyan")translate(0.8*xshift*yaxis)cube(true,[1,2,5]);
translate(01.0*xshift*yaxis)cube();
color("cyan")translate(01.2*xshift*yaxis)cube(true);
translate(1.4*xshift*yaxis)cube(center=true);
color("cyan")translate(1.6*xshift*yaxis)cube(1,true);
translate(1.8*xshift*yaxis)cube(x);
color("cyan")translate(2*xshift*yaxis)cube([2,2,2]);
translate(2.2*xshift*yaxis)cube([2,2]);
color("cyan")translate(2.4*xshift*yaxis)cube([2]);
translate(2.6*xshift*yaxis)cube([2,2,2]);
color("cyan")translate(2.8*xshift*yaxis)cube([2,2,2,]);
translate(3.0*xshift*yaxis)cube([2,2,2,2]);
color("cyan")translate(3.2*xshift*yaxis)cube([2,2,2,2,]);
translate(3.4*xshift*yaxis)cube(.5);


for(i=[0:17]){
color("lime")translate(-.4*xshift*xaxis+i*0.2*xshift*yaxis)cube(1,true);
color("grey")rotate(90,yaxis)translate(i*.2*xshift*yaxis)cylinder(xshift,.05,.05,true);
}
 
gives the following output:
 
Inline-Bild 1
 
 
 
It seems 'cube([1,1,1],center=false)' is used to indicate an error, but sometimes nothing at all is generated.
IMHO, 'cube' should trough a warning as well in the case the parameters are different from what it expects.
 
I use OpenSCAD a lot, love it, for modeling complex designs.
 
Thanxs,
 
TakeItAndRun
 


 
2012/5/24 chrysn <[hidden email]>
hi developers,

openscad crashes when dxf_cross gets called with an invalid file name or
no file name at all.

i suppose there should be some errorhandling around src/dxfdim.cc:147,
or something else should take care of such things:

> Qt has caught an exception thrown from an event handler. Throwing
> exceptions from an event handler is not supported in Qt. You must
> reimplement QApplication::notify() and catch all exceptions there.
>
> terminate called after throwing an instance of
> 'boost::filesystem3::filesystem_error' what():
> boost::filesystem::file_size: No such file or directory

----------

by the way, there was some confusion about the arguments to dxf_cross in
the wiki[1] (and probably will still be until someone signs off the latest
changes).

is there any way we might get openscad function signatures out of the
source code? it seems there isn't as of now; the only ideas i have about
it are

* dangerous regular expressions to pseudoparse the source code
 (looking for Builtins::init for the function names and argnames loops
 / if statements for the arguments)

 (yuck) and

* adding doxygen-style comments or similar to every declaration of an
 openscad function

 (lots of work too).

the current situation (documentation very far from the code) seems to
make it very easy for problems to come up.

what are your ideas on this?


best regards
chrysn

[1] http://en.wikibooks.org/wiki/OpenSCAD_User_Manual/General#Getting_input

--
To use raw power is to make yourself infinitely vulnerable to greater powers.
 -- Bene Gesserit axiom

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad




--
[hidden email]

P.S. Falls meine E-Mail kürzer ausfällt als Dir angenehm ist:
Ich probiere gerade aus kurze Antworten statt gar keine Antworten zu schreiben.
Wenn Du gerne mehr lesen möchtest, dann lass es mich bitte wissen.

P.S. In case my e-mail is shorter than you enjoy:
I am currently trying short replies instead of no replies at all.
Please let me know, if you like to read more.

Enjoy!


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad

--

"The future is already here.  It's just not very evenly distributed" -- William Gibson

Me: http://clothbot.com/wiki/



Reply | Threaded
Open this post in threaded view
|

Re: function signatures (new thread)

Christian Siefkes
In reply to this post by donbright
On 05/26/2012 08:49 PM, Don Bright wrote:
> The same is true of pretty much any function, from cube() to sphere() to
> color(), it is doing educated guessing about what people will write as
> arguments.

But the functions don't always guess the way you (or, at least, I) would
expect. linear_extrude(15) is not the same as linear_extrude(height = 15),
even though the height parameter comes first in the documentation. Instead
it seems to extrude to a much larger height, for whatever reason. That bit
me today.

Best regards and thanks to the OpenSCAD makers -- it's a great tool!
        Christian

--
|------- Dr. Christian Siefkes ------- [hidden email] -------
| Homepage: http://www.siefkes.net/ | Blog: http://www.keimform.de/
|    Peer Production Everywhere:       http://peerconomy.org/wiki/
|---------------------------------- OpenPGP Key ID: 0x346452D8 --
For there to be equivalence, the death penalty would have to punish a
criminal who had warned his victim of the date at which he would inflict a
horrible death on him and who, from that moment onward, had confined him
at his mercy for months. Such a monster is not encountered in private life.
        -- Albert Camus, Reflections on the Guillotine


signature.asc (262 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: function signatures (new thread)

Triffid Hunter
In reply to this post by donbright
On Sun, May 27, 2012 at 4:49 AM, Don Bright <[hidden email]> wrote:
Hi Peter,

From what I have seen basically OpenSCAD uses 'intelligent guessing' to parse parameters. Let's take cube() for example, it is done inside src/primitives.cc

Imagine we say 'cube(0.5)'. You didn't say 'cube( size = 0.5 )'. But the code guesses that that is what you meant. It sets the 'Value' (see value.cc) of size to be 0.5 and type of NUMBER. Now, you didn't say what you want the 3 dimensions of the cube to be, you just fed a single number. So it assumes you want the dimensions all to be the same - 0.5. It creates a new Cube Node with x,y,z=0.5.

I'm pretty sure they're purely positional unless named, so the primitive for cube may be cube(size=1, center=false); thus doing cube(0.5) passes 0.5 in the 'size' position, and indeed if you do cube(10, true) then you get a centered cube whereas cube(true, 10) doesn't work. 

I've written my own modules using this understanding to good effect, putting the size parameters as the first ones and others later.

As Christian says, not all functions are constructed sensibly for this usage for some reason.

tl;dr: no intelligent guessing at all, just purely positional parameters arranged sensibly in many cases.

Reply | Threaded
Open this post in threaded view
|

Re: function signatures (new thread)

donbright
In reply to this post by Christian Siefkes
On Sat, May 26, 2012 at 2:43 PM, Christian Siefkes
<[hidden email]> wrote:

> On 05/26/2012 08:49 PM, Don Bright wrote:
>> The same is true of pretty much any function, from cube() to sphere() to
>> color(), it is doing educated guessing about what people will write as
>> arguments.
>
> But the functions don't always guess the way you (or, at least, I) would
> expect. linear_extrude(15) is not the same as linear_extrude(height = 15),
> even though the height parameter comes first in the documentation. Instead
> it seems to extrude to a much larger height, for whatever reason. That bit
> me today.
>
> Best regards and thanks to the OpenSCAD makers -- it's a great tool!
>        Christian
>
> --
> |------- Dr. Christian Siefkes ------- [hidden email] -------
> | Homepage: http://www.siefkes.net/ | Blog: http://www.keimform.de/
> |    Peer Production Everywhere:       http://peerconomy.org/wiki/
> |---------------------------------- OpenPGP Key ID: 0x346452D8 --
> For there to be equivalence, the death penalty would have to punish a
> criminal who had warned his victim of the date at which he would inflict a
> horrible death on him and who, from that moment onward, had confined him
> at his mercy for months. Such a monster is not encountered in private life.
>        -- Albert Camus, Reflections on the Guillotine
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
>

Here is a patch to make linear_extrude work as you expect:

https://github.com/openscad/openscad/compare/linear_extrude_argument

The problem of course with changing these things is you might
accidentally effect how existing .scad files work. So Im not sure if
this will get accepted into 'master' but it does demonstrate how this
sort of modification can be accomplished.

-DB

Reply | Threaded
Open this post in threaded view
|

Re: function signatures (new thread)

Peter Falke
Tank you all for the explanations.
 
Gruß,
 
TakeItAndRun
 
2012/5/28 Don Bright <[hidden email]>
On Sat, May 26, 2012 at 2:43 PM, Christian Siefkes
<[hidden email]> wrote:
> On 05/26/2012 08:49 PM, Don Bright wrote:
>> The same is true of pretty much any function, from cube() to sphere() to
>> color(), it is doing educated guessing about what people will write as
>> arguments.
>
> But the functions don't always gue

ss the way you (or, at least, I) would
> expect. linear_extrude(15) is not the same as linear_extrude(height = 15),
> even though the height parameter comes first in the documentation. Instead
> it seems to extrude to a much larger height, for whatever reason. That bit
> me today.
>
> Best regards and thanks to the OpenSCAD makers -- it's a great tool!
>        Christian
>
> --
> |------- Dr. Christian Siefkes ------- [hidden email] -------
> | Homepage: http://www.siefkes.net/ | Blog: http://www.keimform.de/
> |    Peer Production Everywhere:       http://peerconomy.org/wiki/
> |---------------------------------- OpenPGP Key ID: 0x346452D8 --
> For there to be equivalence, the death penalty would have to punish a
> criminal who had warned his victim of the date at which he would inflict a
> horrible death on him and who, from that moment onward, had confined him
> at his mercy for months. Such a monster is not encountered in private life.
>        -- Albert Camus, Reflections on the Guillotine
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
>

Here is a patch to make linear_extrude work as you expect:

https://github.com/openscad/openscad/compare/linear_extrude_argument

The problem of course with changing these things is you might
accidentally effect how existing .scad files work. So Im not sure if
this will get accepted into 'master' but it does demonstrate how this
sort of modification can be accomplished.

-DB
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad



--
[hidden email]

P.S. Falls meine E-Mail kürzer ausfällt als Dir angenehm ist:
Ich probiere gerade aus kurze Antworten statt gar keine Antworten zu schreiben.
Wenn Du gerne mehr lesen möchtest, dann lass es mich bitte wissen.

P.S. In case my e-mail is shorter than you enjoy:
I am currently trying short replies instead of no replies at all.
Please let me know, if you like to read more.

Enjoy!

Reply | Threaded
Open this post in threaded view
|

Re: function signatures (new thread)

Christian Siefkes
In reply to this post by donbright
Hi Don, all,

On 05/28/2012 11:35 PM, Don Bright wrote:

> On Sat, May 26, 2012 at 2:43 PM, Christian Siefkes
> <[hidden email]> wrote:
>> But the functions don't always guess the way you (or, at least, I) would
>> expect. linear_extrude(15) is not the same as linear_extrude(height = 15),
>> even though the height parameter comes first in the documentation. Instead
>> it seems to extrude to a much larger height, for whatever reason. That bit
>> me today.
>
> Here is a patch to make linear_extrude work as you expect:
>
> https://github.com/openscad/openscad/compare/linear_extrude_argument
>
> The problem of course with changing these things is you might
> accidentally effect how existing .scad files work. So Im not sure if
> this will get accepted into 'master' but it does demonstrate how this
> sort of modification can be accomplished.
thanks a lot, it would be great if that patch was accepted! It changing
existing .scad files seems quite unlikely to me, since the current behavior
doesn't seem to be reasonable (or do I just not understand it?), so it seems
unlikely that anybody would actually rely on it. Or what do others think?

Best regards
        Christian

--
|------- Dr. Christian Siefkes ------- [hidden email] -------
| Homepage: http://www.siefkes.net/ | Blog: http://www.keimform.de/
|    Peer Production Everywhere:       http://peerconomy.org/wiki/
|---------------------------------- OpenPGP Key ID: 0x346452D8 --
Work is punishment for failing to procrastinate effectively.


signature.asc (262 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: function signatures (new thread)

chrysn
In reply to this post by Peter Falke
On Fri, May 25, 2012 at 06:23:50PM +0200, Peter Falke wrote:
> I second the quest for a listing of all commands with their possible
> parameters and their order directly from the code.

probably relevant to this thread: the function signatures for
linear_extrude[1] & co are outdated in that they describe deprecated
parameters, and even the successor functions to
linear_extrude(filename=), import_dxf[2], are deprecated by now.

the wiki could take some love with respect to deprecations, at latest
with the next release.

(by the way: is there *any* way to search wikibooks for a string inside
a *particular* book? just searching for "square" in the search box
yields results from other books, and the workaround i'm using quite now
includes advanced google queries...)

regards
chrysn (forwarding a bug report sent directly to me)

[1] http://en.wikibooks.org/wiki/OpenSCAD_User_Manual/DXF_Extrusion
[2] http://en.wikibooks.org/wiki/OpenSCAD_User_Manual/2D_Primitives

signature.asc (836 bytes) Download Attachment