[67cat][debugger] Expression evaluation issue?

[Claudiu Bulcu]

Hi,

Have you seen the following before?

I have an expression like this:

paramsCount - (subtract--)

both being int variables.

Every time I hover over the selected expression (quick evaluation), the result is incremented over and over again. Is this by design. I would expect that expression being evaluated to the same value, regardless what the subtract value becomes later in my code.

Try this at home with NB 6.7 RC3.

Regards,

--
Claudiu Bulcu
Software Developer

"A wise person will listen and take in more instruction, and a man of understanding is the one who acquires skillful direction"

http://udy.smugmug.com
www.bulcu.ro

[Claudiu Bulcu]

Wow,

This issue has some nasty consequences on the next steps, because the quick eval also decrement "subtract", which loses its real value during the debugging process, and the data gets corrupted.

This has to be a showstopper.

On Thu, Jun 18, 2009 at 12:00 AM, Claudiu Bulcu <cbulcu@...> wrote:

Hi,

Have you seen the following before?

I have an expression like this:

paramsCount - (subtract--)

both being int variables.

Every time I hover over the selected expression (quick evaluation), the result is incremented over and over again. Is this by design. I would expect that expression being evaluated to the same value, regardless what the subtract value becomes later in my code.

Try this at home with NB 6.7 RC3.

Regards,

--
Claudiu Bulcu
Software Developer

"A wise person will listen and take in more instruction, and a man of understanding is the one who acquires skillful direction"

http://udy.smugmug.com
www.bulcu.ro

--
Claudiu Bulcu
Software Developer

"A wise person will listen and take in more instruction, and a man of understanding is the one who acquires skillful direction"

http://udy.smugmug.com
www.bulcu.ro

[Claudiu Bulcu]

You have a sample project attached to play with.

Run the application, and see the normal output.

Then break the execution before the
int dif = ...
line, and play with quick evaluation. You'll end up with a surprise value written out to the console.

On Thu, Jun 18, 2009 at 12:22 AM, Claudiu Bulcu <cbulcu@...> wrote:

Wow,

This issue has some nasty consequences on the next steps, because the quick eval also decrement "subtract", which loses its real value during the debugging process, and the data gets corrupted.

This has to be a showstopper.

On Thu, Jun 18, 2009 at 12:00 AM, Claudiu Bulcu <cbulcu@...> wrote:

Hi,

Have you seen the following before?

I have an expression like this:

paramsCount - (subtract--)

both being int variables.

Every time I hover over the selected expression (quick evaluation), the result is incremented over and over again. Is this by design. I would expect that expression being evaluated to the same value, regardless what the subtract value becomes later in my code.

Try this at home with NB 6.7 RC3.

Regards,

--
Claudiu Bulcu
Software Developer

"A wise person will listen and take in more instruction, and a man of understanding is the one who acquires skillful direction"

http://udy.smugmug.com
www.bulcu.ro

--
Claudiu Bulcu
Software Developer

"A wise person will listen and take in more instruction, and a man of understanding is the one who acquires skillful direction"

http://udy.smugmug.com
www.bulcu.ro

--
Claudiu Bulcu
Software Developer

"A wise person will listen and take in more instruction, and a man of understanding is the one who acquires skillful direction"

http://udy.smugmug.com
www.bulcu.ro

[Claudiu Bulcu]

This issue is also there with the Evaluate expression (Ctrl+F9).

On Thu, Jun 18, 2009 at 12:39 AM, Claudiu Bulcu <cbulcu@...> wrote:

You have a sample project attached to play with.

Run the application, and see the normal output.

Then break the execution before the
int dif = ...
line, and play with quick evaluation. You'll end up with a surprise value written out to the console.

On Thu, Jun 18, 2009 at 12:22 AM, Claudiu Bulcu <cbulcu@...> wrote:

Wow,

This issue has some nasty consequences on the next steps, because the quick eval also decrement "subtract", which loses its real value during the debugging process, and the data gets corrupted.

This has to be a showstopper.

On Thu, Jun 18, 2009 at 12:00 AM, Claudiu Bulcu <cbulcu@...> wrote:

Hi,

Have you seen the following before?

I have an expression like this:

paramsCount - (subtract--)

both being int variables.

Every time I hover over the selected expression (quick evaluation), the result is incremented over and over again. Is this by design. I would expect that expression being evaluated to the same value, regardless what the subtract value becomes later in my code.

Try this at home with NB 6.7 RC3.

