Stream: beginners

Topic: dotnet platform

Krzysztof Skowronek (Apr 14 2025 at 17:34):

Hi,

for fun I was trying to make a dotnet platform that actually works, and maybe make a PoC actor-based GUI with Avalonia (that's the ambitious version). The sample on Roc lang works, but is missing a lot of detail :)

However, I encountered an isssue. Roc only works with C# if C# is compiled to native code with AOT (ahead of time compilation).

Calling into Roc works fine, but Roc cannot call roc_alloc and so on in the host, unless the host is a native binary.
https://github.com/qrzychu/roc-dotnet-platform - my repo for now

https://github.com/AaronRobinsonMSFT/DNNE/issues/200 - I created this thread on Github in a library that compiles all the "natively exposed" methods into a native DLL even without AOT, but then it is not included in the standard, JIT-ted build.

I guess it's the same for Python, JS, Java and so on.

What's the solution here? Wrapping Roc binary in another binary that provides the functions, and only then calling the Roc main function from dotnet?

I know it's a bit early for this to be a high priority issue, but I've seen talks claiming Roc functions can be called from node.js - I assumed this is mostly analogous.

Is there a way to "redirect" the roc_alloc and others into some specific binary, or is it stricly the host job, and that means that the host can only be native code? Or am I missing something?

Also, other than the basic-cli source code, is there a doc listing all the host functions Roc might call?

Krzysztof Skowronek (Apr 14 2025 at 17:36):

also, how would I make it so that I can actually do roc build instead of dotnet build?

Krzysztof Skowronek (Apr 14 2025 at 17:36):

then this issue becomes much less of an issue :)

Anton (Apr 14 2025 at 18:12):

Also, other than the basic-cli source code, is there a doc listing all the host functions Roc might call?

No doc, but I think this is the cleanest list.

Anton (Apr 14 2025 at 18:20):

What's the solution here? Wrapping Roc binary in another binary that provides the functions, and only then calling the Roc main function from dotnet?

I believe in this case you want to compile Roc to a library with roc build --lib, let me see if I can find an example project for that.

Anton (Apr 14 2025 at 18:21):

also, how would I make it so that I can actually do roc build instead of dotnet build?

With JIT, I think dotnet needs to be in charge of the final build.

Anton (Apr 14 2025 at 18:22):

You can call dotnet through with a build.roc script if you want.

Anton (Apr 14 2025 at 18:24):

I believe in this case you want to compile Roc to a library with roc build --lib, let me see if I can find an example project for that.

Oh yeah, we use that for the .NET example: https://www.roc-lang.org/examples/DotNetPlatform/README.html see roc build main.roc --lib ...

Krzysztof Skowronek (Apr 14 2025 at 18:33):

thanks!

though I got everything to work when dotnet is compiled with native AOT, I was wondering if I would be able to make it work without the AOT.

Thing is, I would like to debug the platform for quite some time until it's "done", then the build.roc would be the solution. It is possible to debug the native app, but then I would have to use something like gdb instead of the dotnet one, which is, well, not great :D

Krzysztof Skowronek (Apr 14 2025 at 18:34):

but still, if I wanted to just call some rock functions from node.js for example, how do I give it the allocation functions? They have to be native

Brendan Hansknecht (Apr 14 2025 at 19:29):

This should all get a lot better with v0.1.0 of roc. Which is in the works but a ways away.

Brendan Hansknecht (Apr 14 2025 at 19:30):

Currently dependences between the a platform and app are mostly implicit

Brendan Hansknecht (Apr 14 2025 at 19:30):

It requires the platform to dynamically exposed certain cffi compatible symbols

Brendan Hansknecht (Apr 14 2025 at 19:31):

C# probably can do this, but it may be a pain

Brendan Hansknecht (Apr 14 2025 at 19:32):

In the future, the platform will have to pass a list of pointers into roc. One for each of the need functions. Those still have to be cffi compatible, but they follow proper dependency chains and should just work without linker pains like you noted above.

Krzysztof Skowronek (Apr 14 2025 at 19:54):

that sounds great :) that woud also mean that every platform needs to provide all of the functions right away, right?

on another note, in roc_alloc, what is the meaning of the second parameter? it's called alignment in the basic-cli platform, but it is ignored in the Rust code (same in dotnet)

Brendan Hansknecht (Apr 15 2025 at 03:23):

For some functions you could just have an empty or dummy impl to start with.

It is how many bytes the data needs to be align to. In most cases allocators already align to a high enough that this value doesn't matter. In some cases, more control is wanted for tighter allocation packing.

Last updated: Jul 05 2025 at 12:14 UTC