IRC channel logs

2014-04-17.log

back to list of logs

<joolean1>hey everybody!
<joolean1>Is anyone here trying to use Guile HEAD?
<joolean1>err, master branch HEAD
<joolean1>I'm finding that auto compilation seems to takeā€¦ forever
<mark_weaver>joolean1: what version of GC are you using? if 7.4.0, then either upgrade to the latest libgc git or set GC_MARKERS=1
<joolean1>Ah. Thanks, Mark.
<mark_weaver>np!
<joolean1>Hmmm. Now I can't seem to build Guile from source any more.
<joolean1>undefined symbol: GC_move_disappearing_link
<mark_weaver>it sounds like you haven't run ./configure since the last time you upgrade libgc.
<joolean1>Blurgh
<joolean1>Possibly not.
<mark_weaver>actually, I would rerun "autoreconf -vfi" and then "./configure" and "make clean" and "make"
<mark_weaver>there were some recent changes that require a recompile of all .go files anyway
<joolean1>Okay, that seems to have helped somewhat.
<joolean1>Although now I've obviously got to rebuild psyntax
<joolean1>Guess I'll go make a sandwich
<mark_weaver>heh :)
<mark_weaver>apparently (system vm assembler) has dethroned psyntax as the longest-time-to-compile file during bootstrap.
<joolean1>sigh
<joolean1>mark_weaver: Hmmm, I'm still having my original problem, which was that I can't seem to compile this one source file with latest Guile and latest libGC
<joolean1>it's a small file but does include some syntax-case definitions
<mark_weaver>what can't you compile? what is the error message?
<joolean1>(although some other code that also used syntax-case compiled just fine, so I don't know if that's related)
<joolean1>it just hangs (for hours)
<joolean1>CPU at 100%
<mark_weaver>well, I guess there are still problems with parallel marking. better set GC_MARKERS=1
<mark_weaver>(that's a run-time flag)
<joolean1>yeah, I did that
<joolean1>no dice
<mark_weaver>what file are you trying to compile?
<joolean1>one moment, I'll push to my project's repo
<mark_weaver>wingo has been doing some major hacking lately on master, so maybe something is broken.
<joolean1>Think it's getting hung up on this: http://git.savannah.gnu.org/cgit/gzochi.git/tree/gzochi-server/src/scheme/gzochi/private/app.scm
<joolean1>yeah, noticed he'd pushed a bunch of stuff just this afternoon
<mark_weaver>not just this afternoon, lots of stuff over the last two weeks or so.
<joolean1>right
<mark_weaver>does it work with stable-2.0 and/or 2.0.11 ?
<joolean1>haven't checked. It was working with whatever Ubuntu 13.10 packages as guile-2.0. I can checkout stable-2.0 and give it a shot.
<mark_weaver>well, it would be good to keep your guile-master working directory as-is, and just build 2.0.11 in another dir.
<joolean1>I'll let you know what I discover.
<joolean1>Thanks for all your help!
<joolean1>Okay, can do.
<mark_weaver>np! if it works in 2.0.11, then I think you should file a bug report.
<mark_weaver>and bring it to wingo's attention here.
<joolean1>Okay!
<joolean1>g'night
<mark_weaver>it would also be interesting to compile the file from within a REPL session and hit ctrl-c at some point, and see in the debugger where it is.
***linas_ is now known as linas
<nalaginrut>morning guilers~
<wingo>moin
<mark_weaver>good morning, wingo!
<mark_weaver>wingo: joolean1 reported last night that the following file causes current master's compiler to run for hours at 100% CPU: http://git.savannah.gnu.org/cgit/gzochi.git/tree/gzochi-server/src/scheme/gzochi/private/app.scm
<mark_weaver>this with GC_MARKERS=1
<wingo>nice :)
<wingo>i wonder if he can provide a one-file test case
<nalaginrut>hmm..doesn't it always 100% during compiling ?
<wingo>well this sounds like a logic bug in the compiler
<wingo>that's a small file, and if the compiler is built, it should compile in less than a second
<nalaginrut>alright
<wingo>good morning lloda
<lloda>hello wingo
<lloda>yesterday f5765cc made my mac panic :)
<lloda>it was the overflow test, it took all the memory, then it filled the disk, then it panicked.
<wingo>!!!
<wingo>that's nuts
<lloda>I needed to reboot anyway :p
<wingo>you would think that the setrlimit would, well, limit resource consumption of that test...
<lloda>may be a bug in the OS, 10.6.8 is no longer supported so...
<lloda>the panic is clearly a bug in the OS, I mean ignoring setrlimit
<wingo>i liked the part where it filled the disk too
<wingo>interesting, now i get errors in gdb's test suite because backtraces changed
<wingo>mark_weaver: you might like this...
<wingo>i get a bt like
<wingo>In /hack/binutils-gdb/+build/gdb/testsuite/gdb.guile/t-scm-error-2.scm:
<wingo> 24: 2 [top-func _]
<wingo> 27: 1 [middle-func _]
<wingo> 30: 0 [bottom-func 42]
<wingo>the _ indicates an argument that is no longer available in the frame
<wingo>whereas the test case was expecting them to be 42
<wingo>which was the argument passed...
<wingo>truly, when the compiler stops preserving the values of the closure and arguments, the backtrace becomes the continuation (the future) and not the execution trace (the past)
<wingo>i can imagine that not everyone would like that
*nalaginrut wrote a macro for multi assign https://gist.github.com/NalaGinrut/10970786
<affds>Asking again since I didn't get an answer yesterday: is there a flag that would warn me about unused imports?
<wingo>there is no such warning pass; would be a nice addition
<affds>wingo: I might try to add it. Where should I look in the source tree?
<wingo>module/language/tree-il/analyze.scm; see the manual for more on tree-il
<affds> okay, thank you.
<wingo>dje42: also interestingly it seems that gdb/guile things don't work with master on real programs due to async finalization; am adding api to disable automatic finalization, which will instead require the user to call scm_manually_run_finalizers ()
<wingo>i ran a test that runs finalizers using asyncs instead of in a thread, and that fixed gdb/guile thigns
<wingo>truly shaving a yak, i just wanted to debug v8 better :P
***sethalve_ is now known as sethalves
<mark_weaver>wingo: regarding the failing gdb tests due to the missing arguments in backtraces: I think the solution to that should be part of what we do to preserve the execution trace through tail calls: essentially to separate the backtrace from the continuation, and make the backtrace limited, a ring of rings perhaps.
<mark_weaver>wdyt?
<mark_weaver>I like the option for manual finalization, btw!
<xdje>Does guile need a -O0 vs -O2 mode?
<mark_weaver>I tend to think not, for various reasons, but it may be that we should have a mode of whether or not to keep an execution trace.
<xdje>Call it what you like. :-)
<mark_weaver>well, that's conceptually very different than disabling optimization.
<mark_weaver>and it would be a run-time mode, not a compile-time mode.
<xdje>The goal is 100% expected behaviour from a debugging POV vs a flat-out-optimization POV.
<mark_weaver>I'm sympathetic to the idea, but keep in mind that the nature of Scheme is such that trying to keep all the information around that you'd want for debugging is likely to make correct programs simply fail to work due to lack of memory.
<mark_weaver>loops are done by recursively calling yourself in tail position, and that's semantically a GOTO with arguments in Scheme.
<xdje>I realize that.
<xdje>Schemer's expect to have to cope with, it's part of the definition of the language.
<mark_weaver>also, with garbage collection, keeping data alive can mean the difference between a program with a huge space leak and one that works correctly.
<mark_weaver>so it's tricky.
<mark_weaver>there are real advantages to aggressively blackholing variables that will never again be used.
<mark_weaver>I wonder if we should look into reversible debugging.
<xdje>I realize that too ....
<xdje>Still, knobs to aid debugging would be welcome I think.
<mark_weaver>sorry, I didn't mean to imply otherwise, just spelling out the challenges...
*mark_weaver goes afk
<wingo>mark_weaver: yeah agreed, wrt the ring of rings, or whatever data structure is appropriate there
<ijp>scheme@(guile-user)> #o108
<ijp>While reading expression: ERROR: In procedure scm_lreadr: #<unknown port>:169:6: unknown # object
<ijp>I think I'll write a more error message for scm_read_number_and_radix
<ijp>more specific*
***linas_ is now known as linas
<mark_weaver>ijp: sounds good!
***wingo_ is now known as wingo