IRC channel logs

<apteryx>janneke: it's never perfect unfortunately. at everjanneke: that's probably infinite loop you have in the srfi I had support for, there was small adjustments needed

<apteryx>hm, that came out confused

<apteryx>probably some loop in the parser (I had this problem sometimes too -- probably a small adjustment to make but could be a bit painful to find)

<rlb>bjoli: overhead may be acceptable, but since pcre only handles utf-8/16/32 (not latin-1), we'd have to do some work for any non-ascii subset latin-1 strings. (Had do deal with that in lokke, which currently specifies pcre syntax for its native regexes -- though I may reasses.) Of course if we switch to utf-8, that goes away.

<shawnw>pcre can work with latin-1 (At least in its native C)

<shawnw>The key is pcre2_maketables()

<rlb>...*really*. I'll have to look in to that. Thanks.

<cpli>janneke: your implementation of conjoin returns #t from (null? args) such that ((conjoin integer? values) 1) => #t instead of (and (integer? 1) (values 1)) => 1

<flatwhatson>it's a bug with the reference implementation, not janneke's fault exactly :)

<janneke>cpli: i found the reference implentation impenetrable, i've been using

<janneke>(use-modules (srfi srfi-1) (srfi srfi-26))

<janneke>(define (conjoin . predicates)

<janneke> (lambda arguments

<janneke> (every (cut apply <> arguments) predicates)))

<janneke>and was tempted to replace it

<janneke>i think you just convinced me

<shawnw>I've found quite a few bugs in reference implementations of SRFIs when porting them to Racket. Tried to report them when I remembered, but I think 235 is one I wrote from scratch.

<janneke>terrible

