Re: Run/Debug profiles

Interesting ramble.  Looks like Petr, Svata and Ivan
are all in agreement that we do not need separate
Debug and Run profiles.  I agree.

We need to ask if the user is better off if we make
two profiles or one.  There seems to be agreement that
the same info is needed for both, so the value of two
profiles is unclear.

To quibble about semantics with Ivan, I consider debugging
as a special kind of execution, both from the user's point
of view and the implementation point of view.  Implementation
is easy, in the Java world it means starting the VM with
certain cmd-lines flags.  From the user's point of view,
IDEs provide the user with both Run and Debug actions.  With
Run, breakpoints are ignored and, with Debug, they are active.
However, running and debugging the same profile makes sense.

I've heard an argument that in some scenarios a debugged
version of a jar file should be used.  The Debug profile
would allow this user to specify a different classpath.
Personally, I don't find this scenario very compelling
as I don't think it occurs very often.

	Evan


Ivan Soleimanipour wrote:
>>From: Svata Dedic <[email protected]>
>>
>>I, too, think (I hope that Hanz forgives me) that "debugging" is a
>>special kind of "execution". In addition, in the real world, when an
>>application does not work for particular startup parameters (a.k.a. Run
>>profile), the developer usually goes to debugger to find why it is so.
> 
> 
> 
> Are you sure about this?
> What makes a debugging run special?
> If you don't have bpts or watches and you run under a debugger how
> can you distinguish this run from a non-debugging run?
> 
> I disgaree with the above statement that debugging is a special kind of
> execution. When you place a bpt or a watch are you debugging?  I
> believe the answer is yes.  But then you're placing them before you
> "run", so how can a debug run be like execution?
> 
> On the other hand given the NB experience with workspaces maybe
> the "yes" answer above isn't quite right? One can place bpts 
> in the editing workspace and an automatic switch happens to 
> the debugging workspace when you run. So does that mean that
> placing bpts is an editing activity?
> 
> I"m not trying to just be picky about semantics. 
> The activity of debugging starts before one executes things.
> 
> One might identify a "program" to be debugged. Once this is done the
> "program" can be used as basis against which one can validate bpts
> watches or answer static queries. Under NB you have the MDR which can
> answer many of these questions, but in other language systems (C++)
> there might not neccessaily be an MDR and a debugger has to be started
> first (The existence of a debugger"  can be hidden or virtualised so
> that the user isn't aware of something called the debugger).
> 
> I think it would be interesting if one contemplates the 
> meaning of the word program.
> 	It might be fun to read "notes on Postmodern Programming"
> 	at http://www.mcs.vuw.ac.nz/comp/Publications/CS-TR-02-9.abs.html
> 	in this regard.
> 	
> To cut to the chase I like to define a program as a set of 
> starting conditions. For example a specific version of 'java' + 
> a CLASSPATH + the starting class.  Or an executable plus LD_LIBRARY_PATH
> (of course LD_LIBRARY_PATH is sometimes neccessary for Java as well since
> it might have JNI).
> 
> This is good enough for "execution". For debugging you might need a 
> bit more because many "programs" have dynamic loading of stuff (not
> the regular class loadoing but say specialized classloaders like in NB
> which load things in dependently of CLASSPATH) 
> 
> You might notice that this definition of program fits what you're
> talking abuot as "profile". It also seems like a debugging profile is
> an extension of a run profile so an inheritance or cloning scheme 
> might make good sense.
> 
> So, what is the practical side-effect of all this rambling on
> projects? Inasmuch as one might debug by System.out.println()//NOI18N
> running is also a debugging activity. I'd like to argue that 
> run and debug profiles should not be separated. That for
> a given profile a lot of the startup conditions are the same you'd
> need under a debugging run. So I'd make the profiles look like this:
> 
> 
> 	+----------------
> 	| generic stuff:
> 	|		 VM:
> 	|	  classpath:
> 	|	 main class:	
> 	| for jpda debugger:
> 	|              blah:
> 	| for profiler:
> 	|                foo:
> 	|  Solaris debugger:
> 	| extended classpath:
> 	| ...
> 	+---------------------
> 	
> Thus there would be no distinction between setting an active
> profile for running vs debugging ...	
> 	 
> 
> Some other things to worry about:
> 
> 	different debuggers (or profilers might require different 
> 	properties in the profile).
> 	
> 	These properties might evolve over time, a debugger
> 	module might be disabled and enabled yet the profile
> 	properties might have to persist.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>