<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>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 ? <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 ***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 <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 <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 <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 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 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 <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? <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() <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 used to have a "green card". That was before the "yellow card" <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>(define (fixp f arg) (let loop ((arg arg) (rv (f arg))) (if (equal? arg rv) rv (loop rv (f rv))))) <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
<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. *RhodiumToad did wonder about that <dalepsmith[m]>jgart: Specifically, the `/msg @NickServ:libera.chat 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 <lilyp>Imagine obfuscating your username only to make it visible <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~ <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 <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) <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 <nckx>But you seem to know the answer. <nckx>Doesn't change the answer. <nckx>What copyright issues, anyway?