A Julia Interpreter and Debugger

https://julialang.org/blog/2019/03/debuggers

351 96 7 years ago

tombert5• 7 years ago

Debuggers are one of those things that I almost never use, and have a completely unearned distaste for. Literally every single time I've used a debugger it's been useful, but it's never something I think about using off the cuff. Maybe I'm just an incompetent goober who spends too much time on IRC :)

I've been getting into Julia a bit for personal projects, since I like it better than Python, so maybe this will be a good excuse to learn how to use debuggers more effectively.

saagarjha5• 7 years ago

Maybe you just don't write bugs ;)

But really, what do you use in their place? Do you work in an environment that is "debugger by default" (as opposed to a separate step where you need to "debug" instead of "run")?

tombert5• 7 years ago

It's not a satisfying answer really, but I use a bunch of log statements. It's definitely not as good as a debugger, but 9 times out of 10, it's sufficient.

dnautics• 7 years ago

"println debugging" is a tried and true strategy. Debuggers' firehose of information can start to get really hairy when you have multiple threads of execution, for example. "println debugging" (if you have the right tools) can get you 98% of the way there and show you exactly only the relevant information.

pjmlp7• 7 years ago

I have been using debuggers since Turbo Pascal 5.0.

My experience regarding people around me that don't use them is that they never actually bothered to learn how to use them.

Same applies to other development tools like profilers and static analysers.

I guess I was quite lucky with some of the teachers and professors that crossed my path.

tombert5• 7 years ago

I know how to use a debugger, at least how to set a breakpoint and step through stuff. I'm sure there are features I'm not familiar with, but I at least understand the fundamentals.

I think part of it is that for the last 5 years , every single language I've used with any kind of professional capacity (JavaScript, Haskell, Erlang, F#, Clojure, Scheme) has had a REPL, so I can quickly play with and reload code, making debuggers a bit less necessary than if I were to do a purely-compiled language.

I definitely would benefit from learning more about performance profilers though. You've given me an idea of reading material for the weekend.

vanderZwan2• 7 years ago

I guess I was quite lucky with some of the teachers and professors that crossed my path.

Debuggers aren't exactly self-explanatory so the role of good teachers should not be underestimated

mamcx3• 7 years ago

Turbo Pascal 5.0 Is important to note how MUCH better some debuggers are than others. Pascal was amazing, specially if you compare to C.

Good debuggers:

- Pascal - Delphi - FoxPro /VisualFoxPro (the best of all, IMHO)

Others more common debuggers (Visual Studio, Xcode, IntelliJ, maybe others I don't remember), have issues, like the amazing "feature" of show opaque values, not allow to inspect stuff or requiere extra steps.

But the worse of all? Them are SLOW. Do "step" is slow. Waiting to see if evaluating values? slow.

Python have almost good, but mostly because python allow to see a lot. GDB sucks as is, but python make it look good.

nicoburns• 7 years ago

Which languages have you tried to use a debugger with? Debuggers like gdb look awful (at least without a GUI). On the other hand, Chrome's JavaScript debugger is a joy to work with.

snazz• 7 years ago

GDB is very useable with the TUI mode or the Emacs integration.

tombert5• 7 years ago

I've used Chrome's JS debugger, which I agree isn't so bad (though I don't really do frontend work, and I only managed to get node-inspector working once).

I've also used the Visual Studio debugger for F#, and I think I did gdb with Eclipse a couple years ago when I did C.

m0zg2• 7 years ago

Could be because you've never used a good one. I could see how that distaste would form if all you've ever used was the likes of gdb, lldb, of (if you work in Python) pdb. But when I was switching away from Windows entirely 15 years ago, giving up windbg and Visual Studio debugger was HARD. It's so convenient when you can just _see_ what your program is doing without a lot of extra friction. The downside is, this very much disincentives the writing of tests, because you can get non-trivial pieces of code working without any tests. But with a little self-discipline, I think having a great debugger was a net positive for me, both code quality and productivity-wise.

marco_salvatori• 7 years ago

Throughout my career, I have never met anyone who used MS tools that did not find them excellent and productivity enhancing. In fact I could probably add to MS any of the language vendors from years ago. I remember using Borlands terminal based C++ environment back in the early 90's. That's about 30 years ago and that environment is better than what I use programming on Linux today.