Regards,

--
Claudiu Bulcu
Software Developer

"A wise person will listen and take in more instruction, and a man of understanding is the one who acquires skillful direction"

http://udy.smugmug.com
www.bulcu.ro

--
Claudiu Bulcu
Software Developer

"A wise person will listen and take in more instruction, and a man of understanding is the one who acquires skillful direction"

http://udy.smugmug.com
www.bulcu.ro

--
Claudiu Bulcu
Software Developer

"A wise person will listen and take in more instruction, and a man of understanding is the one who acquires skillful direction"

http://udy.smugmug.com
www.bulcu.ro

--
Claudiu Bulcu
Software Developer

"A wise person will listen and take in more instruction, and a man of understanding is the one who acquires skillful direction"

http://udy.smugmug.com
www.bulcu.ro

[esmithbss]

This would explain why my app threw an NPE when I tried a quick eval on my debugger process last night.

Apparently it's not just increment/decrement.

Sincerely,

Eric M. Smith

Burning Sun Enterprises

http://typicalisoverrated.com

http://creativity.burningsunenterprises.com

On Jun 17, 2009, at 4:22 PM, Claudiu Bulcu <cbulcu@...> wrote:

Wow,

This issue has some nasty consequences on the next steps, because the quick eval also decrement "subtract", which loses its real value during the debugging process, and the data gets corrupted.

This has to be a showstopper.

On Thu, Jun 18, 2009 at 12:00 AM, Claudiu Bulcu <cbulcu@...> wrote:

Hi,

Have you seen the following before?

I have an expression like this:

paramsCount - (subtract--)

both being int variables.

Every time I hover over the selected expression (quick evaluation), the result is incremented over and over again. Is this by design. I would expect that expression being evaluated to the same value, regardless what the subtract value becomes later in my code.

Try this at home with NB 6.7 RC3.

Regards,

--
Claudiu Bulcu
Software Developer

"A wise person will listen and take in more instruction, and a man of understanding is the one who acquires skillful direction"

http://udy.smugmug.com
www.bulcu.ro

--
Claudiu Bulcu
Software Developer

"A wise person will listen and take in more instruction, and a man of understanding is the one who acquires skillful direction"

http://udy.smugmug.com
www.bulcu.ro

[Jiri Kovalsky]

Hello Claudiu,

I can't open that file. Could you please archive it as ZIP?

Thanks, Jirka

Claudiu Bulcu wrote:

> You have a sample project attached to play with.
>
> Run the application, and see the normal output.
>
> Then break the execution before the
> int dif = ...
> line, and play with quick evaluation. You'll end up with a surprise
> value written out to the console.
>
> On Thu, Jun 18, 2009 at 12:22 AM, wrote:
>
>>  Wow,
>>
>>  This issue has some nasty consequences on the next steps, because
>>  the quick eval also decrement "subtract", which loses its real value
>>  during the debugging process, and the data gets corrupted.
>>
>>  This has to be a showstopper.
>>
>>
>>  On Thu, Jun 18, 2009 at 12:00 AM, Claudiu Bulcu wrote:
>>
>>>  Hi,
>>>
>>>  Have you seen the following before?
>>>
>>>  I have an expression like this:
>>>
>>>  paramsCount - (subtract--)
>>>
>>>  both being int variables.
>>>
>>>  Every time I hover over the selected expression (quick
>>>  evaluation), the result is incremented over and over again. Is
>>>  this by design. I would expect that expression being evaluated
>>>  to the same value, regardless what the subtract value becomes
>>>  later in my code.
>>>
>>>  Try this at home with NB 6.7 RC3.
>>>
>>>  Regards,

[Martin Entlicher]

Claudiu, the expression that you evaluate have the same effect as if you
execute it. This was implemented intentionally, since in the past many
users complained that evaluation of "a = 10" does not set the value to "a".
You're evaluating "subtract--", which is exactly the same as "subtract =
subtract - 1". You're setting a new value to subtract, so no surprise
that it change the program.

The same effect have method evaluation. If you have a method:
doSubtract() {
   subtract--;
}
and evaluate "doSubtract()", the value of "subtract" will also change
and there's nothing we can do about that.

Therefore we've decided that debugger will behave as consistently and
transparently as possible and evaluate everything as if it was executed.

Does that make sense?
Martin

Claudiu Bulcu wrote:

