IRC channel logs
2021-02-13.log
back to list of logs
<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>(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, 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>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 <dftxbs3e>rlb, http://[2a01:e0a:2a2:1351::1ec]:19999/ <rlb>dftxbs3e: 2.2 or 3.0? <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. <rlb>Doesn't look like it. <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. <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_>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. <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>haven't reduced it down to a minimal reproducer yet <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"...) <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 <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. <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>(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>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>wingo: fix is something like this: <rlb>(let ((result (test-runner-fail-count (test-runner-current)))) <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? <vagrantc>ok, cargo-culting your suggestion seems to have worked :) <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? <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>otoh, it's not *that* big a deal - just have to wrap the final test-end in a let. <wingo>there was de5d1a7f99b8e952b115237ebc29633062f99bb9 <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>hahaha (call-with-input-string "#*2" read) => (#* 2) *rlb vaguely wonders about a generative tester for read... <wingo>hahaha (call-with-input-string "(#*2)" read) => (#* 2) <vagrantc>hrm. applying those patches fixed all but one of the tests... *vagrantc double-checks to make sure the patch for that test wasn't botched <vagrantc>rlb: doh! apparently this was already fixed in guile-ssh upstream git... should have looked there first :) <vagrantc>rlb: thanks for all your help, though :) <wingo>(call-with-input-string "#:#|foo|#bar" read) <wingo>yeah. and for some reason the reader skips whitespace between #: and bar <wingo>ease of implementation i think <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>#|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>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”. <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 ... <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 <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 __init__.py if i may make a comparison here) <fnstudio>ok, that was very helpful rekado, many thanks