Please say it isn't so...  :-(   (Is there an emoticon for "deeply unhappy"?) 
But I won't shoot the messenger :-).

Anyway, I'm using v0.3.0-rc4 also, but on Kubuntu 14.04. Can you file an issue, 
please?

--Tim

On Monday, August 18, 2014 08:58:12 AM Martin Klein wrote:
> Hm, this is strange. I'm using julia 0.3.0-rc4 and I'm getting the
> truncated backtrace shown above. I've compiled Julia from Git by checking
> out the v0.3.0-rc4 tag. This is on Debian Testing. Any ideas what is
> happening here?
> 
> Am Montag, 18. August 2014 17:18:51 UTC+2 schrieb Tim Holy:
> > This has been fixed in julia 0.3.
> > 
> > --Tim
> > 
> > On Monday, August 18, 2014 06:42:56 AM Martin Klein wrote:
> > > Hi,
> > > 
> > > I have the following problem, which makes debugging of my self-written
> > > module quite difficult. When an exception is thrown inside my module,
> > 
> > the
> > 
> > > backtrace won't include the position of the error inside my module, but
> > > only the position where I call the function in my module. The following
> > > simple example illustrates the problem:
> > > 
> > > module ErrorTest
> > > 
> > > export foo
> > > 
> > > function foo(x)
> > > 
> > >     # trigger exception
> > >     println(y)
> > > 
> > > end
> > > 
> > > end #module
> > > 
> > > 
> > > Then when I'm using this module in run.jl:
> > > 
> > > using ErrorTest
> > > 
> > > foo(5)
> > > 
> > > 
> > > I get the following backtrace:
> > > ERROR: y not defined
> > > 
> > >  in include at ./boot.jl:245
> > >  in process_options at ./client.jl:285
> > >  in _start at ./client.jl:354
> > >  in _start at /usr/local/bin/..//lib/julia/sys.so
> > > 
> > > while loading /home/martin/test/run.jl, in expression starting on line 3
> > > 
> > > As you can see, the backtrace doesn't reach into the module ErrorTest,
> > 
> > so I
> > 
> > > don't get any information in which part of ErrorTest the error occurs
> > 
> > (i.e.
> > 
> > > line 6 in my example). For larger and complicated modules, this makes
> > > debugging nearly impossible, since I don't even get information in which
> > > function in my module the error occurs. I'm currently using v0.3-rc4. Is
> > > this a bug or intented behaviour? I couldn't find any bug report about
> > > this. If this is intended, what is your usual approach to obtain a
> > 
> > detailed
> > 
> > > backtrace when an error occurs inside a module?
> > > 
> > > Thanks,
> > > Martin

Reply via email to