<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... <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>setting scm_install_gmp_memory_functions = 0 *does* work, but only if you don't later set it to 1 *rlb contemplates warming up sbuild <daviid>dsmith-work: done, see bug#47084 <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 ***apteryx is now known as Guest59538
***apteryx_ is now known as apteryx
<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 :) <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 <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>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 *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 <mdevos>sneek: later tell civodul: never mind, I see configure.ac & Makefile.am exist <mdevos>sneek: later tell civodul: "make check" fails with guile-2.2 (I opened a bug) <sneek>mdevos:, mdevos says: feed me <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) <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! <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 <mdevos>(I see no reason to stick exactly to POSIX, as long as the POSIX<->Guile mapping remains clear) <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 <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 :-) <mdevos>but does anyone have an idea why there isn't a rmdirat? <RhodiumToad>probably someone just didn't want to add another function <civodul>mdevos: could you "git pull" guile-zlib and retry "make check" (on Debian)? <mdevos>... apparently closing GNOME boxes doesn't stop the VM, it just suspends it <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 <mwette>civodul: re guile-zlib, I forgot how to generate configure. autoreconf? <sneek>mwette, nly says: ill be more than happy to test guile libfuse <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" <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 <civodul>i guess we should at least improve the build instructions... <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>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>spk121: would you be ok if i reverted the read-line things for the moment? <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 <spk121>Guile could use some better CI/CD. The old hydra.nixos would build guile on a bunch of platforms / OS's <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 ***Noisytoot is now known as [[
<civodul>overall, i think Guile packaging has gotten much better over the last couple of years ***[[ is now known as [[Like
***[[Like is now known as [[
***[[ is now known as Noisytoot
<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>Could someone please take a look at it? <wingo>rgherdt: applied, tx for ping :) <wingo>i wonder what kevin ryde is doing these days <wingo>he did great guile maintenance in the 1.6 times