<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? <apteryx>some commits I've made to allow more configuration of the htmlprag tokenizer <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? <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 ... <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>great eyes keeping track of many channels btw ;-) <wingo>sneek: later tell davexunit that's like racket's "prefab" structs. would be nice to support that <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>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 <lloda>ok to use srfi-71 in Guile source? <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>civodul: consider (let ((p (open-input-string ""))) (set-port-encoding! p "invalid")) -- currently this doesn't error <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>is a minor change but wanted to check <lloda>on last master, is there more than one reader being used? <lloda>> (call-with-input-string "#f64:3(1 2 3)" read) <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'll try to fix the new one then <wingo>hey thanks for the diligence on the reader fixes, & apologies for my bugs <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>currently i am seeing scheme reader + suspendable ports running at about 50% speed relative to C reader + C ports <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>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 <wingo>without positions, with source-properties (i.e. `read'), and with syntax objects (read-syntax) <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 <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>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 <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>there was also an issue with spuriouis unbound-variable warnings i wanted to look at <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>the mini-gmp patches broke my build <lloda>/usr/bin/ld: ./.libs/libguile-3.0.so: undefined reference to `__gmpz_cmp' <lloda>ok it seems --enable-mini-gmp=no <spk121>lloda: darn, I didn't get that on my boxes. What are you running? <lloda>seems gmp isn't in pkg-config --list-all <lloda>I get this without any options: <lloda>../../src/guile3/configure: line 50004: =yes: command not found <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>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>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 <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 <spk121>dsmith-work: :-< I think I've got a fix. I'm testing now on Fedora, and will try Debian next <wingo>well, still a bug or two in srfi-105 support *civodul had to look up srfi-105, {doh!} <jgart>Hi, the link in the above manual page to guile-tls is broken. <jgart>The package is called gnutls-guile <jgart>What should the link point to instead? <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.