|
🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm Set by lizmat on 8 June 2022. |
|||
| [Coke] | Sure - just happy to update anything obviously bad. :) | 00:42 | |
| i did a rebase, why is github.com/rakudo/rakudo/compare/m.....coke/ps1 showing commits i didn't make to tbe branch? | 00:47 | ||
| Geth | rakudo/coke/ps1: 29a21f7933 | (Will Coleda)++ | src/core.c/REPL.rakumod Add proof of concept for configurable REPL prompt |
00:49 | |
| rakudo/coke/ps1: d2e1ae96f2 | (Will Coleda)++ | src/core.c/REPL.rakumod Allow multiple \t replacements |
|||
| rakudo/coke/ps1: 3d1f450ab7 | (Will Coleda)++ | src/core.c/REPL.rakumod Add support for \c and named ansi codes |
|||
| [Coke] | nevermind, cleaned up | ||
| rakudo: coke++ created pull request #5758: Coke/ps1 |
00:50 | ||
| [Coke] | made the rakudo PR non-draft so I can get the CI on it | 00:51 | |
| timo | i just had A Thought | 08:46 | |
| parsing DWARF may be a good source for generating C library bindings | 08:47 | ||
| possibly easier to do than parsing C header files | |||
| one reason for that is that the DWARF symbols encode in them the final results of all the definitions you're interested in. you don't have to understand #if / #ifdef / preprocessor stuff, you don't have to make sure you can chase down all the includes so you don't end up with dangling definitions, ... | 08:49 | ||
| with gptrixie we currently rely on CastXML, which last time i looked wasn't exactly trivial to set up, and maybe more importantly requires a C compiler like clang or gcc, which is not exactly a tiny dependency | 08:50 | ||
| on the other hand, the debug symbols are only very rarely already available on your target systems without end-user "intervention", so even if we go with parsing DWARF, that would probably be a step that spits out source code that can be distributed, rather than just running once at precompilation time for example | 08:51 | ||
| we don't have to parse the binary dwarf data ourselves, either; we could call dwarfdump and read the output, or we could use libdwarf | 08:52 | ||
| hmm. was i wrong? | 09:13 | ||
| gist.github.com/timo/0342a08148b07...d25b97c261 | 09:21 | ||
| this has no answer for "windows?" and also maybe nothing for mac? are there dwarf debug symbols on macs? is there a public infrastructure where you can easily find the debug symbols for "the mac version of the library i have in front of me right now"? | 09:43 | ||
| one more benefit is that you don't have to have a machine of the target architecture and OS available, and no need to have a cross-compiler set up for the target. but you do need to find the right dwarf symbol files, and on windows you usually don't get dwarf but instead something incompatible and undocumented (last time i checked) | 09:45 | ||
| OTOH, on github actions you do get mac and different linuces, right? do you get 32bit linuces on github actions or do you have to bend over backwards? | 09:47 | ||
| patrickb | Another idea: Only depend on a preprocessor. Then parse the pure C by hand. | 10:58 | |
|
11:01
sena_kun joined
|
|||
| timo | yes, that was also suggested. that also requires the dependencies to be present as source (only headers) as well | 11:14 | |
| also, i'm not sure if there's a way to have a c preprocessor but not a c compiler | 11:18 | ||
| i mean, of course there is a way, but needs a bit of work? like, take the compiler package and remove the compiler from it and leave only the preprocessor | 11:19 | ||
|
22:33
sena_kun left
23:13
sena_kun joined
|
|||