IRC channel logs

2022-09-14.log

back to list of logs

<sneek>Welcome back chrislck :D
<chrislck>sneek: botsnack
<sneek>:)
***Furor is now known as Colere
***Furor is now known as Colere
***rgherdt_ is now known as rgherdt
<flatwhatson>is anyone familiar with the guts of (system vm frame)? i have a strange scenario where backtrace printing fails with "frame-local-ref: Argument 2 out of range: 1"
<flatwhatson>the culprit frame has 9 bindings, but only 1 local according to frame-num-locals
<flatwhatson>so binding-slot refers to a local index which doesn't exist, leading to the above error
<flatwhatson>the frame in question got blown up due to a "Wrong type to apply" error
<flatwhatson>it actually looks like the bindings are wrong, they're identical to the parent frame, which has all locals as expected
<ArneBab>lilyp: did they investigate how efficient bash is at shelling out to subshell? I actually did: we’re talking about 2-3ms. See sell-deferring near the end of subsection https://www.draketo.de/proj/py2guile/#sec-2-2-3-2-1
<ArneBab>dsmith-work: my experience is that systemd devs tick off boxes. Tell them "in this concrete area you’re bad" and they make something there and stick it to their broken structure (making it worse in the process) so they have that box ticked. Just to not have to accept that 90% of their code is not just unnecessary but a dangerous liability no one should allow in their system, least of all in the most privileged position outside the kernel.
***mfiano_ is now known as mfiano
***maximed is now known as antipode
<mwette>flatwhatson: boxed locals don't show up in frame bindings, IIRC
<mwette>(boxed locals being variables subject to set!)
<antipode>On frame-local-ref: maybe relevant: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39954 and https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50153
<mwette> and you get better debug info if you compile the file with -O0 (or others have said -O1)
<mwette> https://github.com/mwette/guile-jtd has a procedure to provide debug command ,frame-bindings
<flatwhatson>the problem seems to be that both frames have the same instruction-pointer, so end up with the same result from frame-bindings/available-bindings
<flatwhatson>i don't think this is related to the bugs listed above, i'm not seeing segfaults, it's just trying to access frame slots which don't exist, which errors out of printing the backtrace
<flatwhatson>my problem really is that this frame was the one where the original error occurred, which is a legitimate error, but it wasn't getting printed due this bindings vs locals mismatch error
<alextee[m]>im trying to bundle libguile in a custom prefix, what else do I need besides the libguile so?
<alextee[m]>I'm currently getting a backtrace like this when i attempt to run a script via C: https://paste.debian.net/1253865/
<alextee[m]>also the prefix i used when installing guile was /usr/local but my bundle is in another prefix under /opt, do i need to pass some kind of env variable for guile to find its resources?
<blake2b>alextee[m]: did you do: pkg-config guile-3.0 --cflags
<blake2b>also pkg-config guile-3.0 --libs
<alextee[m]>yes i used meson to link to it which does that
<alextee[m]>i copied the guile directory under "share" now but it looks like guile can't find it, probably looks at the prefix it was installed in
<alextee[m]>GUILE_LOAD_PATH!
<blake2b>yes thats what i was about to say
<blake2b>also: GUILE_LOAD_COMPILED_PATH
<blake2b>here is my GUILE_LOAD/COMPILED_PATHs if that helps: https://paste.debian.net/1253867/
<alextee[m]>i'm getting a b unch of "no such language scheme"
<blake2b>(its guix tho, so everything is in .guix-home/ instead of /usr/local)
<blake2b>I'm not familiar with that error, and have only basic experience with libguile, but it sounds like you don't have the guile repository in your load path
<blake2b>guile supports several languages, so in the guile repository there is /module/language/scheme but also ecmascript, elisp and few others
<blake2b>*this is assuming you built guile from source
<alextee[m]>i built guile 3 from source
<alextee[m]>hmm where is this repository installed?
<alextee[m]>i'll try GUILE_LOAD_COMPILED_PATH too now
<blake2b>on guix, guile installs to two locations and their children in .guix-profile: lib/guile/3.0, share/guile/site/3.0; should be the same in the /usr/local
*alextee[m] tests now
<alextee[m]>yeah those are the only 2 things i could find, apparently it failed when just using the stuff in shared, i guess it needs the compiled stuff too
<blake2b>I see this is for zrythm? I've been meaning to dig in ever since I heard about guile support, my background is actually in audio-visual installtion, but I havent got around to it yet
<alextee[m]>yeah
<alextee[m]>im trying to make a universal installer that works on all distros
<alextee[m]>except weird ones like guix and nixos
<blake2b>sweet
<blake2b>I used to be a Max/MSP power user, Max4Live capabilities with Guile sounds amazing. i'll hopefully join in soon and can help out with the guile bits
<alextee[m]>nice, there's no users of the guile API yet so i'm not really sure what should be exposed or what it should look like, but i can expose pretty much any internal C function
<alextee[m]>setting GUILE_LOAD_COMPILED_PATH and GUILE_AUTO_COMPILE=0 fixed the issue
<alextee[m]>for some reason auto-compilation is broken
<alextee[m]>but i don't need it
<gabber>dthompson: is chickadee broken on guix? i have the following, minimalist setup: https://termbin.com/h63v but this raises a "no code for module (chickadee cli)"
***maximed is now known as antipode
<sneek>chrislck: wb!!
<chrislck>sneek: botsnack
<sneek>:)
<dthompson>gabber: looks like you need to add guile to your manifest. without it, GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH will not be setup properly to find the chickadee modules.
<unmatched-paren>gabber: if you've ``guix install''ed it, you need to relogin
<unmatched-paren>or use it inside a new login shell
<unmatched-paren>or source the profile
<unmatched-paren>if you've ``guix shell''ed it, add ``guile'' to the command
<sneek>Welcome back chrislck :D
<lilyp>ArneBab: I'm not taking either side here – we all know shepherd is the best init system after all – but back when they formulated this particular complaint systemd had significantly faster startups
<gabber>dthompson, unmatched-paren : thanks! it works just fine :)
<dthompson>gabber: glad that worked!
<dthompson>have fun!
<gabber>thanks!
<ArneBab>lilyp: did you check their claim about faster startup (compared to OpenRC, not compared to sysvinit)?
<spk121>FWIW, a couple of my machines use systemd, and they boot. Not a huge fan of what the did to core files and to logging: I can see why it is "better" but it solved problems I don't need solved
<lilyp>ArneBab: Even if I did, that would have been years ago and in no way reflect the current state of affairs
<lilyp>I hardly doubt that there's a fair init system benchmark
<ArneBab>lilyp: OpenRC had one for the starttime (which also showed why that was a bullshit metric to begin with): under 0.7 seconds — in the extreme case down to 250ms for a full startup-powerdown cycle: http://gentooexperimental.org/~patrick/weblog/archives/2013-10.html#e2013-10-09T09_33_21.txt
<ArneBab>lilyp: what they did that had the biggest impact (instead of writing a huge alternate init system): noticing that killprocs does "sleep 1" two times to support ancient hardware.
<ArneBab>lilyp: fun part: IIRC systemd later touted as a feature that they added those 2 seconds — to support ancient hardware which others had already supported for ages (which the systemd folks did not understand).
<ArneBab>I’m really happy that in Guix we have Shepherd instead.