> Hi,
>
> Have you seen the following before?
>
> I have an expression like this:
>
> paramsCount - (subtract--)
>
> both being int variables.
>
> Every time I hover over the selected expression (quick evaluation),
> the result is incremented over and over again. Is this by design. I
> would expect that expression being evaluated to the same value,
> regardless what the subtract value becomes later in my code.
>
> Try this at home with NB 6.7 RC3.
>
> Regards,
>
> --
> Claudiu Bulcu
> Software Developer
>
> "A wise person will listen and take in more instruction, and a man of
> understanding is the one who acquires skillful direction"
>
> http://udy.smugmug.com
> www.bulcu.ro <http://www.bulcu.ro>

[esmithbss]

I'm sorry, but IMO that's about the most useless thing I can think of.  
What you've basically said is that if you're going to debug your
application, if you want to check on something, you've just changed the
state of your program.  This renders your debugging session absolutely
useless.

Every debugger I've worked with separates evaluate from assign so a
person can evaluate the state of the running program at any time, and as
frequently as needed, but only assign a new value when explicitly doing so.

I experienced this bug by mousing over the code and doing an evaluation
of the value under the mouse pointer.  In my case, it threw an NPE which
trashed my debugging session because it bypassed the code I was trying
to test.

I can't see how this could possibly be beneficial because if what you
say holds true, I can't evaluate the parameter values prior to stepping
into the module.

Eric

Martin Entlicher wrote:

> Claudiu, the expression that you evaluate have the same effect as if
> you execute it. This was implemented intentionally, since in the past
> many users complained that evaluation of "a = 10" does not set the
> value to "a".
> You're evaluating "subtract--", which is exactly the same as "subtract
> = subtract - 1". You're setting a new value to subtract, so no
> surprise that it change the program.
>
> The same effect have method evaluation. If you have a method:
> doSubtract() {
>   subtract--;
> }
> and evaluate "doSubtract()", the value of "subtract" will also change
> and there's nothing we can do about that.
>
> Therefore we've decided that debugger will behave as consistently and
> transparently as possible and evaluate everything as if it was executed.
>
> Does that make sense?
> Martin
>
> Claudiu Bulcu wrote:
>> Hi,
>>
>> Have you seen the following before?
>>
>> I have an expression like this:
>>
>> paramsCount - (subtract--)
>>
>> both being int variables.
>>
>> Every time I hover over the selected expression (quick evaluation),
>> the result is incremented over and over again. Is this by design. I
>> would expect that expression being evaluated to the same value,
>> regardless what the subtract value becomes later in my code.
>>
>> Try this at home with NB 6.7 RC3.
>>
>> Regards,
>>
>> --
>> Claudiu Bulcu
>> Software Developer
>>
>> "A wise person will listen and take in more instruction, and a man of
>> understanding is the one who acquires skillful direction"
>>
>> http://udy.smugmug.com
>> www.bulcu.ro <http://www.bulcu.ro>
>

[Claudiu Bulcu]

Hi Jirka,

You have the zip file.

I've also opened an issue here: http://www.netbeans.org/issues/show_bug.cgi?id=167266

But there you'll find the issue as "wontfix", and the reason of it, which I don't agree upon. I agree with Eric, instead.

On Thu, Jun 18, 2009 at 10:26 AM, Jiri Kovalsky <Jiri.Kovalsky@...> wrote:

Hello Claudiu,

I can't open that file. Could you please archive it as ZIP?

Thanks, Jirka

Claudiu Bulcu wrote:

You have a sample project attached to play with.

Run the application, and see the normal output.

Then break the execution before the
int dif = ...
line, and play with quick evaluation. You'll end up with a surprise value written out to the console.

On Thu, Jun 18, 2009 at 12:22 AM, wrote:

 Wow,

 This issue has some nasty consequences on the next steps, because
 the quick eval also decrement "subtract", which loses its real value
 during the debugging process, and the data gets corrupted.

 This has to be a showstopper.

 On Thu, Jun 18, 2009 at 12:00 AM, Claudiu Bulcu wrote:

 Hi,

 Have you seen the following before?

 I have an expression like this:

 paramsCount - (subtract--)

 both being int variables.

 Every time I hover over the selected expression (quick
 evaluation), the result is incremented over and over again. Is
 this by design. I would expect that expression being evaluated
 to the same value, regardless what the subtract value becomes
 later in my code.

 Try this at home with NB 6.7 RC3.

 Regards,

--
Claudiu Bulcu
Software Developer

