Newest at the top
| 2024-04-18 03:58:03 +0200 | JeremyB99 | (~JeremyB99@2600:1702:21b0:a500:a430:c3a5:5a62:375c) (Read error: Connection reset by peer) |
| 2024-04-18 03:55:52 +0200 | JeremyB99 | (~JeremyB99@2600:1702:21b0:a500:a430:c3a5:5a62:375c) |
| 2024-04-18 03:49:36 +0200 | JeremyB99 | (~JeremyB99@2600:1702:21b0:a500:a430:c3a5:5a62:375c) (Read error: Connection reset by peer) |
| 2024-04-18 03:47:49 +0200 | JeremyB99 | (~JeremyB99@2600:1702:21b0:a500:a430:c3a5:5a62:375c) |
| 2024-04-18 03:46:06 +0200 | otto_s | (~user@p4ff271d1.dip0.t-ipconnect.de) |
| 2024-04-18 03:44:23 +0200 | otto_s | (~user@p4ff27d2e.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2024-04-18 03:43:51 +0200 | todi | (~todi@p57803331.dip0.t-ipconnect.de) |
| 2024-04-18 03:43:35 +0200 | todi | (~todi@p57803331.dip0.t-ipconnect.de) (Remote host closed the connection) |
| 2024-04-18 03:42:36 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 2024-04-18 03:33:59 +0200 | madeleine-sydney | (~madeleine@c-76-155-235-153.hsd1.co.comcast.net) (Quit: Konversation terminated!) |
| 2024-04-18 03:28:16 +0200 | beka | (~beka@2607:f598:bd4a:6e0:c0ad:38f8:7650:7d75) (Remote host closed the connection) |
| 2024-04-18 03:26:56 +0200 | beka | (~beka@2607:f598:bd4a:6e0:c0ad:38f8:7650:7d75) |
| 2024-04-18 03:26:36 +0200 | <geekosaur> | so it's your duty to play along with what the C API requires |
| 2024-04-18 03:26:29 +0200 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) (Remote host closed the connection) |
| 2024-04-18 03:24:51 +0200 | <geekosaur> | (and you probably don't want to assign that function as a finalizer because it would tear down more than just that string) |
| 2024-04-18 03:24:47 +0200 | mei | (~mei@user/mei) |
| 2024-04-18 03:24:16 +0200 | <geekosaur> | you would normally use unsafePackCString when receiving a C string as part of some data from a C library, where its lifetime is controlled by calling some deinitialization function |
| 2024-04-18 03:24:12 +0200 | <Inst> | thanks for your patience |
| 2024-04-18 03:23:59 +0200 | beka | (~beka@2607:f598:bd4a:6e0:c0ad:38f8:7650:7d75) (Remote host closed the connection) |
| 2024-04-18 03:22:37 +0200 | <geekosaur> | if you know that it came from C malloc, use unsafePackMallocCString |
| 2024-04-18 03:22:02 +0200 | <geekosaur> | if you mean unsafePackCString, the point is that there is no way to automatically know how to dispose of it, and indeed it may be a pointer to a C `static` buffer which can't be freed at all |
| 2024-04-18 03:19:36 +0200 | mei | (~mei@user/mei) (Remote host closed the connection) |
| 2024-04-18 03:17:10 +0200 | <Inst> | and actually in the standard bytestring interface, there are provisions for converting bytestring to cstring and vice versa |
| 2024-04-18 03:16:35 +0200 | ridcully | (~ridcully@p508acfbb.dip0.t-ipconnect.de) |
| 2024-04-18 03:16:02 +0200 | <Inst> | with regards to bytestring, it seems that the unsafe functions will create data that's not garbage collected? So how should bytestring-generated data be GCed? |
| 2024-04-18 03:15:29 +0200 | ridcully | (~ridcully@p508accab.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
| 2024-04-18 03:08:42 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2024-04-18 03:08:42 +0200 | wroathe | (~wroathe@23.162.40.122) (Changing host) |
| 2024-04-18 03:08:41 +0200 | wroathe | (~wroathe@23.162.40.122) |
| 2024-04-18 02:58:37 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-04-18 02:57:43 +0200 | dcoutts | (~duncan@cpc69400-oxfd27-2-0-cust750.4-3.cable.virginm.net) (Ping timeout: 260 seconds) |
| 2024-04-18 02:55:55 +0200 | mud | (~mud@user/kadoban) (Quit: quit) |
| 2024-04-18 02:53:54 +0200 | peterbecich | (~Thunderbi@47.229.123.186) (Ping timeout: 252 seconds) |
| 2024-04-18 02:52:10 +0200 | dcoutts | (~duncan@cpc69400-oxfd27-2-0-cust750.4-3.cable.virginm.net) |
| 2024-04-18 02:51:48 +0200 | dcoutts | (~duncan@cpc69400-oxfd27-2-0-cust750.4-3.cable.virginm.net) (Remote host closed the connection) |
| 2024-04-18 02:49:46 +0200 | <geekosaur> | so capi brings back how it used to work (and arguably how the spec expects it to work, although it's not documented as such) |
| 2024-04-18 02:49:11 +0200 | <geekosaur> | capi pretty much only exists because moving to generating asm directly instead of compiling via C broke the original ffi spec in important ways |
| 2024-04-18 02:49:03 +0200 | xff0x | (~xff0x@2405:6580:b080:900:7a5b:fae6:85e7:e330) (Ping timeout: 255 seconds) |
| 2024-04-18 02:48:09 +0200 | <jackdk> | There are important correctness benefits to using CApiFFI, particularly around things like variadic functions and exotic calling conventions, see https://www.haskell.org/ghc/blog/20210709-capi-usage.html |
| 2024-04-18 02:47:48 +0200 | <geekosaur> | asm is faster when it works but most functions expect to be called via C, and as such often make use of preprocessor macros and the like which asm won't know about |
| 2024-04-18 02:46:20 +0200 | <Inst> | in terms of space and time, which is better? |
| 2024-04-18 02:45:31 +0200 | <geekosaur> | capi deals with making function calls via C instead of directly via asm. c2hs writes bindings for you; those might be via capi or via asm |
| 2024-04-18 02:45:07 +0200 | <yushyin> | "when it works" I really feel that |
| 2024-04-18 02:44:08 +0200 | <geekosaur> | because with capi you still have to write the bindings; c2hs does that for you, when it works |
| 2024-04-18 02:44:07 +0200 | <monochrom> | I think they are orthogonal? You could use both? They solve two unrelated problems? |
| 2024-04-18 02:43:27 +0200 | <Inst> | by the way, why are people using c2hs instead of just capi? |
| 2024-04-18 02:42:52 +0200 | <monochrom> | Subsequently I only taught fwrite to a file and then just examining the bytes in the file. >:) |
| 2024-04-18 02:41:08 +0200 | <monochrom> | There was one year when I taught that hack to students. Subsequently I saw you guys here mentioning that it is not kosher, so I retracted it. |
| 2024-04-18 02:40:24 +0200 | <geekosaur> | and always was |
| 2024-04-18 02:40:12 +0200 | <geekosaur> | that one doesn't surprise me; it's a hack that happens to work on many common architectures |