IRC channel logs

2025-11-26.log

back to list of logs

<old>AFAIK, golang revert from that
<old>bootstrapping what exactly?
<old>glibc do so many things it's basically ABI on Linux
<tohoyn>sneek: botsnack
<sneek>tohoyn, you have 1 message!
<sneek>tohoyn, daviid says: I 'll patch scm->gi-array and gi-array->scm so they work fine with array of GVaraint myself, tx - I will kepp GBDus struct semi-opaque though, so you can write your own api to build those you need (and any other user)
<sneek>:)
<sneek>wb tohoyn :)
<janneke>so, how do quasipatterns work in match? i find the docs to describe the syntax, but not the semantics?
<janneke>scheme@(guile-user)> ,m (ice-9 match)
<janneke>scheme@(ice-9 match)> (match '(key value) (('key v) v))
<janneke>$1 = value
<janneke>scheme@(ice-9 match)> (define dynamic-key 'key)
<janneke>scheme@(ice-9 match)> (match '(key value) ((`,dynamic-key v) v))
<janneke>$2 = value ;; yay!
<janneke>scheme@(ice-9 match)> (match '(foo value) ((`,dynamic-key v) v))
<janneke>$3 = value ;; Argh, no; should not match!
<janneke>ideas?
<civodul>janneke: i think it doesn’t work the way you think
<civodul>that is, (match '(foo value) (`(foo ,v) v)) does what you expect
<civodul>to match on a variable, AFAIK you have to resort to a predicate
<civodul>like ((? (lambda (x) (eq? x dynamic-key))) value)
<ieure>I was looking at this the other day, and I agree with civodul, there doesn't appear to be an elegant way to match a specific value like that.
<ieure>"elegant" meaning "syntax less verbose than a lambda predicate"
<mwette>match redefines the meaning of quasiquote and unquote
<mwette>in patterns
<ekaitz>we need to improve the documentation for that
<dsmith>sneek, botsnack
<sneek>:)
<dsmith>!uptime
<sneek>I've been a process for one month and 17 days
<sneek>This system has been up 6 weeks, 5 days, 18 hours, 56 minutes
<janneke>civodul: ouch, and thanks :)
<rlb>civodul: is "make -j5 distcheck" supposed to work from a clean configured tree? Here it crashes, I think (given the interleaved output) trying to build auto-conf-macros.texi with "/usr/bin/guild: 3: exec: /home/rlb/src/guile/up/main/libguile/guile: not found
<rlb>"
<rlb>I wondered if this might just be an existing issue, i.e. no one ever tries a parallel distcheck from scratch.
<rlb>At least it's easy to reproduce...
<rlb>Even a serial "make distcheck" after a successful "make -j5 check" fails like this with main:
<rlb>echo 3.0.10.284-35288 > ../../.version-t && mv ../../.version-t ../../.version
<rlb>/bin/bash: line 1: ../../.version-t: Permission denied
<rlb>Somehow the entire guile-3.... tree that I think distcheck was trying to build was read-only. I'm guessing there's some -j related race in a "from scratch" parallel distcheck. I'll try again with *everything* serialized.
<dsmith>rlb, Could it have been trying to write to a system dir, Like /use/local/... ?
<dsmith>As in a missing $DEST
<rlb>No, that was from within SRCDIR/guile-VERSION-GITINFO/build or something, and guile-VERSION... was read only.
<rlb>I'm guessing that some step makes it read only once it's "ready", but some other step that should have gone first is running in parallel.
<rlb>That dir might also have been left over from my initial from scratch "make -j5 distcheck" run -- either way, suspect there's a -j related bug.
<rlb>(distcheck bug)
<rlb>If anyone has time, might be nice to have a double-check, though of course if it's a race, then might or might not be easily reproducible "elsewhere".
<rlb>I also suspect that this might not be new, and so might not need to hold up the release.
<dsmith>yep! In maint.mk in release-prep: is `chmod a-w $(rel-files);`
<dsmith>perl !!
<rlb>Not sure whether it's changed, but for "forever" perl's been one of the few (only) "languages" you're allowed to rely on being available in debian package maintscripts (prerm/postrm/preinst/postinst/etc.). i.e. unless it's changed and I didn't notice, you can't use python etc. Typically just use perl, (ba)sh, coreutils...
<ieure>Yeah, perl is in Debian's base package set, I think mostly because a bunch of the early Debian tooling was written in it.
<ieure>I think some still is, but maybe less than used to be the case.
<rlb>...I'm probably going to be refreshing my perl in a while because the debian emacs infrastructure needs an overhaul. Things I didn't get right the first time (a good while back).
<rlb>Yeah, "make distcheck", run after a successful build just crashes on that .version-t write every time.
<rlb>I wonder if this is a SRCDIR/BUILDIR issue or something similar.
<rlb>Also strange, right after that failure, and "rgrep -F .version-t" in our source tree finds nothing.
<dsmith>That chmod a-w was last touched in 2012. I wonder how long it's been since a make distcheck
<rlb>Dunno -- if we use that to produce the release archives, then "fairly recently"?
<rlb>fsvo "fairly"
<rlb>ACTION wonders if build-aux/git-version-gen really should/needs-to have the unsafe time-stamp LocalVariables...
<rlb>Yeah, looks like it's probably a src vs build dir issue -- but what's trying to write that file...
<rlb>OK, I think it's the "$(top_srcdir)/.version: Makefile
<rlb>" rule at the end of ./Makefile.am.
<rlb>Perhaps it needs $(distdir)(s).
<dsmith>Why the echo > file-t && mv file-t file dance ?
<rlb>Partial writes?
<rlb>I'm testing this now:
<rlb>cd $(distdir) && echo $(VERSION) > $@-t && mv $@-t $@
<rlb>Though I don't know if that's actually the right thing.
<dsmith>$@ is $(top_srcdir)/.version at that time, no?
<rlb>Oh, wait, that won't be if distdir is the actual ./guile-VERSION dir because it's *supposed* to be read only.
<rlb>I wonder if it was already broken or I broke it in 6bd70136d96e73542e6725bc490199e17f56ee92
<rlb>If anyone else here is better with auto*, by all means, take a look wrt what we ought to be doing there, otherwise I'll try to delve later.