Not to derail either, but is debug mode faster nowadays for package development ? I started julia only a few years back, around 1.5 i think, and my past experience is awful with that. So I’m mostly running → error-ing (a lot) / @info-ing → Revise-ing.
1 Like
I’m afraid nothing has improved on the debugger side. And, if anything my perception is that it got worse with more erratic behavior of the breakpoints (stopping on removed BPs, not stopping on others when the debugging file is modified)
1 Like
This is different from my experience. From my unreliable memory, since 1.5 it has become drastically better. The ability to select which modules to run in compiled mode is newer than 1.5, isn’t it?
I used the debugger successfully today, at least, and it’s okay-ish responsive.
1 Like
Yes, I agree it is. But that is far from being a particular good experience (I use the debugger almost every day).
Support for Positron would be so great! https://youtu.be/8uRcB34Hhsw?si=RNlhc0k2oxvqJLtE
2 Likes
Not only is debugger slow, but the extensions implementation is often broken. Recently it could only @run once per session (hanging afterward). Today, I found that if I tried to use the debug console, Julia crashed immediately.
That one @davidanthoff kindly fixed it about 2 weeks ago.
2 Likes
I was shorter in that message that I should have been. I’m extremely grateful for the tireless and thankless work @davidanthoff and others are doing! My only point was that the bugs aren’t one off, so I only reach for the debugger as a last defense because I don’t trust that it’s rock solid.
2 Likes
With the debugger in Julia it’s like with my old office’s door handle that would, not always, but often enough, give me an electric shock. As a result I was always hesitant to touch it.
11 Likes
Anyone knows of a native good alternative for Android? (Large tablets in mind).
(I’m using code-server which is rather ok, but it lacks a bunch of plugins, as copilot and remote - SSH).
And something that didn’t work ?
I had no idea there was another person in the Julia community who also has a super barebones development and scripting set-up! This is how my spartan Vim session looks this morning:
(Sorry for the tangent!)
6 Likes
What I have found helpful with zed is to add the following block to keymaps.json
{
"context": "Editor && mode == full",
"bindings": {
"cmd-y": ["workspace::SendKeystrokes", "cmd-c ctrl-` cmd-v enter"]
}
}
This allows me to have a Julia session open in the terminal pane and that allows me the select a block of text and press CMD + y to execute that block in the terminal. Poor man’s hack till they get inline REPL bug fixed.
2 Likes
Two things:
First, the debugger part in the VS Code extension went through a major change this summer. I won’t bore you with the details, but those kind of very large changes are rare. It does mean, though, that it is likely some new bugs crept in during that change. My hope is that we can fix the remaining bugs, and then beyond that I don’t see anything with that amount of code churn for the debugger on the roadmap. The big upside of this change in the summer was that the debug adapter can now be used beyond VS Code, and we’ve started to see it utilized in emacs and vim, and in the VS Code extension it now is also available for notebooks and test items.
Second, can you open a bug report about the debug console thing you ran into it? I just tested a basic debug console stuff on my end, and it seemed to work, so we would probably need some more details.
12 Likes
I definitely will! I’m in the midst of a big deliverable so I haven’t managed to narrow to a MWE. The stress might have contributed to my curtness earlier 
1 Like
Let’s hear it for static electricity. Try first contacting the door knob with something metallic. See if that works. 
No, I just did not get a chance to try very much. I didn’t find anything broken.
1 Like
Given the central role of the Julia extension for VS Code, I believe that the resources devoted to this project should be considerably increased. There is a commercial entity to promote Julia: Perhaps it should chip in? Devote one person full time to making this extension work so that newcomers are impressed. At this point, newcomers seem to be distinctly underwhelmed, given their experience with Matlab IDE or R Studio or Spyder.
PS: This is in no way a reflection on the efforts of @davidanthoff and @pfitzseb and the other fine contributors. It is just too big a job to do in a couple of hours on a weekend when there is some time to spare…
30 Likes
And likewise, but to nth power, for the debugger usability.
2 Likes
I could not agree more! The resource allocation right now is really off, there are defacto two people working at best part time on the extension, when the extension is probably one of the most crucial pieces in the Julia ecosystem.
I think the two biggest areas are the language server and the debugger.
For the LS we just need some folks that really make it “their” project. Right now it is sort of limping along, because the main person that worked on it moved to other things years ago. I started a bit of a renovation of the core architecture, but overall it just is not one of my core interests, and I think @pfitzseb might be in a similar situation.
For the debugger the situation in my mind is largely unrelated to the VS Code extension, the core problem there is just that the underlying debugger engine is not at a stage where it can power the kind of smooth debugging experience that users want.
39 Likes