I think you could do something like your first implementation (Tree1), but without the phantom data marker and 'static lifetime: just hold a libfive_tree (which is an opaque pointer), and call libfive_tree_delete in the impl Drop.

Internally, the libfive_tree object is already a reference-counted DAG; it frees itself (and any children that become orphans) when the last copy is deleted with libfive_tree_delete. Since it's reference-counted inside the libfive API, you can't make it Copy, but it could be Clone by adding something like this to libfive.cpp:

void libfive_tree_clone(libfive_tree ptr)
{
    // Build a new tree (increasing the refcount), then release it (without
    // decrementing the refcount) to create a spare raw pointer.  This must
    // be deleted with `libfive_tree_delete` to avoid memory leaks.
    Tree(ptr).release()
}

I'd vote against re-implementing the DAG + stdlib in Rust: the DAG already exists behind the scenes, and the whole point of the C++ stdlib + C API is to avoid rewriting it in every language 😛 .

So I now have two implementations for Tree in Rust.

Using references with (mandatory) lifetimes:

pub struct Tree1<'a> {
    tree: sys::libfive_tree,
    _marker: PhantomData<*mut &'a ()>,
}

impl Tree<'static> {
    pub fn x() -> Self {
        Self {
            tree: unsafe { sys::libfive_tree_x() },
            _marker: PhantomData,
        }
    }

    ...
}

impl<'a> Tree<'a> {
    pub fn union_self<'b>(&'b self, b: &'b Tree) -> Tree<'b> {
        Tree {
            tree: unsafe { sys::libfivestd_union(self.tree, b.tree) },
            _marker: PhantomData,
        }
    }
    
    ...
}

impl<'a> Drop for Tree1<'a> {
    fn drop(&mut self) {
        unsafe { sys::libfive_tree_delete(self.tree) };
    }
}

This variant is straightforward. Everything takes references; including any operators. This is reasonably easy to implement. Leaf nodes have 'static lifetimes. Everything else is tracked with individual lifetimes.

This all works. But everything being references, issues arise once you want to move Tree1s around because of Rust's move semantics. I.e. great for quick results and demo apps but probably not so much for a real CAD app.

The 2nd variant uses Rc and basically creates a copy of the tree to track ownership for getting deallocations right. Also this allows to easily keep copies of (sub)Tree2s and move them around in an app:

pub struct Tree2 {
    tree: Rc<sys::libfive_tree>,
    child_a: Option<Rc<Tree2>>,
    child_b: Option<Rc<Tree2>>,
}

impl Tree2 {
    pub fn x() -> Self {
        Self {
            tree: Rc::new(unsafe { sys::libfive_tree_x() }),
            child_a: None,
            child_b: None,
        }
    }
    
    pub fn union(self, b: Tree2) -> Self {
        Self {
            tree: Rc::new(unsafe { sys::libfivestd_union(*self.tree, *b.tree) }),
            child_a: Some(Rc::new(self)),
            child_b: Some(Rc::new(b)),
        }
    }
    
    ...
}

impl Clone for Tree2 {
    fn clone(&self) -> Self {
        Self {
            tree: Rc::new(*self.tree.as_ref()),
            child_a: self.child_a.as_ref().map(|t| t.clone()),
            child_b: self.child_b.as_ref().map(|t| t.clone()),
        }
    }
}

impl Drop for Tree2 {
    fn drop(&mut self) {
        if 1 == Rc::strong_count(&self.tree) {
            unsafe { sys::libfive_tree_delete(*self.tree) };
        }
    }
}

The second variant is modeled so that a tree has full ownership of all children. Subtrees can be cloned and deallocation happens as expected because of the use of Rc.

The issue here is the standard lib. Many operators take more than two operands. So if I want to wrap that I have two options:

1. Swap out child_a & child_b for a children: Vec<Tree2> and use the stdlib.h header.
2. Just RRIR, stdlib_impl.cpp that is.

I'm currently leaning towards 2. as that is probably also just 1h of search & replace, mostly.

Any thoughts/suggestions/ideas?

Thank you!!! Will check

On Fri, May 7, 2021 at 9:18 AM Doug Moen ***@***.***> wrote:

Merged #127 https://github.com/curv3d/curv/pull/127 into master.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/curv3d/curv/pull/127#event-4701827191, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFMFLVVF6HHQB7WJS37S4WLTMPRY3ANCNFSM44IUFFEA .

Justification

I was trying to model a bridge truss and it was slow unioning a number of strokes. Polyline was derived from IQ's polygon function, sans the signed internal function and added stroke size (d).

How to test

polyline {d:0.1, v:[[0,0],[1,0],[1,1],[0,0]]}  // right triangle

polyline {d:0.1, v:[[0,0],[1,0],[1,1],[0,0]]} >> extrude 0.2

Hey @Xiaoyuew check out this new shape primitive. It solves the performance problem of "large union", in the specific case of a set of stroke primitives.

