[ANN] Juno 0.8

pfitzseb · March 29, 2019, 8:23pm

There actually is no Juno.jl 0.8.2 – just pkg> up and update the Atom packages and you should be good to go.

The version number I’m usually referring to is that of julia-client and Atom.jl, but I can see how that might be confusing.

zsykm · April 13, 2019, 2:37pm

After I went through all your posts carefully and it still took me for quite a while to make all the features you mentioned work.
I have to say thank you all who involved in the development. Nice job!
And I cannot stop thinking things could be a little bit easier when you need to debug, especially to set a breakpoint.
Why don’t the IDE, Juno, to handle all the
using Revise
includet(“thefile/totest.jl”), and
juno.@run
thing? To know all these stuffs could be cool, but … what’s the point? I just want to know what happened to my code. All these configuration stuffs should be done even unnoticed when I click the leftmost column to mark a breakpoint, which can be regarded as a really nice job.

As I see there is still room for better user experience on debugging, here is my humble advice.

Again, thank you a lot for your contribution! (@tim.holy and all of you)

pfitzseb · April 13, 2019, 3:57pm

has major side effects, so we won’t ever do that for you. That said, once

github.com/JuliaDebug/JuliaInterpreter.jl

RFC: refactor breakpoints

JuliaDebug:master ← JuliaDebug:kc/refactor_breakpoints

opened 11:21AM - 02 Apr 19 UTC

KristofferC

+448 -201

The current breakpoint system immediately "lowers" the high level breakpoints gi…ven by a user (a high level breakpoint is for example a breakpoint for a method, or for a file:line) into a set of "lower level breakpoints" (given by a statement index into a FrameCode). This has a major drawback: - After breakpoint insertion we do not know why a breakpoint was set in a FrameCode. Was it because it was a file:line breakpoint or because it was set on a method or a function etc? - This makes it hard for a UI to show the active breakpoints. If a user sets a breakpoint on `convert` you don't want to show 60 breakpoints. From a users p.o.v, they added one breakpoint. That breakpoint can apply to multiple places, but it is still one. A user likely want to toggle / remove all the places where this breakpoint applies collectively. - We cannot insert breakpoint in new `FrameCode`s that are being created. That means we lose breakpoints if Revise decide to reevaluate a method because e.g. you fixed your bug and changed a `+` to a `-`. It means you can't set a breakpoint on `foo` and define a new `foo` and have the breakpoint apply. - For file:line breakpoints, we need to know at insertion time what signature exists at that point. This can be difficult and currently needs Revise This PR introduces two "high level breakpoint" structs called `BreakpointSignature` (for breakpoints on methods, signatures etc) and `BreakpointFileLocation` for breakpoints on file locations. Each `breakpoint` invocation will add *one* of these to a list of breakpoints `_breakpoints`. Upon adding a breakpoint, we look through all `FrameCode` we have created so far and insert the breakpoint if it matches. Upon creation of `FrameCode`'s we insert the breakpoint if it matches. Each breakpoint struct has a field `applications::Vector{BreakpointRef}` which is added to as soon as we add a breakpoint to a `FrameCode`. This allows toggling, removal etc by just looping through this list. This PR should be fairly non-breaking (doesn't break Debugger, but likely breaks Juno). This PR enables the file:line breakpoints unconditionally (aka even if Revise is not loaded).

is merged (and Juno updated for that), those steps will be unnecessary. The Juno.@run part might also be automated in the future if you have breakpoints set or something like that.

For the immediate future you’ll have to live with those slight inconveniences, sorry.

StevenSiew · April 14, 2019, 4:08am

zsykm, I have been complaining that explaining to users about how to use the debugger has been SEVERELY LACKING…

How to use debugger on Juno

create file myjuliaprog.jl
make sure there is a function called main() which runs your entire program. Just like the main() in the C language. For debugging purposes, make sure the initial call to main() is commented out otherwise the program will run when you includet it in step 3
start REPL and type
using Revise
println(“the above is not necessary if you auto start Revise in your startup.jl”)
on the REPL type
includet(“myjuliaprog.jl")
println(“Please note!!! There is a T at the end of the word include”)
on Juno set your breakpoint using mouse cursor on linenumber. You can set as many breakpoints as you want
on REPL type
Juno.@run main()
or
Juno.@enter main() if you want to step through it line by line

Jesus. I wish someone had posted clear and simple instructions like this, instead of me having to find out the hard way through the school of HARD KNOCKS.

zsykm · April 14, 2019, 5:31am

Thank you for your reply!
I’m OK with a few more key stocks. And I definitely believe all the scaffolds will be removed and the final product will be well polished.

As for @StevenSiew has organized some lines on the steps, it could be convenient to put something similar for people who is looking into the Debugger/Rebugger docs for the first time, especially the one like A Julia interpreter and debugger, to save time from digging around.

Thank you again!

zsykm · April 14, 2019, 5:35am

Right! It is the steps to perform.

I understand that, as mentioned in the Announcement of the Debugger, quoted

As of this writing, most of the cleanly-isolated problems have been fixed. While we are still far from perfect, the pursuit of such a demanding goal has contributed extensively to the robustness of these young packages.

In fact it is fun to see how a great language evolved: the tool-chain, the ecosystem, and people: and you be part of it!

Tamas_Papp · April 14, 2019, 6:10am

You could be that “someone”, by making a PR to the relevant docs.

ArnoBetsy · December 24, 2019, 2:34am

Hello! I am new to this compiler （Julia Pro, Julia: 1.2.0, Atom: 1.40.1 x64 )
I may not quiet understand the process, am i misunderstand these steps?
I just want to enter the “main” function and start debugging the file “Test.jl”, is there anything wrong?

PetrKryslUCSD · December 24, 2019, 2:51am

Have you saved the file?

ArnoBetsy · December 24, 2019, 3:01am

Thanks you! i will try this. But just now, i find if i run the block before the process, it will work. It may also the consequence of i didn’t save the file.
Thank you again!

PetrKryslUCSD · December 24, 2019, 3:03am

Clue: the words “hello world” were printed when you included the file. Yet, the file ostensibly defines a function. Unless that function is run, these words should not have been printed.

aviatesk · December 24, 2019, 3:04am

btw, you don’t need to run Revise to use Juno’s debugger anymore in the latest releases.

ArnoBetsy · December 24, 2019, 3:18am

I don’t understand why it print “hello word”. But now, it works!

ArnoBetsy · December 24, 2019, 3:18am

Thank you! I have tried and it works!