IRC channel logs
2024-02-18.log
back to list of logs
<dsmith>I think dumping/unexec and .so's don't mix very well. <lilyp>shawnw: typically you'd use $prefix/share/guile/site/${guile_effective_version}/ <lilyp>there are autotools macros to figure those out <mwette>rlb: I have code returning full tree of dep modules from a single spec. From that could generate a list of .go's to bind. Next step is to look if a ldscript could be generated. <mwette>Then one could generate main() to (1) find program (using realpath); (2) open as elf; (3) find and load all the .go's; (4) exec top-level function <old>rlb: can you could just find the relevant .go files in the ELF file then mapped them to a tmpfs I guess <old>the add the top of the tmpfs used as a compile path <rlb>Looks like as long as you can get a #u8 vector you can load the code. <rlb>...I'd also thought that we used some of the .go mmapped in place from the filesystem, but it looks like right now we may always make a (mem)copy first, or maybe that's only for part of the file -- not positive. <rlb>wrt #u8 - load-thunk-from-memory <rlb>Anyway, this isn't pressing -- just wondered, and might be interested later... <old>if the .go is in the file, using mmap is all that is needed <old>and if u8 is accepted, than that is even better <mwette>It's not clear to me that the guile code for loading elf's can be extended to more than one module. The .go code is copied dynamically allocated memory. The .go files have an init section that needs to be executed as well. <mwette>not clear that the module elf's can be combined with the main() elf sections, either, unless we create a new way to store module code in elf sections <old>mwette: so unpacking all modules (.scm) in a tmpfs would do the trick, then just need the compiler to be embedded <WilhelmVonWeiner>I'm fairly new to guile but even I should've caught that. Missing parens inside the cond. <jpoiret>WilhelmVonWeiner: looks good, but don't you want to load the non-legacy file first? <WilhelmVonWeiner>jpoiret: no, as to not accidentally modify an existing user's expected behaviour. They might not expect the change, might not be able to meet it's requirements or their setup might necessitate the previous behaviour. Bit rude I think <WilhelmVonWeiner>I sent a patch to bug-guile@gnu.org a few hours ago but don't see anything in the archives... <mwette>old: I think we are talking past each other a bit. Let me see if I can get some demo together. <mwette>rlb: Do you know where the gcc ldscripts are (on ubuntu)? I can't find them. <rlb>mwette: not sure I know exactly what you mean by ldscripts. <rlb>...to answer my question from the other day: <rlb> -*- mode: scheme; geiser-scheme-implementation: guile -*- <rlb>...appears to be the way to get it to stop prompting with a bog standard emacs install when you're using a #!/bin/sh exec wrapper. <rlb>i.e. put that on the second line with a # in front. <old>rlb: what other implementation of Scheme are you using? <rlb>Non atm. The issue is that if you have a #!/bin/sh wrapper script (via #!), you need a "# -*-scheme-*-" on the second line or similar, so that emacs will know the file is actually scheme code, but then it prompts for the implementation, presumably because it can't do the normal guessing based on the #! line. <old>I do not have this problem because I set the only viable implementation to be guile <mwette>rlb: For `ld' you can use -T to specify a ldscript. If you don't specify -T the man page says it uses "the default script". <mwette>Wondering where the default script is. I'm going to add an additional ld step to bind in the .go's (instead of combining with "default script"). <mwette>failing at this: the linker does not like the .go files: "file in wrong format" <daviid>apteryx: i hopefully will post my guile-lib patch suggestion later tonight, but if not, by tomorrow night ... tx <daviid>apteryx: but so you know, the idea was to ask if you could rather make the source-properties an kw arg, as in (define* (log-helper lgr level objs #:key (source-properties #f)) ...) and addapt in its core so it'd call ... (if source-properties (accept-log ... source-properties) (accept ...)) - then add an accept-log method that has the added arg ... in the old accep-log core def, you just call (accept-log ... #f) to maintain only one <daviid>this way, previous code that uses the guilelib's logger would still work - and imo, it's a better approach 'anyway' <daviid>actually, (define* (log-helper lgr level objs #:key (source-properties #f)) ...) its core can stay as you propose - then add an accept-log method that has the added arg, and in the old accep-log core def, just call (accept-log handler level cur-time str #f) <apteryx>daviid: thanks for the suggestion; I'll look into it a bit later <daviid>apteryx: the other thing i wanted to ask, is related to the commit log style - nothing really important, but imo, a few simple 'rules' to keep i mind and easy to 'implement', that makes reading the commit log(s) a much nicer experience. here is what i'd recommend, together with an example based on your commit msg (that i didn't change, just for you to look at an example, but it will have to be updated/changed if you agree with my <rlb>I thought I figured out how to fix this, but can't recall -- if a load-extension makes some top-level bindings, and they're used in the .scm file that calls it, compilation complains about "possibly unbound variable"s. Is there a typical way to avoid those?