IRC channel logs


back to list of logs

<gchristensen>Hi, I'm a packager with NixOS. We periodically see failures from Guile's test suite when the host is under heavy load. One warning we see is "warning: call to primitive-fork while multiple threads are running further behavior unspecified. See "Processes" in the manual, for more information.". Is this something we're doing wrong when calling the tests?
<gchristensen>here is one such failure, if someone could be so kind as to look at it:
<gchristensen>it looks like this is the actually failing test: FAIL: 00-repl-server.test: repl-server: simple expression - arguments: (expected-value "scheme@(repl-server)> $1 = 42\\n" actual-value "$1 = 42\\n")
<atw>gchristensen: I'm no authority, but it looks like Ludo Courtès (civodul) put in a potentially relevant fix recently:
<gchristensen>atw: wow! thank you so much! I'll give this patch a try.
<atw>gchristensen: haha, I stumbled into it. I went to and that commit was the head of the "stable-2.0" branch. Pure dumb luck!
<gchristensen>ACTION gives it a test
<gchristensen>well it hasn't made things worse, yet, but it is hard to know until I get it in to the real build infra.
<gchristensen>atw: with race conditions like this it is hard to know if it is actually fixed, but it did pass :) thank you@
<atw>gchristensen: happy to be of service ☺
<sapientech>is accessing a record field any slower than calling a procedure?
<sapientech>nvm above q :)
<sapientech>civodul: in monads.scm, how does the macro being a syntax transformer make w/monad run faster?
***holomorp1 is now known as holomorph
<sapientech>so im assuming with this design the expander grabs the inline monad fields and inline's them?
<sapientech>and if so, you are saving a call to (monad-ret monad)?
<sapientech>better-monads.rkt chooses the latter approach btw
<sapientech>how does the %s/macro/monad being a syn transformer ...
<ecraven>wingo: fyi, new run for the benchmarks is online
<wingo>ecraven: from git master?
<wingo>ACTION looks
<wingo>ecraven: did you year about the embarrassing bug in the last release
<wingo>autoconf tomfoolery led us to always use the backup atomic variables that serialize access through a mutex
<wingo>instead of actual atomic ops
<wingo>3x slowdown on tight loops :P
<wingo>oh good, it is latest git
<wingo>yay back to good numbers
<wingo>thank you ecraven
<wingo>except for ctak, oddly
<wingo>i think some of these tests are unhappily variable
<ecraven>wingo: just ping me if I should rebuild from git and run again :)
<wingo>ecraven: you are very kind, thank you :)
<wingo>and these are results with the new handle-interrupts instruction. neat.
<wingo>we should be doing a benchmarking dashboard of our own tho :P
<ecraven>hehe, everything you need should be in that github
<ecraven>except for the code to generate the html, that is so ugly I'm a bit embarassed to publish it :)
<ecraven>though I've been wanting to create a better framework for running the benchmarks (and also the coverage tests), which also gives you a way to look at the exact error output for faulty runs, so you can find out what actually went wrong more easily
<civodul>Guile 2.1 is often quite close to implementations that do native compilation
<ecraven>hm.. it might be interesting to add petite chez to that benchmark list
<ecraven>ah, it's already there
<wingo>i think we need to be tracking our results over time
<wingo>we make changes that we think are good but we aren't scientific about it
<wingo>when i used to work on web browsers things were much more sciency
<wingo>but, i appreciate the freedom to make changes that search for a new local maximum rather than looking harder for the current local maximum :)
<medfly>Hi! I'm having some trouble with building guile 2.0.12 (and 2.0.13 fails for a different reason earlier)
<wingo>hello :)
<medfly>This is the tail of my build log:
<wingo>medfly: what platform?
<medfly>This is on netbsd
<wingo>what compiler?
<wingo>and did you compile explicitly with any CFLAGS, even "" ?
<wingo>evidently guile can run for you, because it runs at the last stage of the libguile/ build
<medfly>I'll try gcc and no CFLAGS. my default sets it to -O2
<wingo>i suspect that you compiled with -O0 or with a CFLAGS set, and your compiler allocated too much stack space for the VM engine, and the initial compilation of eval.go which uses C stack ran out of C stack. but that would only be the case for -O0 tho
<wingo>that was just a guess, maybe it's not right :) does the bdw-gc test suite pass for you ("make check" in bdw-gc?)
<wingo>i mean the bdw-gc library that guile depends on
<wingo>what compiler were you using, out of curiousity?
<wingo>looks like a recent clang but i can't tell
<medfly>It is a recent clang, yes.
<medfly>3.8 something
<wingo>can you grep libguile/Makefile for CFLAGS
<wingo>just to see if -O2 is there or not
<medfly>this is the result of grepping for CFLAGS:
<medfly>I guess it's mostly absent
<wingo>well you do have -O2
<wingo>so, my hypothesis is wrong :)
<wingo>i guess you build libgc with threads enabled and are also building guile with threads enabled?
***logicmoo is now known as dmiles
<medfly>Oh, I'm not!
<medfly>I'll try with
<medfly>no for both, apparently
<wingo>that's interesting but the important thing is for both to be the same
<lloda>I have this weird bug where (import (x y z)) works but ,re (x y z) fails with ERROR: In procedure primitive-load-path: Unable to find file "x/y/z.scm" in load path
<lloda>what reason could there be?
<wingo>lloda: (pk (module-filename (resolve-interface '(x y z))))
***karswell` is now known as karswell
<davexunit>bah, the emacs forking situation is troubling.
<davexunit>dan wants to add an LLVM JIT, completely ignoring all of the guile-emacs progress over the years.
<holomorp1>davexunit: what progress would that be ignoring? *clueless*
<davexunit>holomorp1: the fact that there is a version of emacs that runs on guile.
<davexunit>it's not a nice idea, it's there and it works. it needs more work, but it's a real thing.
<davexunit>ignoring that and jumping on the LLVM train because it's hip is a bad move.
<davexunit>but then again this same person wants to add javascript extension support to emacs.
<holomorp1>ehh, i remember seeing javascript mentioned in these threads, but not an intention to add it
<lloda>wingo: that returns #f... I saw that there was a compilation error, I fixed it and now it's fine, but ,re () gave me that weird error instead...
<OrangeShark>davexunit: where are they discussing about adding LLVM JIT?
<davexunit>OrangeShark: the person forking plans to add it
<davexunit>to their fork, not to GNU emacs
<davexunit>I partially blame Eli for this development. he puts the brakes on everything.
<OrangeShark>So they want to use LLVM JIT for elisp in their fork?
<davexunit>they are mad that RMS has blocked it
<OrangeShark>they shouldn't be surprised that RMS would block it.
<holomorp1>that's because llvm is not copyleft, right?
***holomorp1 is now known as holomorph
<OrangeShark>not sure so much that, but rather to keep with projects in GNU, I thought gcc also had some similar JIT feature?
<daviid>I don't get it they don't help with guile-emacs instead of going for an llvm
<daviid>the lwn article even mentions guile-emacs
<dsmith-work>Thursday Greetings, Guilers
<dsmith-work>wingo: Building now..
<OrangeShark>is there anything else needed to be done on guile side?
<OrangeShark>for guile-emacs
<daviid>OrangeShark: I think so yes, but not my domain, paroneayea rebased it on master i think, but that is about all I know ...
<OrangeShark>daviid: ah okay, so the changes are in a branch on guile?
<dsmith-work>wingo: Work For Me
<wingo>dsmith-work: excellent
<daviid>from a strategic point of view though, it does not make much sence not to priviledge this route
<daviid>OrangeShark: wip-elisp I think
<dsmith-work>wingo: And that with for x in $(seq 200); do ./check-guile asyncs.test; done
<wingo>dsmith-work: excellent :)
<daviid>OrangeShark: better confirm with paroneayea (there are more then a branch)
<OrangeShark>daviid: ok
<paroneayea>OrangeShark: so my understanding is that the rebase worked, but wingo wanted to review the code before merging
<paroneayea>because it made some major compiler changes
<paroneayea>that's the last I heard
<OrangeShark>paroneayea: ah okay, was there anything else needed to be done to get it working or is it mostly complete?
<paroneayea>OrangeShark: there's lots to do, and even pre review
<paroneayea>you can try to work on the issues, written by bipt here:
<lluis>hello guilers!
<lluis>is there any API to take a list and compile it into a procedure? I know about eval/primitive-eval, but want to enable all the optimization flags available in system/base/compiler
<lluis>yuo, I used compile, but either it thinks it's compiling a list object representation into a list object, or I don't unrestand what's happening
<lluis>when I call the result, I get an error: Wrong type to apply: (lambda () ... all my code here ...)
<lluis>sorry, that was all my complete fault...
<[df]>lluis: you got it working then? :)
<lluis>df: yes, it was an error on my side; thx! :)