I don't know how tightly integrated the zig definitions (RocStr etc.) are with the compiler.
Is there a reason they use a (now very) old version of zig? If not what would be the process for upgrading it to either 0.9.0, master, or (waiting to around November) the upcoming self hosted 0.10.0 compiler?
Additionally, would you accept changes to the zig definitions to use a different style/updated style? I also love to make the platform work with the zig allocator interface so you could change one line and use a different allocator for your roc code?
(Theoretically would it be possible to either compile separate roc .o files with different allocator link functions or even just define/change the function pointers used so certain calls to roc [if used as a library as I asked in #beginners] used different allocators?)
We're working on the 0.10 upgrade. 0.10 is not yet released. We are on the latest released version I think.
When you say "now very old" what are you referring to exactly? We're on 0.9
Maybe I'm thinking of the roc example platform?
I remember recently having to get 0.8.0 to do something in the roc repo
Maybe not
I'll double check, but what about the other suggestions?
we're working on 0.10 but it has a bunch of bugs that mean we can't upgrade yet
we're working together with the zig devs to make sure our code builds before 0.10 is released
There's no Zig 0.8 in the repo today. We only support a single version at a time within our repo and it's 0.9 currently.
Maybe I'm just too used to the zig ecosystem sticking to master and saw something break.
Regarding the suggestion about the Zig allocator interface... all compiled Roc code uses a function called roc_alloc
to allocate. A platform author can define that to work however they want. So I think we might already have the flexibility you're suggesting but in a different way, that isn't tied to Zig specifically.
I see that, I was thinking about doing that for specific function calls (i.e. customising the allocator function used instead of always using roc_alloc
), and updating the zig example platform to use that instead of malloc
Yeah roc_alloc
doesn't have to be built on top of malloc
. You can put something else inside it if you want. But the compiled Roc code calls a function called roc_alloc
and assumes it has a certain type signature.
There is no way to make Roc code use an allocator with a different name or type signature.
But the implementation can be whatever you like.
one trick you can do there is to set a global (or threadlocal) and have roc_alloc
do something different based on its value
like set it right before calling the roc function
Just have to be careful not to free something incorrectly
Given the changing allocators and potentially longer lived data
Last updated: Jul 05 2025 at 12:14 UTC