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

Error rebugging function when cursor is not positioned over the first character. #4

Open
roberthoenig opened this issue Aug 12, 2018 · 5 comments

Comments

@roberthoenig
Copy link
Contributor

roberthoenig commented Aug 12, 2018

julia> abs(2)

To rebug this, the cursor currently must be positioned on the a.
If it's on e.g. the b, an error is thrown:

julia> a┌ Error: Error in the keymap
│   exception =
│    UndefVarError: abegin not defined
│    Stacktrace:
│     [1] top-level scope
│     [2] eval(::Module, ::Any) at ./boot.jl:319
│     [3] stepin(::Base.GenericIOBuffer{Array{UInt8,1}}) at /home/robert/.julia/packages/Rebugger/QDOWe/src/debug.jl:110
│     [4] stepin(::REPL.LineEdit.MIState) at /home/robert/.julia/packages/Rebugger/QDOWe/src/ui.jl:91
│     [5] (::getfield(Rebugger, Symbol("##16#18")))(::REPL.LineEdit.MIState, ::REPL.LineEditREPL, ::Vararg{Any,N} where N) at /home/robert/.julia/packages/Rebugger/QDOWe/src/ui.jl:217
│     [6] #invokelatest#1 at ./essentials.jl:686 [inlined]
│     [7] invokelatest at ./essentials.jl:685 [inlined]
│     [8] (::getfield(REPL.LineEdit, Symbol("##27#28")){getfield(Rebugger, Symbol("##16#18")),String})(::Any, ::Any) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.0/REPL/src/LineEdit.jl:1319
│     [9] prompt!(::REPL.Terminals.TextTerminal, ::REPL.LineEdit.ModalInterface, ::REPL.LineEdit.MIState) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.0/REPL/src/LineEdit.jl:2353
│     [10] run_interface(::REPL.Terminals.TextTerminal, ::REPL.LineEdit.ModalInterface, ::REPL.LineEdit.MIState) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.0/REPL/src/LineEdit.jl:2256
│     [11] run_frontend(::REPL.LineEditREPL, ::REPL.REPLBackendRef) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.0/REPL/src/REPL.jl:1029
│     [12] run_repl(::REPL.AbstractREPL, ::Any) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.0/REPL/src/REPL.jl:191
│     [13] (::getfield(Base, Symbol("##720#722")){Bool,Bool,Bool,Bool})(::Module) at ./logging.jl:311
│     [14] #invokelatest#1 at ./essentials.jl:686 [inlined]
│     [15] invokelatest at ./essentials.jl:685 [inlined]
│     [16] macro expansion at ./logging.jl:308 [inlined]
│     [17] run_main_repl(::Bool, ::Bool, ::Bool, ::Bool, ::Bool) at ./client.jl:330
│     [18] exec_options(::Base.JLOptions) at ./client.jl:242
│     [19] _start() at ./client.jl:421

It'd be great if rebugger worked with the cursor positined at any character of the function name.

@timholy
Copy link
Owner

timholy commented Aug 12, 2018

I think this is a good idea. However, I worry a bit about distinguishing things like this (imagine your cursor is positioned on the l in float):

julia> x = 1.2
1.2

julia> 2float(x)    # means the same thing as 2*float(x)
2.4

julia> int2float(x)   # references a method 
ERROR: UndefVarError: int2float not defined
Stacktrace:
 [1] top-level scope at none:0

So while you're backing up do you include the 2 or not?

Worst-case scenario I can throw a nicer error. Not quite sure what's best here.

@roberthoenig
Copy link
Contributor Author

roberthoenig commented Aug 13, 2018

Hmm, I see. I'm not familiar with the internals of Rebugger, but I thought that it'd work with Expr objects of the actual code? Your comments seems to suggest that rather, it does string-parsing. If that's the case, I think parsing the actual expression would be a more robust approach that'd allow Rebugger too see in the case of 2float(x) that it should rebug only the float, and in the case of int2float, that it should rebug the whole int2float, if that makes sense.

@oxinabox
Copy link
Contributor

It would be nice if rebugger did something sensible rather than throw this error.
Even if it was just throw a more descriptive error

@timholy
Copy link
Owner

timholy commented Jan 22, 2019

The best way to solve this would be to parse the complete input line. But because parsing doesn't provide any mechanism to then match expressions/symbols/whatever to the position in the input string, it's not entirely obvious how you go about aligning the two.

@oxinabox
Copy link
Contributor

oxinabox commented Jan 22, 2019

CSTParser.jl should provide that information, but it's docs are sparse (and it is a big dep).
Maybe just tokenize the line with Tokenizer.jl?

Or as a quick hack use a regex to go backward til you hit a non-letter

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants