IRC channel logs


back to list of logs

<ecraven>ArneBab: ah, probably I updated it and forgot to re-install the r7rs module
<ecraven>I really need to write a script to try and update all schemes on my system :-/
<ArneBab>ecraven: sounds like that — or having a VM setup with the benchmarks
<ArneBab>so they do not interfere with your regular work.
<ecraven>I'll try to put it all into an ansible playbook someday soon ;)
<ecraven>not sure whether a virtualbox vm would have any impact on speed.. though it would still keep the relative results the same, I guess
<ArneBab>there might be differences with the compiled ones — I’m not sure, though. GNU Hurd on a VM gets a lot faster, because it can then profit from the Linux page cache. Maybe a doubled page-cache (in this case then Linux on Linux) can change the behavior of the programs.
<ecraven>well, a playbook would be nice to have anyway, I can just run it and compare to the other results
<ArneBab>that would be nice, yes
<amz3>héllo #guile
<lloda>what is the proper way to set guile-snarf in autoconf?
<ecraven>ArneBab: racket takes 3rd place, it's really much faster than I thought
<ArneBab>ecraven: thank you for checking!
<ecraven>results are uploaded
<ArneBab>ecraven: I expected racket and guile to be about on-par
<ecraven>thank you for showing me I forgot
<ArneBab>happy to help ;-)
<ecraven>I'm sorry to say, racket seems a lot faster than guile :-/
<ecraven>though it does have an instruction jit, I think
<ArneBab>oh, wow, the speed is pretty incredible
<ecraven>it's faster than chez quite a few times
<ArneBab>wasn’t that different some time ago?
<ecraven>yea, a few releases ago
<ArneBab>(racket is fastest for 9 tests)
<ecraven>I'll start a new run tonight, maybe something went wrong :-/ I need a dedicated machine for this
<ArneBab>how long does it take you to do all these runs?
<ecraven>if I run them all in sequence, more than 24 hours, I think
<ecraven>this is an 8-core machine, so I normally run them 3 or so at the same time
<ecraven>though of course that is not ideal
<ecraven>Soon™ I'll change things so that the tests are run multiple times and averages are used
<ArneBab>ecraven: before you stat that, is there a chance that you might add this?
<ArneBab>as another target
<ecraven>I'll need to package it for arch linux, if that works, no problem
<ArneBab>ecraven: here’s some information on that:
<ArneBab>it needs gnu-lightning and ./configure --enable-lightning and being run with guile --tjit
<ArneBab>here’s exact release information (with tarball):
<ArneBab>ecraven: as last question: could you increase the timeout a bit again to allow the ctak test in guile to finish?
<ecraven>hm.. I'll also need to install it as guile-tjit or so
<ecraven>ArneBab: yea, set it at 300s I think, I can update to 600?
<ArneBab>from the last time I tried that should suffice
<ArneBab>(7 of the schemes timeout on ctak)
<ArneBab>ecraven: by the way: thank you for running these tests!
<ArneBab>(I tried to run them on my machine, but didn’t get them to just work … I wasn’t sure whether I have to adjust summarize.sch — and how
<ecraven>the running itself works with only bench
<ecraven>no need for any of the scheme files
<ecraven>ah, come on.. guile-tjit needs lightning, which fails to build on my system
<ecraven>checks float.nodata and clobber.nodata fail
<ArneBab>which compiler do you use for that?
<ArneBab>ecraven: which version was that?
<ArneBab>(I just realized that the version I have on Gentoo is terribly outdated
<ecraven>ArneBab: 2.1, the normal arch linux package
<ecraven>gcc 6.3.1
<ecraven>those are non-negotiable :P
<ArneBab>clearly :)
<ArneBab>(I’m still on gcc 6.3.0, but they should be close enough)
<ArneBab>hm, lightning builds here without problems
<amz3>is there a particular advantage in using 'values' instead of 'list' + 'match' to return multiple values in proc
<amz3>is there a particular advantage in using 'values' instead of 'list' + 'match' to return multiple values in *a* procedure
<ArneBab>amz3: maybe that match is a macro?
<lloda>what is different between #u8(...) and #vu8(...)? why does (u8vector? #vu8(...)) return #f? should there be a vu8vector? predicate?
<amz3>I think u8 is bytevector whereas vu8 is a vector
<amz3>or it's the inverse
<amz3>forget what I said, it's garbage, sorry for the noise
<lloda>np :) they are both bytevectors, but u8 is also an srfi-4 vector (all srfi-4 vectors are also bytevectors). It seems vu8 only exists because there are two APIs for the same thing :-(
<amz3>yes they are both bytevectors
<amz3>so basically if you use (rnrs bytevectors) you can work with both forms of vector, still I don't know what the difference
<amz3>I think mark_weaver told me what the difference was a long time ago
<amz3>how can i express a xpath query over the parent axis?
<amz3>I don't see how to achieve the same with sxpath
<amz3>still it's good enough for my current task
<amz3>so there is a bug in sxpath or I don't know how to do it, basically (sxpath '(// h3 (@ (id)))) should return every element h3 that has an id but instead return the (@ (id something) ...) instead of (h3 (@ (id something)) ..)
<amz3>ah ok got it
<amz3>i will just use what works for the time being, but sxpath has very strange behavior IMO
<amz3>I want to write the equivalent of xpath: //h3[@id="Noun"]/parent::
***sajith is now known as Guest66940
<amz3>guix is on HN
***PuercoPope is now known as PuercoPop
***heroux_ is now known as heroux
***siel_ is now known as siel
<paroneayea>amz3: nice :D
<ArneBab>wingo: did you change (with-statprof … ) to discard the sample count?
<dsmith>sneek: botsnack