IRC channel logs


back to list of logs

<old>sneek: later tell lampilelo that work stealing seems to introduce more overhead on my benchmark. Without it I get 33% faster than fibers now. Maybe the benchmark scenario is not a good case?
<Aurora_v_kosmose>pipeline is such a neat function
<Aurora_v_kosmose>Is there a way to do the same as expand-file-name in Guile?
<Aurora_v_kosmose>Or rather, is there any way prebuilt into Guile 3.0. Obviously one can make their own code for it.
<daviid>Aurora_v_kosmose: canonicalize-path (?)
<Aurora_v_kosmose>Unfortunately doesn't seem like it, it chokes on (canonicalize-path "~/")
<daviid>Aurora_v_kosmose: ok, i did hear it didn't cover 'all cases', there you are - but it's sort of a faq, maybe guix has a proc to expand ~/ path, don't know
<daviid>i think lilyp has a lib to handle those as well
<spk121>a rough workaround for tilde is (canonicalize-path (getenv "HOME"))
<dsmith>What's the guile string/charset analog to tr ?
<spk121>dsmith: string-map
<dsmith>Seems to do the job
<dsmith>No tabs:
<dsmith>How to convert numbers 0-9 to chars #\0 - #\9 ?
<lilyp>daviid: I don't have ~/ unfortunately
***devmsv_ is now known as devmsv
***civodul` is now known as civodul
<spk121>dsmith: I'm sure you figured it out, but, there's (integer->char (+ x 48)) and (string-ref "0123456789" x)
<dsmith>Ahh, 48. I was using #\0 and the types were wrong. I ended up with vector-ref
<dsmith>About same as the string-ref
<dsmith-work>Thursday Greetings, Guilers
***spk121_ is now known as spk121
<spk121>For 'reasons', I'm making a guile where all the *.scm/*.go paths are relative to the location of the executable. Today I learned that argv[0] is not a great way to know where executable was launched from
<RhodiumToad>indeed, it's an arbitrary parameter
<RhodiumToad>what OS? sometimes the ELF aux vector can be of use
<spk121>Well I wanted to just be cross-platform, but, it is for a game jam, so really just Windows 11 and GNU/Linux. I did find a stackoverflow that gives better methods for Linux & Windows
<RhodiumToad>which methods?
<old>spk121: argv[0] is not even mandatory for the OS
<old>you can use /proc/self/exe on linux to know the exact binary, but not where it was launch
<RhodiumToad>if the same binary is hardlinked in several places, how reliable is that?
<old>hardlinks are the inode I think, so really as long as the original hardlink is not removed from the filesystem you're fine I think
<RhodiumToad>that's not the point
<old>s/are the inode/are the same inode
<old>You can also parse /proc/self/maps for the same information about which ELF was loaded
<RhodiumToad>suppose /foo/bin/xxx and /bar/bin/xxx are the same inode, and the caller does execl("/foo/bin/xxx"), is the program guaranteed to see the link goes to /foo/bin/xxx and not /bar/bin/xxx
<old>Hmm that's a good question. Problably the one passed to execl
<old>It's probably documented someone in the kernel
<RhodiumToad>well that's an assumption
*RhodiumToad doesn't read linux kernel
<RhodiumToad>not through lack of ability, but to preserve sanity (and avoid copyright issues)
<spk121>I'll probably go with readlink("/proc/self/exe"). For Windows GetModuleFileName().
<RhodiumToad>that's basically what LLVM does
*RhodiumToad slightly familiar with that bit of code thanks to having had to fix a bug there
<RhodiumToad>it does break if /proc is not mounted within the applicable root or namespace
<old>At some point you need to have requirement
<RhodiumToad>LLVM punts to argv[0] in such cases
<old>Since there's no direct support from the OS in the form of a syscall
<RhodiumToad>on freebsd, the most reliable way seems to be to get AT_EXECPATH from the elf aux vector
<RhodiumToad>that's what llvm does on freebsd, and that's where the bug I had to fix was :-)
<old>On linux I only see AT_EXECFN and AT_EXECFD
<old>Anyway, what is your use case spk121 ?
<old>Having relative path for Guile modules?
<spk121>old: I want the whole game to be a downloadable zip file, and I want the executable to only reference stuff in one directory tree
<old>Assets also? Like images and sounds?
<spk121>Yes, everything
<old>In theory, you could link everythin whithin the ELF file itself and extract everything at runtime. Probably overkill though
<old>Have you tried `guix-pack` for that?
<spk121>I've not tried guix-pack. I have actually thought about stuffing everything into the ELF, which sounds simple, but, is probably complicated
<old>Right. It's low level stuff and probably a huge hack around something that could be done differently.
<RhodiumToad>it's not all that complicated but there are edge cases
<old>What about game state? How do you handle that?
<RhodiumToad>I have examples of turning arbitrary files into data sections somewhere
<old>So there's that, but also having the filesystem. So you need compression and archiving into the ELF
<old>something custom for archiving can be done or something trivial like CPIO can be done
<old>for compression, standard compression algorithm are easy to implement. So really the 'hard' stuff would be to parse the ELF sections
<old>And then you need to do that on Windows, which don't use ELF I suppose?
<spk121>old: game state would probably go into what GLib computes as get_user_cache_dir()
<w0ll3q1uszxabiwo> sending in case anyone knows
<dsmith-work>RhodiumToad: Hey! welcome back
<RhodiumToad>dsmith-work: btw, (integer->char (+ x (char->integer #\0))) would do, no?
<RhodiumToad>that assumes that 0-9 are consecutive, but that's true even in EBCDIC
<dsmith-work>Yeah. Getting old.
<dsmith-work>Ugh! EBCDIC
*dsmith-work used to have a "green card". That was before the "yellow card"
<RhodiumToad>don't get me started on national variants of ebcdic
<spk121>I think I wrote the commit that removed the broken EBCDIC from Guile, back in 1.9
<RhodiumToad>like the fact that [ ] have different code points in US EBCDIC and UK EBCDIC, which makes C coding ... fun
<dsmith-work>So I've got a brain freeze. I need call a function repeatedly until it's return value is same as the argument.
<RhodiumToad>and return what? that value?
<dsmith-work>Yeah, the value
<RhodiumToad>(define (fixp f arg) (let loop ((arg arg) (rv (f arg))) (if (equal? arg rv) rv (loop rv (f rv)))))
<RhodiumToad>(fixp cos 1.0) -> 0.7390851332151607
<dsmith-work>Yeah, that's it.
<RhodiumToad>or (define (fixp f arg0) (let loop ((arg arg0)) (let ((rv (f arg))) (if (equal? arg rv) rv (loop rv)))))
***liberalartist is now known as philip1
<dsmith-work>In case anyone is interested:
<philip1>spk121: Racket has a very portable implementation for finding its executable:
<philip1>Also a portable guide to embedding arbitrary files in executable sections:
<RhodiumToad>philip1: the freebsd version is ... suboptimal
<RhodiumToad>philip1: for why, see
<RhodiumToad>(the reason why is that KERN_PROC_PATHNAME is obtained by looking up the process text vnode in the namecache, which (a) might not return anything, and (b) will return _a_ name for the executable, not necessarily the one actually used
<dalepsmith[m]>jgart: Probably not the real reason, but alists have a read syntax. Hashes do not.
<dalepsmith[m]>jgart: BTW: You
<dalepsmith[m]>s/You/Your message are not showing in libera/
*RhodiumToad did wonder about that
<dalepsmith[m]>Need to register with nicserv
<w0ll3q1uszxabiwo><w0ll3q1uszxabiwo> "" <- CC rekado you are in the contributors list of the project, could you please help me set it up for emacs? :(
<dalepsmith[m]>jgart: Specifically, the `/msg help` bit
<dalepsmith[m]>You end up talking with nickserv just like you do on libera (because you are). Need to do the INDENTIFY dance. Just like on libera
*w0ll3q1uszxabiwo recovered the source code from guix and published it on
<lilyp>Imagine obfuscating your username only to make it visible
<w0ll3q1uszxabiwo><lilyp> "Imagine obfuscating your..." <- shush princess killjoy
<lilyp>oh my, good day to you too
<dsmith-work>I see w0ll3q1uszxabiwo on libera and w0ll3q1uszxabiwo7vet7op4fhjk84wk1o71cut073qmj on matrix
<w0ll3q1uszxabiwo>more like had to change matrix bcs someone keeps joining chat with me and then leaving the room so it was either spending 3 hours leaving empty rooms so that my element doesn't eat 75% of my RAM or make a new account >_<
<w0ll3q1uszxabiwo>and i like long random usernames so that i can switch them on random and make them harder to find~
<dsmith-work>That it is
<philip1>RhodiumToad: Thanks! I think that's not a big issue because its used to read segments within the ELF file itself, but I'll mention this upstream.
<RhodiumToad>the fact that I don't think it's guaranteed to return anything at all might be an issue
<philip1>Yes, that would be :)
<RhodiumToad>you'd have to put a huge amount of pressure on the namecache for the entry to be lost, if it can be lost
<RhodiumToad>but that's the sort of thing that might be done maliciously
<RhodiumToad>(or, who knows, because the nightly security scan is running find(1) over a huge tree)
<spk121>philip1: thanks
<nckx>RhodiumToad: Bit late, but hard links don't ‘point’ anywhere. /foo/bin/xxx doesn't point anywhere like a symlink would. So yes, seeing /foo/bin/xxx is guaranteed, because that's its name. If you invoke /bar/bin/xxx, that's its name. Neither points to the other.
<nckx>That's not an implementation detail either.
<RhodiumToad>I know more about this than you can possibly imagine
<RhodiumToad>you misunderstood the original problem. given that the program was run as /foo/bin/xxx, the problem is to reliably obtain the string "/foo/bin"
<nckx>I don't think you know as much as you think you know. No need to be rude.
<nckx>(Sorry for misjudging your level of expertise, though. That's always annoying.)
<RhodiumToad>the important point here is whether a given interface returns _a_ name for the binary, or whether it is guaranteed to return the same path used by the exec
<RhodiumToad>(and what happens if something is renamed)
<nckx>But you seem to know the answer.
<nckx>Which is no.
<RhodiumToad>"no" isn't an answer to an "A or B" question
<nckx>I know.
<nckx>Doesn't change the answer.
<RhodiumToad>answer to what exactly?
<nckx>What copyright issues, anyway?
<RhodiumToad>contributing to non-GPL'ed operating systems