"A wise person will listen and take in more instruction, and a man of understanding is the one who acquires skillful direction"

http://udy.smugmug.com
www.bulcu.ro

[Claudiu Bulcu]

Hi Martin,

I thought that the evaluator works on copy values... That way my application's flow wouldn't be disrupted, and the debugging would be meaningful (get what expected, according to my in data, an not the data the evaluator brings in). If I wanted to change my data I would have changed (voluntarily) the initial variables values at debug time.

But of course this is an external view of things. Maybe there are technical limitations to achieving that functionality, I'm not aware of.

On Thu, Jun 18, 2009 at 11:36 AM, Martin Entlicher <Martin.Entlicher@...> wrote:

Claudiu, the expression that you evaluate have the same effect as if you execute it. This was implemented intentionally, since in the past many users complained that evaluation of "a = 10" does not set the value to "a".
You're evaluating "subtract--", which is exactly the same as "subtract = subtract - 1". You're setting a new value to subtract, so no surprise that it change the program.

The same effect have method evaluation. If you have a method:
doSubtract() {
 subtract--;
}
and evaluate "doSubtract()", the value of "subtract" will also change and there's nothing we can do about that.

Therefore we've decided that debugger will behave as consistently and transparently as possible and evaluate everything as if it was executed.

Does that make sense?
Martin

Claudiu Bulcu wrote:

Hi,

Have you seen the following before?

I have an expression like this:

paramsCount - (subtract--)

both being int variables.

Every time I hover over the selected expression (quick evaluation), the result is incremented over and over again. Is this by design. I would expect that expression being evaluated to the same value, regardless what the subtract value becomes later in my code.

Try this at home with NB 6.7 RC3.

Regards,

--
Claudiu Bulcu
Software Developer

"A wise person will listen and take in more instruction, and a man of understanding is the one who acquires skillful direction"

http://udy.smugmug.com

www.bulcu.ro <http://www.bulcu.ro>

--
Claudiu Bulcu
Software Developer

"A wise person will listen and take in more instruction, and a man of understanding is the one who acquires skillful direction"

http://udy.smugmug.com
www.bulcu.ro

[Martin Entlicher]

You can always evaluate "subtract" and nothing will be changed. There's
no need to evaluate "subtract--", am I right?
Mouse over "subtract" in expression "paramsCount - (subtract--)" where
nothing is selected, only "subtract" is evaluate, which does not change
anything.

What would you expect debugger would do if you select "subtract = 10"
end evaluate?

-Martin

Eric M. Smith wrote:

> I'm sorry, but IMO that's about the most useless thing I can think
> of.  What you've basically said is that if you're going to debug your
> application, if you want to check on something, you've just changed
> the state of your program.  This renders your debugging session
> absolutely useless.
>
> Every debugger I've worked with separates evaluate from assign so a
> person can evaluate the state of the running program at any time, and
> as frequently as needed, but only assign a new value when explicitly
> doing so.
>
> I experienced this bug by mousing over the code and doing an
> evaluation of the value under the mouse pointer.  In my case, it threw
> an NPE which trashed my debugging session because it bypassed the code
> I was trying to test.
>
> I can't see how this could possibly be beneficial because if what you
> say holds true, I can't evaluate the parameter values prior to
> stepping into the module.
>
> Eric
>
> Martin Entlicher wrote:
>> Claudiu, the expression that you evaluate have the same effect as if
>> you execute it. This was implemented intentionally, since in the past
>> many users complained that evaluation of "a = 10" does not set the
>> value to "a".
>> You're evaluating "subtract--", which is exactly the same as
>> "subtract = subtract - 1". You're setting a new value to subtract, so
>> no surprise that it change the program.
>>
>> The same effect have method evaluation. If you have a method:
>> doSubtract() {
>>   subtract--;
>> }
>> and evaluate "doSubtract()", the value of "subtract" will also change
>> and there's nothing we can do about that.
>>
>> Therefore we've decided that debugger will behave as consistently and
>> transparently as possible and evaluate everything as if it was executed.
>>
>> Does that make sense?
>> Martin
>>
>> Claudiu Bulcu wrote:
>>> Hi,
>>>
>>> Have you seen the following before?
>>>
>>> I have an expression like this:
>>>
>>> paramsCount - (subtract--)
>>>
>>> both being int variables.
>>>
>>> Every time I hover over the selected expression (quick evaluation),
>>> the result is incremented over and over again. Is this by design. I
>>> would expect that expression being evaluated to the same value,
>>> regardless what the subtract value becomes later in my code.
>>>
>>> Try this at home with NB 6.7 RC3.
>>>
>>> Regards,
>>>
>>> --
>>> Claudiu Bulcu
>>> Software Developer
>>>
>>> "A wise person will listen and take in more instruction, and a man
>>> of understanding is the one who acquires skillful direction"
>>>
>>> http://udy.smugmug.com
>>> www.bulcu.ro <http://www.bulcu.ro>
>>

