IRC channel logs

2021-03-12.log

back to list of logs

<rlb>If it were feasible, and unless scheme regex's are likely to have competitive performance, I'd also love to have an easy "standard" option for regexps. Were I to do it, that might mean built-in support for maybe pcre. (And if there's interest, I'd be happy to try to help there -- already did it for lokke.)
<rlb>flatwhatson: plese let me know if you figure anything further out wrt the gnutls issues -- debian's next freeze level begins on the 12th, so much easier to get a fix in now if we need it, than after...
<flatwhatson>12th of March?
<rlb>yep :/
<rlb> https://release.debian.org/bullseye/freeze_policy.html#hard
<rlb>wingo: fwiw, this might well not actually go anywhere, but for no good reason I can discern, I'm still poking at utf-8 strings, and have made non-trivial progress reworking strings.c, etc. i.e. I might not finish, but if I do I'll shout...
<flatwhatson>rlb, wingo: I have a fix! https://paste.gnome.org/pjara0uwz
<flatwhatson>setting scm_install_gmp_memory_functions = 0 *does* work, but only if you don't later set it to 1
<rlb>doh!?
*rlb contemplates warming up sbuild
<daviid>dsmith-work: done, see bug#47084
<spk121>janneke: in guile
<spk121>janneke: in guile's master branch, I've checked in a lot of the 32-bit mingw patches from that guile 2.2 branch. It would be cool if you could adapt your 64-bit mingw patch for master
<janneke>spk121: great, i'll have a look
***apteryx is now known as Guest59538
***apteryx_ is now known as apteryx
<wingo>flatwhatson: !!!!!!!
<wingo>wow :)
<wingo>must be why my tests didn't show changing it to have any perf impact
<wingo>rlb: in any case i would think that utf8 strings would be useful for possibly adopting external regexp libraries
<wingo>spk121: haha that mingw libpath thing is horrible :)
<wingo>ah well
<civodul>hi there!
<civodul>i'm looking for testers of https://notabug.org/guile-zlib/guile-zlib on a non-Guix distro; any takers? :-)
<civodul>basically building and running "make check"
<mdevos>how can I run a single test of guile's test suite?
<mdevos>(make check TESTS=tests/$THE_TEST.test recurses into test-suite/test-suite, which doesn't have the test)
<mdevos>civodul: will do in my Debian VM
<wingo>mdevos: ./check-guile foo.test
<wingo>or are you trying to run one of the standalone tests
<mdevos>wingo: no, a Scheme test
<wingo>spk121: would be interested to hear about the read-line changes fwiw
<spk121>wingo: yeah, that is the sort of controversial one< I guess
<spk121>I started out just wanted it to handle CRLF as well as just LF
<spk121>And while I was there, I threw in the Unicode line endings that almost no one uses for pedantry's sake
<wingo>what would be the disadvantage of ending lines at CR ?
<wingo>and then slurping a LF if the delimiter was CR
<wingo>just wondering how to get back the perf advantages of port-fold-chars
<spk121>Well that's the way it had been. The disadvantage could be seen in reading web headers, which expectes CRLF, which is where you'd actually done exactly that
<spk121>I guess it is a matter of expectation. If you are reading a utf-8-unix file and do read-line, you get a line. If you are reading a utf-8-dos file, you don't get a line. You get a line + return, which is neither a line nor a line + terminator
<spk121>If I wanted to appeal to authority rhetorically, I could point to https://www.unicode.org/reports/tr14/#BreakingRules , but, I didn't really follow those rules exactly either, because literally nobody uses NEL
<spk121>But OTOH, it isn't a need for Guile on MinGW to work, and reverting it is not a problem
<wingo>just for info, did you do any perf testing of those functions?
<wingo>i guess if we really want to have \r not followed by \n as part of a line and not a delimiter, i would be more inclined to keep %read-line be a bit dumber, and make read-line do a read-delimited of "\n\r", and possibly repeat if \r not followed by \n
<wingo>you know, string-append and recurse, etc
<wingo>but, am interested in any thoughts you had there
<spk121>wingo: the lack of benchmarking is definitely a valid criticism. I could try to put something together.
<spk121>But, if I were at work, I would probably say that first we need to decide what are the actual requirements of 'read-line' and do we meet those requirements. And then afterward meeting the requirements, one would work on optimization
<spk121>So what are the requirements of a 'read-line'?
<spk121>But I do want to stress how *mild* any argument I'm making right now is, and how I'd be happy to go with whatever
<wingo>for me the requirements are: as good perf as possible. allows further port optimizations. keep compatibility with old code.
<wingo>reads \r\n is a nice-to-have, but it can conflict with compatibility
<wingo>like people could have code out there that relies on the old behavior. dunno how to mitigate that
<wingo>i am on board with reading \r\n but i just wonder about compat. perhaps less of an issue considering how sub-par guile's windows story is atm
<wingo>would be good to see what read-line has done in the past, if it always just read to \n
<spk121>wingo: read-line has always just be \n or <eof>. I don't know if you open file ports in text mode if they do any CRLF chomping
<spk121>I tried to come up with a benchmark. As near as I can tell, the performance before/after seems in the noise
<spk121>if I've done it correctly
<spk121> https://paste.debian.net/1189001/
<wingo>yeah perf looks good, tx
*wingo still wants to improve the suspendable-ports results...
<wingo>but that concern is from before :P
<spk121>well, we could punt on this and revisit for version 3.2.x, if there is the possibility of code out there actually parsing CRLF with read-line and depending on old behavior. I'm not sure how likely that is, but, who knows?
<spk121>if you revert it in git, the patch will still remain in tree for posterity, so it can be reintroduced later
<mdevos>sneek: later tell civodul: guile-hall is not packaged for Debian, so you might run into trouble there
<sneek>Got it.
<mdevos>sneek: later tell civodul: never mind, I see configure.ac & Makefile.am exist
<sneek>Will do.
<stis>Hi guilers!
<mdevos>sneek: later tell civodul: "make check" fails with guile-2.2 (I opened a bug)
<sneek>Will do.
<mdevos>sneek: tell mdevos: feed me
<sneek>mdevos:, mdevos says: feed me
<mdevos>sneek: botsnack
<sneek>:)
<civodul>mdevos: thanks!
<sneek>civodul, you have 3 messages!
<sneek>civodul, mdevos says: guile-hall is not packaged for Debian, so you might run into trouble there
<sneek>civodul, mdevos says: never mind, I see configure.ac & Makefile.am exist
<sneek>civodul, mdevos says: "make check" fails with guile-2.2 (I opened a bug)
<civodul>spk121: a possibly useful tool is "./benchmark-guile read.bm" (or similar)
<manumanumanu>stis: Tjenare! What are you up to?
<mdevos>quick status update: fchmodat, renameat, mkdirat & symlinkat have been defined and readlink, chdir & utime accept file ports now! To be continued
<civodul>mdevos: guile-zlib should be fixed now, thanks!
<civodul>mdevos: re *at, nice!
<mdevos>I'm wondering, should I define a rmdirat even though it doesn't exist in C? The (rmdirat dir name) would actually be implemented as (unlinkat dir name AT_REMOVEDIR)
<mdevos>I dunno why rmdirat doesn't exist and folks decided for AT_REMOVEDIR instead
<civodul>i'd say stick to POSIX, so provide unlinkat and AT_REMOVEDIR but not rmdirat
<mdevos>I would prefer defining a rmdirat, but whatever. I'll add a comment to rmdir explaining there's no rmdirat
<civodul>ok
<mdevos>(I see no reason to stick exactly to POSIX, as long as the POSIX<->Guile mapping remains clear)
<civodul>yeah well
<civodul>i think we can have POSIX at one layer, and possibly higher-level interface on top of that
<civodul>but "rmdirat" looks like POSIX, but it's not POSIX
<civodul>dunno, i'm nitpicking i guess :-)
<mdevos>Counter-nitpick: The procedure "open" isn't exactly POSIX either, as it returns a port (POSIX equivalent: FILE *) and not a file descriptor.
<mdevos>But we can always define a new bike shed later :-)
<civodul>true :-)
<mdevos>but does anyone have an idea why there isn't a rmdirat?
<RhodiumToad>the SUS rationale section doesn't say
<RhodiumToad>probably someone just didn't want to add another function
<dsmith-work>Happy Friday, Guilers!!
<civodul>Happy Friday!
<civodul>mdevos: could you "git pull" guile-zlib and retry "make check" (on Debian)?
<mdevos>civodul: will restart the VM
<civodul>ah, sorry for the extra work
<mdevos>... apparently closing GNOME boxes doesn't stop the VM, it just suspends it
<civodul>handy, i guess
<mdevos>the clock is an hour behind now.
<mdevos>Also, something I noticed: you can 'unsuspend' a suspended VM even after the host system rebooted
<mdevos>PASS: tests/zlib.scm
<civodul>yay!
<civodul>thanks, mdevos!
<mwette>civodul: re guile-zlib, I forgot how to generate configure. autoreconf?
<sneek>mwette, you have 1 message!
<sneek>mwette, nly says: ill be more than happy to test guile libfuse
<mwette>sneek: later tell nly: lost track re libfuse, here is the ffi file: https://paste.debian.net/1189035/, you just get nyacc and type "guild compile-ffi ffi/fuse.ffi"
<sneek>Will do.
<mwette>civodul: I get a configure error: syntax error near unexpected token '3.0' , for 'GUILE_PKG(3.0 2.2 2.0)'
<mwette>civodul: I used 'autoreconf -vif' before configure
<civodul>mwette: hi! that means you're missing guile.m4 (provided by Guile) in ACLOCAL_PATH
<civodul>if you installed Guile under /usr/local, you probably need something like: ACLOCAL_PATH=/usr/local/share/aclocal
<mdevos>mwette: I think I had to "apt-get install guile-2.2-dev"
<civodul>ah right
<mwette>ah, I have my own guile installed, no apt, and build process is not happy. I did fix ACLOCAL_PATH nd see that guile.m4 is there
<mwette>now getting "configure error: No Guile development packages were found."
<mwette>oh: PKG_CONFIG_PATH -- lemme try that
<mwette>OK. That works now. all pass
<mwette>ubuntu 2.10 x86_64
<dsmith-work>daviid: Closed
<civodul>mwette: yay, thank you!
<civodul>i guess we should at least improve the build instructions...
<mwette>civodul: yw
<dsmith-work>Ok, cool hack of the day. Non-guile though. Got a long-running process on another machine I'm not looking at. (a build or a dd or something)
<dsmith-work>Have a script there with: echo "$*" | nc -u -w 0 -b 192.168.1.255 7478
<dsmith-work>And on the machine I'm looking at:
<dsmith-work>while true; do notify-send -t 0 -u critical -- "$(nc -l -u -p 7478 -W 1)"; done
<dsmith-work>Sends a upd packet with netcat and does a notiification.
***Allan[m] is now known as allan[m]
<mdevos>Would a ‘statat’ binding need a ‘exception-on-error’ argument? 'stat' has one, but ‘lstat’ doesn't.
<wingo>heyyy
<wingo>spk121: would you be ok if i reverted the read-line things for the moment?
<spk121>go for it
<wingo>how much does it affect mingw usage?
<wingo>like if you run on mingw, without that patch, do tests start failing or something, or do "normal" uses not work?
<spk121>It only matter for people using Guile on native windows that want to parse text files. It doesn't affect the test suite or the build, I think
<spk121>Also, the test suite still has 20 ish failing tests, so it was never going to be perfect for this build anyway
<wingo>i guess the impact would be having a trailing \r on returned lines for ports not opened in text mode
<wingo>(apparently O_TEXT eliminates the \r, fwiw)
<spk121>wingo: yeah O_TEXT is supposed to have that effect. Don't think I've ever tried it, though
<wingo>so many moving parts :P
<spk121>Guile could use some better CI/CD. The old hydra.nixos would build guile on a bunch of platforms / OS's
<wingo>yeah agreed
<wingo>we have a lot of great synergies with guix but moving closer to guix has moved us a bit farther away from many platforms common with users
<wingo>no complaints, nb, just a note, and a thing to work on in future
<civodul>there's also been a lot happening on Debian
<civodul>and Aleix working on Homebrew
***Noisytoot is now known as [[
<civodul>overall, i think Guile packaging has gotten much better over the last couple of years
<civodul>even for those not using Guix :-)
***[[ is now known as [[Like
***[[Like is now known as [[
<civodul>(not that it helps for MinGW tho)
***[[ is now known as Noisytoot
<wingo>good points!
<spk121>for a bit I was trying to build Guile on MinGW as a step in trying to build Guile-GI on MinGW. This was on Github/Azure, so it is many different levels of non-free badness
<wingo>apteryx: welcome to guile-lib
<wingo>plz push whatever patches you see fit :) if you need feedback, me civodul daviid and rotty are project admins and would be happy to give feedback
<wingo>careful, if you make too many good patches, you too will be admin & release manager
<rgherdt>good evening! I opened a bug report and submitted a patch 284 days ago, due to an implementation error in hash-table-merge! (currently it basically "merges" the first ht with itself, ignoring the other one)
<rgherdt>Here the ticket: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41131
<rgherdt>Could someone please take a look at it?
<wingo>good evening :)
<wingo>rgherdt: applied, tx for ping :)
<rgherdt>wingo: thanks, you're welcome
<wingo>i wonder what kevin ryde is doing these days
<wingo>he did great guile maintenance in the 1.6 times
*wingo zzz
<wingo>night!