github Taaitaaiger/jlrs v0.10.0
V0.10.0

latest releases: v0.21.1, v0.21.0, v0.20.0...
3 years ago

It's finally done, 7717 added and 5555 removed lines later, jlrs 0.10 is here. In case you're not familiar with this crate, jlrs offers bindings to the Julia C API. As you can guess from that number of changed lines, this is a majorly backwards-incompatible release.

The first thing I want to mention is that I've dropped support for Windows, at least for now. I couldn't get it to build on my own computer anymore, CI broke after introducing CCall::uv_async_send, and I had been unable to update the dependency on bindgen of jl-sys for a while now. Like MacOS, I'd love to (re)introduce support but I just don't use these operating systems myself.

Next, the jlrs-ndarray crate is now a part of jlrs and its fuctionality can be made available by enabling the jlrs-ndarray feature flag. This is part of a larger effort to reorganize the code. In particular, there's no longer a single traits module with all traits, but things have been split out a bit. Traits that deal with converting data between Rust and Julia can be found in the convert module and traits that deal with type layouts in the layout module.

Obviously, those changes aren't the cause of that huge number of changed lines. No, that's due to a more fundamental change. Julia is a language with a garbage collector which owns all Julia data and when using the C API, it must be "told" what values are in use. This previously involved a lot of things called frames which was confusing, and had some technical issues such as a requirement to declare the amount of space that would be dedicated to GC-related bookkeeping, the (GC-)stack size. This has all changed significantly and is the source of most changed lines.

It's no longer possible to declare a stack size when initializing Julia. The stack will normally be large enough, and is now able to grow in the rare case that not enough memory is allocated for this bookkeeping. The main entrypoint to interact with Julia no longer called frame, but scope. All interactions with Julia take place inside a scope. Methods like Julia::scope take a closure that is executed in that scope. Methods that new values now uses the Scope trait rather than the Frame trait. This trait also offers the methods Scope::value_scope and Scope::result_scope which can be used to create a nested scope, with its own frame, but root the final result in the current frame. This replaces the old construction with Outputs that could be reserved in arbitrary frames.

These changes also affect the async runtime. AsyncFrame is now called AsyncGcFrame and offers the same functionality as GcFrame does as well as async variations of the methods that create nested scopes. It's no longer possible to declare a stack size, and the number of threads that Julia will use can only be set with the JULIA_NUM_THREADS environment variable.

Finally, the method CCall::uv_async_send has been added. This can be used when calling Rust from Julia with ccall in combination with Base.AsyncCondition to offload your work to another thread, return from the ccall'ed function, and wait for the actual work to complete without blocking Julia.

Don't miss a new jlrs release

NewReleases is sending notifications on new releases.