Requests for Delhi2009/2010
Tommi Prami
(disclaimer: if these are user errors, please let me know :) )
one of the most annoying things are:
1. Debugger don't show variable value while hovering on top of it.
- This happens a lot. Some times it works sometimes don't
2. Debugger don't understand with statement
- This is really annoying, when you make code simper to read
by with statement, it makes debugging harder
3. Can't figure out how I could make 1. "DeskTop"
always active for debugging and 1. for coding
- It was so but now it somehow is broken, and
just don't know how I could define which
desktop is used when...
-Tommi Prami-
Peter Below (TeamB)
If you want to make feature requests the location to make them on is
qc.codegear.com.
These groups are peer support groups and have no guaranteed Codegear
presence.
> one of the most annoying things are:
>
> 1. Debugger don't show variable value while hovering on top of it.
> - This happens a lot. Some times it works sometimes don't
It depends on whether the compiler decided to keep some variable in a
register or in a stack location. This is optimization at work. For
variables kept in registers the register may get reused after the last
statement that made use of the variables value, and after that the
original value is simply not there anymore. If you try to evaluate it
at such a location via the Run->Evaluate/Modify dialog, or have a watch
on it the IDE will tell you that the variable is not accessible anymore
due to optimization. Disabling such optimization for debugging, e.g.
through a setting in the project options would require a lot of changes
to the compiler, I imagine, and the chance of that being done is so
close to zero as to be indistinguishable from it <g>.
>
> 2. Debugger don't understand with statement
> - This is really annoying, when you make code simper to read
> by with statement, it makes debugging harder
With statements are a source of error, nothing more. They may make code
easier to write (less typing) and easier to read (less text to parse)
but massively harder to *understand*, and that is the metric you should
use.
>
> 3. Can't figure out how I could make 1. "DeskTop"
> always active for debugging and 1. for coding
> - It was so but now it somehow is broken, and
> just don't know how I could define which
> desktop is used when...
View->Desktops-> set debug desktop (caption may be different, I'm
extrapolating from the german IDE here).
This defines the current desktop as the standard debug desktop. The
normal one used during editing is the last one you selected from the
desktop dropdown in the IDEs main toolbar or from the view menu.
--
Peter Below (TeamB)
Don't be a vampire (http://slash7.com/pages/vampires),
use the newsgroup archives :
http://www.tamaracka.com/search.htm
http://groups.google.com
Jim P
> Tommi Prami wrote:
>
> If you want to make feature requests the location to make them on is
> qc.codegear.com.
> These groups are peer support groups and have no guaranteed Codegear
> presence.
>
>> one of the most annoying things are:
>>
>> 1. Debugger don't show variable value while hovering on top of it.
>> - This happens a lot. Some times it works sometimes don't
>
> It depends on whether the compiler decided to keep some variable in a
> register or in a stack location. This is optimization at work. For
> variables kept in registers the register may get reused after the last
> statement that made use of the variables value, and after that the
> original value is simply not there anymore. If you try to evaluate it
> at such a location via the Run->Evaluate/Modify dialog, or have a watch
> on it the IDE will tell you that the variable is not accessible anymore
> due to optimization. Disabling such optimization for debugging, e.g.
> through a setting in the project options would require a lot of changes
> to the compiler, I imagine, and the chance of that being done is so
> close to zero as to be indistinguishable from it <g>.
Peter I agree with you here, I have found that at times, I wish that I
could see the variable value, after I have stepped past the variable.
As you say Optimizations are occurring. and I understand why.
What I have found is that a lot of high level - even C level programmers
do not realize that such things exist like registers, or passing on the
stack. They just expect it to all work as expected and do not stop and
realize what is happening under the code - - in the engine so to speak.
but this reminds me of my CPA, He does not care how the car works, he
simply wants to turn the key on and have the car go. Too bad that many
programmers are becoming this way.
As I see from this type of request or comments in the past.
>> 2. Debugger don't understand with statement
>> - This is really annoying, when you make code simper to read
>> by with statement, it makes debugging harder
>
> With statements are a source of error, nothing more. They may make code
> easier to write (less typing) and easier to read (less text to parse)
> but massively harder to *understand*, and that is the metric you should
> use.
I use With statements with care, I keep my code modules simple and
straight forward. I also you very long names for variables (except
local variables ) So the with statement helps me a lot. - - but then
I do not do anything fancy. I do not use with statements that span pages
of code - - if the code is long and has areas that a with statement is
not needed, I will break the with statement up to just the areas that it
is used. To keep it clean and make it clear that a with is involved.
I also stop and look at what I am doing to make sure that I can not have
a problem with the compiler getting confused to which variable or
property that I am referencing. as this can cause major coding problems.
By keeping the with statements simple, do not need to trace into with
statements and monitor variables - - - effected by the use of the with.
But never seem to have with statements inside of with statements inside
of with statements - - - ugh that would be very nasty code. - - - -
Just very simply with statements - -
David Cornelius
> could see the variable value, after I have stepped past the variable.
> As you say Optimizations are occurring. and I understand why.
>
> What I have found is that a lot of high level - even C level programmers
> do not realize that such things exist like registers, or passing on the
> stack. They just expect it to all work as expected and do not stop and
> realize what is happening under the code - - in the engine so to speak.
With the compiler optimization option off, variable hovering works often,
but not always. And when it doesn't, and I have to know the value of a
variable, I turn on CodeSite, an awesome debugging tool!
--
David Cornelius
CorneliusConcepts.com
Tommi Prami
> qc.codegear.com.
> These groups are peer support groups and have no guaranteed Codegear
> presence.
What group??? I'll look into it... Oh' it's QualityCentral. Last time I
looked it scared me away ;) Hope that it is more simple and intuitive
now (for me) ... :)
>> one of the most annoying things are:
>>
>> 1. Debugger don't show variable value while hovering on top of it.
>> - This happens a lot. Some times it works sometimes don't
>
> It depends on whether the compiler decided to keep some variable in a
> register or in a stack location. This is optimization at work.
I'll never debug code that is Optimized. I'll (we) have separate
projects for debug and release. and debug versions have always
Optimizations disabled. If Optimization is disabled debugger should take
care of it (some way), at least when brake point is set into some
method, it should take extra measures to keep all variables alive.
Basically it is just annoying to debug something, and you just can't see
the values. And one of our ViualStudio coders has looked at some of
our Delphi projects and this is driving him nuts. I am kind of used to
it by now, but still I think I would be much more productive if I would
always see variable content while debugging... (or have way to tell
compiler/debugger, that this code can be slower but I need to see
everything what is going on...)
>> 2. Debugger don't understand with statement
>> - This is really annoying, when you make code simper to read
>> by with statement, it makes debugging harder
>
> With statements are a source of error, nothing more. They may make code
> easier to write (less typing) and easier to read (less text to parse)
> but massively harder to *understand*, and that is the metric you should
> use.
True, but if there is with clause, debugger _must_ understand it also.
>
>> 3. Can't figure out how I could make 1. "DeskTop"
>> always active for debugging and 1. for coding
>> - It was so but now it somehow is broken, and
>> just don't know how I could define which
>> desktop is used when...
>
> View->Desktops-> set debug desktop (caption may be different, I'm
> extrapolating from the german IDE here).
> This defines the current desktop as the standard debug desktop. The
> normal one used during editing is the last one you selected from the
> desktop dropdown in the IDEs main toolbar or from the view menu.
Thanks man...
Peter Below (TeamB)
> I'll never debug code that is Optimized. I'll (we) have separate
> projects for debug and release. and debug versions have always
> Optimizations disabled.
There are optimization of different kinds. Some, like using registers
for variables if possible, are hardwired into the compiler and cannot
be disabled. Some others are implemented as a kind of post-processing
of the generated code (a separate step in the build process) and those
can be disabled.