<shawnw>(mine returns 1 in cpli's example. I feel gratified.)

<cpli>janneke: if you want to stay tail recursive, here's an edited version of the "reference" that just works: https://paste.sr.ht/~cpli/139243f31bebc54d3ed9ef38d925528de1977f14

<cpli>i have to say though: it looks HORRENDEOUS

<cpli> wait, we can just paste code in here?

<janneke>well, if it's a handful of lines

<haugh>also note The "disjoin" test group in the SRFI-235 implementation expects ((disjoin identity)) to return #t, but this behavior is not specified by the SRFI.

<cpli>haugh: shouldn't it mirror (or)? i.e. #t???

<haugh>What version of guile are you running where (or) returns #t

<cpli>oh

<haugh>I mean I agree with your sentiment haha

<cpli>uhh s/\?.*/\?/ ...

<haugh>Intuitively yes. I have a TODO to seek clarification on that from the SRFI group but frankly those folks intimidate me

<cpli>chicken is funny about it

<cpli>(define (conjoin . preds)

<cpli> (lambda (x)

<cpli> (let loop ((preds preds))

<cpli> (or (null? preds)

<cpli> (and ((##sys#slot preds 0) x)

<cpli> (loop (##sys#slot preds 1)) ) ) ) ) )

<cpli>and i can't even find (srfi :235) as a separate egg

<cpli>even though the srfi document acknowledges: Thanks to Kon Lovett, author of the Chicken egg (who credits Graham Fawcett and Philip L. Bewig)

<haugh>Chicken was my first lisp! I appreciate how much convenience they've merged into chicken.base but don't like that implementation. To me the two-dimensional concept of mapping a logical operator across lists of procs and args is essential

<haugh>janneke, please note that your implementation applies each proc to all args, where the standard specifies (and ref. implements) each proc to each arg

<haugh>compare to {all,any,each}-of

<janneke>haugh: ow crap, the standard defines another variant of my conjoin -- how terrible :(

<janneke>guess i'll have to keep cargo-culting my conjoin after all, then

<cpli>janneke you want (define (conjoin . predicates) (lambda arguments (every (lambda (arg) (every (cut <> arg) predicates)) arguments)))

<cpli>really, this one is perfect.. tail call and everything

<cpli>(define nullable-pointer->not-null-string

<cpli> (compose (conjoin (compose not string-null?) values)

<cpli> (conjoin (compose not null-pointer?) pointer->string)))

<cpli>beautiful.

<wingo>pushed patch by rlb to enable parallel test driver for unit tests

<wingo>humm, weird errors updating gnulib

<janneke>cpli: i'm having a look

<janneke>cpli: tbh, the difference between the two variants elude me, do you have a simple test case that shows how they differ?

<janneke>your version seems to work for me, so the difference is in an aspect that i don't use, apparently

<janneke>ACTION goes to run a full test suite

<cpli>janneke: ((conjoin (compose number->string car)) '(1) '(2)) raises: "wrong number of arguments to car"

<cpli>even though it should => "2"

<wingo>is anyone a master of gnulib? for me when I make a fresh guile checkout, then "guix shell -D guile automake autoconf libtool gettext -- autoreconf -vif" it does correctly bootstrap.

<Arsen>wouldn't call myself a master but i frequently work with it.. bhaible is on IRC too should it go that way

<Arsen>but, if it correctly bootstraps, what's the issue

<wingo>but then if i first "rm gnulib-local/m4/clock_gettime.m4.diff" (because it does not apply) then "guix shell python -- ~/src/gnulib/gnulib-tool --update", then try to bootstrap again, I get errors

<wingo>humm, i had though the clock_gettime patch was applied, but it seems i just need to adapt it instead. probably not the issue but I will see what I can do

<wingo>anyway failing to bootstrap is the issue :)

<Arsen>one sec, gonna try to repro

<Arsen>is this the state on trunk?

<wingo>yes

<wingo>ACTION trying to update gnulib before release

<Arsen>gonna pull.. haven't pulled since sending that patch from the other day ;P

<Arsen>huh, was that patch you sent never applied?

<wingo>Arsen: it seems it was never applied. but maybe it doesn't matter, surely something has changed in 13 years ;)

<Arsen>hm, autogen is struggling to bootstrap it too (I suspected that some of these files get downgraded, this happened with poke for instance: https://sourceware.org/bugzilla/show_bug.cgi?id=30051 )

<Arsen>you're seeing the threadlib error right?

<wingo>Arsen: yes. i tried explicitly adding it and that didn't change anything

<Arsen>that's because autopoint steps over it

<Arsen>autoreconf-2.72: running: autopoint --force

<Arsen>...

<Arsen>Copying file m4/threadlib.m4

<Arsen>grr..

<Arsen>gonna replace autogen with the gnulib autogen stuff

<wingo>annoying :)

<wingo>i admit i don't even know what autopoint is

<Arsen>autopoint - copies standard gettext infrastructure

<Arsen>so, the gettext stuff

<Arsen>gettext and gnulib are both maintained by bruno, so they overlap a bit..

<Arsen>./autogen.sh: done. Now you can run './configure'.

<Arsen>~/gnu/guile$

<Arsen>the simplest workaround is likely to make autogen run gnulib-tool --update after autopoint

<Arsen>... and --add-import'ing threadlib I guess

<Arsen>this has ton of warnings right now, though; lemme see if I can get rid of them

<Arsen>adding the gettext module removed some

<Arsen> https://paste.sr.ht/~arsen/775b9c30e1002f3b6fbc9c1a8e3733ac597ab8c3 these remain

<Arsen>these are automake warnings completely it'd seem to me

<Arsen> https://paste.sr.ht/~arsen/fe3a49653cf1a0283d2e1f9eabc380718932a16d here's the full thing I think

<Arsen>there's a bunch of generated files I didn't check..

<Arsen>it'd be nice to convert this to the 'modern' (uncertain of the modernity, I only started using gnulib a few years ago) gnulib approach of being a submodule and using its bootstrapping stuff (incl. bootstrap.conf)

<Arsen>the patch has a highly mechanicalized version of that - the bootstrap.conf gnulib_modules were just from lib/Makefile am, as are the extra opts (the rest is the default stuff from the template bootstrap.conf from GL/build-aux/bootstrap.conf)

<Arsen>oh, and no submodule ofc

<Arsen>the only differences to the base are that I added gettext and threadlib modules, and yeeted the gnulib-local diffs

<janneke>cpli: ah, thanks. wondering about the "should", though.

<janneke>i think i like this better:

<janneke>(map (conjoin (compose number->string +)) '(1 2) '(10 20))

<janneke>$2 = ("11" "22")

<janneke>than this

<janneke>(map (conjoin (compose number->string +)) '(1 2) '(10 20))

<janneke>$1 = ("10" "20")

<Arsen>wingo: I've prepared a far smaller patch if you just want to get the release out (but I recommend doing the procedure above sooner or later anyway): https://paste.sr.ht/~arsen/8721ddaa2f2f6856a1276bb9a50ce9a56fc174a8

<Arsen>build testing ti right now

<Arsen>../../libguile/jit.c:373:30: error: macro "unreachable" passed 1 arguments, but takes just 0

<Arsen> 373 | unreachable (scm_jit_state *j)

<Arsen>uhoh

<Arsen>ah, unreachable is a C23 macro.. and a function in guile.. very fun

<Arsen>ok, fixed that.. building now it'd seem.. BOOTSTRAP(stage0) GUILEC ice-9/psyntax-pp.go

<sneek>dsmith: Greetings :D

<dsmith>sneek, botsnack

<sneek>:)

<Arsen>wingo: can confirm buildability with the above

<Arsen>(well, after renaming undefined())

<wingo>Arsen: thank you!!!!!

<Arsen>no problem :-)

<Arsen>happy to help

<wingo>much appreciated

<Arsen>may I ask that you update to bootstrap stuff after the release?

<Arsen>it might clean up the generated files in VCS and make it easier to tell which gnulib is in use

<Arsen>plus autopull and autogen gnulib provides are nice

<wingo>i think submodules are probably a hard sell but let's talk about it :)

<Arsen>well, the submodule is used to have an in-vcs reference to the gnulib development is using, the files are still pulled out of it for the actual distribution

<Arsen>(the way they are now)

<wingo>understood

<wingo>right so right now gnulib is not a development-time dependency of guile. i would have to talk with civodul to see what he things

<wingo>*thinks

<wingo>surely there is a bug in gnulib tho, right?

<Arsen>poke is a point of reference for how a project doing that looks btw, should it be needed

<Arsen>there's likely at least one, perhaps multiple, bugs in gnulib ;)

<Arsen>no sure which one you're referring to

<wingo>i.e. afaiu it will no longer be possible to autoreconf a distributed guile tarball

<Arsen>indeed, that's due to a conflict between gettext and gnulib - they provide some shared build system files

<wingo>something in gnulib is causing these missing gl_PTHREADLIB etc references

<Arsen>usually, installed gettext is behind gnulib, so that breaks when autopoint runs..

<Arsen>I'm not sure bruno et al consider that a bug

<wingo>hmm

<Arsen>but, that's why the autogen.sh script exists - it runs gnulib-tool at the right time not to break stuff

<Arsen>unsure if it works on a dist tarball - haven't tried lately

<wingo>you can understand my reluctance to add more build tools :) one of the nice things about "vendoring" gnulib is that i know what users build against

<wingo>whereas if everyone is gnulib-tool --update'ing all the time, who knows

<Arsen>that's why the submodule reference is useful - all poke hackers running commit $X run the same version of gnulib, and can even re-vendor gnulib on command

<wingo>ACTION much more of a "subtree merge" person than a git submodule person

<Arsen>hm, that would work, but I'm not sure it's nicer here

<wingo>well, it avoids the extra steps on git checkout

<Arsen>I like to think of submodules as simple references to another git tree

<Arsen>that is true, but autopull handles it

<wingo>autopull??

<Arsen> https://git.savannah.gnu.org/cgit/gnulib.git/tree/top/bootstrap-funclib.sh#n625 - basically just 'get me gnulib dammit'

<Arsen>it does become obsolete if a subtree merge is used

<wingo>i would not mind switching to a subtree merge of gnulib. i must have something irrational about submodules tho, i have used them in the past but never been quite happy with it

<wingo>but, what would be easiest in a near term would be to fix gnulib so that it does not need to run during bootstrap

<wingo>it did not need to run before, and i don't yet see why it should run now

<Arsen>it doesn't really, if autopoint doesn't, probably

<wingo>(apologies for being a curmudgeon, it does seem to be my default mode these days)

<Arsen>no worries - you're not being difficult, really (either that, or my meter is way off ;-) )

<wingo>so for people that run gnulib-tool during bootstrap: is the idea that you install gnulib?

<wingo>or do you have it uninstalled in some sibling directory or something

<Arsen>I'm not sure you can install it

<Arsen>I just set GNULIB_SRCDIR=${HOME}/gnu/gnulib while hacking at it

<wingo>but if you have a submodule / subtree then you would bootstrap from the subtree?

<Arsen>yes (but the hacky patch above I did doesn't - it lacks the logic for that)

<wingo>i think a gnulib update will probably slip this release but i have work time to poke guile these days and will be following up on this

<Arsen>sure thing - will try to be around to help

<wingo>many thanks for your patches & patience!

<Arsen>no worries :-)

<rlb>wingo: thanks much, and can confirm that the tests don't appear to deadlock in fork here anymore.

<lechner>Hi, how may I check if a variable is defined, please? Do I have to catch an exception?

<daviid>lechner: see 6.18.7 Variables in the ref man

<lechner>daviid / thank you! I have been reading there but i do not see a boolean predicate 'defined?' or similar there https://www.gnu.org/software/guile/manual/html_node/Variables.html

<daviid>variable? and variable-bound?

<daviid>you need to check if the obj is a variable, then if it is bound ...

<lechner>at least in geiser, i get an "Unbound variable:" exception

<lechner>for (variable? something-undefined) that is

<lechner>although it should arguably say "Undefined variable"

<daviid>6.10.4 Querying variable bindings - defined?

<lechner>same thing

<daviid>lechner: do you pass a symbol?

<lechner>daviid / okay, i didn't. thanks!

<daviid> (defined? 'blue)

<daviid>$13 = #f

<daviid>scheme@(guile-user)> (define blue 'blue)