Didn’t I read somewhere that’s there’s a magic # debug comment in this? Like a way to set a breakpoint in the code?
Ah, a macro for it. Nice! Thanks.
Did debugger macro helped you?
1 Like
I actually wasn’t able to figure it out. I don’t know know GDB or LLDB at all, so once I’m in those I have no clue what to do. Then if I set the debugger and build with debug and run ./test it says zsh: trace trap ./test. I’m not really sure what that means. If I hop in to VSCode and click “Run” > “Start Debugging” nothing happens. I don’t see any pop up or anything.
I feel like the debugging stuff right now is a bit beyond my technical knowledge to use it. But thanks for checking in on me!
We can setup some time and I can help you remotely to look at it. Will give you some clues. It will be much faster that way.
1 Like
I appreciate that. You don’t have to go to all that trouble for me though. I’m sure the debugging stuff is pretty nice for those more familiar with how to use it 
Maybe you could do a screen cast on setting it up and a few tips and tricks on using it? Maybe like how to use it in a simple kemal app or something? That could benefit a lot of people!
I definitely should allocate some time and made that screencast.
6 Likes
A well behaved debugger is a must for a language to be considered anything more than a casual scripting language, IMHO.
CodeLLDB + crystal_formatters.py meets the minimum bar I think.
For starters it took me some time to get crystal_formatters.py hooked up. I’m glad I got there - being able to see the content of Strings and Arrays while debugging means we’re out of first gear!
For me the trick was to realise Homebrew doesn’t install crystal_formatters.py, so I just downloaded it from crystal/etc/lldb/crystal_formatters.py at master · crystal-lang/crystal · GitHub and moved it (somewhat arbitrarily) to /usr/local/etc/lldb/crystal_formatters.py. Once I specified that path in launch.json I was up and running.
Second issue was that 11 days ago @asterite made some optimisations to crystal, and updated crystal_formatters.py to suit. Of course, due to the aforementioned Homebrew install issue, that meant I had a crystal_formatters.py designed for a future version of crystal! Once I rolled back the changes to my local copy of the file, I was finally rid of the
Got exception ‘NoneType’ object has no attribute ‘type’`
errors, and Arrays were correctly formatted!
Now my variable list looks like this:
input is a String and cups is an Array.
FWIW, this works fine from the command line using Apple-provided lldb-1200.0.44.2, as well as the version CodeLLDB uses, which is 11.0.0.
So good news and many thank yous for putting this together. In my mind, the next two killer features are:
- Not descending into sub-functions (eg.
eachandtimes) when “Stepping Over” (aka,nextinlldb), as discussed above. From the explanation above I understand the issue is that they’re inline functions, so the debugger doesn’t see them as sub-functions. Certainly, modern programming languages blur the line between functions in all sorts of complicated ways. But it’s easy to destroy the effectiveness of the debugger if you can’t step over a few critical lines without losing your way in the depths of code you didn’t write. Perhaps it would be sufficient if a single invocation of “Step Over” kept stepping until the program counter returned to the source file where the invocation occurred. That is, if the top of the call stack is at line 30 ofmyProg.crand the “Step Over” button is clicked, the debugger does not stop again until the call stack is back inmyProg.crsomewhere. That means it may skip over lines of code which look steppable, but I think we’ve already been trained by modern languages to understand that not every line of code is breakpoint-able. - Formatting of Nillable variables, as discussed above. Just a little prompting would go a long way. The hover tooltip code insights (provided by
Crystal Language/crystaline?) already provide very valuable line-by-line type information (eg(Int32 | Nil)) so just knowing which is which would do for a start. No where near as high a priority as #1.
So, I finally got around to using the vscode debugger feature for Crystal. I wish I had looked more into using it sooner; it works AWESOME!
Debug Crystal in VSCode via CodeLLDB - DEV Community and links were very helpful!
Thanks to all who helped make this possible! 
2 Likes
Guess I should give it another go. I failed to get it working the few times I tried in the past.
1 Like