[Gmsh] Rust bindings experiment

[Max Orok]

Hi everyone,

I've been doing a little work on the Rust API implementation and I have
some minimal examples up and running.

You can take a look at how the API is shaping up here:
https://mxxo.github.io/rgmsh/rgmsh/index.html
There are some more in-depth examples here:
https://mxxo.github.io/rgmsh/rgmsh/model/index.html

It is still very work-in-progress :)

There are some differences compared to the current API, based on some
issues I run into a lot.

1. I have a lot of trouble keeping tags straight.
A lot of my bugs come from mismatching tags (e.g. using View tags where
Field tags are required, etc.)

I am trying to make the tags a little more explicit by giving them all
types.

That way, you can see what kind of tags a function expects,
and how to get that kind of tag (e.g. add_point returns a PointTag, etc.)

// make a pointlet p1: PointTag = geom.add_point(0., 0., 0.)?;// and
anotherlet p2: PointTag = geom.add_point(1., 1., 0.)?;
// create a line from the two pointslet l1: CurveTag = geom.add_line(p1, p2)?;


Done properly, this catches more of my dumb errors at compile time,
because functions that take tags won't compile given the wrong kind of input.


// try to make a line from two raw integerslet l1 = geom.add_line(1,
2); // won't compile


2. For some functions with lots of parameters, I usually have
to have the documentation open to understand what the function is doing.

I want to try experimenting with making these longer functions more
explicit.

For example, to add a torus in the C++ API, you could use:

gmsh::model::occ::addTorus(1, 1, 1, 3, 0.2);

and you could probably guess what each parameter means.
It's also nice and quick to write :)

Here is one alternative implementation idea:

let centroid = Point { x: 1.0, y: 1.0, z: 1.0 };let torus = geom.add_torus(
    Torus {
      centroid,
      main_radius: 3.0,
      pipe_radius: 0.2
    })?;


It's more verbose, but arguably clearer to someone else reading your code
(and hopefully easier to debug if the result wasn't as expected etc).
When I make API calls, I usually try and document what each parameter was,
and this style reduces the burden on me to explain what I'm doing.

I hope to allow both styles so that people used to "quick and dirty" calls
don't have to change unless they want to.

Thank you very much for your time.
Max



On Sat, Jul 27, 2019 at 2:30 PM Christophe Geuzaine <cgeuzaine at uliege.be>
wrote:

>
> Hi Max,
>
> Sounds cool - we've never used Rust... The simplest is indeed probably to
> just wrap our official C bindings.
>
> Christophe
>
> > On 26 Jul 2019, at 21:59, Max Orok <morok at mevex.com> wrote:
> >
> > Hello everyone,
> >
> > I was thinking about a set of Rust bindings for the Gmsh C API (v4.4)
> and made a very raw set using the bindgen tool:
> > https://github.com/mxxo/gmsh-sys
> >
> > For a more idiomatic Rust API, I'll be following the re-implementation
> of the C++ API in C (gmsh.h_cwrap) as a guide.
> >
> > The naming for Rust's package manager is first come first serve (and
> undeleteable), so I thought I'd see if there were any objections to
> registering a "gmsh-sys" low-level C binding crate and a "gmsh" idiomatic
> Rust API crate.
> >
> > On the one hand, bindgen automatically generated Rust wrappers for
> Gmsh's C header, so it could theoretically be part of the build pipeline
> and included in the main repo. On the other hand, there may not be a huge
> appetite for Rust support among Gmsh's users, especially compared to C++
> and Python. My impression is using Rust for scientific codes is a bit of an
> ongoing experiment.
> >
> > On the maintenance side, packaging up an unofficial library crate for
> distribution might be an interesting possibility without Gmsh having to
> explicitly support yet another language API using the generator, especially
> with the semantic differences for things like error handling.
> >
> > Please let me know if you have any comments or suggestions.
> >
> > Have a nice weekend!
> >
> > Max
> > --
> > Max Orok
> > Contractor
> > www.mevex.com
> >
> >
> > _______________________________________________
> > gmsh mailing list
> > gmsh at onelab.info
> > http://onelab.info/mailman/listinfo/gmsh
>
> —
> Prof. Christophe Geuzaine
> University of Liege, Electrical Engineering and Computer Science
> http://www.montefiore.ulg.ac.be/~geuzaine
>
>
>
>

-- 
Max Orok
Contractor
www.mevex.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://onelab.info/pipermail/gmsh/attachments/20191119/6245a5cb/attachment-0001.html>