I have often thought that programmers posture over their tool independence to signal their excellence. Before the current generation of programmers, many programmers would proclaim how they didn't need to use higher level languages to assist them in programming because assembly language was sufficient given their reasoning powers. Today programmers proclaim they don't need types to insure data invariants as their reasoning powers are sufficient. They proclaim they don't get any value from unit testing because they can maintain correctness across all development phases using their reasoning powers alone. They proclaim they don't need automatic garbage collection because they can insure correct memory usage using their reasoning powers. They have no use for IDEs, debuggers, or profilers because they believe none of these tools could augment their reasoning powers.

Excellent programmers can indeed compensate for poor tooling through their reasoning powers alone. But if history is a guide, people who don't use the best tools, practices and technologies to produce the best work, at some point, wont produce the best work.

taeric2• 7 years ago

I think the main problem with debuggers is that I've seen people crippled by the need of them. Literally unable to simply stop and ask what could possibly have caused the outcome they saw. Having to use a program to step through with the required values to reproduce what they should already know will happen when those values are present.

Which isn't to say that live coding and debuggers are bad. However, they are usually much more useful to find out either how something got to where it is, or to augment what you have until it is ready to send for review.

register2• 7 years ago

This should be a game changer. I had tried Julia before and was disappointed by the interactivity of the REPL because redefinition of code at runtime was anything but easy to achieve. If it works as stated Julia REPL now should be on par with CL's one. I'll give Julia another try!

npr112• 7 years ago

Revise.jl allows you to modify code and use the changes without restarting Julia.

Might be helpful :) https://timholy.github.io/Revise.jl/stable/

register2• 7 years ago

I tried Revise and the fact that it doesn't require you to restart Julia doesn't mean that it allows you to change code on the fly. It means that you don't have to close the REPL and restart it and that you don't have to explicitly reload code. To see the effects of a change to a function invoked in a loop you have to wait for the loop to complete and return back to the REPL. This is not really SO interactive. In CL you see the effect of any change immediatly at the next iteration of the loop. What Revise does is to automatically recompile updated code by detecting changes automatically. I hope that this interpreter brings the same level of interactivity as CL. I'll try it for sure.

superdimwit• 7 years ago

Is CL Common Lisp?

saagarjha5• 7 years ago

Don't know much about Julia, but it seems like this debugger works by running the code in an interpreter? Is there tooling around debugging compiled Julia code as well, or is this the only way to feasibly debug Julia? It any of this tooling standardized so it could work in say GDB or LLDB (taking advantage of their command syntax, Python API, etc.)?

johnsea• 7 years ago

Iirc the first attempt, Gallium, did that. I believe it was technically super ambitious and a bit brittle maybe. It worked with Julia version 0.5. Maybe one time Keno or someone else very capable has time to revive it, I don't know.

vanderZwan2• 7 years ago

I wouldn't be surprised if it wasn't so much "brittle" as that Julia internals were too much of a moving target before reaching 1.0 to make it worth the effort of keeping it working between releases.

3JPLW2• 7 years ago

This effort is effectively the revival of half of Gallium. At the end Gallium was a combination of two debugging techniques — it was both a "native" gdb/lldb-style compiled debugger as well as an interpreter. The native debugging was fast but indeed challenging and rather limited — most Julia code gets optimized away when it gets compiled leaving you with a rather unhelpful stack frame that's challenging to line back up with your original code. So there was also a rudimentary interpreter (the ancestor of this interpreter) for other cases.

ViralBShah• 7 years ago

Yes, the original attempt was a bit brittle. So this attempt addresses things from the other end and having something robust but slow. From here on, the plan is to keep adding features from Gallium that improve performance.

StefanKarpinski6• 7 years ago

Yup, Gallium used DWARF debug info like gdb/lldb and could debug optimized, compiled Julia code. It's named Gallium because the DWARF standard constant for the Julia language is 31 and gallium is the 31st element in the periodic table :) Unfortunately, compilers generate horrible debug info and it was very hard to get even basic stuff like knowing the values of all in-scope local variables to work reliably and making breakpointing work was very much a work in progress.

