| 2025-07-09 00:04:16 +0200 | dtman34 | (~dtman34@2601:447:d182:6512:c2f9:c3a:b83d:6490) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in) |
| 2025-07-09 00:06:39 +0200 | dtman34 | (~dtman34@2601:447:d182:6512:c2f9:c3a:b83d:6490) dtman34 |
| 2025-07-09 00:06:41 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-09 00:12:13 +0200 | dtman34 | (~dtman34@2601:447:d182:6512:c2f9:c3a:b83d:6490) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in) |
| 2025-07-09 00:13:45 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-07-09 00:20:03 +0200 | falafel | (~falafel@79.117.174.28) falafel |
| 2025-07-09 00:20:33 +0200 | euphores | (~SASL_euph@user/euphores) (Ping timeout: 248 seconds) |
| 2025-07-09 00:25:14 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-09 00:26:42 +0200 | euphores | (~SASL_euph@user/euphores) euphores |
| 2025-07-09 00:26:53 +0200 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2025-07-09 00:29:54 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-07-09 00:30:14 +0200 | dtman34 | (~dtman34@2601:447:d182:6512:c2f9:c3a:b83d:6490) dtman34 |
| 2025-07-09 00:31:32 +0200 | machinedgod | (~machinedg@d75-159-126-101.abhsia.telus.net) machinedgod |
| 2025-07-09 00:35:40 +0200 | dtman34 | (~dtman34@2601:447:d182:6512:c2f9:c3a:b83d:6490) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in) |
| 2025-07-09 00:40:38 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-09 00:43:40 +0200 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-07-09 00:44:21 +0200 | emmanuelux | (~emmanuelu@user/emmanuelux) emmanuelux |
| 2025-07-09 00:45:24 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-07-09 00:48:18 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-07-09 00:49:49 +0200 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 244 seconds) |
| 2025-07-09 00:54:28 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2025-07-09 00:56:24 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-09 00:57:52 +0200 | mreh | (~matthew@host86-146-25-68.range86-146.btcentralplus.com) (Ping timeout: 244 seconds) |
| 2025-07-09 01:01:24 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-07-09 01:11:57 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-09 01:16:11 +0200 | dtman34 | (~dtman34@2601:447:d182:6512:c2f9:c3a:b83d:6490) dtman34 |
| 2025-07-09 01:17:05 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-07-09 01:20:49 +0200 | arahael | (~arahael@user/arahael) (Ping timeout: 244 seconds) |
| 2025-07-09 01:21:10 +0200 | sajenim | (~sajenim@user/sajenim) (Ping timeout: 252 seconds) |
| 2025-07-09 01:24:40 +0200 | sajenim | (~sajenim@user/sajenim) sajenim |
| 2025-07-09 01:25:19 +0200 | acidjnk | (~acidjnk@p200300d6e70b66211036d412d118a821.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2025-07-09 01:27:03 +0200 | jmcantrell | (~weechat@user/jmcantrell) jmcantrell |
| 2025-07-09 01:27:17 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 248 seconds) |
| 2025-07-09 01:27:45 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-09 01:28:59 +0200 | sprotte24 | (~sprotte24@p200300d16f065b001972c1ed9b092c7b.dip0.t-ipconnect.de) (Quit: Leaving) |
| 2025-07-09 01:29:08 +0200 | Nosrep_ | (~jimothy@user/nosrep) Nosrep |
| 2025-07-09 01:30:21 +0200 | Nosrep_ | Nosrep |
| 2025-07-09 01:30:27 +0200 | dmj` | (uid72307@id-72307.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-07-09 01:32:54 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-07-09 01:34:17 +0200 | dtman34 | (~dtman34@2601:447:d182:6512:c2f9:c3a:b83d:6490) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in) |
| 2025-07-09 01:34:40 +0200 | dtman34 | (~dtman34@2601:447:d182:6512:c2f9:c3a:b83d:6490) dtman34 |
| 2025-07-09 01:37:33 +0200 | falafel | (~falafel@79.117.174.28) (Ping timeout: 272 seconds) |
| 2025-07-09 01:40:29 +0200 | trickard | (~trickard@cpe-92-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-07-09 01:41:18 +0200 | dtman34 | (~dtman34@2601:447:d182:6512:c2f9:c3a:b83d:6490) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in) |
| 2025-07-09 01:43:04 +0200 | trickard_ | (~trickard@cpe-92-98-47-163.wireline.com.au) |
| 2025-07-09 01:43:32 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-09 01:46:04 +0200 | nek0 | (~nek0@user/nek0) (Quit: The Lounge - https://thelounge.chat) |
| 2025-07-09 01:48:18 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-07-09 01:52:41 +0200 | Digitteknohippie | (~user@user/digit) Digit |
| 2025-07-09 01:53:53 +0200 | Digit | (~user@user/digit) (Ping timeout: 268 seconds) |
| 2025-07-09 01:59:19 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-09 02:04:03 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-07-09 02:04:45 +0200 | jespada | (~jespada@r179-25-42-81.dialup.adsl.anteldata.net.uy) (Ping timeout: 276 seconds) |
| 2025-07-09 02:07:37 +0200 | nek0 | (~nek0@user/nek0) nek0 |
| 2025-07-09 02:15:06 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-09 02:19:21 +0200 | dtman34 | (~dtman34@c-73-242-68-179.hsd1.mn.comcast.net) dtman34 |
| 2025-07-09 02:20:20 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-07-09 02:22:16 +0200 | dtman34 | (~dtman34@c-73-242-68-179.hsd1.mn.comcast.net) (Client Quit) |
| 2025-07-09 02:30:08 +0200 | ensyde | (~ensyde@c-73-147-64-74.hsd1.va.comcast.net) ensyde |
| 2025-07-09 02:30:53 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-09 02:35:12 +0200 | ensyde | (~ensyde@c-73-147-64-74.hsd1.va.comcast.net) (Ping timeout: 268 seconds) |
| 2025-07-09 02:37:44 +0200 | califax | (~califax@user/califx) (Ping timeout: 244 seconds) |
| 2025-07-09 02:37:54 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-07-09 02:38:31 +0200 | califax | (~califax@user/califx) califx |
| 2025-07-09 02:42:59 +0200 | trickard_ | trickard |
| 2025-07-09 02:45:00 +0200 | dtman34 | (~dtman34@2601:447:d182:6512:c2f9:c3a:b83d:6490) dtman34 |
| 2025-07-09 02:48:54 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-09 02:53:56 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-07-09 02:54:41 +0200 | ystael | (~ystael@user/ystael) (Ping timeout: 248 seconds) |
| 2025-07-09 02:55:55 +0200 | xff0x | (~xff0x@2405:6580:b080:900:c28b:dc6e:ea0:b5fe) (Ping timeout: 260 seconds) |
| 2025-07-09 02:56:19 +0200 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 260 seconds) |
| 2025-07-09 02:58:42 +0200 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2025-07-09 03:00:20 +0200 | Square | (~Square@user/square) Square |
| 2025-07-09 03:02:55 +0200 | tmciver | (~tim@syn-198-255-177-240.res.spectrum.com) (Ping timeout: 260 seconds) |
| 2025-07-09 03:04:41 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-09 03:06:40 +0200 | sajenim | (~sajenim@user/sajenim) (Ping timeout: 272 seconds) |
| 2025-07-09 03:08:53 +0200 | fp | (~Thunderbi@hof1.kyla.fi) fp |
| 2025-07-09 03:09:34 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-07-09 03:09:46 +0200 | tmciver | (~tim@syn-198-255-177-240.res.spectrum.com) tmciver |
| 2025-07-09 03:20:07 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2025-07-09 03:20:28 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-09 03:25:27 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-07-09 03:26:34 +0200 | machinedgod | (~machinedg@d75-159-126-101.abhsia.telus.net) (Ping timeout: 276 seconds) |
| 2025-07-09 03:27:44 +0200 | dtman34 | (~dtman34@2601:447:d182:6512:c2f9:c3a:b83d:6490) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in) |
| 2025-07-09 03:28:13 +0200 | dtman34 | (~dtman34@2601:447:d182:6512:c2f9:c3a:b83d:6490) dtman34 |
| 2025-07-09 03:28:30 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-07-09 03:34:37 +0200 | rvalue | (~rvalue@about/hackers/rvalue) (Read error: Connection reset by peer) |
| 2025-07-09 03:35:04 +0200 | rvalue | (~rvalue@about/hackers/rvalue) rvalue |
| 2025-07-09 03:36:16 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-09 03:38:21 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 276 seconds) |
| 2025-07-09 03:41:25 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-07-09 03:48:10 +0200 | dtman34 | (~dtman34@2601:447:d182:6512:c2f9:c3a:b83d:6490) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in) |
| 2025-07-09 03:52:03 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-09 03:56:59 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-07-09 03:57:12 +0200 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2025-07-09 03:58:30 +0200 | <Axman6> | What's the state of the art for wrapping C libraries these days? I'd love to be able to just chuck a C header at some tool and get corresponding definitions in Haskell, but afaiui that's not how any of the tools work, right? |
| 2025-07-09 04:00:05 +0200 | <glguy> | is this what AI is for? poorly done FFI? |
| 2025-07-09 04:00:53 +0200 | <glguy> | I hadn't heard of an interesting advances in C bindings |
| 2025-07-09 04:01:01 +0200 | <glguy> | any* |
| 2025-07-09 04:03:47 +0200 | <geekosaur> | c2hs works that way. the problem is that C function definitions are ambiguous when it comes to pointers |
| 2025-07-09 04:04:26 +0200 | <geekosaur> | are they arrays? "out" parameters? is a double indirection a mutable array, an array of arrays, or an "out" array? |
| 2025-07-09 04:04:44 +0200 | <glguy> | the couple times I tried c2hs it took me longer to get it to do what I wanted that to do it manually |
| 2025-07-09 04:05:13 +0200 | <geekosaur> | ghc2hs and successors use a modified c2hs, but the headers they read are generated from an API spec and are commented with the missing information |
| 2025-07-09 04:07:20 +0200 | dtman34 | (~dtman34@2601:447:d182:6512:c2f9:c3a:b83d:6490) dtman34 |
| 2025-07-09 04:07:38 +0200 | <geekosaur> | basically, C types are so primitive that you really need to study the API of the function you're binding and write the correct marshaling code yourself |
| 2025-07-09 04:07:51 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-09 04:08:35 +0200 | <geekosaur> | unless you can pull the gtk2hsc2hs trick and work (directly or indirectly) from an API spec that has all the information you need to write it properly |
| 2025-07-09 04:14:34 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-07-09 04:15:18 +0200 | poscat0x04 | (~poscat@user/poscat) (Remote host closed the connection) |
| 2025-07-09 04:16:15 +0200 | dtman34 | (~dtman34@2601:447:d182:6512:c2f9:c3a:b83d:6490) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in) |
| 2025-07-09 04:16:27 +0200 | <Axman6> | geekosaur: just wrapping all the structs/non-function types would be enough for me |
| 2025-07-09 04:17:10 +0200 | dtman34 | (~dtman34@c-73-242-68-179.hsd1.mn.comcast.net) dtman34 |
| 2025-07-09 04:17:28 +0200 | <Axman6> | The other big problem that I've run into is wanting to wrapp macOS libraries, which often use Apple's blocks syntax, which none of the tools seem to know about |
| 2025-07-09 04:17:41 +0200 | <Axman6> | s/pp/p |
| 2025-07-09 04:17:48 +0200 | <geekosaur> | c2hs should mostly be able to do that unless they do things like making variable length structs (which I think is either technically illegal or barely legal) with the last element extending past the end of the declared part |
| 2025-07-09 04:18:33 +0200 | poscat | (~poscat@user/poscat) poscat |
| 2025-07-09 04:19:35 +0200 | <geekosaur> | C's just evil |
| 2025-07-09 04:20:27 +0200 | <geekosaur> | (I wrote a lot of C code between 1985 and 2016) |
| 2025-07-09 04:21:40 +0200 | <geekosaur> | and yeh, nobody supports blocks. I thiiiink Apple tried to get them standardized but they chose a different extension instead? |
| 2025-07-09 04:22:20 +0200 | <glguy> | were blocks meant to be used outside of ObjC? |
| 2025-07-09 04:22:35 +0200 | <geekosaur> | Apple added them to clang |
| 2025-07-09 04:22:36 +0200 | dtman34 | (~dtman34@c-73-242-68-179.hsd1.mn.comcast.net) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in) |
| 2025-07-09 04:23:09 +0200 | dtman34 | (~dtman34@2601:447:d182:6512:c2f9:c3a:b83d:6490) dtman34 |
| 2025-07-09 04:23:35 +0200 | <geekosaur> | last I heard the C standard committee was considering importing C++'s lambda syntax |
| 2025-07-09 04:23:48 +0200 | <geekosaur> | but hadn't made a decision yet |
| 2025-07-09 04:24:06 +0200 | <glguy> | with captures? |
| 2025-07-09 04:24:14 +0200 | <geekosaur> | don't recall |
| 2025-07-09 04:24:23 +0200 | <geekosaur> | probably not since C can't do them right |
| 2025-07-09 04:24:37 +0200 | <geekosaur> | hence "syntax" |
| 2025-07-09 04:24:43 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-07-09 04:25:54 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-09 04:26:14 +0200 | td_ | (~td@i53870933.versanet.de) (Ping timeout: 245 seconds) |
| 2025-07-09 04:27:30 +0200 | <Axman6> | Hmm, looks like I made more progress on getting this stuff work than I thought I did, looking at my old code. I at least got enums... |
| 2025-07-09 04:27:59 +0200 | td_ | (~td@i5387091B.versanet.de) |
| 2025-07-09 04:29:04 +0200 | biberu | (~biberu@user/biberu) (Read error: Connection reset by peer) |
| 2025-07-09 04:30:57 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-07-09 04:31:06 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2025-07-09 04:31:14 +0200 | dtman34 | (~dtman34@2601:447:d182:6512:c2f9:c3a:b83d:6490) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in) |
| 2025-07-09 04:31:54 +0200 | <Axman6> | urgh, ok, it's not even blocks that cause problems, Apple use types like `const es_message_t *_Nonnull message` and that confuses c2hs, "The symbol `*' does not fit here." |
| 2025-07-09 04:32:07 +0200 | dtman34 | (~dtman34@2601:447:d182:6512:c2f9:c3a:b83d:6490) dtman34 |
| 2025-07-09 04:32:32 +0200 | <Axman6> | (and even more confusingly, the location it points to is not where the * even is, it points to half way through the es_message_t) |
| 2025-07-09 04:33:55 +0200 | <geekosaur> | sounds like a macro expanding to some Apple-specific attribute? |
| 2025-07-09 04:34:26 +0200 | <geekosaur> | (the visible `*` is fine assuming `es_message_t` expands to a valid type) |
| 2025-07-09 04:35:19 +0200 | <Axman6> | yeah, that's what I thought too. I tried #define _Nonnull but that didn't help |
| 2025-07-09 04:35:34 +0200 | <geekosaur> | no, you want to look at how es_message_t is defined |
| 2025-07-09 04:36:39 +0200 | <geekosaur> | try using clang -E on the source file |
| 2025-07-09 04:37:11 +0200 | dtman34 | (~dtman34@2601:447:d182:6512:c2f9:c3a:b83d:6490) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in) |
| 2025-07-09 04:38:33 +0200 | <geekosaur> | I suspect it will turn out to be a macro which involves watever Apple has chosen to use instead of gcc's __attribute__() |
| 2025-07-09 04:38:35 +0200 | dtman34 | (~dtman34@2601:447:d182:6512:c2f9:c3a:b83d:6490) dtman34 |
| 2025-07-09 04:38:43 +0200 | <geekosaur> | *whatever |
| 2025-07-09 04:40:04 +0200 | <Axman6> | It expands to es_respond_result_t es_respond_auth_result(es_client_t *_Nonnull client, const es_message_t *_Nonnull message, es_auth_result_t result, bool cache);, which is preceeded with a bunch of attributes |
| 2025-07-09 04:40:20 +0200 | <geekosaur> | if you're really lucky it will turn out to share with __attribute__() that you can #define it away for use by tools |
| 2025-07-09 04:41:41 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-09 04:41:50 +0200 | <geekosaur> | that sounds like either you didn't do what I asked or there is a typedef for es_message_t including tomfoolery |
| 2025-07-09 04:43:19 +0200 | dtman34 | (~dtman34@2601:447:d182:6512:c2f9:c3a:b83d:6490) (Client Quit) |
| 2025-07-09 04:44:29 +0200 | senoraraton | (~senorarat@4.sub-75-238-52.myvzw.com) (Quit: Lost terminal) |
| 2025-07-09 04:46:29 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-07-09 04:47:05 +0200 | <Axman6> | https://paste.tomsmeding.com/N2G4Z9iq |
| 2025-07-09 04:48:49 +0200 | <Axman6> | is typedef enum : uint32_t { ... } as C++ ism? |
| 2025-07-09 04:54:46 +0200 | <Axman6> | Asking because one of the headers that get included is <sys/mount.h>, which include the following definition: https://gist.github.com/axman6/64c207ab31310d26e175024594fc46fa, c2hs says "The symbol `:' does not fit here." |
| 2025-07-09 04:57:28 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-09 04:59:00 +0200 | notzmv | (~umar@user/notzmv) notzmv |
| 2025-07-09 04:59:51 +0200 | <geekosaur> | C++ and I think maybe the very latest C standard? |
| 2025-07-09 05:00:02 +0200 | <geekosaur> | otherwise C always treats an enum as int |
| 2025-07-09 05:02:16 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-07-09 05:03:30 +0200 | <geekosaur> | okay, apparently just C++ |
| 2025-07-09 05:04:11 +0200 | dtman34 | (~dtman34@c-73-242-68-179.hsd1.mn.comcast.net) dtman34 |
| 2025-07-09 05:05:53 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-07-09 05:07:56 +0200 | <geekosaur> | also I note that strict in your first paste does that extensible struct thing I mentioned (note the `uint64_t opaque[]` at the end) |
| 2025-07-09 05:08:10 +0200 | <geekosaur> | *struct |
| 2025-07-09 05:09:08 +0200 | <geekosaur> | that's going to make life fairly difficult if you need to save the whole thing and cough it up on a future FFI call |
| 2025-07-09 05:12:12 +0200 | dtman34 | (~dtman34@c-73-242-68-179.hsd1.mn.comcast.net) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in) |
| 2025-07-09 05:13:14 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-09 05:14:43 +0200 | <geekosaur> | although in fact C is no better, they would need to provide a function to capture it as an opaque blob on the heap to which you get a pointer that can be freed by another function |
| 2025-07-09 05:15:36 +0200 | wbrawner | (~wbrawner@static.205.41.78.5.clients.your-server.de) (Remote host closed the connection) |
| 2025-07-09 05:16:48 +0200 | <probie> | I think the assumption is probably that values of es_message_t are never created by hand, only ever passed by reference |
| 2025-07-09 05:17:15 +0200 | <geekosaur> | would pretty much have to be |
| 2025-07-09 05:17:21 +0200 | <geekosaur> | I just worry about lifetimes |
| 2025-07-09 05:17:35 +0200 | <geekosaur> | (where's rust when you need it? 😈 ) |
| 2025-07-09 05:17:54 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-07-09 05:18:19 +0200 | <probie> | Not quite related; why can't GHC's FFI support passing structs |
| 2025-07-09 05:19:14 +0200 | <geekosaur> | because the ABI varies by compiler and platform and sometimes by how the function is called (e.g. varargs/stdarg, but also what other parameters use what registers) |
| 2025-07-09 05:19:45 +0200 | <geekosaur> | the raku folks fought with this, came up with something that worked on amd64, then found aarch64 was completely different |
| 2025-07-09 05:20:07 +0200 | <geekosaur> | and then found even amd64 didn't quite work when returning them |
| 2025-07-09 05:20:59 +0200 | <geekosaur> | you are very much better off handing that problem off to a C compiler and sticking to pointers otherwise |
| 2025-07-09 05:22:37 +0200 | <probie> | Which I'm pretty sure GHC can already do, with the capi calling convention stuff |
| 2025-07-09 05:23:28 +0200 | <geekosaur> | you still have to get stuff across the boundary |
| 2025-07-09 05:23:36 +0200 | jmcantrell | (~weechat@user/jmcantrell) (Quit: WeeChat 4.6.3) |
| 2025-07-09 05:24:31 +0200 | <geekosaur> | as is, capi and ccall can mostly share code. I think capi would need to be thoroughly reworked to even attempt it, and then I think you run into Windows questions iirc? |
| 2025-07-09 05:25:24 +0200 | <geekosaur> | (I may be wrong there, may only have been ccall vs. the now defunct stdcall, not capi at all) |
| 2025-07-09 05:26:10 +0200 | <probie> | I'm not really complaining and know it's not trivial to solve, I just find it frustrating that I can't naively wrap certain C APIs and have to introduce "new" versions of any function that takes a struct by value or returns a struct |
| 2025-07-09 05:26:45 +0200 | <geekosaur> | but in any case you'd still at some level be writing or reading a struct pointer, all capi could do would be to turn it nto a direct parameter/return |
| 2025-07-09 05:27:39 +0200 | <geekosaur> | +in its generated stub |
| 2025-07-09 05:28:17 +0200 | <geekosaur> | personally I consider this just another example of C being a mess of bad hacks |
| 2025-07-09 05:29:02 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-09 05:31:46 +0200 | <probie> | With the library I'm currently working with, I end up with a lot of places where I'd like to be able to write `f =<< (g foo bar)` instead of `alloca $ \someStruct -> g' someStruct foo bar >> f someStruct` |
| 2025-07-09 05:32:03 +0200 | <probie> | Because it deals with graphics, and colours are structs passed by value |
| 2025-07-09 05:34:24 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |