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 <[email protected]> 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 <[email protected]> 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 > > [email protected] > > 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
_______________________________________________ gmsh mailing list [email protected] http://onelab.info/mailman/listinfo/gmsh
