Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programming in the Debugger

willcrichton.net

Post reply on HN
Print view View original

81–89 of 89 posts

Re: Programming in the Debugger

#81

Post by meken »

nikitakit wrote: post #38

I'm interested if anyone has good tools for this kind of workflow, especially for Python. As others have mentioned in the comments it seems that similar workflows have existed across a number of languages and IDEs for many years, but it seems that they haven't really caught mainstream attention (in the sense of there being common conventions that multiple languages and tools follow). For my own workflow, I have a deb…

Interesting approach. I hadn't thought of using a single notebook to adjust the scope and enter into functions. I my tool I take a one-function one-notebook approach because that's how I did it by hand for a long time.

Re: Programming in the Debugger

#82

Post by meken »

gunnihinn wrote: post #41

I keep thinking I should be more interested in Jupyter than I am. Maybe someone who knows things can tell me this: Can I use it to develop and debug larger existing programs? That is, can I take 10k lines (say) of Python, that are spread across some modules, load them into Jupyter, not get a horrifying mess, and work on my program?

I think so and that's the goal of my tool (do a Ctrl-f for pynt on this page - I don't want to spam the link too many times).

This functionality is also present (somewhat) in pycharm where you can attach a jupyter console to any region of code. Though, that's just a console and not a notebook.

Re: Programming in the Debugger

#83

Post by nikitakit »

meken wrote: post #81
nikitakit wrote: post #38

I'm interested if anyone has good tools for this kind of workflow, especially for Python. As others have mentioned in the comments it seems that similar workflows have existed across a number of languages and IDEs for many years, but it seems that they haven't really caught mainstream attention (in the sense of there being common conventions that multiple languages and tools follow). For my own workflow, I have a deb…

Interesting approach. I hadn't thought of using a single notebook to adjust the scope and enter into functions. I my tool I take a one-function one-notebook approach because that's how I did it by hand for a long time.

I'm curious how you handle the issue of scope in pynt.

From what I see in the readme, a lot of the features are about extracting code snippets from the source file and sending them to the notebook. But when you're trying to interactively edit a function that's deep in the call stack, there's a question of how to pause execution right as the function is being called and set up the execution scope for the REPL/notebook.

I actually think handling scope is perhaps the key issue for interactive programming. If the global scope is easier to interact with than anything nested, you continue to have a "penalty for abstraction". This is the case even if your language is purely functional/reactive/supports reversible debugging -- in some of his talks about Eve, Chris Granger mentioned how scope proved to be a real challenge even in a functional programming setting (IIRC).

This is one of the reasons I prefer Hydrogen to Jupyter notebooks. In a notebook all cells are toplevel, whereas in hydrogen I can select any chunk of text (or chunk of the AST) and execute it. It's not as good at presenting computational narratives, but much better for interactively changing an existing program to do something new. There's still a lot of issues on the UI front though, so I'm definitely interested in any ideas about that.

Re: Programming in the Debugger

#84

Post by Leszek »

DC-3 wrote: post #77
Leszek wrote: post #60

Earlier quoted context omitted.

Perhaps that's something you should evaluate about yourself then, because I don't think you'd raise the same ParseError if the profession were "nurse". Unconscious biases don't have to be malicious to exist, and I catch myself thinking the way you describe sometimes before realising "wait, this should be fine though".

It's nothing to do with the fact that it's about software development, I don't think (or at least hope). I just find it jarring to see 'her' used as an 'abstract' gender neutral pronoun. In my mind, 'his' has two semantically distinct definitions, and 'her' has just one - and that's just how the English language works.

Agree to disagree on this being a universal 'abstract' gender neutral pronoun problem, and not being profession related.

Re: Programming in the Debugger

#85

Post by mindB »

meken wrote: post #79
mindB wrote: post #28

Earlier quoted context omitted.

What do you use for running the jupyter REPL in emacs? I haven't found a great way of doing so yet. Just running it in a comint buffer?

If you connect your code buffer to an jupyter notebook via Emacs IPython Notebook [1] then you can hit C-c C-o (ein:console-open) which will launch a jupyter REPL. - [1] https://github.com/millejoh/emacs-ipython-notebook

