Introducing safe_wren

114 views
Skip to first unread message

Eric Seidel

unread,
Oct 22, 2021, 8:57:04 PM10/22/21
to wren...@googlegroups.com, munifi...@gmail.com, Adam Barth

Hi wren community!


[I also bcc’d some of the numerous authors of wren-related rust packages from crates.io.  Apologies if this email is unwanted.]


Adam Barth and I have been translating Wren from C to Rust these last few months.  Mostly for our own enjoyment (and as an excuse to learn Rust), but the project got far enough along we figured we should at least tell this community.


We called it “safe_wren” because all the other wren* related package names were already taken on crates.io, and probably the biggest difference from the original wren is that it is safe against arbitrary inputs. It should never crash from inputs, I’ve fuzzed it for days.


It exposes both a C API (about 90% of the original wren’s C API) and a not-very-polished Rust API.  I’ve only tested it locally.  It works at least as a drop-in replacement with wren_test compiled from wren’s c implementation.  I’ve not yet tried to integrate it with something more complicated.


Safe_wren passes 818 tests (skips 81) of the official test suite. We added 33 tests while writing safe_wren.


The license is MIT and identical to the original wren (we modeled the code heavily on the original C).


Differences from the original wren code (or wren_c as we call it).

  • Never crashes to bad input (but can currently still be hung via infinite loops)

  • Reference-counted, not (yet) garbage collected (in progress).

  • Requires utf8 input and wren Strings are strings of utf8, not byte-buffers (safe_wren does not allow invalid utf8 bytes)

  • Stops at first compile error (instead of continuing)

  • Does not (yet) allow overriding the allocator or setting heap size constraints.

  • Still missing opt-meta, and class attributes

  • Currently 2x slower than wren_c on some microbenchmarks (should be comparable after GC work completes)


Unsure if it will be useful to anyone, but it’s available on GitHub:

https://github.com/RubberDuckEng/safe_wren

and published on crates.io:

https://crates.io/crates/safe_wren


Patches and feedback welcome!

https://github.com/RubberDuckEng/safe_wren/issues

You’re also welcome to come heckle us on our weekly web show (which is where we did most of this development):

https://www.youtube.com/c/RubberDuckEng.

In our last few shows we started writing a GC in Rust with plans to eventually integrate it into safe_wren.

https://github.com/RubberDuckEng/vmgc


Eric

Michel Hermier

unread,
Oct 23, 2021, 5:33:21 AM10/23/21
to wren-lang
Hi,
I took a little time to read the code, to make a quick review. Firstly, nice effort, having multiple implementation is great for the community and life of a project.
I'm not particularly fluent or have more experience then reading code/watching stream about rust, so my understanding might be biased by my polyglot understanding of computational languages.

To me, the implementation does look too much like wren C "oxidized". Parts definitely needs some love, and seems to lack some abstraction/reorganization. One example is InputManager that reimplent an input stream combined with the tokenizer if I'm not mistaken.

I don't fully understand the borrow model, but it seems to be a great pain to properly implent the garbage collected memory. In particular accessing the content seems to requires a proxy value, with quite a bunch of unsafe code, and I wonder how hard/slow/safe it really is, to properly implement the borrow model.

Other than that, it is working and it is the most important so you can build on top of it and make it more rust/correct.
Reply all
Reply to author
Forward
0 new messages