iPython notebooks and PyCharm have complementary features, so I'm switching a lot from one to the other. But I would like to make the relationship tighter.
For example, when I'm in a notebook and some code blows up, I would like to set a break point in PyCharm, run my code snippet again, and explore the variables in the breakpoint's scope.
At this point, when I'm in this situation I have to either:
Use the debug command in the notebook, but the navigation within this debugger is a bit clunky (no context autofill, no back-history, no function help display... basically, it seems I'm not in a notebook anymore!)
Go to PyCharm, write a script to recreate the same environment (i.e. imports, variables with their values, etc.) as I was in in the notebook, and launch debug on that script.
This is the main use case I'd like to see solved. Of course, things like triggering PyCharm's "find usages" and "jump to definition" from iPython notebook itself would be a charm (pun not initially intended), but I'll curb my desires for the perfect IDE. For now.
PyCharm 4.0 just came out with iPython integration and allows you to edit *.ipynb files. The official notes are here. Here's how it looks on my screen:
Related
I am using Visual Studio Code with the Julia plugin. Regular debugging is impossibly slow, so I a tried to use the package Infiltrator.jl. I insert #infiltrate where I want execution to stop, just like a breakpoint and then start the REPL. Execution indeed stops there and the REPL prompt changes to yellow infil>. So far so good, but when I type something the letters get scrambled, sometimes when I hit Enter and sometimes even before that. It happens before my eyes. After two or three attempts the REPL prompt changes back to green julia> and the REPL freezes.
Anyone familiar with this problem?
As per the readme:
Running code that ends up triggering the #infiltrate REPL mode via inline evaluation in VSCode or Juno can cause issues, so it's recommended to always use the REPL directly.
I'm new to Julia, I have a file called "example.jl" and I want to open it in Jupyter. I added the Julia kernel to my jupyter kernels.
My question is:
Is there a terminal command like:
jupyter notebook blabla.ipynb [that I use to open my notebooks]
Which opens my "example.jl" script in my jupyter notebook with the right jl kernel?
I looked into many pages and couldn't find an answer.
P.S: What I do now is to open a notebook with jl kernel and copy the Julia script into it. But I'd like to know if there are more elegant ways to open .jl s.
Generally you need to create a new empty Jupyter notebook with Julia kernel and copy-paste your code there.
There is also a nice Julia implementation - Weave.jl. Since Jupyter's format is more complex, special code formatting is required (for hints see pictures at https://github.com/JunoLab/Weave.jl) - once it is done you can do the conversion in the following way:
convert_doc("examples/some_code.jl", "some_notebook.ipynb")
There are some other (usually Python-based) tools available, that under some circumstances can be used to split source code file into several Jupyter cells but again every time this assumes some specific code formatting.
P.S.
If you are looking for and IDE try Visual Studio Code with Julia extension which is great.
I have code blocks that begin with # %%.
I would like the debuger to start inside a particular code block and then pause at my breakpoint.
It just runs through the entire script by default.
Thanks
It is not supported at the moment: https://youtrack.jetbrains.com/issue/PY-29672
Perhaps Jupyter notebooks in PyCharm can be a good alternative. They do support independent cell debugging.
Over the years, I just can't seem to find a free debugger that suits me. Normally, I just connect to my university's cluster and use DDT, but I'd like to find something free that I can use locally on my machine. I've been playing with gdb -tui, but it doesn't have a window to show the other project files or a window for watched variables. I can't find a way to open up another file in the project in the source window so that I can scan the source code and see where I want to set my breakpoint. I have to open the other file in vim, find the line number, then set the breakpoint in gdb. I have switched to doing all my code writing in vim, and that seems to work pretty well for me, but I still haven't found a good all-in-one package for debugging the code after I write it. Any suggestions from anybody who have a good code development setup would be greatly appreciated.
I ssh into a linux VM which is setup remotely. I use Vim to write my code. For debugging however, I use netbeans through X11 which can sometimes be painfully slow. I tried using gdb buts its an efficiency killer. I love to hover over my variable and get to now their value rather that doing p variable_name , plus I like see and navigate through the code. Is there something light simple gui based debugging tool I can use. I have tried to use clewn http://clewn.sourceforge.net/ , but that doesnt work because it has a missing netbeans_intg feature. Is there any other similar vim gui based debugging tool ?
You can try ddd
which is a gui for gdb, I think it's lighter than netbeans.
cgdb is an interface to gdb but it is not a graphical one. It does not offer the possibility of hovering over a variable, but it shows you a window with the source code.
Well, I was in sort of your situation sometime ago, and you can have a look at my question about using gdb with remote sources.
First of all, your problem with netbeans_intg feature is related to vim which has been compiled with no support for it. If you can rebuild vim yourself, you can then enable it. Otherwise, as you can see in the answer that I gave myself to my question, you can leverage clewn's remote-vim capabilities.
In a nutshell, you can have a "local" vim (i.e. on a desktop/laptop machine presumably), which must still be built with netbeans_intg support, but now it is a vim under your complete control (i.e. it's on "your" machine), while clewn will run on the linux host where gdb and your debuggee will run.
You can then keep the source files on your desktop/laptop and have the remote clewn sort of "drive" your local vim to the proper source files while debugging.
IOW: clewn will get information out of gdb to know exactly which file/line you're into and connect to remote vim and tell it: "hey, go grab this file and show it around this line", highlighting current line, breakpoints etc.
This is a great solution for when you have far-away deployed systems and you need to debug them with minimum impact on the host where they are running, and presumably no option to transfer there all of your source files.
I don't know if this fits in any way with what you're trying to do, but it did really change things for me.
Hth,
Andrea.
Check out GDB server. Theoretcially, you should be able to start gdb on your linux machine in server mode and connect via GUI of your choice. As long as that GUI supports remote gdb connections, which Netbeans does.