IRC channel logs

2021-03-03.log

back to list of logs

<apteryx>ah, the memory explosion when attempting to run the test suite is caused by Guile bug https://bugs.gnu.org/39251
<apteryx>the test suite of guile-lib*
<daviid>apteryx: the devel branch patches the autotool chain so md5.scm using -O0
<apteryx>OK. Altertively we could use the work around in the Guix package, which is to define redefine f-add and f-ash as (define f-add (@ (guile) +)) and (define f-ash (@ (guile) ash)), respectively.
<daviid>apteryx: well, I 'merely' reproduced the patch offered by the guile-lib debian maintainer - I need to find soemtime to merge those in master and release
<apteryx>OK. By the way, where should I send patches for guile-lib to?
<daviid>which patch?
<daviid>apteryx: anyway, guile-devel
<apteryx>some commits I've made to allow more configuration of the htmlprag tokenizer
<apteryx>commit*
<apteryx>thanks
<daviid>ah, great - could you make sure to also include the patch rekado_ wrote for guix, related to this 'more then once' reported <p> related problem?
<apteryx>it addresses it
<daviid>apteryx: i mean coordinate your work with what is in guix, and/or recently proposed by rekado_ , fnstudio ... because i don't know enough ablut htmlprag and will have to 'blindingçly' apply what is offered ...
<daviid>ah ok, perfect, tx
<apteryx>yep, I'll make sure no more local hacks remain in Guix rather than upstream
<apteryx>do you want to be cc'd when I send the patches?
<daviid>apteryx: no need tx, guile-devel is fine - did you write those patches on top of the devel branch?
<daviid>apteryx: i don't think the 3 patches i pushed would change anything, but i'd rather apply yours to devel, check 'make distcheck' and then merge to master and release asap (not before march the 6th though, i am overloaded as it is ...
<apteryx>alright, will rebase my stuff on devel
<daviid>apteryx: if what you just wrote in #guix, Unbound variable: #{\#t}# is related to guile-lib, it is fixed on the devel branch
<apteryx>OK! Cool.
<apteryx>thanks
<apteryx>great eyes keeping track of many channels btw ;-)
<daviid>np, you may tx Göran Weinhold
<apteryx>Thank you, Göran :-)
<wingo>sneek: later tell davexunit that's like racket's "prefab" structs. would be nice to support that
<sneek>Got it.
<roelj>I'd like to define 'string-replace-substring' when it's not provided by Guile. Is there a way I can test this, and define the alternative if it isn't bound? This is similar to the #ifndef bits in C.
<roelj>So, I can use ‘defined?’ and then define it with ‘primitive-eval’?
***rekado_ is now known as rekado
<rekado>roelj: can you use cond-expand here?
<rekado>I think most uses of primitive-eval are icky and have better alternatives.
<roelj>Yeah I thought there must be a better way
<roelj>So, does cond-expand only work for the predefined Guile core features?
<roelj>I now have this: https://paste.debian.net/1187609/
<roelj>But I'm not sure if that's the best way to do it either.
<rekado>do you need to check whether it’s defined at all? If you know when it was added you can cond-expand the definition only for older versions of Guile
<wingo>(unless (defined? 'foo) (define! foo ...))
<wingo>but yeah you can unconditionally provide the definition
<apteryx>rekado: early preview for a parameterizable parent-constraints in guile-lib: https://notabug.org/apteryx/guile-lib
<lloda>ok to use srfi-71 in Guile source?
<civodul>lloda: i'd say yes
<lloda>alright
<wingo>civodul: consider (let ((p (open-input-string p))) (set-port-encoding! p "invalid")) -- currently this doesn't error
<wingo>as the iconv descriptors are only loaded when characters are decoded
<wingo>which is fine to me
<wingo>er i meant:
<wingo>civodul: consider (let ((p (open-input-string ""))) (set-port-encoding! p "invalid")) -- currently this doesn't error
<wingo>anyway
<wingo>now consider (let ((p (open-input-string ""))) (set-port-encoding! p "invalid") (read-char p))
<wingo>there are no bytes available from P, thus EOF
<wingo>but, with the C code we make sure to check that the iconv descriptors can be opened, if we return EOF. for suspendable ports we fail to do this
<wingo>thinking about it, it seems to me that it would be better for C ports to adopt the suspendable-ports strategy
<wingo>wdyt?
<wingo>is a minor change but wanted to check
<lloda>on last master, is there more than one reader being used?
<lloda>e.g.
<lloda>> (call-with-input-string "#f64:3(1 2 3)" read)
<lloda>= #f64(1.0 2.0 3.0)
<lloda>vs
<lloda>> #f64:3(1 2 3)
<lloda>= #1f64@3(1.0 2.0 3.0)
<lloda>the latter is a bug
<wingo>lloda: yeah the compiler uses read-syntax and the scheme reader
<wingo>the "read" procedure is still the old one tho
<wingo>i have a patch to unify these so there is only one reader
<lloda>i see
<lloda>i'll try to fix the new one then
<wingo>hey thanks for the diligence on the reader fixes, & apologies for my bugs
<lloda>it's just self interest ;-)
<lloda>and rather it's I who should thank you for everything
<civodul>wingo: at first sight, i think not checking encoding in this case is fine
<civodul>not allocating the iconv descriptors is a win, too
<wingo>great
<civodul>thanks for asking, as always :-)
<wingo>currently i am seeing scheme reader + suspendable ports running at about 50% speed relative to C reader + C ports
<civodul>ok
<wingo>which to me sounds pretty reasonable. will improve as compiler improves of course
<civodul>what about Scheme read + C ports, which i guess is the most common case?
<civodul>(is it really something the compiler can help with?)
<wingo>last i checked, C reader with positions ran at about 15 MB/s, whereas Scheme reader runs at 10 MB/s or a little more
<wingo>with c ports
<civodul>ok
<wingo>C reader of course only uses C ports
<civodul>Scheme reader always has positions, right?
<wingo>no, you can run the scheme reader either way
<civodul>ah ok
<wingo>three ways actually
<wingo>without positions, with source-properties (i.e. `read'), and with syntax objects (read-syntax)
<civodul>ah neat
<wingo>the compiler uses read-syntax. perhaps we can retire the source properties thing in some future, but who knows
<wingo>sometimes people use them in their compilers
<civodul>yeah, source props are probably quite entrenched
<civodul>but it's good to have a way out!
<wingo>it would be sufficient to just make them used less :)
<civodul>advertising and recommending 'read-syntax' would be a first step
<civodul>BTW, are you planning for a 3.0.6 soonish?
<wingo>yeah. been working on docs, & as usual it makes me rethink code abit
<wingo>a bit
<wingo>yeah i think 3.0.6 can come whenever the reader is finished. probably should pull in spk121's dlopen work, and make a sweep of guile-devel
<civodul>great
<wingo>(reader is finished == documented and everything, makes sense, etc)
<wingo>will be a good release i think
<civodul>i'd use guile-on-minigmp on Guix core-updates
<civodul>definitely!
<civodul>there was also an issue with spuriouis unbound-variable warnings i wanted to look at
<civodul>haven't got around to it yet
<civodul>*spurious
<daviid>wingo: before 3.0.6, please try to look at and hopefully fix #43025 (where the first message has the snipset to reproduce the bug ...) - tx
<wingo>lloda: just pushed a patch replacing "read" in (guile)
<wingo>will make a followup to make C reader available as primitive-read or so
<wingo>and eventually will remove all reader options from primitive-read
<lloda>noted
<lloda>the mini-gmp patches broke my build
<lloda>/usr/bin/ld: ./.libs/libguile-3.0.so: undefined reference to `__gmpz_cmp'
<lloda>how does this work
<lloda>ok it seems --enable-mini-gmp=no
<lloda>seems not :-\
<lloda>halp :-(
<spk121>lloda: darn, I didn't get that on my boxes. What are you running?
<lloda>debian buster
<lloda>seems gmp isn't in pkg-config --list-all
<lloda>checking for GMP... no
<lloda>I get this without any options:
<lloda>../../src/guile3/configure: line 50004: =yes: command not found
<spk121>OK, I think I see it
<lloda>this is the config.log piece https://paste.debian.net/1187692/
<spk121>well since it didn't find gmp, it should have fallen back to mini-gmp. So that logic is broken. I think I see the problem, let me test...
<spk121>lloda: on debian, is GMP's pkg config file named 'gmp'?
<lloda>no
<lloda>apparently it doesn't have a pkg-config file
<spk121>no even if you install a gmp-dev or libgmp-dev or something like that?
<lloda>those are installed ofc
<lloda>but they don't seem to include a pkg-config file
<lloda>the debian package is libgmp-dev
<spk121>well then. this may take a moment
<lloda>libraries have been slowly getting that
<lloda>i remember when glfw wasn't in pkg-config and then there was an update and it was
<lloda>:-\
<civodul>spk121: in GMP 6.2.0 upstream, it's gmp.pc, FWIW
***berndj-blackout is now known as berndj
<lloda>i tested the fix i just pushed on the commit before the gmp one, shouldn't make any difference
<dsmith-work>Ya, current git is failing to build for me with or without --enable-mini-gmp
<dsmith-work>v3.0.5-82-g9516a10ab
<dsmith-work>Debian stable
<spk121>dsmith-work: :-< I think I've got a fix. I'm testing now on Fedora, and will try Debian next
<dsmith-work>Cool. No worries. Just adding a datapoint.
<wingo>moo
<wingo>well, still a bug or two in srfi-105 support
*wingo grumbles
*civodul had to look up srfi-105, {doh!}
<jgart> https://www.gnu.org/software/guile/manual/html_node/Web-Client.html
<jgart>Hi, the link in the above manual page to guile-tls is broken.
<jgart>This link: https://www.gnu.org/software/guile/manual/gnutls-guile/Guile-Preparations.html#Guile-Preparations
<jgart>The package is called gnutls-guile
<jgart>What should the link point to instead?
<jgart>Should it point to this link instead? https://www.gnutls.org/manual/gnutls-guile.html#Guile-Preparations
<jgart>I'll be happy to send a patch for the updated link if someone can confirm if I should use the one I linked above.