in lookup_ref: new not defined

[stefan-k]

Just pulled fd51447, did make clean && make and now I'm getting this error right after starting Julia:

julia> in lookup_ref: new not defined
in lookup_ref at /home/stefan/coding/juliafork/jl/multi.jl:340
in take_ref at /home/stefan/coding/juliafork/jl/multi.jl:663
in take at /home/stefan/coding/juliafork/jl/multi.jl:676
in run_repl at /home/stefan/coding/juliafork/jl/client.jl:90
in _start at /home/stefan/coding/juliafork/jl/client.jl:213

Any ideas? I'm running Arch Linux.

[StefanKarpinski]

I can't reproduce this on OS X.

[Keno]

Hmm, I see the same error on Ubuntu. I'll try to debug.

[JeffBezanson]

I'm on 32-bit ubuntu 11.10 and I don't see this...strange.

[Keno]

Something super strange just happened. I had to do something else for a minute on a different computer (well, actually a different VM) and when I came back it suddenly worked again ... I can't explain to myself how that could happen. @stefan-k could you try to do a complete rebuild of Julia and all the dependencies?

[pao]

You can't see me type git bisect bad because my terminal is hosed, but the bisect blames cfcc147.

julia> in lookup_ref: new not defined
 in lookup_ref at /home/patrick/julia/jl/multi.jl:340
 in take_ref at /home/patrick/julia/jl/multi.jl:663
 in take at /home/patrick/julia/jl/multi.jl:676
 in run_repl at /home/patrick/julia/jl/client.jl:90
 in _start at /home/patrick/julia/jl/client.jl:213
patrick@lubuntu-vm:~/julia$ cfcc1477f3a0233ec1262fd723661bf01ced7eba is the first bad commit
commit cfcc1477f3a0233ec1262fd723661bf01ced7eba
Author: Stefan Karpinski <[email protected]>
Date:   Tue Mar 13 13:08:54 2012 -0400

    Finally close #328. This took deep meditation.

    Sorry that took so long, Jeff.

:040000 040000 d7a05c51c0d6eb5a4ca80082b807ef20a8491975 739167aecd8f9be2ce760c5134f3b2a218e388bd M      jl
patrick@lubuntu-vm:~/julia$ 

[Keno]

Nevermind my comment. I accidentally used an old build that I had lying around. Still broken :(. But at least it's reproducably still broken.

[Keno]

I can confirm @pao's analysis of which commit broke it (which would also explain why I didn't see this in my normal fork). I'll have a look at what's going wrong here.

EDIT: Also, the terminal issue comes from the fact that the terminal isn't deprepped when Julia encounters an exception. SHould be easily fixed by allowing libradline to deprep at the very end of the program

[nolta]

Weird, everything works fine for me.

[Keno]

what OS are you on? I have no idea what causes the problem (that is why the problem exists, I know what line causes it (see cfcc147)). Could this have something to do with 32 vs 64 bit?

[nolta]

Ubuntu 11.10 (i686) & Fedora 14 (x86_64), so it's not a 32/64-bit problem, at least for me.

[pao]

Linux lubuntu-vm 3.0.0-16-generic #28-Ubuntu SMP Fri Jan 27 17:44:39 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux (Ubuntu 11.10) & not working (see above).

[Keno]

I mentioned in the pull request that the problematic line was showln(x)=(show(x);println()). Now, I tried a few alternatives, but they are all also broken:

test(x)=(show(x);println())
showln(x)=(show(x);print('\n'))
function showln(x)
    show(x)
    print('\n') #same with println
end

For compleness, I should note that the same line works just fine in my fork (which doesn't have process.jl however). I am truly stomped here.

[pao]

I think the key is the definition of print(). If I add a zero-argument print() fallback, all is well. So this may be something to do with varargs?

[StefanKarpinski]

There's something really messed up here. Maybe a weird memory bug. Going to have to bust out the Valgrind on this.

[JeffBezanson]

I traced this to a possible bug in femtolisp; basically one of the lowering functions in julia-syntax.scm was effectively returning its argument instead of its result. But, it is very sensitive and any perturbation of the input code or lowering code puts the heap in a slightly different state that avoids the problem. I think it would take too long to fully track down, and we should try to ignore it, and eventually replace the front-end with one written in julia anyway.