Debugger.jl on the other hand is slow, being interpreter-based, but very reliable. The down side is that it's really slow, so if you need to debug performance intensive code, you might be in trouble. In the future, the plan is to steal tech from Gallium [1] and MagneticReadHead [2] and use them to create a hybrid interpreted/compiled debugger that is as reliable as Debugger.jl is now but which can run code fast enough to debug even compute-intensive workloads effectively.

[1] https://github.com/JuliaDebug/Gallium.jl

[2] https://github.com/oxinabox/MagneticReadHead.jl

KenoFischer• 7 years ago

The history here is a bit as follows. Back about four years ago, I set out to write a debugger for Julia and while I was at it, I figured I might as well fix all of the other things that have always bothered me about debugging. As an example of that, it had the following features:

  - Being completely written from scratch in Julia
  - Mixed debugging between Julia and C/C++ code
  - Integration with https://github.com/mozilla/rr for time traveling debugging
  - Debugging windows programs running on a linux host under wine (and in particular even as an rr replay).
  - Zero overhead debugging by using mixed modes (DWARF based debugging generally, a much more accurate interpreter based one when possible).
  - Very precise location tracking, on an expression basis, not just a line-by-line basis
  - Multi-process debugging by riding along RPC calls, even across machine and even as separate rr recordings across machines

As you can tell from this feature list, that project was a bit over ambitious and in the end failed to be a particularly useful debugger for Julia. It was useable for a bunch of basic cases, but fairly brittle. Also, then 0.6 came around and all of Julia's internal APIs changed and porting over the entirety of Gallium would have been quite hard.

After 0.6 was released, I decided this wasn't working out for a Julia debugging story and pulled out just the interpreter and UI parts from Gallium (that package was called ASTInterpreter2.jl). This worked ok, but was lacking a bunch of features that I never got around to implementing, because the lead up to 1.0 required a whole bunch of compiler work that nobody else was available to do. This work now is based on that work from 0.6, but actually making it work nicely and paying a whole lot of attention to it that I was never able to. I'm very happy that Tim, Kristoffer and Sebastian decided to take this on, because I feel like my workload has only increased over the past year ;).

I still very much want all the ambitious features from above, and we do still have the code (and much of it is actually in use, just not for debugging) and I'm fully expecting them to make a recurrence. However, this time around, we'll start with a stable, usable system and gradually make it faster and add features, rather than building an unstable system with all the features and trying to fix it. The former approach is much better for getting usable tools out (though sometimes the latter can lead to more interesting results in a research setting). The other thing to note is that Julia is much more stable now, so it's easier to keep things running without breaking every few months.

npr112• 7 years ago

Even newer... so early days, but you might also be intereting `MagneticReadHead.jl`. The debugging instrumentation gets compiled into the code.

https://github.com/oxinabox/MagneticReadHead.jl

oxinabox6• 7 years ago

Author of MagneticReadHead.jl here. Hit me up with any questions.

It is a a bit less polished than Debugger.jl right now.

FridgeSeal3• 7 years ago

I don’t know enough to answer your question about hooking into gdb/etc, but are you familiar with with the code_lowered macros? They will output a given function/scope in whatever lowered form you request (lowered Julia, LLVM, and something else).

oxinabox6• 7 years ago

Also there is currently early plans for Debugger.jl to incorperate compilation at some point.

nathcd• 7 years ago

JuliaInterpreter received numerous performance enhancements, and now can run step-wise through code at roughly 50× its original speed. These optimizations reduce—but come nowhere close to eliminating—the most serious disadvantage of running all code in the interpreter: slow performance. It is hoped that the performance gap between compiled and interpreted code, which can be many orders of magnitude, will narrow in the coming months. However, the interpreter will always be slower than compiled code.
It’s also worth noting that there are cases where the interpreter feels faster, at least on initial execution. Julia’s JIT compiler produces excellent results, but all that code-analysis takes time; there is interest in exploring whether running more code in the interpreter could reduce latency, a.k.a. the “time to first plot” problem. JuliaInterpreter is a potential tool for exploring that trade off, and it appears that not much additional work would be needed.

