IRC channel logs

2020-07-20.log

back to list of logs

<seepel>Ahhh, good call out. I'll definitely need webkitgtk as well.
<pkill9>what's the character predicate for forward-slash?
<pkill9>found it, #\/
<RhodiumToad>#\ followed by any character is a character literal whose value is that character
<rlb>Unless I missed it, be nice to include some documentation regarding the pipeline error handling, i.e. what happens if any given process fails, how is the exit status computed, etc. Perhaps even nicer if we had something like bash's PIPESTATUS.
<dsmith>rlb: That newish pipe commmand returns a list of pid's. (along with the in fd and out fd)
<dsmith>I guess that's so you can call wait on them to get result status
<rlb>Ahh, ok - that'll work. No way to get stderr, but that's not critical atm. Thanks.
***jonsger1 is now known as jonsger
<dsmith>rlb: And that newish function is "pipeline".
<rlb>right
***catonano_ is now known as catonano
<str1ngs>daviid: were you looking for my help yesterday? I must have missed that
<seepel>str1ngs: He was recruiting you to help me install g-golf in guix. I've since managed to sort myself out. Turns out there was a bug in the package definition, and I didn't realize that g-golf didn't support guile 3 yet.
<dsmith>pkill9: You know, I think that's just the way readline works.
<dsmith>pkill9: Just noticed at a bash prompt, when completing an exec or a filename, it *also* adds the space.
***wxie1 is now known as wxie
<str1ngs>seepel: does the guix g-golf definition have a bug?
<str1ngs>seepel: daviid I notice you want the latest g-golf to work. I'll look into to it. I need to update nomad to use the latest g-golf as well.
<daviid>str1ngs: i was away from the kb, but i think seepel did solve that problem - by all mean, i'll let you (two) solve that problem
<str1ngs> daviid I've been pretty busy the last two months. I should make some time to get back upto speed with g-golf.
<seepel>str1ngs: Yes it seems to, the guile-lib package seems to point to guile 3 but is needed for the g-golf tests which look for it in the 2.2 site directory so the check phase fails.
<seepel>I have a modified version which seems to work, hoping to find some time tomorrow to figure out how to submit a patch :)
<str1ngs>seepel: right should just be a matter of using guile2.2-lib for the input.
<daviid>str1ngs: np! nothing changed, at least from a nomad usage pov - i'm working on the manual at the moment, the only thing that will change in the future, for nomad, is the way interfaces are being handled
<daviid>str1ngs: of course i'll let you know, but for the time being, everything is 'the same' ...
<str1ngs>daviid: sounds good. sorry I missed your highlight yesterday.
<seepel>str1ngs: Yup, that's the conclusion I came to as well. My only question is if guile2.2-lib should also be in the native-inputs considering they are needed for the build.
<str1ngs>seepel: I added guile-lib as an input g-golf when I submitted it and it passed review. So lets assume that's okay for now.
<str1ngs>I would also bump the git hash to whichever daviid thinks is the best. if git HEAD is fine the use the latest hash of cource.
<str1ngs>course*
<seepel>I did bump the hash. Actually, another question I had was how I should bump the version. Right now it is (git-version "1" "683" commit)
<str1ngs>seepel: one sec there is an easier way to do this.
<daviid>str1ngs: seepel yes, yu may pick-up the very latest commit, which adds doc to tell how users may configure g-golf ...
<seepel>I meant the guix package version.
<str1ngs>seepel: actually this wont' work for g-golf because it does'nt have tags. use git rev-list --count HEAD to get the revision. so (git-version "1" "804" commit) should work
<seepel>str1ngs: Perfect, thank you!
<str1ngs>maybe daviid will be nice and tag alapha release :)
<str1ngs>seepel: see emacsy-minimal for an easier way to get a version for git. but it relies on release tages
<daviid>str1ngs: asap, but not too early either ... we will have to make this guix update danse a few more times i'm afraid ...
<str1ngs>daviid: no worries just a single alpha release tag would be useful. but because this is a GNU project I'm guessing you want to be more strict about release tags.
<str1ngs>seepel: with the emacsy-minimal package you can just use something like v0.4.1-28-gd459ca1 for the commit with (version (string-drop commit 1)) and it's all handle automatically. but I forget how to have git spit out the version tag with the hash. there is away to do it.
<str1ngs>seepel: ahh I remember git describe :)
<daviid>str1ngs: i thought it was as easy as copy/pasting the commit id, rehashing the package and 'patch guix' with those two 'simle changes' ...
<daviid>str1ngs: i won't 'alpha release' until i have full interface implementation, a complete user manual part and a few more other 'minor' things ...
<daviid>and i also hope to have proper 'callbacks' (which is not exactly a piece of cake ...) in the alpha release
<str1ngs>daviid: still need to had the git revision from rev-list --count HEAD. to get a version for guix
<daviid>mean while, I also hope to have a few more audacious users, to get rid of as many bugs as possible and augment/fix (missing) types ...
<str1ngs>but you have it about right. usually with nomad I do a bunch of testing before I submit a patch for guix as well.
<str1ngs>I'll probably find some bugs in the next couple of days when I get back up to speed. will let you know :)
<daviid>str1ngs: ok, great
<str1ngs>daviid if also g-golf working pretty good when I update it. I'll maybe submit the feature-g-golf branch to guix. that should gain more traction for both g-golf and nomad.
<daviid>str1ngs: excellent, but let's make 'small but sure' steps ...
<str1ngs>sound good.
<daviid>str1ngs: i don't remember if you were around when i pushed the feature, but were you g-golf has 'short name method'
<str1ngs>daviid: I saw some mention of that. I plan to look at that as well tomorrow. I'd rather switch to short names now then later. will save me work.
<daviid>*but g-golf has 'short name methods' - and syntax name protection - this is now described in the manual as well, along with other 'configure g-golf' things ... maybe worth a quick read ...
<daviid>str1ngs: ok
<spk121>.
***wxie1 is now known as wxie
<manumanumanu>ArneBab: I have a much simpler one than srfi-134 here: https://hg.sr.ht/~bjoli/data-structures/browse/persistent-fifo.scm. Adding removal of items back and front should be simple enough. It Enqueueing and dequeueing is amortized o(1), like srfi-134, but it doesn't do any balancing, and should be slightly faster than srfi-134
<manumanumanu>ArneBab: oops. I shouldn't be half-reading discussions :)
<manumanumanu>Nice implementation! I have thought about porting the last generator srfis to guile and making a proper package out of it. The make-coroutine-generator on top of delimited continuations is just too nice to not have. Last time I checked, a list-generator on top of delcc was even faster than a list-generator using set
<manumanumanu>!!
<manumanumanu>oops. *using set!
<manumanumanu>not only that, the fifo I linked to can trivially be made a deque with the same amortized o(1) for pushing to the front.
***sputny1 is now known as sputny
<pkill9>does anyone know how I could generate the list of inputs used in guix package definitions? they are of the the form `(("package-name" ,package-variable))
<pkill9>I want to generate that quasiquote too
<pkill9>i looked to see how `guix import pypi` does it but can't work out how
<mwette>not sure what you mean ? (pretty-print '`("abc" ,def)) => `("abc" ,def)
<pkill9>mwette: i want to generate "abc" and "def"
<pkill9>as in, I want to produce those programmatically
<dsmith-work>Monday Greetings, Guilers
<pkill9>but what i want to do
<pkill9>is to write the quasiquote
<pkill9>but programmatically create the abc and def
<pkill9>I don't know how to compute the abc and def, while adding a quasiquote to the beginning of the list of inputs
<pkill9>the list of inputs is like so: `(("input1" ,input1) ("input2" ,input2))
<pkill9>I want to programmatically generate the names of input1 and input2
<pkill9>but I want to then after doing that, add the quasiquote at the beginning
<pkill9>anyone know how?
<mwette>Ahh. I ran into same issue but ended up building a list and using eval-string.
<mwette>(define (acons-defn name type seed)
<mwette> (cons (eval-string (simple-format #f "(quote `(~A ,~S))" name type)) seed))
<mwette>(eval-string (simple-format #f "(quote `(~S ,~A))" "input1" "input1"))
<mwette>
<pkill9>ah i see, thanks
<mwette>I made a Guile Scheme code generator for modules using ffi using bytestructures.
<pkill9>got it working \o/ thanks mwette
<pkill9>lisp is the ultimate virus due to it's code-generating-code nature
<roelj>Is there a way to disable auto-compilation in C code when Guile is "started" using "scm_init_guile"?
<roelj>I think a call to setenv("GUILE_AUTO_COMPILE", "0") before scm_with_guile isn't working.
<dsmith-work>roelj: Unlikely to fail, but did you check the return value from setenv ?
<roelj>dsmith-work: Of course not ;).
<roelj>Checking now
<dsmith-work>roelj: I took a quick look at the code that checks the env variable. Hard to see how it could be wrong.
<dsmith-work>roelj: And it *is* called before scm_init_guile.
<dsmith-work>Uh,
<dsmith-work> s/before/from/
<roelj>dsmith-work: Yes yes. I've done a minimal test example, and that works!
<civodul>has anyone parsed xhtml with xml->sxml?
<civodul>it chokes for me, but there's no line info
<roelj>civodul: What happens when you remove the doctype?
<civodul>roelj: it doesn't help
<RhodiumToad>is your xhtml actually valid xml?
<roelj>civodul: Hm, this seems to work fine for me: (xml->sxml "<!DOCTYPE html><html><head><title>Test</title></head><body><h1>Hello!</h1></body></html>")
<dsmith-work>civodul: Is it huge?
<dsmith-work>(like blowing out a stack or something)
<civodul>dsmith-work: no no, it's a parse error
<civodul>on pages like this: https://download.savannah.nongnu.org/releases/guile-json/
<civodul>"Wrong character " #\=
<civodul>"Wrong character " #\=
<civodul>err
<RhodiumToad>that page isn't even close to valid anything
<dsmith-work> https://validator.w3.org/check?uri=https%3A%2F%2Fdownload.savannah.nongnu.org%2Freleases%2Fguile-json%2F&charset=%28detect+automatically%29&doctype=Inline&group=0
<roelj>civodul: https://validator.w3.org/check?uri=https%3A%2F%2Fdownload.savannah.nongnu.org%2Freleases%2Fguile-json%2F&charset=%28detect+automatically%29&doctype=Inline&group=0
<civodul>ah!
<RhodiumToad>it just breaks off at the end with bad tags and no proper closing of anything
<civodul>alright, so it's not the parser that's to blame :-)
<civodul>ty!
<dsmith-work>"14 Errors, 13 warning(s)"
<dsmith-work>roelj: heh
<a_v_p>civodul: Hello! I've sent a new Guile-SSH release announcement to "guile-user" ML almost two days ago, but the message didn't appear in the ML yet. Am I missing something?
<dsmith-work>I wonder how htmlprag will do on that..
<pkill9>any idea why this json is failing to be read by guile-json's (json-string->scm)? https://www.reddit.com/r/modhelp/comments/.json
<pkill9>i put it in a variable with (define a (readline)) and pasted it into the terminal
<a_v_p>There was Guile-SSH distribution archive with a GPG signature attached to the email -- probably, that didn't pass some mail filters on ML? If so, I can re-send the announcement without the archive.
<pkill9>then (json-string->scm a) errors with ice-9/boot-9.scm:1669:16: In procedure raise-exception:
<pkill9>In procedure integer->char: Argument 1 out of range: 55356
<heisenberg-25>I am getting a no code for module error while building a guile project. File A defines module <a> and it is imported by file B. But compilation of file B fails with no code for module <a>. I am using autotools to build the project
<str1ngs>daviid: hello, one small issue I've found with g-golf's autotools. In autogen.sh config.rpath is generated using touch. would it be possible to just add a empty build-aux/config.rpath to git tree. This would help with autotools projects that use g-golf as a sub project. for example I use g-golf as a sub project here https://gitlab.com/mike.rosset/nomad-3rdparty . which makes it easier to install nomad dependencies that do not exist
<str1ngs>normally, like emacsy and shroud.
<roelj>How would I set the *random-state* from C? scm_c_define("*random-state*", ...)?
<str1ngs>roelj: it's easier to use the SCM_DEFINE macro see clear-image in https://www.gnu.org/software/guile/manual/html_node/Function-Snarfing.html . there is also a SCM_DEFINE_PUBLIC
<str1ngs>in the case of clear-image you can then use clear_image from C. if I'm understanding your question
<roelj>str1ngs: Does this also work for variabels that are already defined?
<str1ngs>roelj: aww one sec scm_c_define binds a variable not a procedure. once sec I'll explain how to set the variable .
<roelj>str1ngs: I see there's scm_variable_set_x, but I don't know how what to pass to it.
<str1ngs>I think you can get the binding with SCM var = scm_c_lookup ("*random-state*"); which you can then pass to scm_variable_set_x
<roelj>If there's a better way to initialize Guile's pRNG from C then I'd also like to hear about it :)
<roelj>str1ngs: Ah, thanks!
<str1ngs>roelj: also it might be better to use scm_c_public_ref since it's not dependent on the current module. it's what I would normally use here.
<roelj>str1ngs: IIUC then scm_c_public_lookup doesn't dereference the variable. Why is it important to dereference it? The call to scm_variable_set_x would fail if the variable wasn't bound, right?
***terpri_ is now known as terpri
<roelj>str1ngs: Well, it works and I learned something new today. Thanks!
<str1ngs>roelj: actually in this case you want scm_c_public_lookup to get the bindings. scm_c_public_ref gets the value.
<str1ngs>does this make more sense?
<roelj>Oh yes
<roelj>I didn't realize that difference thoguh
<str1ngs>apologizes been awhile since I used these. I should have read it more deeply
<roelj>So, I now do scm_c_public_lookup, followed by scm_variable_set_x.
<str1ngs>right that seems more correct
<roelj>How do I catch if something goes wrong? Can I test the return value of scm_c_public_lookup?
<roelj>The doc says "signals an error", but that leaves me a bit clueless.
<str1ngs>in this case I would use a catch. but if you use scm_c_public_lookup on a well defined variable the chance of this through an error is next to nil. personally just use higher lever catch
<str1ngs>s/through/throwing
<roelj>str1ngs: Do you have an example of a catch written in C?
<str1ngs>what I do for my C bindings is keep the C function procedures slim. and then write most of the higher level stuff in scheme. so then it is easier to write guards etc.
<str1ngs>I have an example one sec it's old and not being used now. but should work. it's partly in C++ though but should give you an idea.
<roelj>str1ngs: Sounds great!
<str1ngs>personally if you write things right your catches should be in pure scheme anyways.
<str1ngs>roelj: see http://git.savannah.nongnu.org/cgit/nomad.git/tree/qt/keymap.cpp?h=feature-qt#n86
<str1ngs>then see call_proc and eval_handler at top of the file.
<roelj>str1ngs: Thanks! I see it's actually very similar to the Scheme variant.
<roelj>This really helps, thanks!
<str1ngs>no problem
<dsmith-work>roelj: Might not be the best example, but here is sqlite2 code that calls into scheme and catches and rethrows.
<dsmith-work>So handlings Scheme (which handles) -> C -> Scheme (which throws)
<dsmith-work> https://gitlab.com/dalepsmith/guile-sqlite/-/blob/master/sqlite.c
<roelj>dsmith-work: Heh, I like how it makes sqlite errors catchable.. :)
<dsmith-work>roelj: That's what the bot has been running for about 15-17 years or so.
<dsmith-work>(with tuneups for different guile versions)
<roelj>dsmith-work: What's that SCM_DEFINE followed by a #define? Does it automatically make the function available from guile?
<dsmith-work>That's part of the snarfer machinery. Basicaly, Yes.
<heisenberg-25>Is there a libevent wrapper for guile?
<dsmith-work>The #define FUNC_NAME is for error message
<roelj>Woah, 15 years is impressive, what Guile version was this initially written for?
<dsmith-work>Can't remember. 1.8 at least.
<dsmith-work>But as I said, tweaks for different versions.
<dsmith-work>roelj: The SCM_VALIDATE_* macros use FUNC_NAME I believe
<dsmith-work>roelj: But it *has* been the same old db copied around from machine to machine.
<roelj>impressive, as it seems pretty readable and I don't see any version-specific work-arounds
<roelj>but I haven't looked everywhere :P
<dsmith-work>Oh, I had to change the catch/throw stuff I'm sure.
<dsmith-work>The original code just used a simple makefile. No auto* stuff.
<dsmith-work>That predates the initial commit
<roelj>So even back then Autoconf had a high barier of entry? ;)
<dsmith-work>Hah. Must have been on Guile-1.6 initially
<roelj>It seems that Guile opens a temporary file on startup. What's that about?
<dsmith-work>Yes. Autotools and I are still not speaking to each other.
<roelj>dsmith-work: Haha, still!?! It's been what.. 30 years?
<dsmith-work>I've only touched autotools twice.
<RhodiumToad>autotools are horrible, it's just that the alternatives are sometimes worse
<roelj>Hm, so when I run "guile", I see it opens /tmp/ffiXXXXXX", then the file gets deleted, but it's still in the "open files" list for Guile (so I assume it doesn't close the file?). What's that about?
<roelj>If I grep the Guile source code, I can't seem to fine anything FFI related that does this
<justin_smith>roelj: creating, opening, and deleting a tmp file is idiomatic, the OS lets you continue using the file (as you hold a reference to the fd) and the space is reclaimed after process exit
<justin_smith>that said, I'm not sure what guile does this for, I just know it's a *nix idiom
<roelj>justin_smith: Ah, what happens when you write to a fd of a file that was deleted?
<RhodiumToad>it still writes to it
<RhodiumToad>the file still exists, it just has no names
<RhodiumToad>(files in unix-like OSes may have no name, or one name, or multiple names)
<justin_smith>right - the fd lets you do all the standard operations (read, write, truncate) but other people can't find it by name
<RhodiumToad>I'm guessing this is from libffi rather than guile proper?
<dsmith-work>It might be the compiler creating the file
<RhodiumToad>what guile version is this? I don't see it
<dsmith-work>That calls mkstemp: module/system/base/compile.scm
<roelj>Hm this is interesting
<roelj>I use Guile 3.0.4.
<RhodiumToad>dsmith-work: yeah, but no "ffi" in its template string
<dsmith-work>Ahh. True
<RhodiumToad>roelj: does it still happen with guile -q ?
<roelj>What's more interesting is that "strace -f guile" doesn't show it either, but if you look in /proc/<pid>/fd, it's there.
<roelj>RhodiumToad: Yes, with "guile -q" it also happens
<roelj>It's not a big deal, but I'm curious about it
<dsmith-work>Yes. Very curious.
<RhodiumToad>not happening here (on freebsd)
<roelj>even more interesting
*dsmith-work guesses it's a glibc thing
<RhodiumToad>again, I'd suspect libffi
<roelj>Ah it's in libffi (src/closures.c)
<roelj>The function is called “open_temp_exec_file_dir”.
<RhodiumToad>wonder why it doesn't happen here
<roelj>RhodiumToad: The file opening is wrapped in #ifdef O_TMPFILE. Is that something Linux-specific?
<RhodiumToad>yes
<roelj>Then I think we have a winner
<RhodiumToad>but it goes on to do mkstemp or mkostemp if that isn't defined, which does the same thing
<RhodiumToad>(and that isn't happening here)
<roelj>Oh right, in open_temp_exec_file_name.
<alexshendi>Good evening! May I ask questions about chickadee here, or is there a more appropriate place?
<RhodiumToad>my guess is that that stuff never gets called because it maps in an executable segment some other way.
<RhodiumToad>ah. I think the file is being used to circumvent security restrictions that prevent a writable mapping from becoming executable.
<dsmith-work>alexshendi: You can ask, sure. Not sure if the devs for that are around. (better to ask then ask to ask and all that)
<roelj>RhodiumToad: Aha!
<RhodiumToad>i.e. with an executable file to back the page, it can make separate writable and executable mappings for it
<justin_smith>RhodiumToad: I assume this is needed in some form in order to JIT?
<roelj>I don't understand why this is needed, but then also this is way over my head I think.
<RhodiumToad>yes, and also libffi needs to be able to construct call trampolines
<str1ngs>daviid: I've mailed a patch to update guix's g-golf to the latest revision see https://issues.guix.info/42446 pending review of course.
<RhodiumToad>specifically, it looks like libffi has a "closure" mechanism to construct closures, which will need to create executable trampolines
<justin_smith>roelj: how's this for a simple version - the underlying system says memory is either read-only and executable, or r+w and non-executable, creating a new file is a way to map something you wrote to, as executable, without the kernel killing you for breaking the rules
<justin_smith>this is direct execution (machine instructions), not interpretation of some bytecode by a static program
<roelj>justin_smith: That's a great explanation!
<roelj>But why is r+w memory non-executable? And why isn't this a problem for non-code-generating code?
<justin_smith>roelj: it's a security issue - imagine if a buffer is being written to using user input, and they provide a long input
<justin_smith>and the input is long enough, that their input, gets written over your program
<justin_smith>this is called a buffer overlflow exploit, this is how hackers get root on your box
<justin_smith>because in the old model, all your data and your code were in one contiguous memory, and you could let users write over your executable if you didn't check indexes
<RhodiumToad>note that this is an OS limitation not a hardware one
<RhodiumToad>it's not hugely effective at preventing exploits, since it does nothing about ROP
<roelj>Interesting.. How does the kernel differentiate between r+w regions and read-only regions in memory? Or is that info that the compiler provides?
<RhodiumToad>(which is based on arranging to execute instructions that are already present, rather than writing new ones)
<RhodiumToad>whether a page is writable or executable or both is controlled by the hardware, specifically the virtual memory translation system
<dsmith-work>Yep
<RhodiumToad>for each page in the process's address space, there's an entry that says what physical memory if any is used for that page, and what the access permissions are
<roelj>Right.. can you recommend a book that explains these things? :)
<RhodiumToad>ugh, I'm useless at book recommendations
<roelj>Or any other sources? :D
<RhodiumToad>anything that has a basic introduction to virtual memory will cover this
<dsmith-work>roelj: That stuff is usually deep in the kennel, but is also exposed through mmap. See the mmap man page
<RhodiumToad>yeah, mmap and mprotect are the user-level interface to manipulate virtual memory
<dsmith-work>Different archs have different vm capabilities.
<dsmith-work>ppc might have something that x86 doesn't.
<RhodiumToad>yeah, every cpu design has to make its own tradeoffs between vm functionality and performance
<justin_smith>I thought ARM 64 bit actually had a way for a higher privelege process to impose read-only access of another process to some memory region
<justin_smith>not finding that in the docs right now though
<dsmith-work>But there is some common features that most support.
<RhodiumToad>and let's not get into the horror show that is i286/i386 segmentation
*dsmith-work shudders
<RhodiumToad>at least that's all gone in long mode
<dsmith-work>RhodiumToad: Here are some scary words from the past: large small compact
<RhodiumToad>been there
<dsmith-work>And near and far
*RhodiumToad did a _lot_ of 8086 (not even 286) assembly back in the day
*dsmith-work has also been there
<dsmith-work>RhodiumToad: I was working on a 68K project once, and enjoyed the incredible luxury of allocating a 512K buffer.
<dsmith-work>It was like hearing a choir of angels, or coming upon a linking book in Myst.
<RhodiumToad>68k was so nice
*RhodiumToad did quite a lot of 68k assembler
<paines>hi
<paines>So I compiled guile-opengl with guile-3.0.1 from Ubuntu, and it cannot find the module gl, when I now try to use it . I think this is because the installation of the modules happened into /usr/local/lib/guile/3.0. Anyone can help with this ?
<dsmith-work>paines: Well, as usual with mysterious file finding issues, try to run it under "strace -ffile" to see what it's looking for and where it's looking.
<dsmith-work>s/-ffile/-efile/
<dsmith-work>paines: And compare that to where you think it should be looking.
<paines>dsmith-work, good idea. it acutally seems to look everywhere except /usr/local/
<dsmith-work>So. You installed guile via a package, and guile-opengl from source?
<paines>exactly
<dsmith-work>I'm thinking you could add the /usr/local locations to your load-path, or reconfigure/compile the guile-opengl with something like --prefix=/usr (not familiar with that)
<paines>i think this can be remedied with GUILE_LOAD_PATH
<paines>or yeah
<paines>recompile and add the correct prefix
<paines>yeah. with --prefix it works directly. no hazzle. thanks man!
<cyclopsian>does anyone know if there is a languageserver client for guile, or some other way to get completions and linting in my text editor?
<cyclopsian>if not, I may write one soon
<dsmith-work>cyclopsian: Geiser
<dsmith-work>Well, assuming your editor is emacs
<dsmith-work>cyclopsian: https://www.nongnu.org/geiser/
<cyclopsian>it may finally be time for me to switch to emacs from vim
<cyclopsian>:)
<dsmith-work>cyclopsian: There is also the great evil of using vi key bindings in emacs, if you want.
<dsmith-work> https://www.emacswiki.org/emacs/Evil
<roelj>I have an autotools-based project, and I'd like to add the guile modules to GUILE_LOAD_PATH. I created a config file to write the installation path of the guile modules, but those are written as "NONE/share/guile/site/3.0" and "${exec_prefix}/lib/guile/3.0/site-ccache", which are not the final paths. How would I gather the final destination to set GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH to?
*dsmith-work runs away and hides
<roelj>dsmith-work: Come on, this is your chance to discover the inner beauty of M4 and the unlimited possibilities of a build system!
<roelj>With GUILE_SITE_DIR I can get the paths of Guile itself, but I'm looking for the paths where my package's libraries will be installed, which isn't always the same.
<dsmith-work>roelj: Well, take a look at some random package that does the right thing.
<mwette>kernel.org/html/latest/admin-guide/mm/concepts.html
<roelj>dsmith-work: Here's the magic AC_DEFINE_DIR: https://fossies.org/linux/nano/m4/ac_define_dir.m4. This Autotools is truly brilliant :P