Newest at the top
| 2024-11-01 15:32:42 +0100 | <merijn> | mauke: CPP macros is capi only (but you can use both at the same time). The type checking I *thought* it also did for ccall |
| 2024-11-01 15:32:37 +0100 | <mauke> | importing addresses of variables is in the base FFI |
| 2024-11-01 15:32:13 +0100 | <merijn> | I'd prefer ccall where possible, but capi is a huge win. I think capi also lets you reference Ptr to variables directly (as opposed to only functions) |
| 2024-11-01 15:32:11 +0100 | <mauke> | I thought capi was what you were talking about when you mentioned CPP macros and checking against headers |
| 2024-11-01 15:31:20 +0100 | Square2 | (~Square4@user/square) (Ping timeout: 255 seconds) |
| 2024-11-01 15:31:19 +0100 | k_hachig_ | (~k_hachig@2607:fea8:351d:ef0:901a:fefb:e87f:78b3) (Ping timeout: 260 seconds) |
| 2024-11-01 15:31:16 +0100 | <merijn> | mauke: capi is nice for some things, though. Since it lets you foreign import CPP macros as values: https://github.com/merijn/Belewitte/blob/ed95965077ee0a55c9a206b75445ddf93723916b/benchmark-analys… |
| 2024-11-01 15:30:54 +0100 | <merijn> | capi is very different, since it generates stubs instead of calling directly from Haskell |
| 2024-11-01 15:30:37 +0100 | <merijn> | I thought it did |
| 2024-11-01 15:30:05 +0100 | <mauke> | I know capi does weird things |
| 2024-11-01 15:29:50 +0100 | <mauke> | for ccall? are you sure? |
| 2024-11-01 15:29:33 +0100 | <merijn> | (modulo marshalling as defined in the FFI part of the standard) |
| 2024-11-01 15:29:22 +0100 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2024-11-01 15:29:10 +0100 | <merijn> | mauke: https://github.com/merijn/Belewitte/blob/ed95965077ee0a55c9a206b75445ddf93723916b/benchmark-analys… |
| 2024-11-01 15:29:07 +0100 | <merijn> | mauke: It's been awhile, but iirc if you mention the header file on the foreign import it will check that the Haskell type you declare for it corresponds to the C type |
| 2024-11-01 15:28:11 +0100 | vgtw | (~vgtw@user/vgtw) vgtw |
| 2024-11-01 15:28:10 +0100 | <mauke> | er, yes |
| 2024-11-01 15:27:48 +0100 | <merijn> | mauke: "can" for the type checking, you mean? |
| 2024-11-01 15:27:29 +0100 | <mauke> | tomsmeding: the cp $(cabal list-bin yourexename) wherever method gives me a non-stripped executable |
| 2024-11-01 15:26:44 +0100 | k_hachig_ | (~k_hachig@2607:fea8:351d:ef0:901a:fefb:e87f:78b3) k_hachig |
| 2024-11-01 15:25:55 +0100 | <mauke> | define "can" |
| 2024-11-01 15:25:03 +0100 | <merijn> | Not to mention GHC being able to use CPP macros as values |
| 2024-11-01 15:24:45 +0100 | <merijn> | Which can be helpful for your sanity |
| 2024-11-01 15:24:36 +0100 | <merijn> | mauke: GHC can automatically check whether your declared types match the headers |
| 2024-11-01 15:24:06 +0100 | <merijn> | \o/ |
| 2024-11-01 15:23:23 +0100 | <mauke> | oh hello, executable stripping works if I turn it on in ~/.cabal/config |
| 2024-11-01 15:22:46 +0100 | <mauke> | technically I could probably just delete the header files because I'm pretty sure ghc doesn't care anyway |
| 2024-11-01 15:22:44 +0100 | tired | (~tired@user/tired) tired |
| 2024-11-01 15:21:46 +0100 | <mauke> | I don't have generated files, so for me it's all "sdist" in a sense |
| 2024-11-01 15:20:00 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2024-11-01 15:19:45 +0100 | <merijn> | runtime" to be one of the things preserving my sanity |
| 2024-11-01 15:19:39 +0100 | <merijn> | Docker makes sense when you remember that lots of ecosystems (looking at you npm, typescript, python, etc.) don't have a sane boundary to distinguish "necessary at build/packaging" from "necessary at runtime". And while I share your annoyance of "I need to set 4 fields in .cabal to packabe my headers" is annoying. I find the clear distinction between "what is sdist, what is build time, and what is |
| 2024-11-01 15:19:29 +0100 | vgtw | (~vgtw@user/vgtw) (Ping timeout: 248 seconds) |
| 2024-11-01 15:17:12 +0100 | <merijn> | Using docker the "right" way is for people who don't know how to build/package their own stuff :p |
| 2024-11-01 15:16:32 +0100 | <mauke> | which I then copy out to the host system |
| 2024-11-01 15:16:23 +0100 | <mauke> | right now I'm using docker "backwards" in that I have a custom build container just for creating CentOS 7 binaries |
| 2024-11-01 15:15:40 +0100 | <mauke> | "running on stupid machines" is very valid |
| 2024-11-01 15:15:17 +0100 | <merijn> | You can ignore that part on sane machine ;) |
| 2024-11-01 15:14:55 +0100 | <merijn> | basically |
| 2024-11-01 15:14:54 +0100 | <mauke> | I see |
| 2024-11-01 15:14:50 +0100 | <mauke> | ah, it's just a realpath reimplementation |
| 2024-11-01 15:14:44 +0100 | <merijn> | mauke: It's mostly "I was running on some stupidly broken machines" engineered |
| 2024-11-01 15:13:51 +0100 | <mauke> | wow, that scriptpath thing looks ... overengineered |
| 2024-11-01 15:13:10 +0100 | <merijn> | I dunno if adding library-stripping also work? |
| 2024-11-01 15:12:54 +0100 | <mauke> | cabal install with split sections and explicit executable-stripping: 11M |
| 2024-11-01 15:12:42 +0100 | <mauke> | cabal install with split sections: 18M |
| 2024-11-01 15:12:31 +0100 | <mauke> | cabal install with 'executable-stripping: True' in project file: 16M |
| 2024-11-01 15:12:20 +0100 | <merijn> | mauke: I also have this neat lazy people trick for testing "in-development" executables https://github.com/NLeSC-AAA2/etherpacket/blob/master/EtherPacket |
| 2024-11-01 15:12:04 +0100 | <mauke> | cabal install with default options: 25M |
| 2024-11-01 15:11:49 +0100 | <mauke> | final tally: |