Looks like that just calls make-comint-in-buffer eventually[1] with some fancy stuff to make sure it connects to the same jupyter server as being used for ein. Not sure I see a lot of utility there if I'm just wanting to run a jupyter REPL next to a regular code buffer or e.g. org-mode.

[1] https://github.com/millejoh/emacs-ipython-notebook/blob/cfd0...

Re: Programming in the Debugger

#86

Post by mindB »

tincholio wrote: post #66
mindB wrote: post #28

Earlier quoted context omitted.

What do you use for running the jupyter REPL in emacs? I haven't found a great way of doing so yet. Just running it in a comint buffer?

ob-ipython works really well.

The REPL opened with org-babel-switch-to-session has been really buggy for me. Has it worked for you? Could just be because I'm using it with non-python kernels, which isn't well supported yet in general as far as I can tell.

Re: Programming in the Debugger

#87

Post by tincholio »

mindB wrote: post #86
tincholio wrote: post #66

Earlier quoted context omitted.

ob-ipython works really well.

The REPL opened with org-babel-switch-to-session has been really buggy for me. Has it worked for you? Could just be because I'm using it with non-python kernels, which isn't well supported yet in general as far as I can tell.

I've only used it with a Python kernel so far, and doing eval on each or all blocks in the buffer (org-ctrl-c-ctrl-c, and org-babel-execute-buffer). Haven't had problems so far.

Re: Programming in the Debugger

#88

Post by visarga »

nikitakit wrote: post #83
meken wrote: post #81

Earlier quoted context omitted.

Interesting approach. I hadn't thought of using a single notebook to adjust the scope and enter into functions. I my tool I take a one-function one-notebook approach because that's how I did it by hand for a long time.

I'm curious how you handle the issue of scope in pynt. From what I see in the readme, a lot of the features are about extracting code snippets from the source file and sending them to the notebook. But when you're trying to interactively edit a function that's deep in the call stack, there's a question of how to pause execution right as the function is being called and set up the execution scope for the REPL/notebook…

I thought about this problem - how to have interactivity and a nice editor at the same time, so I created a solution based on IPython.

I am using an inline ipython shell to interact with the local variables from any scope. I just drop a call to "DBG()" (how I called it) where I want to take a peek. In order to write the code, I use a normal program editor and work remote with SSH. The only drawback is that I have to exit and reload the program for each change in the source files, but at least I have direct access to all scopes.

When I start a new program the last instruction is a call to DBG(). I compose functions in the REPL and move them to the source file, above the DBG call. I love the interactivity, ability to inspect, compose and test until I get the code right, while at the same time being able to structure larger source files in a nice editor.

Here's the library: https://github.com/horiacristescu/romanian-diacritic-restora...

Pros: lightweight, access all scopes, works remote, you can use your text editor

Cons: no inline graphics

Re: Programming in the Debugger

#89

Post by scraft »

fantispug wrote: post #47
scraft wrote: post #46

Sometimes I look at the bug database, pick up the next highest priority bug, have zero idea what the problem may be, sometimes there isn't any screenshots and the description is worded so poorly it is hard to make sense of. So I follow the repro steps, which perhaps take 15 minutes and trigger the issue. After that I may pause execution and examine some variables and work out what is wrong. From there I need to work…

But would you be sure you've actually fixed the bug? Perhaps your edit changes the state that would be reached by the continue (e.g. bug is on first iteration of a loop, and your edit inadvertantly changes the initialisation). I think it's useful for fleshing out a bug and could save time if there's another issue downstream, but I wouldn't count it as solved until it has been tested on a fresh run.

Again there is no need for black and white. Take each case as it comes. Often edit and continue is enough sometimes you do need to stop and restart to be sure. Sometimes you are 99% sure and that is enough when you have 4 weeks of bugs and 1 week to ship a product. Heck sometimes you are trying to repro a complex but and half way through hit and unrelated issue, I make a sound of pain and someone else asks what's up, I tell them, they say it is fixed in latest, but I can edit and continue a fix now to save having to spend ages reproing. There are loads of times the feature is useful. I would suggest the people finding it amateur and not useful aren't using it correctly or at sensible times.
Post reply on HN