Oh wow, this is great. I've really enjoyed what little toying around with Julia I've done, but it seemed just shy of feeling truly interactive to me. But I really do love the featureset of the language, so if this gets integrated into the language and it helps in time to interactivity, I'll absolutely be moving some parts of my work to Julia.

Certhas• 7 years ago

More importantly to me, Julias combination of features means code is not very self documenting and error messages are (often) terrible.

If I need to understand what subtle assumption of DifferentialEquations I violated stepping into the point of failure is God sent. And that's a well documented package.

More importantly, I now can usually reason my way around. But my students can use this to learn what goes wrong in their codes interaction.

This is a massively important step in the tooling and ecosystem. Congratulations to the developers.

amasad• 7 years ago

This awesome! I just created a Julia Debugger playground on Repl.it: https://repl.it/@amasad/julia-debug (it's a bit slow to start but then runs smoothly)

Here is a quick screencast: https://imgur.com/a/PXTRgHp

waldir• 7 years ago

It's really great to be able to just click a link and start playing with Julia without installing anything! While there are other platforms offering a similar experience, I'm glad Repl.it added Julia to its tool belt.

Just a quick note for the inattentive like me: you have to click the "Run" button before executing the `@enter foo(20)` command.

teamspirit• 7 years ago

I've been meaning to get into julia for quite some time, but I always feel like the community is always like, "this version still needs X, when that comes out, it'll be ready." Is this it? I guess if I had applied that logic to anything else I would never have started on those either. Meh, maybe it's just me.

StefanKarpinski6• 7 years ago

Yes, after this, we're done, there are no more things to do! You should start using Julia now :)

Just kidding, there are many cool things that are in the works, including Go-style multithreading and effortless automatic differentiation of arbitrary code, allowing you to "machine learn" any algorithm without a complex framework.

But that's all stuff that's not even available in most languages—now is a great time to start using Julia:

1. The latest stable release is 1.1—code you write now will keep working on all 1.x releases

2. There's excellent editor and IDE support for Julia in pretty much every imaginable configuration

3. There's a solid debugger with interfaces from the terminal and IDEs (and I'm sure soon there will be many more)

sidesentists2• 7 years ago

Just as a nudge for something not really of practical importance but something I'd like to see for other reasons: self-hosting.

3JPLW2• 7 years ago

I sure hope there will always be exciting new improvements just around the corner. The Julia community prides itself in being greedy, so we're often looking forward to those things.

It's worth noting that this entire effort is done in external packages that work on both Julia 1.0 and 1.1. One of the biggest things Julia previously needed was stability, and we now have that.

FridgeSeal3• 7 years ago

This is super cool and I’m really looking forward to giving this a go, great work Julia team!

mark_l_watson• 7 years ago

Sweet. I have been slowly learning Julia - this should help!

hawski2• 7 years ago

That's a great news! I search for a new general use (for me) language. I come from C++ and C land. I don't like Python for bigger projects, because of it's typing regime, performance and white space significance. So far Julia seems nice and improvement in tooling is always welcome, because tooling is crucial for the language survival.

A side question: How is Julia for web development? I'm not really a web developer and my mindset is more in realms of C, shell and CGI or Go. I mean a small to mid scale operation so SQLite integration is probably enough and Julia has a package for that.

4thaccount5• 7 years ago

Julia's main focus is on scientific computing. Basically think of it as a Matlab or Python + Numpy or even a C++ replacement for numeric computing.

A lot of the libraries are focused on optimization, differential equations, statistics, matrix operations...those sorts of things. It doesn't have classes in the way you would probably think (not really an OO language).

hawski2• 7 years ago

Go and C do not have classes either. If it's a bit comparable it would be a plus for me. I'm mainly a C++ programmer by trade by I don't enjoy it and in my free time I use mainly C with some shell glue and some Go.

I read that their focus is on scientific computing, but I feel that there is a growing effort to expand Julia's use cases. Also I think that some end user applications could gain a bit from optimized statistics or matrix operations.

gugagore• 7 years ago

I'm not sure if you're suggesting that an "OO language" is a better match for web development, but in case you love some of the OO features like inheritance of fields, you can check out https://github.com/rjplevin/Classes.jl

