***DeeEff_ is now known as DeeEff
<amz3>mark_weaver: what do you think about exporting 'open-process' from ice-9 popen <amz3>I need this to wrap a command line program that takes input in stdin and output in stdout <amz3>stdout is written only if stdin is closed so the other popen procedure don't work <wingo>it is fine with me fwiw, if you submit a doc patch <amz3>wingo: btw, I think bug 23000 is linked to port buffering... <amz3>if a client side socket is closed, and server try to read it, the program crash <amz3>but not directly when the server read the socket... <wingo>i don't think that's a guile bug -- i think in that case you need to handle SIGPIPE <amz3>ah ok good to know, I will have a look at the webserver ***dsmith-w` is now known as dsmith-work
<Bobbejaantje>srfi 18 in guile doesn't seem to export the current-thread binding probably because it's identical to Guile's own current-thread binding <Bobbejaantje>Ah yeah, the source code of the module does seem to imply as much <Bobbejaantje>Hmm, it does seem to re-export others which are in the core but not current-thread <Bobbejaantje>mark_weaver, so I should be free to just add current-thread t the re-export list locally? <mark_weaver>the commit that fixes it is 6587bcfa53f620142e4f712ad347a25e3c33a9bca <mark_weaver>Bobbejaantje: oh, wait, this fix was before the release of 2.0.11 <mark_weaver>Bobbejaantje: I guess you're using 2.0.9 or earlier? <mark_weaver>Bobbejaantje: okay. you might consider updating to 2.0.11 <davexunit>that's an oddly specific question that no one knows <Bobbejaantje>Most likely it'll be faster in some things, and slower in some others. <random-nick>also the code might be differently written depending on how fast something is in an implementation <Bobbejaantje>If you look at most benchmark tests the code is so hyper micro-optimized in a way that no sane person would ever write in that language that it just becomes a contest of "How well can this language write assembly via low-level foreign interfaces" <nalaginrut>xchat broken for me these days, fortunately I found hexchat ***dje is now known as xdje
<nalaginrut>dsmith-work: because I want an alternative to load my previous config ***lloda` is now known as lloda
<nalaginrut>ACTION realized that there're few debug functions in 2.1 while 2.0 has many <janneke>nalaginrut: i think 2.1 breakpoints are broken too <nalaginrut>but anyway 2.1 is so cool that I can't help to use <janneke>i'm not complaining...i have a couple of 2.1 patches that i'd like to get in <janneke>debugger, gnu-style error messages, but first the invalid .go skipping <janneke>all i have sits in guile-devel, some for over a year ;-) <random-nick>why aren't the default guild scripts compiled at build-time? <ecraven>I've been running the larceny r7rs benchmarks on a few different schemes, and would like to try guile too <ecraven>would you be so kind and tell me how to correctly invoke guile so it compiles a scm source file (as optimized as is useful), and how to then invoke it to use that compiled version for the benchmark? <mark_weaver>ecraven: r7rs support is not in guile yet, except on the r7rs-wip branch in our git repository, where there are still some missing bits <ecraven>mark_weaver: the tests might still run, they mainly require a couple of r7rs-specific functions (current-seconds, the jiffies stuff) <ecraven>random-nick: I'd like to compile them before the first run, so the benchmarking runs on compiled code <ecraven>great :) I'll just see how far I get with that, thank you! <mark_weaver>but yeah, "guild compile" is usually how we compile code from makefiles, etc. <random-nick>ecraven: invoking "guild compile <file>" will do the equivalent of autocompilation if you don't specify where to output <random-nick>and guile won't autocompile if it's already autocompiled in the cache <ecraven>very nice, just tried that, works well <mark_weaver>ecraven: btw, guile-2.1.x (prerelease) contains a very different VM and compiler than 2.0.x, and is much faster <ecraven>mark_weaver: oh, I thought that was released already <mark_weaver>stable releases are X.Y.Z where Y is an even number. <ecraven>how can I get the number of units for get-internal-real-time per second? <ecraven>thanks, I'll look at that branch for all the things I need <mark_weaver>ecraven: it's mostly complete, but not as comprehensively tested as I'd like <ecraven>I think the tests mostly use the time / jiffy stuff for benchmarking, apart from that the code isn't very R7RS-specific <mark_weaver>the (current-second) procedure in (scheme time) is probably not as fast as one might hope for <ecraven>probably (current-time) would be good enough? <ecraven>wow, compiling guile from source sure takes some time <random-nick>ecraven: you can read why it is compiling so long while it's compiling <davexunit>IIRC guile should now come with some pre-built compiler binaries to bootstrap with <nalaginrut>seems we may set certain environment var for it now <ecraven>whatever the archlinx PKGBUILD does :) <ecraven>however, the benchmarks seem to run fine after defining a couple of new names for r7rs procedures :) <ecraven>I'll publish the results as soon as I get everything cleaned up <davexunit>the long compile times are actually a nice thing, oddly enough. <ecraven>is guild compile sufficient, or should I pass some optimisation parameters? <davexunit>because it's indicative that guile bootstraps itself from other than a previously compiled version of itself. <davexunit>which means that guile doesn't require putting trust in yet another binary blob <ecraven>that is more nice when you're not actively waiting for it to get done :p <ecraven>no such option, probably need to wait until 2.1 is compiled? <random-nick>ecraven: at the end it should say what is the default optimisation level and what level does what <random-nick>yep looks like there are no optimisation parameters in the current stable <ecraven>random-nick: well enough, benchmarks are what they are, it's just to get a feeling for what is what <wingo>paroneayea: what bug are you getting? <wingo>which guile, and do you have a backtrace? <wingo>abort() should only indicate internal errors <wingo>but if you do "ulimit -c unlimited" in your shell before running guile <wingo>then it will dump core and then you can "gdb guile core" to open the core in gdb <paroneayea>wingo: I'm getting a SIGABRT in the actor model system I'm using on top of 8sync <wingo>an abort() still sounds bad :) <paroneayea>the actor model builds on top of 8sync and allows actors to "reply" to each other with messages <paroneayea>as such, there are two levels deep of delimited continuations :) <paroneayea>one for 8sync, one for messages waiting on reply <paroneayea>those are stored by the system until a reply comes back <paroneayea>if a message gets replied to and its coroutine resumes <paroneayea>*if* there's something trying to catch the error beyond the delimited continuation prompt <paroneayea>but I only know how to reproduce it within 8sync :) <paroneayea>I've tried making a more paired-down version of the problem <wingo>paroneayea: a backtrace would be close to good <paroneayea>wingo: ok, so you said ulimit -c unlimited, then run it and get the sigabrt <wingo>paroneayea: that will dump core <wingo>meaning it creates a file called core <wingo>then you open it up in gdb and get a backtrace <wingo>if your guile is built with debugging symbols, anyway :) <paroneayea>wingo: ok, want me to make the smallest version of this I can, or should I just give you the current error I'm hitting? :) <paroneayea>I'm not sure it is, it's whatever one is from guix <wingo>just send the thr apply all bt and we'll see <wingo>paroneayea: so now you "gdb guile core" <wingo>then send that to bug-guile, with whatever context you would like to include :) <paroneayea>ACTION still hitting "return" and is at line #8672 of the backtrace stil... <wingo>it shouldn't be that long :) <wingo>but it's interesting to know that it's that long <ecraven>but the results for guile 2.0 are in :) <paroneayea>wingo: "at least it only happens on an error" but it would be nice to have it fixed esp because live hacking the actor model system, I expect I'll make errors and fix them as the system is running :) <ecraven>no guarantees, I didn't verify things a lot <ecraven>except for the second, that's just "number of wins" <ecraven>as soon as guile 2.1 git finishes building (at system/repl/debug.go now), I'll try to run that too <ecraven>as I said, things need to be verified a lot more, but this gives some kind of basic impression <random-nick>ecraven: are the lines starting with GUILEC or BOOT GUILEC now? <ecraven>it's a fast machine, but I guess arch is running make -j1 <wingo>paroneayea: so, frames 28 and 29 of your bt: <wingo>#28 0x00007f505360db42 in scm_misc_error () <wingo> from /gnu/store/hyk2i7b8mwbrbiyqk5sgrfgds9zvcrn5-guile-2.0.11/lib/libguile-2.0.so.22 <wingo>#29 0x00007f5053606602 in scm_c_abort () <wingo> from /gnu/store/hyk2i7b8mwbrbiyqk5sgrfgds9zvcrn5-guile-2.0.11/lib/libguile-2.0.so.22 <wingo>#30 0x00007f5053689741 in vm_abort () <wingo>that would indicate to me that there is something wrong, that you are failing to abort to a prompt <wingo>probably it means that in the pre-unwind handler you have installed, <wingo>you are aborting to a prompt that might not be active <wingo>and of course that recurses and recurses forever <wingo>and the abort happens because stack overflow <wingo>and specifically, not just stack overflow, but stack overflow was already raised but not unwound because of this issue <wingo>and so you've overflowed within the limited overflow buffer (these are 2.0 concepts) and there's no space in which to handle the exception any more, so abort(0 <paroneayea>the pre-unwind-handler (I checked) came from the first time it was raised <paroneayea>and I assume whatever it's setting up to "catch" the error (even though when I re-initialize the coroutine) probably is too <wingo>i am not quite following you. i just wanted to point out the immediate cause of the abort <wingo>which is that some pre-unwind handler is trying to abort to a prompt that is not active <ecraven>compilation done, running the benchmarks now :) <paroneayea>wingo: would the pre-unwind-handler abort to a prompt normally as it exits, even if there's no specific call to abort to a prompt from within there? <paroneayea>I don't know what happens when the pre-unwind-handler leaves... is jumping to a "catch" itself aborting to a prompt? <wingo>paroneayea: yes, "throw" will abort to a prompt established by "catch". i doubt there is a bug in "throw" but it's possible i guess <ecraven>interesting, 2.1 seems to be slower *and* faster than 2.0, on different benchmarks <ecraven>I'll post new results when the tests are done <ecraven>wingo: any parameters I should give guild compile? <wingo>ecraven: i think the defaults are fine <wingo>we haven't done any optimizations to r6rs in 2.1/2.2, and there are some that could be done <wingo>especially around integer and float operations <paroneayea>I've got a catch-all outside of the prompt I'm using for the coroutine. the coroutine gets stored, and later re-awoken <ecraven>I'm just faking it, basically, removing the INCLUDE and hoping all necessary identifiers are visible :) <paroneayea>it tries to be caught by the catch-all that was originally from before the suspended (and saved) coroutine <paroneayea>and so the pre-unwind-handler works fine but the catching prompt it tries to jump to <wingo>ecraven: sounds like fun :) benchmarks are a nice way to stir the pot :) <ecraven>wingo: hehe, well, I'll need to make sure the results are really valid before they can be trusted <wingo>paroneayea: so is it a bug on your side then, that you don't re-instate the catch-all when reinstating the coroutine? <wingo>not sure from the description <wingo>ecraven: yeah it's an easy way to make a lot of people mad at you too! i hope guile folks will take it all in the spirit of good fun tho ;) <paroneayea>wingo: we do reinstate a catch-all sorta, but it's outside of where the coroutine resumes <paroneayea>(catch (lambda () (resume-coroutine)) (lambda _ (display "got it\\n"))) <paroneayea>not the new one I'm wrapping it with when I resume it <wingo>well, i catch it tomorrow. night :) <ecraven>wingo: not yet, I'll probably post it tomorrow morning :)