IRC channel logs

2024-10-08.log

back to list of logs

<rlb>...I haven't been following, but offhand, wrt the compilation messages, is guile unusual in printing all that by default? i.e. I thought some subset of python, perl, emacs, and/or ruby might do something similar without the noise -- though maybe they don't cache per-user (well I think emacs native compilation does now).
<rlb>I also vaguely wondered about typical "log levels" and putting those messages at debug, but decided not to open that can of worms atm :)
<dsmith>I think most compilers (well, unixy ones) are silent except for warnings and errors.
<dsmith>Unless some verbose option is selected
<old>dsmith: see https://www.linfo.org/rule_of_silence.html
<dsmith>old, Yep.
<dsmith>I was working with an IBM backup system (Tivoli Storage Manager), and you could write SQL queries, like which tape a certain file was on, and it would *ALWAYS* spit out a copyright notice first thing.
<dsmith>Very annoying for scripting things.
<dsmith>Every command had to piped through tail or something to strip it out.
<rlb>nice
<mange>What's the simplest way to run a program with stdin from a string, and capturing stdout to a string? I'm looking at spawn, and I've got something working, but it seems pretty involved... I'm wondering if there's something more straightforward that I'm missing?
<dsmith>mange, Probably pipeline: https://www.gnu.org/software/guile/manual/html_node/Pipes.html#index-pipeline
<dsmith>mange, Something like: https://bpa.st/3JYTA
<mange>Right, okay. That is much cleaner than what I got to with spawn. Thanks! :) I assume I'd also have to use waitpid (maybe with WNOHANG) to know when the process is finished, too?
<dsmith>Depends on the command I think. That example closes the command's stdin, so it gets EOF. Then reads one line. You could instead read all the output until EOF.
<dsmith>If the output will be more than a pipebuf (64K by default on Linux I think) the the command will block until that's been read.
<mange>My input will definitely be <256 characters, and I expect my output to be <100, so that should be fine.
<old>Is is possible to help git-diff to understand better my code? I have the following shebang at the top of my script: https://paste.sr.ht/~old/255bc0a946cb84a88a4f0a3bb0ec1333614ec668
<old>and whenever I modify the script and check the diff, I have something like: @@ -355,9 +355,9 @@ exec guile --no-auto-compile -e main -s "$0" "$@"
<old>even though the modification is done in a procedure. Looks like git gets the wrong context here in a way
<Arsen>yes you can - one moment
<Arsen>ugh.. cgit is down
<Arsen>here's an elisp example:
<Arsen>git_config diff.elisp.xfuncname \
<Arsen> '^\([^[:space:]]*def[^[:space:]]+[[:space:]]+([^()[:space:]]+)'
<Arsen>run that for your repo, and...
<Arsen>*.el diff=elisp
<Arsen>put that in .gitattributes
<Arsen>obviously adjust for scheme syntax
<Arsen> https://git.savannah.gnu.org/gitweb/?p=emacs.git;a=blob;f=.gitattributes;h=38cc45f3ee34fe4269c3dd648bc518741ed676fc;hb=HEAD#l88
<Arsen> https://git.savannah.gnu.org/gitweb/?p=emacs.git;a=blob;f=autogen.sh;h=f56966ae0d1fe8f6a4bb38d12b2549cf6e3fb011;hb=HEAD#l356