IRC channel logs


back to list of logs

<lechner>lampilelo: thanks!
***Server sets mode: +ntz
***Server sets mode: +ntz
<chrislck>sneek: botsnack
***Server sets mode: +ntz
***Server sets mode: +ntz
***roptat is now known as Guest8848
<ulfvonbelow>(file-port? (car (pipe))) => #t
<ulfvonbelow>is `file-port?' supposed to indicate whether a port is related to a file, or whether it's related to a file descriptor?
<dcottingham>Pretty sure file-port? is about whether it's a file. Also pretty sure all ports have associated file descriptors. But maybe it's time for an experiment.
<dcottingham>Nope. New theory: not all ports have associated file descriptors, and file-port? is about whether it has a file descriptor.
<fcw>Question: Why is SIGINT and SIGQUIT ignored in (system* "bash" "-c" "trap") but not in (system "bash -c trap") ?
<jpoiret>fcw: maybe because system uses bash under the hood to launch the command, while system* does not?
<fcw>jpoiret: I suspect that it is caused by these lines but I don't understand the reason for ignoring these two signals.
<jpoiret>apparently, that's because you may want Ctrl+C on the foreground process to only reach the child, so that the parent can handle the failure of the command
<fcw>Oh well, looks like I'll have to use `system` instead of `system*` then.
<fcw>jpoiret: By the way, I encountered this "problem" in Guix. Mailing list thread:
<jpoiret>right, i saw that. I wonder how the executable could inherit those though
<fcw>I was wondering the same, but I have not found the cause.
<sneek>wb chrislck :)
<dsmith-work>Tuesday Greetings, Guilers
<nckx>jpoiret: Processes always inherit signal masks by default.
<jpoiret>yeah but from what i understand, it's the resulting binary that has the same behivour
<nckx>I thought you were talking about bash.
<nckx>I mean
<nckx>this ML stuff is just
<nckx>Is it a run/dump image/restore kind of language/compiler? That would be my guess. That it just serialises its entire $state.
<nckx>Utterly bonk.
<jpoiret>ah right, didn't think of that
<jpoiret>tex style
<lechner>Hi, are there libpam binding (as in Linux PAM) for Guile?
<lampilelo>lechner: here are two lists of guile-based projects:
<lampilelo>i doubt there are pam bindings for guile anywhere though, you can always use guile's ffi
<lechner>lampilelo: thanks!
<lampilelo>lechner: also you can (more or less) automatically generate guile bindigs for any c library using nyacc ( or or swig (
<lechner>lampilelo: thanks for those, too!
<lampilelo>nyacc generates ffi bindings written purely in scheme whereas swig will create c code to be compiled to a dynamic library you can then load as an extension
<lechner>lampilelo: yeah, i'll have a look at nyacc first
<lechner>Hi, why do I get guild: unknown script "compile-ffi" when trying ti use nyacc on Guix, please?
<lampilelo>hm, i don't remember how scripts are loaded, maybe you need to have it in the load-path? or maybe you can pass its absolute path to guild
<dsmith-work>sneek: botsnack
<mwette>if the nyacc module/ dir is in your GUILE_LOAD_PATH then "guild compile-ffi -h" should work
<sneek>mwette, you have 1 message!
<sneek>mwette, civodul says: a stop-the-world GC is indeed triggered when libguile makes an open(2) call that returns EMFILE
<mwette>"guild compile-ffi ..." will result in loading the module (scripts compile-ffi)
<lechner>mwette: thanks! that's my issue. the module is not available in /run/current-system/profile/share/guile/site/3.0/
<stis>hello guilers!
***Server sets mode: +ntz
***Server sets mode: +ntz
***Server sets mode: +ntz
***Server sets mode: +ntz