Re: Run/Debug profiles

> 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.