[wingide-users] wingide-users Digest, Vol 113, Issue 14
cfry1 at MIT.EDU
Sat Sep 28 14:00:10 MDT 2013
From: Wingware Support [support at wingware.com]
Sent: Friday, September 27, 2013 3:28 PM
To: Christopher Fry
Cc: wingide-users at wingware.com
Subject: Re: [wingide-users] wingide-users Digest, Vol 113, Issue 14
Christopher Fry wrote:
> This I the first time I've looked at a list of new features for Wing 5.
> It does not include what I consider to be the most important deficiencies of Wing4.
> First, programmers spend most of their time fixing bugs.
> I see NOTHING that directly affects debugging, and the stuf that's there appears
> to be to be barely helpful at all.
It's mostly a GUI rewrite which was an absolute necessity at this point
in the life of the old GUI toolkit Wing 4 used.
Fry sez: OK that all makes sense. Sometimes you have to do "infrastructure"
improvements before doing "feature improvements".
One thing relevant to
debugging (for some people) is that I/O from commands typed in the
shells is asynchronous and thus gets to the IDE before the commands execute.
Fry sez: I don't understand the above at all, but probably not so important that I do.
> In Eclipse, a lot of the "debugging" you have to do is debugging eclipse itself,
> ie whoops I accidentally dragged this pane over there and now I can't find
> the stepper controls and have no way to figure out how to get them back.
> So on the face of it, letting a user drag panes around is a bad idea.
> If a feature is in Eclipse, consider it a red flag as something NOT to implement.
Being able to drag tabs was our #1 most requested feature. We can't
ignore that and have tried to do a reasonable job with it.
Fry sez: OK paying attention to users IS important. If this means that I can
drag certain important file tab to the left and they will stay visible there even after
I open up other files, that sounds like a useful feature.
> So what DO we need for debugging?
> -a better inspector: its very hard to see the details of certain objects,
> esp App Engine model classes
> - A way to invoke the inspector on results you get from entering in an expression
> in the Python Shell/
> - way to step though some code that I've started by typing in a call to the Python shell.
These were planned for Wing 5 and still are, but we haven't been able to
work on them for 5.0. This is because rewriting 350K lines of GUI code
is hard and time consuming. We had to focus on that and get it done.
Fry sez: Yep, I understand, thanks!
> - A way to have a running app in the editor and be able to type in an expression
> into some python listener and see its results WITHOUT having to set a breakpoint.
> I don't want to set a break point, I want to define a bunch of classes, methods
> then call them. Don't make me artificially have to set a breakpoint somewhere,
> then call some method I don't care about form my UI button click or whatever,
> then get into debug probe and NOW I can type in my expression.
> - AND let me INSPECT the result of that expression.
How would you determine the locals context to run within? Or just use
the global context? Also, how would you deal with the inevitable
threading/concurrency issues just injecting code randomly into a running
app? I realize that's not always going to be an issue but it sure will
confuse some people.
Fry sez: Here's how it works in a good environment.
The classes, methods and globals are all defined in the env that I'm wanting to execute in,
but nothing else. I'll tell you what I sometimes do to solve this problem.
I put at the bottom of my file some dummy code like foo()
then set a breakpoint at that line.
Then I execute the program with the green button.
Or I find some way to "break" the program by clicking on something in the UI.
This is a pain.
Here's how it works in the Water idea: You don't have a difference between "shell" and
"debug probe". You just have one environment. You select expressions in your
text editor and eval them. One of the expressions you can select is "load_file(...)
or a whole bunch of files that "load your whole program.
Now your "listener" has all this stuff loaded in, as does your inspector.
And you just eval more stuff. Say you edit a method. Well to see its effect
just eval the method def and its "in" the env so any calls to it get the new def.
Often at the bottom of a file I'd have a bunch of comments that would be
calls that I do for testing. Loading the file would NOT eval the comments,
but after its loaded, I could go in and select a commented fn call and call it.
NOW very occasionally the env would get screwed up. Say for instance
I'd rename a method, now both the old def and new def would be defined.
Mostly this wouldn't matter but if I had an old call around, it would still
work when it ought to error. The worst I could do is just reboot the IDE.
So my env was "dirtier" than your's. But in practice it is SOOO much more
convenient that its way worth it.
I understand Python might have some restrictions here. Its not a great language.
But you might be able to find some ways to get this more dynamic behavior
and make development MUCH easier.
If you are not familiar with such IDEs (none are popular now) I can appreciate
why you'd be skeptical. Its a different developer mindset.
> I consider the above more important than anything I see in your list of improvements.
> I told you all this a year ago and you said wait for version 5.
> Nothing in your list compels me to try version 5.
> I'm sure there's good stuff in there. You are smart people who do good work.
> But do you actually use Wingware to debug? If so, why haven't you
> observed the problems that I've articulated above?
Yes, we debug Wing with itself every day, all day long. Almost
everything I do, including writing new code, is in the debugger. I work
almost exclusively in the Debug Probe, which I find a lot easier and
faster to use than the graphical inspectors. I do use the Watch tool
fairly often, however. I would also like recursive debugging from the
shells, but to say Wing's debugger is useless without this seems a bit
odd. (Not sure that's what you're saying, but it sounds like it)
Fry sez: I never said wingware debugger is useless. As far as I know, its the
best of the Python environments and probably better than any Ruby env too.
Its just that I envision it being significantly better and I *hope* it isn't that hard to do.
You've got the essential pieces in place already.
BTW, data extraction for a debugger in Python is a difficult problem.
Objects can implement __str__, __repr__, __len__, property methods, etc
and they can and often do horrible things when those are called. We
avoid it by default.
Fry sez: OK I didn't know that. Python is not a great language.
Does enabling the Debugger > Advanced > Resolve
Properties preference help with App Engine model classes?
Fry sez: Sounds promising but how do I find "debugger"? There's a "Debug" menu with
no "Advanced" on it.
There's no expectation that every user will upgrade to 5.0. We
understand that people are going to upgrade when we offer them a
compelling reason to do that, and the features that people care about
vary greatly from individual to individual. If that's not until 5.1 or
6.0, that's just fine.
fry sez: No doubt I will find all sorts of improvements in v 5 and I expect to
upgrade pretty soon. Its just I was getting nervous that you forgot about the
debugging tools I mentioned to you a year or two ago.
Thanks for the feedback!
Fry sez: Working on IDEs is difficult but very very important. I appreciate your great efforts!
One of the hardest things you have to do is make up for Python deficiencies.
A good lang makes writing IDEs for it easier.
Wingware | Python IDE
Advancing Software Development
More information about the wingide-users