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

Python Tools for Visual Studio

hanselman.com

Post reply on HN
Print view View original

131–134 of 134 posts

Re: Python Tools for Visual Studio

#131

Post by pnathan »

flyinRyan wrote: post #123
pnathan wrote: post #99

Earlier quoted context omitted.

Honestly, coming into visual studio/c# from emacs/common lisp feels like going backwards in time for me. Running my CL environment on Gentoo feels like the future; a not-quite-there-yet-but-still-awesome future; running VS on Windows feels like kiddie toys that haven't gotten around to growing up yet. And that's a weird feeling when you realize the dollars, time, and research poured into each environment. :-)

The future! I can't imagine how anyone could say that. I started out with Smalltalk, then started doing C# professionally and eventually started doing CL in emacs. CL/SLIME/Emacs was by far the worst of that trilogy. I can't think of one single thing that the emacs combo did better or even as good. Both Smalltalk and VS+Resharper have great refactoring tools. Both have great debugging tools (and in Smalltalk I can ev…

> restricted to just text.

I think that lies at the heart of our disagreement. I don't find text restrictive, I find visuals and GUIs restrictive.

What specifically do you miss about debugging?

Re: Python Tools for Visual Studio

#132

Post by flyinRyan »

pnathan wrote: post #131
flyinRyan wrote: post #123

Earlier quoted context omitted.

The future! I can't imagine how anyone could say that. I started out with Smalltalk, then started doing C# professionally and eventually started doing CL in emacs. CL/SLIME/Emacs was by far the worst of that trilogy. I can't think of one single thing that the emacs combo did better or even as good. Both Smalltalk and VS+Resharper have great refactoring tools. Both have great debugging tools (and in Smalltalk I can ev…

> restricted to just text. I think that lies at the heart of our disagreement. I don't find text restrictive, I find visuals and GUIs restrictive. What specifically do you miss about debugging?

Well, as I stated: in Smalltalk I can trace statement by statement (compound statements work flawlessly), make a change to a method and the debugger does the right thing. With SBCL under SLIME on Emacs I have to fiddle around with optimize statements over and over, recompile mutliple times before debugging does anything at all, at which point it still doesn't work very well. Randomly skipping over sexpressions, etc., etc. The experience is awful and every time I've ask on #lisp I've been called an idiot for trying to debug instead of tracing (not even exaggerating, sadly).

Re: Python Tools for Visual Studio

#133

Post by cdavid »

int_19h wrote: post #76
cdavid wrote: post #64

Earlier quoted context omitted.

Can you expand a bit on how that works in principle ? Can you make it work with a standard python or did you need to insert probes' into the python interpreter to catch when it goes form C to Python and vice et versa

Some more specifics: Stack walking works by rewriting the native stack. Basically we just let the native stack walker do its job, then strip out all python##.dll frames except for PyEval_EvalFrameEx. For that one we read the "f" argument and then parse the PyFrameObject to which it points, and replace the frame with our own using data from that frame object. We parse the data structures ourselves, but use symbols to…

Thanks a lot for the detailed explanation.
Post reply on HN