IRC channel logs
2024-05-27.log
back to list of logs
<lechner>Hi, add-to-load-path amends %load-path. Is there a similar function for %load-compiled-path, please? Due to my application, I cannot use the GUILE_LOAD_COMPILED_PATH environment variable. It's just a bunch of conses, right? <mwette>add-to-load-path is a macro for `(set! %load-path (cons elt (delete elt %load-path)))' <lechner>Hi, does Guile code have a way to find out in which file it is located, if any? <mwette>don't know; i use `find . -name '*.scm' -exec grep add-to-load-path {} \; -print' <lechner>that must be for a different purpose. i would like to load a file in a nearby location. <mwette>got it: done that in python often <old>lechner: look at primitive-load documentation. Are you looking to load dynamically at runtime or during compilation? <mwette>source-properties may work, but it will likely not give full path <lechner>old / i am using primitive-load, from C <lechner>mwette / thanks! it's okay. i have it another way <lechner>Hi, I tried to roll my own add-to-load-compiled-path https://bpa.st/WT4A but why am I getting "ice-9/psyntax.scm:2824:12: In procedure syntax-violation: Syntax error: unknown location: source expression failed to match any pattern in form add-to-load-compiled-path"? <lechner>Okay I think it's because of the way I use it in for-each. Do I need an explicit (lambda (folder) (add-to-load-compiled-path folder) instead of just add-to-load-compiled-path? Why is this a macro and not a function, please? <lechner>so i can't do (for-each add-to-load-path folders) <mwette>because add-to-load-path is a macro; foreach wants a procedure <lechner>mwette / thanks, i get that. why is it not a procedure? <mwette>Oh, so it works at compile time, i think. <mwette>And your for-each should probably be changed to a macro, too. <mwette>If you want the path update to apply at compile time. <lechner>i don't think i understand the "compile time" thing. I am loading a file that contains the path <lechner>is anything "run" at "compile time"? <lechner>the purpose would be to save time during execution? <lechner>that advantage would only apply if I were to add a string constant, right? <mwette>this: (add-to-load-path "/a/b/c") (use-modules (foo)) <lechner>that seems like a minor use case, but okay <lechner>Hi, is it expected that when "loading" from a relative path in code that was "loaded" itself, the path is relative to the code rather than the current working directory? <old>lechner: could you show us an example of what you are trying to achieve? Is it in C or Scheme? Do you want to include file into another at compile time like #include or you want to load file? <old>for your last question, I could not say. I believe it is always relative to the current working directory <lechner>it really isn't. i will show you once i figure out how <lechner>i rewrote Linux-PAM in Guile and "load" anonymous lambdas, which again "load" anonymous lambdas. it's probably odd use from your perspective but i spend two years with module reflection and entry points where there are none <lechner>old / please create a file with these contents (lambda (name) (load name)) <lechner>then in Geiser do, (define func (load "/path/to/reproducer.scm")) <lechner>reproducer.scm should be located in a folder other than your current working directory <lechner>then call (func "path/relative/to/cwd/reproducer.scm") <lechner>you will get "file not found". the path in the error will show why <mwette>path is relative to something in the load-path <lechner>mwette / is it relative to the wrong thing, though? <lechner>also, i might have missed messages due to a power outage. is there a channel log? <lechner>yeah, i'm trying but my browser starts slowly <lechner>mwette / does your code reference relate to my "load" issue? <mwette>Sorry: maybe I misinterpreted. I thought you were trying to find full path from relative path embedded in code. You can get relative path from compiled procedures, but to get the full path you need to prepend element from the %load-path. <lechner>mwette / thank you! your code was helpful in other ways, but my concern here is that "load" interprets relative paths incorrectly <mwette>oops sorry, wrong; include-from-path I think. <lechner>yeah, the issue isn't finding the file. the issue is that a nested load looks in the wrong place <lechner>you can see the mangled path with the reproducer above <graywolf>Do you think it would be feasable to change %default-port-conversion-strategy? I realize it would technically be backward-incompatible behavior, but I wonder if anyone actually relies on the current value. <lechner>graywolf / this is encoding related right? <graywolf>lechner: Yes. Current default is 'substitute, which silently corrupts data by replacing it with `?' unless encoding is utf8. <graywolf>I think 'error would be better default, so I wonder if it could be changed... <graywolf>Yes :) And on core-updates the fix should even be as simple as setting LANG=C.utf8 as default env var for derivation builders. However in the process I found '(guile)Encoding'. <rlb>graywolf: ...is that an ascii question mark, or U+FFFD? <lechner>graywolf / why isn't "the encoding utf8"? <graywolf>In the Guix bugs or how that can happen in general? <graywolf>In mumi I do not know, so in general: If LANG is set, the guile automatically calls setlocale (if not turned off by env variable). That does modify %default-port-encoding. <graywolf>In guix builder LANG is not set, so we operate in C locale and the ports are not utf8 <graywolf>Does it have LANG set and the locale files available? <lechner>that's probably why we have encoding problems all over ci <lechner>i'm not sure about mumi. i tried to setlocale the port on my fix above and that didn't work <lechner>i concluded the error was further up the chain <mwette>On another topic: ffi, it would be nice if make_cif was exposed and we could be able to execute (pointer->procedure ptr cif) => procedure. <graywolf>What does if rit on program-file is (set-port-encoding! port "UTF-8") on the port. <graywolf>I mean, if locales are available and LANG is set, everything seems to work fine (as documented) <graywolf>So outside of sandboxed artificial environments if pretty much just works afaict <graywolf>Sadly Guix is full of sandboxed environments :D <graywolf>lechner: I will believe you, I was 6 at that time so no real memories :) <lechner>Hi, is there a better way to check whether a file is group or world writable than this? (logand #o044 (string->number (number->string (stat:perms (stat filename))) 8)) <rlb>There's access?, but there are the suid/sgid caveats mentioned, and it doesn't discriminate user/group/other. <lechner>what is returned by stat:perms, please? <rlb>Perhaps the permission bits from the mode. <lechner>okay, i got it now. it is a straight octal value was confused because 644 in octal is 420 is decimal