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

Breakpoint-like use-cases #33

Open
timholy opened this issue Aug 23, 2018 · 12 comments
Open

Breakpoint-like use-cases #33

timholy opened this issue Aug 23, 2018 · 12 comments

Comments

@timholy
Copy link
Owner

timholy commented Aug 23, 2018

Feel free to contributed examples directly to this issue. For use-cases that are described externally, here's a list of links:

@pfitzseb
Copy link
Contributor

Imho Gallium's breakpoint handling was quite nice (when it worked):
https://github.com/Keno/Gallium.jl/tree/v0.0.4#breakpointing-options

Most of those could probably be implemented in Rebugger in some fashion, I think, although I'm quite unfamiliar with the internals. And if not then it should be fairly trivial to implement with Cassette: Just prehook the relevant methods/functions (or all of them and then check @__LINE__) and throw an exception that Rebugger can catch.

@timholy
Copy link
Owner Author

timholy commented Aug 26, 2018

Maybe an @enterif(condition, expression) to conditionally step-in (one would insert this into a method-body that one is already rebugging).

@mattcbro
Copy link

mattcbro commented Sep 6, 2018

I think some kind of @Enter macro would still be useful for programmatic debugging. I'm finding it a bit of a pain to type a function call in the REPL and position the cursor to the first character of the function, and then typing alt-e.

I also still haven't quite figured out how to view variables consistently. I think I have to insert an @show into the code, however things seem to always mess up when I try this. For one it doesn't seem possible to insert a new line in the code one is about to execute.

Oh one more thing. The documentation desperately needs to point out that nothing works until you do an includet("filename.jl") on your code. This fact is buried somewhere at the end. It should be shown in the usage examples.

Nevertheless I am grateful for this first start at debugging in Julia 1.0. Will this become the defacto debugging utility?

@timholy
Copy link
Owner Author

timholy commented Sep 7, 2018

I also still haven't quite figured out how to view variables consistently. I think I have to insert an @show into the code, however things seem to always mess up when I try this.

Works for me, could this be confounded by #44? Try it on short functions first.

For one it doesn't seem possible to insert a new line in the code one is about to execute.

Just hit Alt-Enter (https://docs.julialang.org/en/latest/stdlib/REPL/#Key-bindings-1).

You also have to get used to the REPL's rules about navigating history vs. editing a line (hint: the right and left arrows are your friend), but that's not specific to Rebugger.

The documentation desperately needs to point out that nothing works until you do an includet("filename.jl") on your code.

A PR would be gratefully accepted. One small correction, however, your statement is true only if you write "scripts" rather than "packages." (By packages I mean something you can load with using or import.) I organize almost all my "serious" code into packages and only use scripts to, e.g., load, process, and generate figures for particular data sets.

@timholy
Copy link
Owner Author

timholy commented Sep 7, 2018

Agreed, though, that Rebugger needs more functionality. I am pretty occupied with improvements to Revise now (which underpins Rebugger), but I will get there eventually.

@goretkin
Copy link

I am not sure if this falls into the use case here, but I'd love to add Rebugger.breakpoint() to somewhere inside a function, re-run my code, and get thrown into a REPL in the scope of the breakpoint call.

@mattcbro
Copy link

I am not sure if this falls into the use case here, but I'd love to add Rebugger.breakpoint() to somewhere inside a function, re-run my code, and get thrown into a REPL in the scope of the breakpoint call.

Agreed. Such a functionality would be extremely helpful in lieu of setting breakpoints.

I was thinking about how to write something like this myself. While Julia does have a parser, it evaluates in the module global scope. Thus you can't even assign local variables, only globals that have already been assigned. I'm not sure how to make the local function scope visible to Julia. Rebugger must have figured that out.

@timholy
Copy link
Owner Author

timholy commented Nov 20, 2018

You can do this now, just insert error("oops") into the method and use Alt-S.

@mattcbro
Copy link

You can do this now, just insert error("oops") into the method and use Alt-S.

Really? Does Rebugger redefine error? Also pardon my ignorance but what does Alt-S do? Is that a Rebugger keyboard shortcut?

@pfitzseb
Copy link
Contributor

No, error just throws an error :) See the docs for details.

@goretkin
Copy link

goretkin commented Nov 28, 2018

This is a fringe use-case, but this doesn't appear to work if you're includeing a file that calls the method with the error call.

@timholy
Copy link
Owner Author

timholy commented Nov 28, 2018

Yes, you need to let the include succeed. But then you can edit the method to add the error, then call it from the REPL.

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

4 participants