Arya Elfren (Aug 31 2022 at 20:56): Arya Elfren (Aug 31 2022 at 20:56):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?)
Brian Carroll (Aug 31 2022 at 20:59):We're working on the 0.10 upgrade. 0.10 is not yet released. We are on the latest released version I think.
Brian Carroll (Aug 31 2022 at 21:00):When you say "now very old" what are you referring to exactly? We're on 0.9
Arya Elfren (Aug 31 2022 at 21:03):Maybe I'm thinking of the roc example platform?
Arya Elfren (Aug 31 2022 at 21:04):I remember recently having to get 0.8.0 to do something in the roc repo
Arya Elfren (Aug 31 2022 at 21:04):Maybe not
Arya Elfren (Aug 31 2022 at 21:05):I'll double check, but what about the other suggestions?
Folkert de Vries (Aug 31 2022 at 21:05):we're working on 0.10 but it has a bunch of bugs that mean we can't upgrade yet
Folkert de Vries (Aug 31 2022 at 21:05):we're working together with the zig devs to make sure our code builds before 0.10 is released
Brian Carroll (Aug 31 2022 at 21:06):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.
Arya Elfren (Aug 31 2022 at 21:06):Maybe I'm just too used to the zig ecosystem sticking to master and saw something break.
Brian Carroll (Aug 31 2022 at 21:10):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.
Arya Elfren (Aug 31 2022 at 21:17):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
Brian Carroll (Aug 31 2022 at 21:20):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.
Brian Carroll (Aug 31 2022 at 21:21):There is no way to make Roc code use an allocator with a different name or type signature.
Brian Carroll (Aug 31 2022 at 21:21):But the implementation can be whatever you like.
Richard Feldman (Aug 31 2022 at 22:20):one trick you can do there is to set a global (or threadlocal) and have roc_alloc do something different based on its value
Richard Feldman (Aug 31 2022 at 22:21):like set it right before calling the roc function
Brendan Hansknecht (Aug 31 2022 at 22:35):Just have to be careful not to free something incorrectly
Brendan Hansknecht (Aug 31 2022 at 22:35):Given the changing allocators and potentially longer lived data
Last updated: Jul 26 2025 at 12:14 UTC