Newest at the top
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 |
2024-04-18 02:39:44 +0200 | euleritian | (~euleritia@dynamic-176-006-177-197.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
2024-04-18 02:39:41 +0200 | madeleine-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 +0200 | peterbecich | (~Thunderbi@47.229.123.186) |
2024-04-18 02:24:57 +0200 | oo_miguel | (~Thunderbi@78-11-181-16.static.ip.netia.com.pl) (Ping timeout: 272 seconds) |
2024-04-18 02:24:44 +0200 | philopsos | (~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 |