Who here's familiar with Rust? And it's automatic code generation facilities?
I want some advice.
@alcinnz if you still want advice, I might be able to help
To set some context I'm implementing my own browser engine (I'm happy to discuss why, but I don't think it's relevant here) and the trickiest bit so far has been parsing CSS properties.
So I created a program which reads in an internal domain specific language and outputs piles of match statements and type declarations as text files.
I find that program extremely helpful in coping with even a relative few CSS properties, but I don't like maintaining it.
1. What sort of advice are you looking for?
2. If it makes you feel better, librsvg is though the fourth or fifth refactoring of parsing CSS properties. It uses Rust macros, mostly.
3. ... and Servo is on its Nth, and it's still not finished. It generates tons of Rust code from Mako/Python templates. It feels to me like they wanted Rust proc-macros, but they weren't ready when they wrote that code.
@alcinnz you can use a build script with cargo. In fact, they have an example of code generation right in the cargo docs: https://doc.rust-lang.org/cargo/reference/build-scripts.html#case-study-code-generation
You can make your code generation library a crate, include it as a `[build-dependency]`, then use it in your `build.rs` file to generate code at build time
https://gitlab.gnome.org/GNOME/librsvg/blob/master/rsvg_internals/src/properties.rs is where most of this happens in librsvg - it could certainly be compressed with some codegen and such. Grep for make_property! there.
This translation is implemented at:
And the full project is at:
It's very far from complete, but my goal is to see how much simpler a browser can be without implementing any JS APIs.
@alcinnz @balrogboogie I have an example of a code generator with the quote crate here: https://gitlab.gnome.org/federico/gnome-class/tree/master/src/gen
Probably start with boilerplateext.rs - that has the toplevel code, which interpolates sub-pieces into it. Grep for "quote!" in that file.
And no, I'm not planning on implementing everything myself (WebRender will be very handy for one thing). With the cssparser crate I basically just failed to look into it, not that I'm finding the parsing (other than the CSS properties) to be too difficult. I'll look into that too.
But it was a conscious decision that I wanted to handle parsing CSS properties outside of CSS parsing/selection/cascade.
(cssparser is not a full parser; it's more of a CSS tokenizer, and you must build the actual parsing code from it. It leaves all the data structures up to you. It has traits to parse e.g. selectors and at-rules, but expects you to provide the corresponding data structures. *Very* happy to talk about this if you want; one of the next steps in librsvg is supporting that.)
@alcinnz sure, what's up?
FLOSS.social was launched on 1 April 2018 as a Mastodon instance for people who care about, support, or build Free, Libre, and Open Source Software (FLOSS). Of course, discussions aren't limited to just FLOSS -- let's share our unique interests! English is preferred for maximum conversation opportunities within the FLOSS community, but it is not required. Respect is required, however: Users on FLOSS.social agree to abide by the Contributor Covenant Code of Conduct. This service was installed and is maintained in part by Masto.Host with equipment located at OVH. You can support this instance financially through the Monthly Supporter Program, processed through CommitChange using the free software Houdini Project.