This is from line 236 in libfive.h:

[[deprecated("use libfive_tree_nullary instead")]]
libfive_tree libfive_tree_nonary(int op);

Which makes clang fall over with:

  /Users/moritz/code/libfive/build/libfive/include/libfive.h:236:2: error: expected expression
  /Users/moritz/code/libfive/build/libfive/include/libfive.h:237:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
  /Users/moritz/code/libfive/build/libfive/include/libfive.h:237:1: error: redefinition of 'libfive_tree' as different kind of symbol
  /Users/moritz/code/libfive/build/libfive/include/libfive.h:188:31: note: previous definition is here
  /Users/moritz/code/libfive/build/libfive/include/libfive.h:237:13: error: expected ';' after top level declarator
  /Users/moritz/code/libfive/build/libfive/include/libfive.h:236:2: error: expected expression, err: true
  /Users/moritz/code/libfive/build/libfive/include/libfive.h:237:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int], err: false
  /Users/moritz/code/libfive/build/libfive/include/libfive.h:237:1: error: redefinition of 'libfive_tree' as different kind of symbol, err: true
  /Users/moritz/code/libfive/build/libfive/include/libfive.h:237:13: error: expected ';' after top level declarator, err: true

I think this [[...]] stuff is C++14 and later but a C compiler can't understand it?

What I have done in my fork is to prefix every function in stdlib.h with libfivestd_. I also changed the gen_c.py to do the right thing already. I.e. generated files hav no diff with previous ones except signatures in C API.

Would you accept a PR for this if I changed the the other binding generator scripts accordingly and everything builds/runs/tests fine?

Yeah, I get it. I wrote a gen_rust.py and there I have the issue with move (Rust keyword). I swap that out for moveit.

Justification

Run make test and make release build in macos environment for PR and master builds. See https://github.com/curv3d/curv/pull/125#issuecomment-832831058

How to test

• go to github Actions tab
• verify workflow logs

Not quite – this is because the C and C++ union need to be distinguished by the bindings generator, and functions which take zero arguments but return different types aren't allowed.

union is a keyword in C/C++, so the name union() would not work.

Thanks for isolating this 1 line change in a separate pull request. Processing this change was a big deal for me.

See subject.

make test contains unit tests that ensure that the *.gpu files generated by the examples do not change. Because I don't want to break the GPU code generator by accident when I am refactoring code. But when there is a deliberate change (as in this pull request) then I need to regenerate all of the files in tests/gpu/*.gpu.

Ideally, I would create a github action to run 'make test' after every change to libcurv/* or curv/*. Then we would have received automatic notification of the test faiure after you created the pull request. But I haven't got around to learning how github actions work. There is a github action for rebuilding Curv on windows, but it wasn't my contribution.

So I abandoned my tries to get the C++ header through bindgen for the time being.

I have a rough version of the Rust API in place – https://github.com/virtualritz/libfive-rs.

This contains libfive itself as a subrepo under libfive-sys. This is built from source. Currently this tracks my fork as I have added a libfivestd_ prefix to the stdlib.h functions (see #432).

Feedback welcome. Probably best to build the docs to get an idea.

cargo doc -p libfive --no-deps --open

Not sure how to ever get this published on docs.rs since that is sandboxed so all dependencies must be part of the package.

With boost being one that is pretty much impossible due to crates.io size constraints, I guess.

Yes, that fixes it for me.

Thanks, fixed!

I get several dozens of those:

libfive/libfive-sys/libfive/libfive/stdlib/stdlib.h:80:37: error: must use 'struct' tag to refer to type 'tvec3'

Adding two typedefs to stdlib.h fixes this:

typedef struct tvec2 tvec2;
struct tvec2 {
    libfive_tree x, y;
};
typedef struct tvec3 tvec3;
struct tvec3 {
    libfive_tree x, y, z;
};

Does this work with

__attribute__((deprecated("deprecated", "libfive_tree_nullary")))
libfive_tree libfive_tree_nonary(int op);

?

When using something like bindgen it is preferable to use whitelisting (allowlisting).

Unfortunately the stdlib functions do not have a prefix so if one wants to generate bindings for those, only blacklisting (blocklisting) is possible which is tedious and never really prevents everything unrelated to be filtered out from the bindings, unless one starts blacklisting individual items.

Would is be possible to also prefix the stdlib.h functions with libfive_?

I get several dozens of those:

libfive/libfive-sys/libfive/libfive/stdlib/stdlib.h:80:37: error: must use 'struct' tag to refer to type 'tvec3'

Adding two typedefs to stdlib.h fixes this:

typedef struct tvec2 tvec2;
struct tvec2 {
    libfive_tree x, y;
};
typedef struct tvec3 tvec3;
struct tvec3 {
    libfive_tree x, y, z;
};

'make test' now passes all tests again. I think we are done.