Newest at the top
| 2025-12-19 12:36:24 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-19 12:35:33 +0100 | lambda_gibbon | (~lambda_gi@208.83.175.39) (Ping timeout: 244 seconds) |
| 2025-12-19 12:31:23 +0100 | lambda_gibbon | (~lambda_gi@208.83.175.39) |
| 2025-12-19 12:23:15 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-19 12:21:49 +0100 | trickard_ | (~trickard@cpe-81-98-47-163.wireline.com.au) |
| 2025-12-19 12:21:35 +0100 | trickard | (~trickard@cpe-81-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-12-19 12:20:50 +0100 | Googulator23 | (~Googulato@2a01-036d-0106-48e4-3c18-a4bd-1bda-7c8b.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-12-19 12:20:49 +0100 | Googulator24 | (~Googulato@80-95-87-105.pool.digikabel.hu) |
| 2025-12-19 12:18:19 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-19 12:07:39 +0100 | lucabtz | (~lucabtz@user/lucabtz) (Ping timeout: 244 seconds) |
| 2025-12-19 12:06:53 +0100 | trickard_ | trickard |
| 2025-12-19 12:04:47 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) marinelli |
| 2025-12-19 12:03:56 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2025-12-19 12:01:52 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 244 seconds) |
| 2025-12-19 11:55:42 +0100 | tromp | (~textual@2001:1c00:3487:1b00:9c43:d0f8:e383:616c) |
| 2025-12-19 11:55:28 +0100 | trickard_ | (~trickard@cpe-81-98-47-163.wireline.com.au) |
| 2025-12-19 11:55:15 +0100 | trickard | (~trickard@cpe-81-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-12-19 11:53:31 +0100 | tromp | (~textual@2001:1c00:3487:1b00:9c43:d0f8:e383:616c) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-12-19 11:50:49 +0100 | Googulator50 | (~Googulato@2a01-036d-0106-48e4-3c18-a4bd-1bda-7c8b.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-12-19 11:50:44 +0100 | Googulator23 | (~Googulato@2a01-036d-0106-48e4-3c18-a4bd-1bda-7c8b.pool6.digikabel.hu) |
| 2025-12-19 11:47:30 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) (Quit: marinelli) |
| 2025-12-19 11:36:33 +0100 | tema | (~tema@93.175.2.131) (Ping timeout: 272 seconds) |
| 2025-12-19 11:30:55 +0100 | merijn | (~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 +0100 | Lycurgus | (~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 +0100 | Googulator50 | (~Googulato@2a01-036d-0106-48e4-3c18-a4bd-1bda-7c8b.pool6.digikabel.hu) |
| 2025-12-19 11:20:43 +0100 | Googulator71 | (~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 +0100 | raym | (~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 |
| 2025-12-19 10:58:54 +0100 | haritz | (~hrtz@user/haritz) haritz |
| 2025-12-19 10:58:54 +0100 | haritz | (~hrtz@140.228.70.141) (Changing host) |
| 2025-12-19 10:58:54 +0100 | haritz | (~hrtz@140.228.70.141) |