IRC channel logs


back to list of logs

<leoprikler>ngz: fwiw (and (string? v) v) should work
<ngz>leoprikler: Yes, but then I need to evaluate v twice.
<leoprikler>ahh, so you want it to expand to (let ((v exp)) (and (string? v) v))
<mwette>RhodiumToad: typing lots of commas
<RhodiumToad>yeah, value-if-string could have been defined as (and (string? v) v) but I don't think that's any improvement over (if)
<RhodiumToad>oh, I found another way
<RhodiumToad>(cond ((foo) string? => identity) ((bar) string? => identity) (else ""))
<RhodiumToad>that is apparently from srfi-61 but it's built-in syntax in guile
<dftxbs3e>I don't understand why GNU Guile is slow some times without consuming 100% CPU or I/O
<daviid>rlb: thanks! will try vagrant asap, many tx for the steps in the debian paste ... i was not aware it was that easy to create and use other deb env to test ... cool!
<sneek>daviid, you have 1 message!
<sneek>daviid, rlb says: I can set it up and try with 2.2 tomorrow. Also, if you have access to vagrant, I can give you trivial steps to reproduce whatever I find. Oh, and if I forget, certainly feel free to ping me.
<rlb>I just use vagrant for testing for the most part, but it's quite useful there.
<rlb>Happy we have the debian images too.
<rlb>(Oh and there are freebsd images which have been very useful for tracking down compatibility issues.)
<rlb>dftxbs3e: what's the context?
<dftxbs3e>rlb, I don't know for sure, I can't say anything so what I said is not very useful. If I find anything I'll be sure to share.
<daviid>rlb: it all seems very powerful - tx again, will ping when i have some results ...
<rlb>dftxbs3e: if you can reproduce it, might check "atop 3" or attach via "strace -p PID ..." or, similar if you haven't already. Might see something relevant.
<dftxbs3e>rlb, didnt know about atop, how does it work exactly? what's 3?
<rlb>That just tells it to refresh every 3 seconds rather than the default 10, and it's a little unusual in that how much you see is determined by the size of the window, so you may want to make the terminal it's in largeish.
<rlb>And it provides a broader overview than top or htop, i.e. it includes various cpu, io, and network metrics, among other things.
<dftxbs3e>I use netdata to monitor
<dftxbs3e>At this point I am thinking a remote service might be bottlenecked
<dftxbs3e>I am also pondering file system metadata performance
<rlb>Right, I'd wondered if it might be blocked on disk or the network.
<rlb>You may well be able to see that in atop, or a similar tool (dstat, vmstat, iostat, etc.)
<rlb>iotop might also be interesting or jnettop
<dftxbs3e>Basically I am running an instance of guix-build-coordinator-agent to build GNU Guix packages. It seems to run slower than on x86_64, as I am on PowerPC 64-bits
<dftxbs3e>netdata provides all the information for all these tools combined in a nice way
<rlb>Ahh, ok.
<dftxbs3e>rlb, http://[2a01:e0a:2a2:1351::1ec]:19999/
<rlb>dftxbs3e: 2.2 or 3.0?
<dftxbs3e>3.0 latest
<dftxbs3e>But at this point I am thinking it might be cbaines's scheduler that is the bottleneck and I don't have access to that to monitor or change.
<dftxbs3e>rlb, can you access the URL above or..?
<rlb>Doesn't look like it.
<dftxbs3e>rlb, do you have IPv6 networking?
<rlb>guessing not
<dftxbs3e>if your GNU/Linux distribution has a "miredo" package you can just run that as root it'll get you a teredo 4to6 tunnel set up without any configuration, unfortunately it didnt make it to Debian buster but it's in stretch and bullseye.
<rlb>Ahh, thanks.
<dftxbs3e>Do you know why interpreting Scheme code directly would be slow? Also why interpreting vs byte code compilation makes such a difference in performance?
<solrize_> Who wrote it?
<solrize_>Mu Lei AKA NalaGinrut, a Certified Scheme Nut - someone who would rather face death than not use the Scheme programming language to build a website.
<rlb>dftxbs3e: substantial topic, but one perhaps notable reason is that compiling to byte code can allow work to be done in advance.
<dftxbs3e>rlb, in the case of GNU Guix for example, you cannot run it without compiling, it's just not practical due to speed.
<vagrantc>hi, looking into a failure in the guile-ssh testsuite on debian after upgrading guile from 3.0.4 to 3.0.5 ... any wild guesses?
<rlb>vagrantc: hmm, not sure - is it easy to reproduce?
<rlb>(if you've gotten to that yet)
*rlb hopes it's not the gmp issue...
<vagrantc>rlb: it consistently fails with guile 3.0.5 with multiple different tests
<vagrantc>rlb: and consistently works with 3.0.4
<vagrantc>haven't reduced it down to a minimal reproducer yet
<vagrantc>and not sure i even really know how :)
<rlb>mostly be nice to see more of the backtrace...
<rlb>Do you see more if you run it directly (if you've tried that)?
<rlb>(Of course, don't know if you *can* easily run guile-ssh tests "directly"...)
<vagrantc>yeah, trying to figure that out
<wingo>humm weird
<wingo>could be something broken with the "case" optimization, but that would surprise me...
<wingo>i guess you are compiling the same package in the same way, just with different guile?
<rlb>Looks like one of the culprits is "ice-9/eval.scm:155:9: In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): #f".
<vagrantc>fwiw, the tests also pass with guile-2.2
<vagrantc>the guile-ssh package builds with both guile-2.2 and guile-3.0 ... when i downgrade the guile-3.0 packages to 3.0.4 the tests pass ...
<vagrantc>got a local build running to see if i can't get an environment set up to more easily manually run tests
<vagrantc>and if we're lucky, find more detailed failure logs
<vagrantc>here's one log:
<vagrantc>not sure how to make it more verbose
<vagrantc>that's just dist.log
<rlb>If their test suite has the ability to run individual test files like guile does, that might speed things up. i.e. in guile "./check-guile asyncs.test".
<rlb>And then suppose you might try commenting out tests to narrow it down to hopefully a single test that triggers it...
*vagrantc tries parsing the autotools generated Makefile
<rlb>(Then we could see if we can move that to a more standalone file that can be run more directly or something...)
<vagrantc>gah. can't even figure out how it actually runs the tests :/
<rlb>it's using autotools
<rlb>i.e. if you just set TESTS, then automake "handles it".
<rlb>See "info automake" for details.
<rlb>And I think we can just set it to narrow.
<vagrantc>ok, i can "make TESTS=dist.scm"
<vagrantc>er, "make check TESTS=dist.scm"
*rlb is trying popen.scm
<rlb>vagrantc: if you're in the top-level after a "fakeroot debian/build" looks like this may allow us to run guile using the package modules/libs:
<rlb> LD_LIBRARY_PATH=debian/build/guile-3.0/libguile-ssh/.libs guile -L modules
<rlb>and then, for example, (use-modules (ssh auth)) should work.
<rlb>Assuming that's accurate enough, then we can copy and narrow down something like popen.scm, running it via "... guile ... foo.scm"
<rlb>Oh, and here, "guile" is guile-3.0, but of course you could also just say that explicitly.
<rlb>I know :)
<wingo>what is it? :)
<rlb>(may be that change to test-end)
<vagrantc>this didn't work ... LD_LIBRARY_PATH=debian/build/guile-3.0/libguile-ssh/.libs guile-3.0 -L modules debian/build/guile-3.0/tests/popen.scm
<rlb>i.e. they're doing the same thing I was.
<rlb>(in lokke)
<rlb>Getting the test-runner fail count to decide what the exit code should be *after* the final test-end.
<rlb>In 3.0.4 that worked fine. In 3.0.5, the runner is gone.
<rlb>i.e. it's just #f
<vagrantc>this sounds promising :)
<rlb>wingo: fix is something like this:
<rlb>(let ((result (test-runner-fail-count (test-runner-current))))
<rlb> (test-end "popen")
<rlb> (exit (= result 0)))
<rlb>But I wonder if we should revert that change. This is at least the third test-suite we know of that's been broken in a Z release.
<rlb>(though not sure what caused the change)
<rlb>vagrantc: if you patch all the test files to do something like that at the end, rather than just "(exit (= (test-runner-fail-count (test-runner-current)) 0))", I think it'll stop crashing.
<vagrantc>so, is the test suite poorly written, or is that a workaround for otherwise correct code?
<rlb>vagrantc: I'm not sure the behavior is defined by srfi-64, but previously, even after you exited the top-level test-group, you could still access the runner, but after 3.0.5, the runner is #f once you exit the top-level group.
<vagrantc>so the test suite is relying on undefined behavior, at least
*rlb looks at the srfi-64 spec again...
<wingo>rlb: is there a bug for this?
<wingo>srfi-64 didn't change fwiw
<vagrantc>ok, cargo-culting your suggestion seems to have worked :)
<vagrantc>at least for popen
<wingo>so it could be a bug introduced by the compiler. or i dunno, i would like to know tho
<rlb>from a quick skim, i could see an argument that 3.0.5 is actually correct.
<rlb>"It is an error to invoke test-assert if there is no current test runner."
<rlb>"Additionally, if the matching test-begin installed a new test-runner, then the test-end will de-install it, after reporting the accumulated test results in an implementation-defined manner."
<rlb>So yeah, if there is no runner, the first test-begin should create one, and then that ^ says, that it has to "de-install" it...
<rlb>wingo: no bug yet, that I recall.
<rlb>But maybe it's not a bug...
<wingo>but what could have caused the behavior change
<rlb>If it's a parameter, then maybe we're cleaning those up better or something?
*rlb guesses wildly
<wingo>don't think so
<wingo>i mean the change list in 3.0.5 was small
<rlb>(Though it would be nice to have some "normal" way to do what I do in that commit, and what someone else commented on the other day -- they had to come up with something similar.)
<rlb>Yeah, not sure.
<rlb>otoh, it's not *that* big a deal - just have to wrap the final test-end in a let.
<wingo>there was de5d1a7f99b8e952b115237ebc29633062f99bb9
<wingo>not in NEWS :(
<rlb>Hah, there we go :)
<rlb>Yeah, so my current inclination is to think that my srfi-64 code was buggy.
<rlb>i.e. that the current behavior does in fact match the spec better...
<wingo>well, i am happy at least it is not the compiler :)
<rlb>maybe at least add something to the NEWS (in the 3.0.5 section) for the next release
<rlb>vagrantc: won't be surprised if that ends up being the whole problem.
<vagrantc>rlb: so for guile-ssh i patch the tests and submit it to guile-ssh upstream?
<rlb>Sounds plausible to me. Currently seems like we were actually fixing a variance from the spec, and so whether now or later, they'd likely need to address it.
<wingo>i regret to inform yall that i am back on my bullshit
<wingo>(call-with-input-string "(#*101010101012)" read)
<wingo>$1 = (#*10101010101 2)
<wingo>hahaha (call-with-input-string "#*2" read) => (#* 2)
*rlb vaguely wonders about a generative tester for read...
<rekado>wingo: I get $1 = #*
<wingo>i meant
<wingo>hahaha (call-with-input-string "(#*2)" read) => (#* 2)
<vagrantc>hrm. applying those patches fixed all but one of the tests...
<wingo>#* is a weird datum
*vagrantc double-checks to make sure the patch for that test wasn't botched
<RhodiumToad>a bitvector of length 0?
<wingo>RhodiumToad: yep
<vagrantc>ah, missed one of the tests...
<vagrantc>rlb: doh! apparently this was already fixed in guile-ssh upstream git... should have looked there first :)
<rlb>heh, oops
<vagrantc>rlb: thanks for all your help, though :)
<wingo>(call-with-input-string "#:#|foo|#bar" read)
<wingo>$1 = #:bar
*wingo glares at read.c
<RhodiumToad>oh, #|foo|# is a comment?
<wingo>yeah. and for some reason the reader skips whitespace between #: and bar
<wingo>ease of implementation i think
<spk121>all bugs are features
<spk121>also, what do you think should happen if you change the first colon in your example into a semicolon
<wingo>spk121: should happen? input-error
<wingo>unexpected EOF while reading # object
<wingo>spk121: i take it back :) #;EXPR skips EXPR as a comment
<wingo>in this case it skips the single expr #|foo|#bar
<wingo>so the result is simply EOF
<wingo>#|foo|# itself being a comment
<wingo>hey totally unoptimized, essentially untested (ice-9 read) is in the repo
<wingo>sometime soon I will run it against read.c for all .scm files in guile, to verify it does the same thing
<roelj>wingo: It's amazing to see how you've been hacking away at this for more than a week!
<fnstudio>hi, i'm having a look at and, particularly, at the syntax for creating a new module, eg `(define-module (ice-9 popen))`
<fnstudio>the fact that the module name can contain multiple keywords (in the case above `ice-9` and `popen`), is that a form of namespacing?
<fnstudio>is the idea that i can have another file where, say, `ice-9 pclose` is defined?
<fnstudio>and then there's maybe a way for importing all modules in a group (ice-9) together at the same time by just importing ice-9?
<rekado>fnstudio: no. (ice-9 popen) basically corresponds to “ice-9/popen.scm”.
<fnstudio>rekado: oh i see
<rekado>if you want to re-export things in a file “ice-9.scm” you’d have to do that manually
<rekado>you can do that, but it’s not done automatically purely based on the name
<fnstudio>could i have something like `ice-9/pipes/open.scm`?
<rekado>sure, the module name would be (ice-9 pipes open)
<fnstudio>and, if yes, would that be imported via ...
<fnstudio>you were faster
<rekado>but it’s unusual to have one module per exported definition
<fnstudio>in that case, what would i get if i imported (ice-9 pipes)?
<rekado>because you didn’t define a module called (ice-9 pipes) in ice-9/pipes.scm
<fnstudio>ah i se
<rekado>you can do that, though, and have it load (ice-9 pipes open) and re-export its bindings.
<fnstudio>(i might be wrong but that reminds me of when submodules are re-exported via Python's if i may make a comparison here)
<fnstudio>ok, that was very helpful rekado, many thanks