<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>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") <gchristensen>atw: wow! thank you so much! I'll give this patch a try. <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>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: 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>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 <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>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 <wingo>can you grep libguile/Makefile for CFLAGS <wingo>just to see if -O2 is there or not <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
<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 <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>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? <OrangeShark>they shouldn't be surprised that RMS would block it. ***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 <OrangeShark>is there anything else needed to be done on guile side? <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? <daviid>from a strategic point of view though, it does not make much sence not to priviledge this route <dsmith-work>wingo: And that with for x in $(seq 200); do ./check-guile asyncs.test; done <daviid>OrangeShark: better confirm with paroneayea (there are more then a branch) <paroneayea>OrangeShark: so my understanding is that the rebase worked, but wingo wanted to review the code before merging <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 <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! :)