[Claudiu Bulcu]

One more thing. I was greatly annoyed during a debugging session on a real application, having just that scenario. I just kept receiving IndexOutOfBoundException, after evaluation of that expression, and I thought that my application's logic was at thought. Really frustrating...

--
Claudiu Bulcu
Software Developer

"A wise person will listen and take in more instruction, and a man of understanding is the one who acquires skillful direction"

http://udy.smugmug.com
www.bulcu.ro

[Claudiu Bulcu]

OK, since that behaviour is by design, I won't consider it as a bug anymore, but it remains a big annoyance :-P.

I noticed too that Eclipse implements it the same way, also Idea. But just because every major java IDE does it that way, it doesn't mean it is the right way (it feels wrong, more precisely, based on the debugging experience I described above). Or maybe the "Evaluate expression" should be known as "Evaluate, and modify expression" :-P

I still feel that it would be useful to have the quick evaluation work on copies, somehow, and leave the state of the application unchanged. Is this even possible? Can you tell me this Martin? If it is, would it be hard to implement?

--
Claudiu Bulcu
Software Developer

"A wise person will listen and take in more instruction, and a man of understanding is the one who acquires skillful direction"

http://udy.smugmug.com
www.bulcu.ro

[Martin Entlicher]

If you receive some exceptions, please file them into Issuezilla. We
need the full stack trace of the exception to locate the problem.

-Martin

Claudiu Bulcu wrote:

> One more thing. I was greatly annoyed during a debugging session on a
> real application, having just that scenario. I just kept receiving
> IndexOutOfBoundException, after evaluation of that expression, and I
> thought that my application's logic was at thought. Really frustrating...
>
> --
> Claudiu Bulcu
> Software Developer
>
> "A wise person will listen and take in more instruction, and a man of
> understanding is the one who acquires skillful direction"
>
> http://udy.smugmug.com
> www.bulcu.ro <http://www.bulcu.ro>

[Martin Entlicher]

Claudiu Bulcu wrote:
> OK, since that behaviour is by design, I won't consider it as a bug
> anymore, but it remains a big annoyance :-P.

I understand that unwanted modification of the application state is
annoying. But as I described, the same problem can happen by method
invocation.

> I noticed too that Eclipse implements it the same way, also Idea. But
> just because every major java IDE does it that way, it doesn't mean it
> is the right way (it feels wrong, more precisely, based on the
> debugging experience I described above). Or maybe the "Evaluate
> expression" should be known as "Evaluate, and modify expression" :-P

It's not that we'd copy functionality of Eclipse or Idea here. It's just
that we see the current behavior more consistent. And I just checked
Eclipse to find out if they see it in the same way.

> I still feel that it would be useful to have the quick evaluation work
> on copies, somehow, and leave the state of the application unchanged.
> Is this even possible? Can you tell me this Martin? If it is, would it
> be hard to implement?

It is possible for assignments. Evaluation of expressions is interpreted
on copies, therefore we can ignore assignments. But it's not possible
for changes made inside methods. When you call a method that change
variables, we can not do anything about it. We'd have to interpret the
method execution, which would be an overkill.

It would not be that hard to implement, but I do not feel like this is
what we should do. Just because we can not save your application from
modifications through method calls - that would produce inconsistent
behavior. Imagine evaluation of something like:
"Math.sqrt(a = (x*x + y*y)) + adjustment()" where method adjustment()
works with "a" field. If we would not set "a" to the computed value,
adjustment() would return a nonsense.

Past versions of NetBeans did ignore assignments in expressions and it
was a subject of complaints. In my view current behavior is more correct
and you simply need to pay attention to what you're evaluating.

Also, please note, that any "tooltip" evaluations in Editor should not
do any harm unless you select something. By default only values of
variables are shown (their toString() values, thus we suppose that
toString() should not have any side-effects).

-Martin

