IRC channel logs

2019-11-18.log

back to list of logs

<RhodiumToad>&gt; is treated as an embedded #\> character ;;WHAT
<RhodiumToad>the whole _point_ of CDATA is that there are no special entities in it, the ONLY markup is ]]>
<RhodiumToad>fascinating how such an obvious bug apparently remains undetected for decades
<wingo>moin
<manumanumanu>Ahoy Guilers!
<wingo>:)
<civodul>howdy!
<manumanumanu>wingo, civodul : now that you both are here! I just finished srfi-171 (transducers), which are a generalization of map, filter and friends. If I were to provide a patch to include it in guile, would it have any chance of getting merged? The transducers are implemented in the same way as in clojure (ie: eagerly) with the same "protocol".
<wingo>manumanumanu: it's easy to merge support for a new srfi :) do you have copyright assignment on file? make sure to document the thing too
<civodul>yup, also with tests :-)
<manumanumanu>No copyright assignment, but that can be arranged. Documentation can be converted to texi without much fuzz.
<civodul>but it sounds like it would be a great addition!
<wingo>send me your email address and i can put you in contact with the fsf copyright clerk
<wingo>been a while since i did that so i don't know how fast they are these days
<manumanumanu>I need something to do before boredom makes me hack my for loops into a srfi like john asked me. It is such a daunting task :D
<manumanumanu>not only that, porting it to another scheme is somewhat of meh task.
<manumanumanu>Chez scheme would have been easy if it had been easier on the phasing and if it had had keywords.
<chrislck>tflatten. finally.
<amz3>manumanumanu: at least, you do not need to learn a new cffi interface :)
<amz3>well, chez scheme cffi looks like guile cffi, but chibi cffi is completly different.
<manumanumanu>chrislck: how come?
<manumanumanu>amz3: I really like the chez ffi, but for writing portable ffi code I usually just use the r6rs-ffi.
<amz3>I had some concerns regarding r6rs-ffi, but I don't remember exactly what it is.
<amz3>that r6rs ffi: https://github.com/ktakashi/r6rs-pffi
<manumanumanu>exactly
<manumanumanu>Quite a spectacular achievement :D
<chrislck>manumanumanu: srfi-1 doesn't have list-flatten and there's lots of bad implementations around
<chrislck>except: https://stackoverflow.com/questions/7313563/flatten-a-list-using-only-the-forms-in-the-little-schemer/7324493
<manumanumanu>bad implementations? Isn't everyone using a regular tree walk? That should be O(n) and work on improper lists
<chrislck>lots use append... https://stackoverflow.com/questions/8387583/writing-flatten-method-in-scheme
<manumanumanu>That would be faster than using transducers.
<manumanumanu>wowza.
<manumanumanu>chrislck: this is mine: https://pastebin.com/gX2vZM8A
<manumanumanu>that uses no reverse and doesn't die on improper lists (although it properizes them :D)
<manumanumanu>It should be close to optimal.
<wingo>yeah that version is nice
<wingo>use the stack :thumbsup:
<manumanumanu>what I of course meant to say: for guile and racket that should be optimal. I don't know what other schemes have that very very nice optimization.
<manumanumanu>chrislck: if you want to spread that flatten around, please do. I claim no copyright to that piece of code.
<amz3>what is the plan regarding R7RS-large libraries?
<amz3>if any?
<manumanumanu>there should be plenty of time to decide. Have they voted on anything else than the red docket yet?
<amz3>re vote: I am not sure. I am not thinking about patches for guile, for the time being. I am considering a) one repository per SRFI b) a monorepo (like https://git.sr.ht/~amz3/guile-arew)
<amz3>also, I am not confortable with SRFI-64, but I prefer to avoid duplicated or wasted efforts... My current favorite test runner, rely on library reflection: https://git.sr.ht/~amz3/guile-arew/tree/d308be1b43267678253f499976a5506a614f6ada/check.scm
<wingo>amz3: i have no plan. i think that given the size, it would be best suited to a repo outside guile imo
<chrislck>manumanumanu: i'd settled on 2 similar functions from your srfi: https://github.com/Gnucash/gnucash/blob/maint/libgnucash/scm/utilities.scm#L202
<chrislck>there were lots of comments decrying delete-duplicates in old code :-P
<chrislck>but the bottlenecks were never guile efficiency... lots of slowdowns in bad code elsewhere, now hopefully most gnucash scheme is now O(efficient)
<chrislck>see 1 example of old-code de-uglifying: https://github.com/Gnucash/gnucash/commit/ef3bc616
<chrislck>and another another: https://github.com/Gnucash/gnucash/commit/cbd86491
<chrislck>conclusion: hallelujah modern scheme tutorials :)
<manumanumanu>chrislck: list? is o(n) for gnc:list-flatten... I'd just use a hash-table for delete-duplicates :D
<manumanumanu>pair? is better
<chrislck>TIL
<chrislck>thx!
<manumanumanu>chrislck: yeah. I did that thing as well, but with match. It is because list? has to distinguish between proper and improper lists.
<spk121>.
*chrislck has a mission to remove all inappropriate use of set! :)
<manumanumanu>chrislck: talking about hidden costs :D
<amz3>wingo: ok.
<amz3>that is neat to read that much activity around guile.
<jcowan>manumanumanu, amz3: the Tangerine Docket has also been voted on
<RhodiumToad>so is there a place to report bugs in ssax/upstream, or shall I treat it as a guile bug?
<jcowan> https://bitbucket.org/cowan/r7rs-wg1-infra/src/default/TangerineEdition.md
<jcowan>RhodiumToad: You could send them directly to Oleg himself
<RhodiumToad>this is a bug apparently caused by misinterpreting the spec, so a public bug list would be better
<RhodiumToad>(and yes, I've checked with other experts and with other implementations to make sure it's not _me_ misinterpreting it)
<amz3>RhodiumToad: maybe comp.lang.scheme newsgroup?
<RhodiumToad>is that still going? huh
*RhodiumToad largely abandoned usenet after being a newsadmin for so long
<RhodiumToad>I don't see contact info for oleg?
<jcowan>Historically oleg@pobox.com; I have no idea if that still works
<jcowan>c.l.s is still quite useful despite being infested by THAT ITALIAN LOON WHO UPPERCASES ALL HIS RANTS
*RhodiumToad just signed up again for news.individual.net
<RhodiumToad>posted on c.l.s
<RhodiumToad>as for the loon, I assume groups-abuse at google is at least as clueless as they were back in the day when they asked me to teach them their jobs
<RhodiumToad>I nearly had them depeered at one point
<jcowan>I think they just simply are not listening
<RhodiumToad>they pretty much never did, getting them cut off was the only way I found to get their attention
<RhodiumToad>but I'm no longer in the business
<weinholt>RhodiumToad, groups-abuse just bounces
<RhodiumToad>hah
<weinholt>seems it was connected to a group and that group no longer exists
<RhodiumToad>typical
<weinholt>i find it odd that his rants are posted via Belgian ISPs. i sent abuse reports to them, one reported it was handled, but nothing came of it. also reported it to google's net-abuse (iirc) alias. nothing happened.
<amz3>that strengthen the idea that google groups (and news groups) will join killedbygoogle.com
<weinholt>amz3, usenet will still exist after google and will likely be better off :)
<jcowan>I used to subscribe to the RSS feed, but now I use the emailed daily summary
***jao is now known as Guest67735
<amz3>www meh blah p2p blah blah gnunet blah.
<dsmith-work>Morning Greetings, Guilers
<RhodiumToad>good evening
<daviid>chrislck: wrt flatten, here is one :) http://git.savannah.nongnu.org/cgit/grip.git/tree/grip/list.scm line 73+
<daviid>maybe I should move it to guile-lib... it is almost a faq here :)
<count3rmeasure>morning!
<RhodiumToad>fascinating, W3's testsuite for xml contains exactly no instances of &gt; inside CDATA
<str1ngs>daviid: hello, do you know of anything to help produce coverage for guile-lib (unit-test)? currently I'm using https://github.com/mrosset/home/blob/master/tools/coverage.in which I snarfed from gash. I'm wondering if there is a better way?
<wingo>amz3: do fibers work well with http clients/
<wingo>?
<wingo>i.e. can i http-get from within a fiber, and does all work as it should?
<daviid>str1ngs: hello - the link you pasted does not work
<str1ngs>daviid: one sec will paste to debpaste for you.
<str1ngs>daviid: http://paste.debian.net/1116832
<str1ngs>this is some extra automake autotools stuff but the meat and potatoes is in coverage.in
<str1ngs>there is*
<str1ngs>the original is here http://git.savannah.nongnu.org/cgit/gash.git/tree/tools/coverage.in I just added some hacks for (unit-test)
<daviid>str1ngs: sorry, I'm not familiar with this, I just write what ever tests my projects needs and manually run 'make check' ... never used (system vm ...)
<str1ngs>daviid: I understand. I was wondering if this has been sovled before I guess. Thanks for looking at it.
<str1ngs>daviid: this piggy backs of make check. I just use make coverage to generate html from lconv.info. to see if I missed anything that might need testing
<str1ngs>good for finding dead code as well
<daviid>html, oh my god ...
<daviid>non merci :)
<amz3>wingo: i did not test recently with guile 2.9.x, but with guile 2.2 I think it works.
<amz3>Now I can recall that a version of my project was using fibers to crawl websites.
<amz3>To be honest, I did not do extensive benchmark.
<amz3>str1ngs: I think guile has coverage support, Let Me Check.
<amz3>str1ngs: yes there is: test-suite/guile-test. Nala Ginrut reported some feature missing in the coverage module of guile. I have a patch in my guile checkout that contains the following: https://paste.gnome.org/pzvvwlghv
<str1ngs>amz3: will check this out thanks
<ArneBab_>when using the append from manumanumanu, Guile does not release all of its memory on (gc). To reproduce:
<ArneBab_>flatten: https://pastebin.com/gX2vZM8A
<ArneBab_>(define longlonglist (iota 100000000)) (define longlonglist2 (iota 100000000))
<ArneBab_>(begin (flatten (list longlonglist longlonglist2)) #f)
<ArneBab_>(gc)
<RhodiumToad>boehm-gc is never guaranteed to release all memory, it's a conservative collector
<ArneBab_>In this case it keeps 6GiB of memory (half of the peak memory)
<ArneBab_>it feels like this is a bit much
<RhodiumToad>um
<RhodiumToad>you still have the two original lists
<RhodiumToad>how much do they take up?
<ArneBab_>around 3 GiB
<RhodiumToad>I believe, from what I know of the boehm gc, that it's a potential issue if you have very long chains of connected cells, and a false match on the stack or heap ends up pointing to one of them
<RhodiumToad>that can potentially convince the gc that a long list is reachable when it is not
<RhodiumToad>how consistent is the effect if you make small changes to the lengths?
<RhodiumToad>proportionally small, that is
<ArneBab_>you mean whether I also see this if I use iota 90000000 ?
<jcowan>Also, some repls hang onto inputs and/or outputs
<ArneBab_>that’s why I used the (begin … #f) — otherwise the formatting of the output kills all performance.
<RhodiumToad>yes, does the memory retained at the end change much in response to proportionally small changes to input size
***daviid is now known as Guest95982