2024/04/18

Newest at the top

2024-04-18 02:58:37 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2024-04-18 02:57:43 +0200dcoutts(~duncan@cpc69400-oxfd27-2-0-cust750.4-3.cable.virginm.net) (Ping timeout: 260 seconds)
2024-04-18 02:55:55 +0200mud(~mud@user/kadoban) (Quit: quit)
2024-04-18 02:53:54 +0200peterbecich(~Thunderbi@47.229.123.186) (Ping timeout: 252 seconds)
2024-04-18 02:52:10 +0200dcoutts(~duncan@cpc69400-oxfd27-2-0-cust750.4-3.cable.virginm.net)
2024-04-18 02:51:48 +0200dcoutts(~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 +0200xff0x(~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
2024-04-18 02:39:44 +0200euleritian(~euleritia@dynamic-176-006-177-197.176.6.pool.telefonica.de) (Read error: Connection reset by peer)
2024-04-18 02:39:41 +0200madeleine-sydney(~madeleine@c-76-155-235-153.hsd1.co.comcast.net)
2024-04-18 02:39:28 +0200 <monochrom> Yeah I was appalled that it does not let me examine the 4 bytes of a 32-bit int by union { int i; char b[4]; }
2024-04-18 02:39:04 +0200 <Inst> rest is library documentation
2024-04-18 02:39:01 +0200 <Inst> tho core is only 186 pages
2024-04-18 02:36:40 +0200 <geekosaur> also, Apr 16 20:54:53 <c_wraith> "Developers who manage to figure out what the standard actually means are frequently appalled." truer words never spoken of C
2024-04-18 02:36:18 +0200 <Inst> i'm skimming through it now, it's only 757 pages, which, while long, is still manageable
2024-04-18 02:35:00 +0200 <geekosaur> not comprehensible by mortals
2024-04-18 02:33:25 +0200 <Inst> what's wrong with reading the C standards?
2024-04-18 02:25:30 +0200peterbecich(~Thunderbi@47.229.123.186)
2024-04-18 02:24:57 +0200oo_miguel(~Thunderbi@78-11-181-16.static.ip.netia.com.pl) (Ping timeout: 272 seconds)
2024-04-18 02:24:44 +0200philopsos(~caecilius@user/philopsos) (Ping timeout: 252 seconds)
2024-04-18 02:23:15 +0200 <monochrom> https://ro-che.info/ccc/11
2024-04-18 02:22:53 +0200 <geekosaur> -s+d
2024-04-18 02:22:49 +0200 <geekosaur> …which leaves "comprehens"…
2024-04-18 02:22:17 +0200 <monochrom> If you accept laziness, I can legitimately claim that I am familiar with it, because I will read the relevant sections on demand! >:)
2024-04-18 02:22:16 +0200 <Inst> i like monochrom being appropriately harsh
2024-04-18 02:21:01 +0200 <monochrom> Well, sure, no, but I happened to read that section about how "int foo[4]" and "int foo[5]" are different types.
2024-04-18 02:20:31 +0200 <geekosaur> is anyone really?
2024-04-18 02:20:15 +0200 <monochrom> inb4 "in this case, I simply wasn't familiar with the C standard"
2024-04-18 02:19:21 +0200 <monochrom> That's actually wrong.
2024-04-18 02:19:02 +0200 <Inst> C doesn't even have a true array type, just a pointer, an increment based on type, and some sugar
2024-04-18 02:18:34 +0200 <geekosaur> neither is C 😛
2024-04-18 02:18:07 +0200 <Inst> no, in this case, i simply wasn't familiar with C encoding of strings
2024-04-18 02:18:07 +0200 <masaeedu> Oh, I see
2024-04-18 02:17:38 +0200 <monochrom> I did not mean assume. I meant understandable if some of them don't.
2024-04-18 02:17:08 +0200 <masaeedu> It's a bit elitist to assume non-programmers lack technical imagination...
2024-04-18 02:15:53 +0200 <monochrom> I'm beginning to wonder if you are just complaining that the word "Foreign" does not appear in the function names.
2024-04-18 02:14:37 +0200 <Inst> it's just annoying because Foreign.C.String has a very pleasant interface, except that strings aren't supposed to be good for performance due to being a linked list of chars