>
> --
> Claudiu Bulcu
> Software Developer
>
> "A wise person will listen and take in more instruction, and a man of
> understanding is the one who acquires skillful direction"
>
> http://udy.smugmug.com
> www.bulcu.ro <http://www.bulcu.ro>

[Claudiu Bulcu]

Hi Martin,

The exceptions were thrown in my code, not in NB, after the quick evaluation changed the variable's value, and used the new value to access a list element. So you understand my annoyance.

On Thu, Jun 18, 2009 at 2:26 PM, Martin Entlicher <Martin.Entlicher@...> wrote:

If you receive some exceptions, please file them into Issuezilla. We need the full stack trace of the exception to locate the problem.

-Martin

Claudiu Bulcu wrote:

One more thing. I was greatly annoyed during a debugging session on a real application, having just that scenario. I just kept receiving IndexOutOfBoundException, after evaluation of that expression, and I thought that my application's logic was at thought. Really frustrating...

--
Claudiu Bulcu
Software Developer

"A wise person will listen and take in more instruction, and a man of understanding is the one who acquires skillful direction"

http://udy.smugmug.com

www.bulcu.ro <http://www.bulcu.ro>

--
Claudiu Bulcu
Software Developer

"A wise person will listen and take in more instruction, and a man of understanding is the one who acquires skillful direction"

http://udy.smugmug.com
www.bulcu.ro

[Martin Entlicher]

O.K. I see.
-Martin

Claudiu Bulcu wrote:

> Hi Martin,
>
> The exceptions were thrown in my code, not in NB, after the quick
> evaluation changed the variable's value, and used the new value to
> access a list element. So you understand my annoyance.
>
> On Thu, Jun 18, 2009 at 2:26 PM, Martin Entlicher
> <Martin.Entlicher@... <mailto:Martin.Entlicher@...>> wrote:
>
>     If you receive some exceptions, please file them into Issuezilla.
>     We need the full stack trace of the exception to locate the problem.
>
>     -Martin
>
>     Claudiu Bulcu wrote:
>
>         One more thing. I was greatly annoyed during a debugging
>         session on a real application, having just that scenario. I
>         just kept receiving IndexOutOfBoundException, after evaluation
>         of that expression, and I thought that my application's logic
>         was at thought. Really frustrating...
>
>         --
>         Claudiu Bulcu
>         Software Developer
>
>         "A wise person will listen and take in more instruction, and a
>         man of understanding is the one who acquires skillful direction"
>
>         http://udy.smugmug.com
>         www.bulcu.ro <http://www.bulcu.ro> <http://www.bulcu.ro>
>
>
>
>
> --
> Claudiu Bulcu
> Software Developer
>
> "A wise person will listen and take in more instruction, and a man of
> understanding is the one who acquires skillful direction"
>
> http://udy.smugmug.com
> www.bulcu.ro <http://www.bulcu.ro>

[esmithbss]

The problem is bigger than just what is evaluated.  The problem is the  
scope of the evaluation.

If I'm debugging an application and try to do an evaluation on a  
variable, I want that evaluation to use the current debugger values as  
a starting point, but it shouldn't change the state of my debugger  
until my main instruction pointer actually steps or runs through the  
code.

In my specific case I was trying to track down a null pointer and the  
evaluator three an NPR from it's execution into my debugger scope.  
The result was a loss of almost 20 minutes of meticulous work because  
the exception was thrown out of the exception handlers scope.

Definately bad form for the evaluator.


Sincerely,

Eric M. Smith
Burning Sun Enterprises
http://typicalisoverrated.com
http://creativity.burningsunenterprises.com

On Jun 18, 2009, at 4:53 AM, Martin Entlicher  
<Martin.Entlicher@...> wrote:

