IRC channel logs
2025-10-21.log
back to list of logs
<meaty>does guile support r7rs define-library? the manual only mentions the r6rs library form but also says r7rs is supported <meaty>no mention of it in 'R7Rs Incompatibilities' either <rlb>I'd expect so: module/ice-9/r7rs-libraries.scm:(define-syntax define-library <rlb>Though I haven't used it myself. <apteryx>meaty: it does but some things are lacking <apteryx>e.g., 'include' doesn't behave correctly <apteryx>it is not able to load modules with numbers in it, e.g. (srfi 26) <apteryx>with all that, you can finally build SRFI 209 in its r7rs form. <apteryx>I think all these should be good for contributing to Guile proper, except the 'include' fix, which I found to be unrelablie (it appears to require byte-compiled objects to work as intended). <apteryx>old: didn't know about blue, it sounds good! <apteryx>can strip be meaningfully used on Guile .go modules? It manages to extract the debug info, but then objdump chokes on the separate .go.debug files with "objcopy: Unable to recognise the format of the input file" <apteryx>is there something in a Guile ELF that can be reliably parsed to infer if it's been produced by Guile? I could skip processing these then. <apteryx>in a Guile-generated .go ELF, I should say. <apteryx>there are some sections starting with .guile, I could look for that I guess <apteryx>is it a problem/bug with .go file format that we can't strip the debug info from them? Or expected/by design? <apteryx>is there a way to read from some offset in Guile? ala pread(2) <euouae>You'd have to write a C extension, I don't know if you're interested in that <apteryx>any working mmap implementation out there? I saw the C one from mwette, but their last comment was that it still had issues <euouae>apteryx: as far as I can tell it's the high level API that's difficult to implement (mmap-file) <euouae>Nala Ginrut claims he calls mmap() from FFI and it works fine <euouae>apteryx: what kind of things do you work on in Guile? <euouae>I vaguely know that you do stuff with Guile, I think I've seen your username before <euouae>what does that involve? writing packages? <apteryx>there's packages, there's services, there's the underlying plumbing/modules. It's a vast world :-). <apteryx>via parse-elf in (guix elf); which currently works on an in-memory bytevector object <euouae>oh I see, Courtes says he wanted to load PT_DYNAMCI <apteryx>mmap would allow passing that same bytevector object but file-backed <apteryx>so if you encounter a 1 GiB .so, just to read the PT_DYNAMIC segment, you currently need to put all that in memory, which is a a bit ridiculous <euouae>You don't need to do that of course <euouae>Courtes says there's other areas that do similar things and he thinks mmap would be a good way to solve this, and I agree <euouae>but you can also just use an ELF parser, no? <euouae>`man 5 elf` and you can see the details <apteryx>IIUC (guix elf) is a complete parser <apteryx>it was originally proposed for Guile 2.1, but it looks like it didn't make it <apteryx>it's complete, or complete enough, but the whole interface assumes a bytevector. Which is OK if we have mmap :-). <euouae>okay you need to fix that, or I could do it <euouae>it should not assume an entire bv, it's just bad <euouae>I'd rather fix (guix elf) than mess around with mmap to be honest <apteryx>what do you mean exactly by chunked input? <euouae>while read(buf, file): elf.parse(buf) <apteryx>I thought it could use a port and manually seek to the right spot on every read, but that'd be a big interface change. <euouae>Yeah this interface needs to change, it's not good <euouae>You don't need to break it, you can just add more procedures <euouae>I'm willing to take a stab at this <apteryx>that chunk idea wouldn't be efficient for ELF, it jumps at many places from the various headers to segments to actual value address, IIUC <euouae>you read the header then you decide where to jump next <apteryx>right. The header is at max 64 bytes. <euouae>It can control the read itself, you can specify the desired program headers (or sections) <euouae>It's basically bad that there's a (parse bv) it can't be overstated how bad that interface is; (parse-elf port #:headers '(PT_DYNAMIC)) e.g. is much better <apteryx>I think the idea was to parse everything at once, and return the full thing. <euouae>No the idea was that the author bailed out of the details :P <apteryx>I'm still not convinced it's that; you could give the first (parse-elf bv) with a 64 bytes bv and get the <elf> record just fine I think <euouae>apteryx: well, again, I can work on this if you'd like me to <apteryx>If you'd like too, that'd be nice. I could move on to the next bug :-) <euouae>I'll take a stab at it because I want to refresh stuff about ELF <euouae>I'm working on trying to debug certain stuff in Guile and I started from 0 tryin to understand the compiler (tree-il, cps, bytecode) <euouae>it'd be nice to supplement with how bytecode is laid out in ELF files <euouae>alright I'll start now give me 10 days though I expect it'll take much less (thankfully ELF is very well documented and easy to work with AFAIK) <apteryx>yes, I remember Wingo saying there were optimizations left to be done in the .go ELF files in terms of reducing size <apteryx>by the way, there is some exercising of that coding in tests/gremlin.scm, which can be run with 'make check TESTS=tests/gremlin.scm' in the Guix checkout. <euouae>thanks, yeah gremlin is one of the users of (guix elf) <euouae>I'm debating in my head whether I should take (guix elf) into its own standalone library <euouae>I suppose other projects could in theory benefit from having an ELF praser <apteryx>I'd start with (guix elf) since it's already there and you won't get lost into the details of setting up a build system and stuff (though guile-hall helps). <euouae>It has 6 examples which are the most common I could think of <euouae>(guix elf) is the simplest, pure Guile library <apteryx>I've heard today of the 'blue' Guile-authored build system, I wonder how it'd do. <euouae>I think I'll keep it at that namespace (guix elf) namely, I'll contribute the patch to Guix and separately release it as its own library too. Assuming I get anywhere with this. <euouae>apteryx: I had a pretty bad experience with OCaml trying to use Dune (uses Scheme syntax!) and I really prefer if people torture us with Autotools instead <euouae>mra is getting Guile to work with meson though <apteryx>that sounds like another good option to have <lloda>i get that python is infra this this but it's a bit icky to have guile packages depend on python to build <euouae>if you're trying to bring new people in to have fun with the language it's not a bad idea to have meson as an option regardless of dependencies <mra>enouae: I've got some of the basics working, now I just need to figure out how I want the actual interface to work. <mra>frankly, I think that autotools is a nightmare, so I'm just trying to avoid it <mra>blue seems cool, although i will say that i tend to agree with the meson folks that build systems should not be turing-complete <mra>also, I'm pretty convinced that meson is the best build system that exists for C, and having Guile support would, I suspect, make building Guile projects with some parts written in C really easy. <euouae>There's some things that meson can't do and it's not easy to put those features in, I like CMake better <mra>euouae: what are the features that you find lacking in meson? <dariqq>mra: I ported my sample guile+autotools project to meson a couple of months ago but there are some things where I was fighting against meson to make it work <euouae>Autotools does not support this out of the box either. (You have to do the work yourself) <euouae>Granted that this is a very specific thing about the visibility of symbols in the produced C/++ libraries that most people don't care about <apteryx>euouae: by the way, I had found poke-elf and pax-utils to be useful to inspect elf files, in case you have that need. dumpelf prints the C-like structs <mra>dariqq: I've looked at your project! it was a great help. did you get a sense of what features you wished meson had to make the process easier? <mra>that would help me a lot with designing the API <dariqq>mra: nice, my thing is definitly a bit over engineered :). The biggest issue for me is the ocpy pasting to compile and install guile modules for each subdir is really annoying. Some other things are supporting multiple guile versions at the same time and getting the path to guile/guild etc is complicated. Having a similar api to guile.m4 would be useful where it makes sense . The snarfer is a bit difficult to use because you need to get <dariqq>the cflags that meson does not make easily available. Most of these are not really guile specific. <apteryx>there's no such thing as gc-set-finalizer! that I could call from Scheme, right? <apteryx>looks like I should perhaps use a guardian instead <apteryx>I was able to get a mmap/munmap binding to work, and add some sugar on top in the form of call-with-mmap-bytevector <apteryx>the work of Mu (Nala Ginrut) in Artanis made this much easier, thank you! 