Re: Run/Debug profiles

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?

The VM behaves differently, although it still executes user .class 
files. I would also argue that profiling (-Xrunhprof...) is also a 
special kind of execution. But special in the OO sense: may add 
attributes/behaviours to the execution.

I fear that you understood "special" in the sense that debug profiles 
should be presented separately from execution ones. NO! The "special 
kind" was to indicate that debugging is not THAT different from 
execution so it is inherently a completely different activity.

> 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?
> 
The user application can not. But you can attach a debugger to the app 
and pause the execution. You can not do that if the VM is started 
without "-Xdebug...".

> 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?
Ivan, this is off topic in the sense my statement was meant. I was not 
considering a particular GUI (and also not current NetBeans GUI) at all

> 
> I"m not trying to just be picky about semantics. 
> The activity of debugging starts before one executes things.
> 
[snip]
> 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).
Good.

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

Yes, it seems that we are in a violent agreement.

> 
> 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:
> 
[snip ascii art]
> 	
> Thus there would be no distinction between setting an active
> profile for running vs debugging ...	
> 	 
Eclipse does not do the distinction. The user defines a profile and opts 
to include it into "Favourities" for debugging or execution. But even if 
the profile is no. See the other messages for IntelliJ/Eclipse comparison.

> 
> Some other things to worry about:
> 
> 	different debuggers (or profilers might require different 
> 	properties in the profile).
> 	
No big problem (at least I think) -- additional pages can be hooked into 
the Customizer.

> 	These properties might evolve over time, a debugger
> 	module might be disabled and enabled yet the profile
> 	properties might have to persist.
> 
No problem at all -- the project's settings system takes care of that.

-Svata