include() statement and external "functions" usage

[RustyJoeM]

hello,

this is a question rather than actual issue...

Have you considered adding support for include() statement of external .scad files for resulting output scad code?

To allow adding include into resulting code, and place calls to external functions with rust-code defined parameters, where needed/appropriate - sort of new ScadElement enum type that would allow to add arbitrary included scad functions with defined (named) parameters that would contain values from rust.

e.g.:

include <BezierScad.scad>   # some public "lib" avialable for scad, with no need for us to generate innards in rust

// ... custom code generated by this crate, plus, somewhere, following:

	minkowski() {    # no problem here, ScadElement::Minkowski
		linear_extrude(1)    # no proplem again, ScadElement::LinearExtrude
		BezLine(s, width = [0.1], resolution = DETAIL_LEVEL, centered = false, showCtls = false);  # this line is scad call to included file, where values/value names are coming from rust code

Not sure if this could be implemented using some simple new ScadElement enum type with HashMap input that would allow to define function name plus param names/values or something similar...

[TheZoq2]

I had not considered that possibility, and I don't think i personally have a use for it, but it does sound like a neat idea!

I'm not sure what the best way to do it would be. One simple way might be to to add a way to specify include files in he ScadFile objects, and adding a new scad element as you suggested

[RustyJoeM]

I discovered your crate only like 2 hours back, ad am thinking of using it to transform my cumbersome and partially unfinished scad scripts for 3d printable model into neater Rust program...

Myself being Rust beginner (only one small app finished so far here on github), I do not want to promise anything, though I will maybe try to put together a rough pull request with an attempt.

My current rough idea is with two new ScadElement types, one for inclusion (simple string param should suffice), other for included functions invocation (normal vs named params as HashMap or Vector of tuples / other?)

edit:
(or, inclusion not as ScadElement, though ScadFile param/"setter"... I need to investigate include() statement on scad wiki/docs to see reasonable use-cases)

[TheZoq2]

Sounds good! Fun fact: this was my first serious rust project that I wrote. Let me know if you run into any issues :)

Regarding the implementation I think it might be neater to not have an include ScadElement as that would allow you to do weird things like adding children to the include directory

scad!(Include("file.scad"); cube(...))

I imagine it could be done similarly to how the file detail is specified here https://github.com/TheZoq2/Rust-Scad/blob/master/src/scad_file.rs#L17 and here https://github.com/TheZoq2/Rust-Scad/blob/master/src/scad_file.rs#L41

[RustyJoeM]

😆 exactly same idea/alert popped into my mind before editing my latest comment, and redirecting my thoughts to ScadFile setting instead...

[RustyJoeM]

I started to implement this on a fork today, but am struggling with representation of the function direct and named arguments...
Adding arguments as Strings might be easiest and straightforward (manageable by me), but it feels to be poor choice, due to need to construct strings before ScadElement creation, instead of utilizing the ScadType trait's already implemented get_code() methods for various types of values...

Combination of lifetimes for references or insane Vec<Box<dyn ScadType> trait clone restrictions seem are over my current Rust skill to implement this properly.

Will try to cope with it a bit more, though does not look good, my head keeps exploding... :)

edit:

Currently new ScadElement felt like a good start point:

FunctionCall(String, FnCallParams),

pub type FnCallArgs = Vec<Box<dyn ScadType>>;
pub type FnCallNamedArgs = Vec<(String, Box<dyn ScadType>)>;

#[derive(Clone)]
pub struct FnCallParams {
    pub args: Option<FnCallArgs>,
    pub named_args: Option<FnCallNamedArgs>,
}

however Clone trait implementation for FnCallParams keeps me brain-locked and I find it over-complicated to provide Rust safe implementation, as compared to good old dangerous C code i'm used to :)

[RustyJoeM]

Progress committed as:

RustyJoeM@66726d7

Current limitation for include statement - i put it into "header" of resulting file, though it should be usable also further in .scad file, to allow user variables pre-setting before include and variables overwrite...(https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Include_Statement)

Include is added as a new setting for ScadFile, and FunctionCall as a new ScadElement.

Arguments/ named arguments are defined as optional Rc<> wrapped Vector, to prevent need to implement clones or define explicit lifetimes for already existing ScadObject variants. (at least that is direction where my experiments lead me, not sure if this would really be necessary).

I still need to experiment with usage and see how it handles. Please let me know if oyu have time your opinions on current direction... (i'm more than opened to criticism ;) )

[RustyJoeM]

I opened pull request #9 with usage example excerpt in the PR comment.