2025/12/19

Newest at the top

2025-12-19 12:45:36 +0100CiaoSen(~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen
2025-12-19 12:42:55 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds)
2025-12-19 12:41:37 +0100lucabtz(~lucabtz@user/lucabtz) lucabtz
2025-12-19 12:36:24 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2025-12-19 12:35:33 +0100lambda_gibbon(~lambda_gi@208.83.175.39) (Ping timeout: 244 seconds)
2025-12-19 12:31:23 +0100lambda_gibbon(~lambda_gi@208.83.175.39)
2025-12-19 12:23:15 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds)
2025-12-19 12:21:49 +0100trickard_(~trickard@cpe-81-98-47-163.wireline.com.au)
2025-12-19 12:21:35 +0100trickard(~trickard@cpe-81-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2025-12-19 12:20:50 +0100Googulator23(~Googulato@2a01-036d-0106-48e4-3c18-a4bd-1bda-7c8b.pool6.digikabel.hu) (Quit: Client closed)
2025-12-19 12:20:49 +0100Googulator24(~Googulato@80-95-87-105.pool.digikabel.hu)
2025-12-19 12:18:19 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2025-12-19 12:07:39 +0100lucabtz(~lucabtz@user/lucabtz) (Ping timeout: 244 seconds)
2025-12-19 12:06:53 +0100trickard_trickard
2025-12-19 12:04:47 +0100marinelli(~weechat@gateway/tor-sasl/marinelli) marinelli
2025-12-19 12:03:56 +0100mari-estel(~mari-este@user/mari-estel) mari-estel
2025-12-19 12:01:52 +0100CiaoSen(~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 244 seconds)
2025-12-19 11:55:42 +0100tromp(~textual@2001:1c00:3487:1b00:9c43:d0f8:e383:616c)
2025-12-19 11:55:28 +0100trickard_(~trickard@cpe-81-98-47-163.wireline.com.au)
2025-12-19 11:55:15 +0100trickard(~trickard@cpe-81-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2025-12-19 11:53:31 +0100tromp(~textual@2001:1c00:3487:1b00:9c43:d0f8:e383:616c) (Quit: My iMac has gone to sleep. ZZZzzz…)
2025-12-19 11:50:49 +0100Googulator50(~Googulato@2a01-036d-0106-48e4-3c18-a4bd-1bda-7c8b.pool6.digikabel.hu) (Quit: Client closed)
2025-12-19 11:50:44 +0100Googulator23(~Googulato@2a01-036d-0106-48e4-3c18-a4bd-1bda-7c8b.pool6.digikabel.hu)
2025-12-19 11:47:30 +0100marinelli(~weechat@gateway/tor-sasl/marinelli) (Quit: marinelli)
2025-12-19 11:36:33 +0100tema(~tema@93.175.2.131) (Ping timeout: 272 seconds)
2025-12-19 11:30:55 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 250 seconds)
2025-12-19 11:25:08 +0100 <merijn> Similarly relevant? https://www.reddit.com/r/rust/comments/17r7hf6/comment/k8h4hpw/
2025-12-19 11:22:42 +0100 <merijn> Something like this SO answer? https://stackoverflow.com/questions/54849928/how-can-one-force-rust-to-take-ownership-of-memory-al…
2025-12-19 11:21:09 +0100Lycurgus(~juan@user/Lycurgus) (Quit: alsoknownas.renjuan.org ( juan@acm.org ))
2025-12-19 11:20:48 +0100 <merijn> I can't imagine Rust not supporting a non-copying pointer in unsafe
2025-12-19 11:20:46 +0100Googulator50(~Googulato@2a01-036d-0106-48e4-3c18-a4bd-1bda-7c8b.pool6.digikabel.hu)
2025-12-19 11:20:43 +0100Googulator71(~Googulato@2a01-036d-0106-48e4-3c18-a4bd-1bda-7c8b.pool6.digikabel.hu) (Quit: Client closed)
2025-12-19 11:11:03 +0100 <haskellbridge> <Morj> *const T in both mentions
2025-12-19 11:10:45 +0100 <haskellbridge> <Morj> Oops, my matrix client might have eaten the asterisks as the formatting
2025-12-19 11:10:23 +0100 <haskellbridge> <Morj> Like, if you have two functions: one accepting a Box<T>, and another &T - they both will be exported as accepting _const T, and_const T is safe to copy
2025-12-19 11:09:47 +0100 <haskellbridge> <Liamzee> precisely, you DON'T want to copy
2025-12-19 11:09:31 +0100 <haskellbridge> <Liamzee> I mean in the Parquet case, this is looking as though it'd likely be a disaster, maybe I would have to go through the 2 million line Apache Arrow instead :(
2025-12-19 11:08:39 +0100 <haskellbridge> <Morj> Rust also doesn't have a stable abi, so the functions you export from rust are only going to have C compatible arguments, which are all Copy, so the ownership semantics happen a layer deeper
2025-12-19 11:06:46 +0100 <merijn> Liamzee: I mean, in the haskell FFI you can manually do 'malloc' to get a pointer that doesn't get freed by Haskell in which case Rust can take ownership
2025-12-19 11:05:48 +0100 <haskellbridge> <Liamzee> But the problem is that I can't do it all from the Haskell side, no? I'd have to go into the rust, manually edit stuff so it doesn't take ownership. Ugh.
2025-12-19 11:05:06 +0100 <merijn> Liamzee: You'll just have to manually and explicitly manage ownership
2025-12-19 11:04:38 +0100 <haskellbridge> <Liamzee> yup, i see the problem now, apparently GHCRTS and Rust will fight over ownership?
2025-12-19 11:04:32 +0100 <haskellbridge> <Morj> What serokell or well-typed are writing is even more magic, where they want to automatically interoperate between haskell and rust types, and not have to write foreign imports and exports
2025-12-19 11:03:39 +0100 <merijn> But that C wrapper is extra indirection
2025-12-19 11:03:28 +0100 <merijn> Liamzee: The main difference is "ccall" directly generates code calling stuff according to C ABI. CAPI has GHC generating and compiling a C wrapper (using a C compiler) then calling that wrapper.Which is how it can access, e.g. CPP values, because the CPP is substituted in the generated C wrapper
2025-12-19 11:03:11 +0100raym(~ray@user/raym) raym
2025-12-19 11:02:32 +0100 <haskellbridge> <Liamzee> still, so exciting, Haskell being a driver for Rust has been a dream of mine for years. I just thought it was black magic that required being at Serokell or Well-Typed to pull off
2025-12-19 11:01:51 +0100 <haskellbridge> <Liamzee> I can probably live with ccall, right?
2025-12-19 11:01:43 +0100 <haskellbridge> <Liamzee> i mean if i'm just doing things with Rust artifacts
2025-12-19 10:59:58 +0100 <merijn> Liamzee: Anyway, I would generally *prefer* ccall over capi unless I specifically needed capi, for for example accessing CPP macros