pjmlp7• 7 years ago

Multimethods are OO.

ddragon• 7 years ago

Certainly not as mature as most languages that focus on web (since it was not the priority), but it shouldn't be hard to create simple services. For example with:

https://github.com/essenciary/Genie.jl

https://github.com/wookay/Bukdu.jl

FridgeSeal3• 7 years ago

I’ve just finished building a REST api with it that was fairly painless and seems pretty fast (after first compile).

If you need more features the Genie.jl library is aiming to be a full featured web framework.

ellisv3• 7 years ago

I must agree Genie.jl is great!

arthurcolle• 7 years ago

Python added 'type hints' as of 3.5 BTW https://docs.python.org/3/library/typing.html

Julia has a web framework called Genie (https://github.com/essenciary/Genie.jl) which seems decent enough (probably useful for data visualizations but I don't know of many people using it (I haven't used it for anything worth mentioning)

One of the neatest things I found when I was messing around with Julia was UnicodePlots, which lets you make nice plots right in the terminal. I love that little library and used it to build a little live orderbook of GDAX right in the terminal. I wish there were more terminal-based applications for non-sysadmin/engineering tasks, I feel like its such a useful medium.

truth_seeker• 7 years ago

About Python and performance, have you tried pypy runtime? It is an alternative to the default, cpython.

http://speed.pypy.org

Rotareti• 7 years ago

In addition to this. About Python and typing, have you tried mypy (statically typed Python)? I find the typing story quite decent since Python 3.6. I use it on every project that goes above ~1000 LOC.

http://mypy-lang.org/

AlexCoventry• 7 years ago

I tried julia three years ago, but version skew was a huge drag. Has the situtation improved on that front?

BlackFingolfin• 7 years ago

Yes, the language was (intentionally) stabilized with 1.0. So version 1.1 (the current one) is fully compatible with that, and this will remain so for the whole 1.x series. And I expect that even 2.x won't be as bad (if at all) as the major changes that were made during the early evolution of the language.

oxinabox6• 7 years ago

Amazingly, even packages have started to stablize. Even though a great many of them are on there own v0.x, they are both moving towards theire 1.0 releases, and being more careful about not breaking there v0.x releases.

roywiggins• 7 years ago

It has since gone 1.0, so I assume it's better. I am just dipping my toes in right now though.

ellisv3• 7 years ago

Yes. The language is much more stable since 1.0 (intentionally).

However some packages are still being updated.

h8hawk• 7 years ago

The main problem with Juno is Atom . I really hope julia come up with better VSCode support. Atom editor is essentially broken. They should choose VSCode as their main editor.

ellisv3• 7 years ago

I’m curious why you think this. I use Atom often and for many things so I don’t consider it broken at all.

chrispeel• 7 years ago

There is no main editor, you chose your own. Some who like VSCode made [1], which you could use and contribute to.

[1] https://github.com/JuliaEditorSupport/julia-vscode

oxinabox6• 7 years ago

Both Julia-VSCode and Juno are open source projects. As are plugins for like a dozen other editors.

I'm not sure who the "they" you speak of is. that "should choose VSCode as their main editor."

oxinabox6• 7 years ago

My guess would be: 40% julia users use Atom, 40% julia users use JuPyTer, 30% julia users use VSCode 30% julia users use something else (Vim, Emacs, Sublime, IntelliJ).

And it adds up to over 100% because many people use many things. I use all of the above

xvilka• 7 years ago

They are participating in Google Summer of Code and there are many interesting projects in the ideas[1] list.

[1] https://julialang.org/soc/ideas-page

iamed2• 7 years ago

One thing that outsiders miss when considering MATLAB is the incredible debugging workflow. With this release and the Juno integration, we finally have the same experience for Julia! As a developer who used to use MATLAB and now uses Julia every day I am very excited to make use of this tool.

b_tterc_p• 7 years ago

Does this mean for loops would now be slower than vectorized ops? Excuse me if that’s a stupid question

boromi• 7 years ago

When can we expect integration with VScode. Atom is too slow on my computer.

A Julia Interpreter and Debugger

Related Stories