Newest at the top
| 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) |
| 2025-12-19 10:58:37 +0100 | <merijn> | I basically had a C++ + haskell project where I just had a makefile calling cabal to deal with building the haskell bits |
| 2025-12-19 10:58:07 +0100 | <merijn> | Liamzee: FWIW cabal is pretty well-behaved when you call it from, e.g. a Makefile |
| 2025-12-19 10:56:36 +0100 | <haskellbridge> | <Liamzee> so I took a look at Apache Arrow, and noped the hell out, am now considering whether I can do parquet-rs instead |
| 2025-12-19 10:56:10 +0100 | raym | (~ray@user/raym) (Ping timeout: 245 seconds) |
| 2025-12-19 10:56:06 +0100 | <haskellbridge> | <Liamzee> I promised someone and I'll probably break the promise, to go give them FFI parquet support |
| 2025-12-19 10:55:50 +0100 | <haskellbridge> | <Liamzee> I read that Rust has cbindgen |
| 2025-12-19 10:55:27 +0100 | <merijn> | Liamzee: Oh, cabal not being able to call cargo, yeah that's true |
| 2025-12-19 10:55:27 +0100 | <haskellbridge> | <Morj> "ABI" - yes, but you do the same thing and export unmangled functions with C abi in c++ |
| 2025-12-19 10:55:06 +0100 | <haskellbridge> | <Liamzee> then copy paste |
| 2025-12-19 10:55:04 +0100 | <haskellbridge> | <Liamzee> ? I had to generate a static build artifact from Cargo |
| 2025-12-19 10:55:00 +0100 | <haskellbridge> | <Morj> I mean «modern» c++ with smart pointers and stuff. If we're talking c++ with manual memory management, that's terrible, but that's also terrible to use from c++ |
| 2025-12-19 10:54:53 +0100 | <merijn> | What do you need a custom setup.hs for? |
| 2025-12-19 10:54:46 +0100 | <merijn> | Liamzee: What? |
| 2025-12-19 10:54:37 +0100 | <haskellbridge> | <Liamzee> the worst part right now is that Cabal can't do this on its own, not without a custom Setup.hs |
| 2025-12-19 10:54:37 +0100 | <merijn> | Because C++ doesn't have any ABI defined at all |
| 2025-12-19 10:54:12 +0100 | <haskellbridge> | <Morj> Hm, you think? Why? |
| 2025-12-19 10:53:55 +0100 | <haskellbridge> | <Morj> In general rust's typical approaches to memory are very similar to c++ |
| 2025-12-19 10:53:53 +0100 | <merijn> | Morj: No, C++ is infinitely worse |
| 2025-12-19 10:53:46 +0100 | <merijn> | Liamzee: ccall is just the tradiational C ABI, with all limitations of that (i.e. no access to CPP, etc) |
| 2025-12-19 10:53:38 +0100 | <haskellbridge> | <Morj> Mm, in my experience it's about the same nightmare as binding to c++ code |
| 2025-12-19 10:53:17 +0100 | <haskellbridge> | <Liamzee> I'm sure once it gets into sophisticated memory handling it's going to become nightmarish, especially under concurrent conditions |
| 2025-12-19 10:53:00 +0100 | <haskellbridge> | <Liamzee> Morj: this isn't that painful, 5 minutes |
| 2025-12-19 10:52:55 +0100 | <haskellbridge> | <Morj> Also «easy, doable, and /fun/», really? |