Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

errors inside macros give incorrect line numbers #7

Closed
mlubin opened this issue Apr 8, 2013 · 13 comments
Closed

errors inside macros give incorrect line numbers #7

mlubin opened this issue Apr 8, 2013 · 13 comments

Comments

@mlubin
Copy link
Member

mlubin commented Apr 8, 2013

In dummy.jl:

using MathProg
m = Model("max")
@setObjective(m, z)

Then:

$ julia dummy.jl 
ERROR: z not defined
 in include_from_node1 at loading.jl:92
 in process_options at client.jl:250
 in _start at client.jl:329
at /home/mlubin/.julia/MathProg/test/dummy.jl:139
@IainNZ
Copy link
Collaborator

IainNZ commented Jun 21, 2013

The 'true' issue is JuliaLang/julia#1334, still open

@mlubin
Copy link
Member Author

mlubin commented Sep 4, 2015

Unfortunately not fixed after JuliaLang/julia#12544:
After a slight syntax update, dummy.jl becomes

using JuMP
m = Model()
@setObjective(m, Max, z)

and I get

ERROR: LoadError: UndefVarError: z not defined
 in include at ./boot.jl:260
 in include_from_node1 at ./loading.jl:271
 in process_options at ./client.jl:308
 in _start at ./client.jl:411
while loading /home/mlubin/dummy.jl, in expression starting on line 584

@leotac
Copy link
Contributor

leotac commented Sep 17, 2015

Ouch, no luck on this yet? It's rather annoying :(

@mlubin
Copy link
Member Author

mlubin commented Sep 17, 2015

We may have to restructure the macros to take advantage of the recent improvements, but I haven't looked into it.

@mlubin
Copy link
Member Author

mlubin commented Oct 2, 2015

@ihnorton, I didn't follow all of the nuances of JuliaLang/julia#12544, but what do we have to do in JuMP to get call site line numbers reported correctly?

@ihnorton
Copy link

ihnorton commented Oct 2, 2015

You want it to report UndefVarError on line 3, correct?
Can I just do Pkg.add("JuMP") and run your example?

To clarify, 12544 is about getting correct line numbers when generated code throws an error. If I am understanding the situation here, the error is being thrown during macro expansion, so none of the generated code is actually running yet. See the second part of my comment here about errors during macro expansion (can't throw across the flisp stack). This PR is relevant, although I think I might be able to get you UndefVarError on line 3 without it (or with a much less intrusive version -- only annotate on the flisp side).

@mlubin
Copy link
Member Author

mlubin commented Oct 2, 2015

Yes, the example should run with vanilla JuMP.
On Oct 2, 2015 5:52 PM, "Isaiah" notifications@github.com wrote:

You want it to report UndefVarError on line 3, correct?
Can I just do Pkg.add("JuMP") and run your example?

To clarify, 12544 is about getting correct line numbers when generated
code
throws an error. If I am understanding the situation here, the
error is being thrown during macro expansion, so none of the generated code
is actually running yet. See the second part of my comment here
JuliaLang/julia#8701 (comment)
about errors during macro expansion (can't throw across the flisp stack). This
PR JuliaLang/julia#13339 is relevant, although
I think I might be able to get you UndefVarError on line 3 without it (or
with a much less intrusive version -- only annotate on the flisp side).


Reply to this email directly or view it on GitHub
#7 (comment).

@mlubin
Copy link
Member Author

mlubin commented Oct 2, 2015

@ihnorton, the error is at run time, not macro expansion.

@ihnorton
Copy link

ihnorton commented Oct 4, 2015

Thanks. With the simplified example, 12544 doesn't apply because the error is being thrown by the interpreter. JuliaLang/julia#13444 should help there.

I assume you also want to use these macros inside of functions, where 12544 would apply, however, the location will still be off because I haven't figured out how to track the top-level location properly with nested locations, so right now we just default to the starting line number of the function body.

@mlubin
Copy link
Member Author

mlubin commented Oct 4, 2015

I definitely get a better backtrace when I put the code into a function:

using JuMP
function foo()
    m = Model()
    @setObjective(m, Max, z)
end
foo()

gives

ERROR: LoadError: UndefVarError: z not defined
 [inlined code] from /home/mlubin/.julia/v0.4/JuMP/src/macros.jl:602
 in foo at /home/mlubin/dummy.jl:601
 in include at ./boot.jl:261
 in include_from_node1 at ./loading.jl:304
 in process_options at ./client.jl:308
 in _start at ./client.jl:411
while loading /home/mlubin/dummy.jl, in expression starting on line 7

Though it's pointing to line 601 from dummy.jl which doesn't exist, it's macros.jl:601.

@ihnorton
Copy link

ihnorton commented Oct 5, 2015

With JuliaLang/julia#13431 that should show as dummy.jl:3. Clearly that's still off by one -- it's the function start rather than the actual line, as per my comment above -- but at least on a line that actually exists!

@mlubin
Copy link
Member Author

mlubin commented Oct 19, 2015

@ihnorton, on master I'm now getting:

ERROR: LoadError: LoadError: UndefVarError: z not defined
 [inlined code] from /home/mlubin/.julia/v0.5/JuMP/src/macros.jl:584
 in foo at /home/mlubin/dummy.jl:4
 in include at ./boot.jl:261
 in include_from_node1 at ./loading.jl:384
 [inlined code] from ./operators.jl:313
 in process_options at ./client.jl:277
 in _start at ./client.jl:377
while loading /home/mlubin/dummy.jl, in expression starting on line 6
while loading /home/mlubin/dummy.jl, in expression starting on line -1

@mlubin
Copy link
Member Author

mlubin commented Nov 22, 2016

This seems to basically be fixed now? If we find another instance of bad backtraces we can open a new issue.

@mlubin mlubin closed this as completed Nov 22, 2016
mlubin added a commit that referenced this issue Mar 11, 2018
use NaNMath package to return NaNs instead of throwing DomainErrors
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

4 participants