> You can always evaluate "subtract" and nothing will be changed.  
> There's no need to evaluate "subtract--", am I right?
> Mouse over "subtract" in expression "paramsCount - (subtract--)"  
> where nothing is selected, only "subtract" is evaluate, which does  
> not change anything.
>
> What would you expect debugger would do if you select "subtract =  
> 10" end evaluate?
>
> -Martin
>
> Eric M. Smith wrote:
>> I'm sorry, but IMO that's about the most useless thing I can think  
>> of.  What you've basically said is that if you're going to debug  
>> your application, if you want to check on something, you've just  
>> changed the state of your program.  This renders your debugging  
>> session absolutely useless.
>>
>> Every debugger I've worked with separates evaluate from assign so a  
>> person can evaluate the state of the running program at any time,  
>> and as frequently as needed, but only assign a new value when  
>> explicitly doing so.
>>
>> I experienced this bug by mousing over the code and doing an  
>> evaluation of the value under the mouse pointer.  In my case, it  
>> threw an NPE which trashed my debugging session because it bypassed  
>> the code I was trying to test.
>>
>> I can't see how this could possibly be beneficial because if what  
>> you say holds true, I can't evaluate the parameter values prior to  
>> stepping into the module.
>>
>> Eric
>>
>> Martin Entlicher wrote:
>>> Claudiu, the expression that you evaluate have the same effect as  
>>> if you execute it. This was implemented intentionally, since in  
>>> the past many users complained that evaluation of "a = 10" does  
>>> not set the value to "a".
>>> You're evaluating "subtract--", which is exactly the same as  
>>> "subtract = subtract - 1". You're setting a new value to subtract,  
>>> so no surprise that it change the program.
>>>
>>> The same effect have method evaluation. If you have a method:
>>> doSubtract() {
>>>  subtract--;
>>> }
>>> and evaluate "doSubtract()", the value of "subtract" will also  
>>> change and there's nothing we can do about that.
>>>
>>> Therefore we've decided that debugger will behave as consistently  
>>> and transparently as possible and evaluate everything as if it was  
>>> executed.
>>>
>>> Does that make sense?
>>> Martin
>>>
>>> Claudiu Bulcu wrote:
>>>> Hi,
>>>>
>>>> Have you seen the following before?
>>>>
>>>> I have an expression like this:
>>>>
>>>> paramsCount - (subtract--)
>>>>
>>>> both being int variables.
>>>>
>>>> Every time I hover over the selected expression (quick  
>>>> evaluation), the result is incremented over and over again. Is  
>>>> this by design. I would expect that expression being evaluated to  
>>>> the same value, regardless what the subtract value becomes later  
>>>> in my code.
>>>>
>>>> Try this at home with NB 6.7 RC3.
>>>>
>>>> Regards,
>>>>
>>>> --
>>>> Claudiu Bulcu
>>>> Software Developer
>>>>
>>>> "A wise person will listen and take in more instruction, and a  
>>>> man of understanding is the one who acquires skillful direction"
>>>>
>>>> http://udy.smugmug.com
>>>> www.bulcu.ro <http://www.bulcu.ro>
>>>

[esmithbss]

I would expect the evaluator to work much like the rails console.  It  
should be an area where I can experiment/evaluate what may happen  
without affecting my running app.  I would expect people would change  
values of variables through the variables pane using editable fields  
when a value display is double-clicked, or the elipses button is  
pressed.

Sincerely,

Eric M. Smith
Burning Sun Enterprises
http://typicalisoverrated.com
http://creativity.burningsunenterprises.com

On Jun 18, 2009, at 4:53 AM, Martin Entlicher  
<Martin.Entlicher@...> wrote:

> You can always evaluate "subtract" and nothing will be changed.  
> There's no need to evaluate "subtract--", am I right?
> Mouse over "subtract" in expression "paramsCount - (subtract--)"  
> where nothing is selected, only "subtract" is evaluate, which does  
> not change anything.
>
> What would you expect debugger would do if you select "subtract =  
> 10" end evaluate?
>
> -Martin
>
> Eric M. Smith wrote:
>> I'm sorry, but IMO that's about the most useless thing I can think  
>> of.  What you've basically said is that if you're going to debug  
>> your application, if you want to check on something, you've just  
>> changed the state of your program.  This renders your debugging  
>> session absolutely useless.
>>
>> Every debugger I've worked with separates evaluate from assign so a  
>> person can evaluate the state of the running program at any time,  
>> and as frequently as needed, but only assign a new value when  
>> explicitly doing so.
>>
>> I experienced this bug by mousing over the code and doing an  
>> evaluation of the value under the mouse pointer.  In my case, it  
>> threw an NPE which trashed my debugging session because it bypassed  
>> the code I was trying to test.
>>
>> I can't see how this could possibly be beneficial because if what  
>> you say holds true, I can't evaluate the parameter values prior to  
>> stepping into the module.
>>
>> Eric
>>
>> Martin Entlicher wrote:
>>> Claudiu, the expression that you evaluate have the same effect as  
>>> if you execute it. This was implemented intentionally, since in  
>>> the past many users complained that evaluation of "a = 10" does  
>>> not set the value to "a".
>>> You're evaluating "subtract--", which is exactly the same as  
>>> "subtract = subtract - 1". You're setting a new value to subtract,  
>>> so no surprise that it change the program.
>>>
>>> The same effect have method evaluation. If you have a method:
>>> doSubtract() {
>>>  subtract--;
>>> }
>>> and evaluate "doSubtract()", the value of "subtract" will also  
>>> change and there's nothing we can do about that.
>>>
>>> Therefore we've decided that debugger will behave as consistently  
>>> and transparently as possible and evaluate everything as if it was  
>>> executed.
>>>
>>> Does that make sense?
>>> Martin
>>>
>>> Claudiu Bulcu wrote:
>>>> Hi,
>>>>
>>>> Have you seen the following before?
>>>>
>>>> I have an expression like this:
>>>>
>>>> paramsCount - (subtract--)
>>>>
>>>> both being int variables.
>>>>
>>>> Every time I hover over the selected expression (quick  
>>>> evaluation), the result is incremented over and over again. Is  
>>>> this by design. I would expect that expression being evaluated to  
>>>> the same value, regardless what the subtract value becomes later  
>>>> in my code.
>>>>
>>>> Try this at home with NB 6.7 RC3.
>>>>
>>>> Regards,
>>>>
>>>> --
>>>> Claudiu Bulcu
>>>> Software Developer
>>>>
>>>> "A wise person will listen and take in more instruction, and a  
>>>> man of understanding is the one who acquires skillful direction"
>>>>
>>>> http://udy.smugmug.com
>>>> www.bulcu.ro <http://www.bulcu.ro>
>>>

