Are there any platforms out there with some basic sockets support or do I have to make my own currently?
none that I know of, but if you're interested in adding them to an existing platform (e.g. basic-cli) I'd be happy to help!
That’d be fun! I’ll clone basic-cli and get comfy with it
feel free to post any questions here!
Very hardcoded but it's a start! client.gif
haha! I love how specific the function is.
glad it wasn't to hard to figure the base out
Yeah, it felt so intuitive!
Now I need to return a pointer to the stream so I can read and write later. Not sure what type I need to use for that.
Likely you want an opaque type that simply wraps a Nat
or a Box {}
That way userland Roc code won't be able to do anything with it, but it can still be passed around as a pointer.
You can look at what was done here for a file: https://github.com/roc-lang/roc/blob/main/examples/cli/false-interpreter/platform/File.roc
In this case, I also managed the lifetime of the file to make sure the handle got closed. Only exposing a function that took a lambda for what to do with the file.
Oh, though I used U64
, which is wrong on 32bit platforms, so I wouldn't copy that.
I see
So Nat
is like usize
?
Yep
Alright, on it! Thank you :)
It's getting more interesting chat.gif
This is pretty fire, nice Agus!
I love the gif. Really cool to see.
Oh wow, so cool! :tada:
wow, that's awesome!!! :heart_eyes:
@Agus Zubiaga was this all on your first day getting into Platform development?
I did cross midnight but yeah :grinning:
It was my first day actually using Roc at all. I had only seen some talks before.
Props to you folks for making it so straightforward!
wow, amazing! :heart_eyes_cat:
It's been fun! I'll play with the API when I get some more free time. I have to make some things fail at the Task
level instead of panicking in the platform, and figure out how to read arbitrary bytes.
If everything goes well I can probably make a PR later in the week!
Got the API to a pretty good state I think: https://github.com/agu-z/roc-basic-cli/blob/sockets-support/src/Tcp.roc
Example: https://github.com/agu-z/roc-basic-cli/blob/sockets-support/examples/tcp-client.roc
It can now read all data in the stream (was reading into a fixed buffer before). Also, you can read/write raw bytes if you want to.
Replaced Tcp.connect
with Tcp.withConnect
which manages the lifetime of the connection so you can't forget to close, similar to: https://github.com/roc-lang/roc/blob/main/examples/cli/false-interpreter/platform/File.roc
I think the only missing part for a PR is error handling. I wrote the types but glue doesn't work so I can't return them from Rust.
I'll look into how much code per type we need, maybe I can just write them by hand
Yeah, maybe not lol
I'd rather spend the time investigating why glue doesn't work in the first place. Gotta run now but I might do that later or tomorrow.
I'd love to have someone else get involved with glue, so if you want to look into it that would be awesome! I'd be happy to help with answering any questions :smiley:
Yeah, it’ll probably take me a while to get familiar with the compiler internals but happy to!
I managed to generate the glue code for my errors with this trick: https://roc.zulipchat.com/#narrow/stream/316715-contributing/topic/Broken.20glue/near/339383878
However, even if a I return a RocResult::ok
from the rust, when I pattern match on the Roc side it always matches the Err
case. Even if the platform is never creating RocResult::err
at all.
and neither of the a and x in Result a x
are the []
type?
Not in the Effect
module or my Tcp
module
Only the main function because it needs to be Task _ []
yeah so not in relevant code paths.
ok, well this sounds like just a mismatch between where glue is storing and roc is reading the bytes
Yeah, that's what I thought. Lemme try something like a RocStr
from roc_std
an error.
Well, I guess that wouldn't matter because I'm never generating an error yet
Is that the same issue as this? Folkert’s response from the Roc Clock thread (can’t seem to copy the link from mobile):
well. this is interesting and frustrating: rust will send a RocResult<u8, ()>
over to roc as a u16
. we "receive" it as { [0 x i8], [1 x i8], i8, [0 x i8] }
, which is reasonable (if you've seen LLVM IR before), but it is _not_ valid according to the C ABI
I was having the same issue where RocResult would always be Err
I see. Yeah, I guess that'd make sense
Ok yeah, I tried the other examples and it looks like Roc thinks all Result
are Err
in general
Hmm. I wonder when that broke. It definitely has not always been the case.
I mean all Result
coming from rust to be clear
I think it depends on the size of the type that is in a result
I'd guess it works for i64
/usize
but not for most other things
In my case I have a raw pointer in the Ok
case and a glue generated enum in the Err
case.
Should this be fixed in roc_std
or in the compiler?
this is a compiler thing
Last updated: Jul 05 2025 at 12:14 UTC