[wingide-users] Missing breakpoints & projects

[Tom Stambaugh]

----- Original Message ----- 
From: "Martijn Pieters" <mj at zopatista.com>
To: "Tom Stambaugh" <tms at zeetix.com>
Cc: <wingide-users at wingware.com>
Sent: Monday, September 03, 2007 12:22 PM
Subject: Re: [wingide-users] Missing breakpoints & projects


>> [snipped]
>> This is particularly true given the ease with which one can open  and 
>> close
>> various project files while debugging. Does the "Breakpoints" tab  of the
>> "Wing Tool Box" show what is actually happening, or does it show the
>> definitions in whatever project is open? When I have a file open,  does 
>> it
>> change the definition list in the project that created it, or does it
>> instead change the currently-open project?
>
> I am not entirely sure what you are saying here. The breakpoints tab 
> shows project-wide breakpoints, so the list should change when you  change 
> projects, regardless of whether a file is shared between  different 
> projects.
>
> [snipped]
>
> Different use cases have different needs.
>
 Here are at least two use cases to consider.

Suppose the debugger is active, with a debugging thread open, halted at a 
breakpoint (the "Stop" icon is lit), and with the breakpoint definitions in 
some "projectA" in place. Suppose some "ClassB" is a class in some 
"projectB". I discover, in looking at the current code, that a bug is likely 
to be in some method "ClassB.foo". Suppose ClassB.foo will be executed with 
the thread is continued.

Use case 1. I use the file menu to open the source of ClassB. Note that it 
is not in the active project ("projectA"). I navigate to ClassB.foo and set 
a breakpoint. I now open projectB, making projectB the active project.

Use case 2. I use the project menu to open projectB. I navigate to the 
"Project" tab and open ClassB from it. I navigate to ClassB.foo and set a 
breakpoint.

For each use case:
A: What should happen to the screen when I change projects (what windows 
open, what windows close, etc)
B: What should happen when I click the "Debug" button (ie, should the thread 
stop at the new breakpoint)
C: What should appear when I open the "Breakpoint" tab of projectB?

> You use projects in quite a different way from what I use, you use it  to 
> look at subsets of a larger project, and expect your breakpoints  to 
> persist in that context.
>
> I use projects to define a discrete set of code that forms one 
> application (usually a particular site for a customer), where a large 
> body of code is reused between projects. I expect breakpoints to not 
> pollute my other projects.

When you have two projects, each including the shared code, do you include 
the shared code in those projects?

When you are debugging one customer's application and find a problem in the 
shared code, what process do you follow to determine whether that same bug 
also affects other customer applications? Have you tried actually changing 
the projects on the fly? I ask because, at least on my v2.1.4-2, the 
breakpoints leak from project to project anyway. The project seems to 
attempt to remember whatever files are open, the breakpoints come with those 
files, and that creates a leak when changing from project to project for an 
overlapping file.