[esmithbss]

Unfortunately, the tool tip evaluation is not quite as clean as you  
assume.

In my case, my method threw an exception during the evaluation inside  
a method.  The method was a getter but that doesn't matter when  
tracking down an NPE.

Sincerely,

Eric M. Smith
Burning Sun Enterprises
http://typicalisoverrated.com
http://creativity.burningsunenterprises.com

On Jun 18, 2009, at 6:46 AM, Martin Entlicher  
<Martin.Entlicher@...> wrote:

> Claudiu Bulcu wrote:
>> OK, since that behaviour is by design, I won't consider it as a bug  
>> anymore, but it remains a big annoyance :-P.
>
> I understand that unwanted modification of the application state is  
> annoying. But as I described, the same problem can happen by method  
> invocation.
>
>> I noticed too that Eclipse implements it the same way, also Idea.  
>> But just because every major java IDE does it that way, it doesn't  
>> mean it is the right way (it feels wrong, more precisely, based on  
>> the debugging experience I described above). Or maybe the "Evaluate  
>> expression" should be known as "Evaluate, and modify expression" :-P
>
> It's not that we'd copy functionality of Eclipse or Idea here. It's  
> just that we see the current behavior more consistent. And I just  
> checked Eclipse to find out if they see it in the same way.
>
>> I still feel that it would be useful to have the quick evaluation  
>> work on copies, somehow, and leave the state of the application  
>> unchanged. Is this even possible? Can you tell me this Martin? If  
>> it is, would it be hard to implement?
>
> It is possible for assignments. Evaluation of expressions is  
> interpreted on copies, therefore we can ignore assignments. But it's  
> not possible for changes made inside methods. When you call a method  
> that change variables, we can not do anything about it. We'd have to  
> interpret the method execution, which would be an overkill.
>
> It would not be that hard to implement, but I do not feel like this  
> is what we should do. Just because we can not save your application  
> from modifications through method calls - that would produce  
> inconsistent behavior. Imagine evaluation of something like:
> "Math.sqrt(a = (x*x + y*y)) + adjustment()" where method  
> adjustment() works with "a" field. If we would not set "a" to the  
> computed value, adjustment() would return a nonsense.
>
> Past versions of NetBeans did ignore assignments in expressions and  
> it was a subject of complaints. In my view current behavior is more  
> correct and you simply need to pay attention to what you're  
> evaluating.
>
> Also, please note, that any "tooltip" evaluations in Editor should  
> not do any harm unless you select something. By default only values  
> of variables are shown (their toString() values, thus we suppose  
> that toString() should not have any side-effects).
>
> -Martin
>
>>
>> --
>> Claudiu Bulcu
>> Software Developer
>>
>> "A wise person will listen and take in more instruction, and a man  
>> of understanding is the one who acquires skillful direction"
>>
>> http://udy.smugmug.com
>> www.bulcu.ro <http://www.bulcu.ro>