[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[platform-debug-dev] Re: platform-debug-dev digest, Vol 1 #23 - 1 msg
|
From my experience building a compiled debug plugin ...
(1) We have expressions that can't be evaluated because they go out of
context. I would expect
to handle this by sending a change event and the representation of the
expression's value would
indicate that it was out of context.
I have to think about what this means if an expression has expired because
the remote debug engine has terminated. If these expressions are to be
"restored" the next time
the engine connects, then I somehow need to re-connect these expressions to
the engine
connection that makes sense.
I don't really want all expressions to be sent to all new engines
connections in the way that
we handle breakpoints in 1.0
(2) I agree. This is how we do it today. For performance reasons we
expect our remote
debug engines to decide when an expression has changed at which time our
plugin is
told about it. We update the expression and then fire a change event.
Alan Boxall - IBM Distributed Debugger
D1/121/8200/MKM
internet id : boxall@xxxxxxxxxx
Notes: Alan Boxall/Toronto/IBM @ IBMCA
Phn:(905)413-4117 T.L. 969-4117
Fax:(905)413-4850 T.L. 969-4850
(1) An "expired" expression refers to an expression that can no longer be
evaluated. For example, when I "inspect" an expression that results in an
object, and the VM that that object lives in termiantes, the expression
has expired. That is, the object can no longer be inspected becuase it no
longer exists. A user deleting an expression is different - i.e. the
request came from the user (i.e. from the outside). An "expiration" comes
from an implementation of an expression (i.e. from the inside).
Note, that the "expiration" depends on an implementation. For an
"inspected" expresion an exipration occurrs when the inspected object can
no longer be seen (garbage collected, VM dies). For a "watch item", an
expiration may never occurr, as a watch item is an expression that can be
evaluated in many different contexts.
(2) Regarding event firing... it is up to the model to fire an event
whenever the value changes. This is because it is only the implementation
knows when the value has changed and when to evaluate. The generic debug
UI does not know when to evaluate an expression - only the underlying
implementation. For example, and "inspected" expression evaluates when
first inspected, and then its value is updated (but the expression is not
re-evaluated) when a thread in its associated VM suspends. A "watch item"
will evaluate only when a thread suspends in a specific location.
(3) Regarding "turning off" an expression. An implementation could choose
to "disable" an expression. This would seem reasonable for "watch items".
Darin
Dave_Dykstal@xxxxxxx
Sent by: platform-debug-dev-admin@xxxxxxxxxxx
11/28/2001 02:12 PM
Please respond to platform-debug-dev
To: platform-debug-dev@xxxxxxxxxxx
cc:
Subject: Re: [platform-debug-dev] Proposal: Debug
Expressions
Darin --
Just a couple of questions from someone not intimately familiar with the
debugger details.
-- What is an "expired" expression -- one that cannot be evaluated because
it's components are out of scope, one that has be marked "disabled" by the
user, or one that has just been deleted by the user?
-- You mention that expressions must fire an event when the value of an
expression has changed. Expressions may also be asked for their value,
for example by UI hitting reaching a suspend point with a watched
expression. Is it the responsibility of the model to fire the event
whenever the expression changes value or only in response to a request for
the expression to be reevaluated?
and a comment:
-- It seems that an expression may not be able to be evaluated not only
because its dependencies are not met (wrong model, component variable out
of scope, ...) but also because a user has requested that it not be
evaluated until some other point in time -- so there should be some way of
manually turning off evaluation of an expression.
-- Dave
--=_alternative 0056334686256B13_=
Content-Type: text/html; charset="us-ascii"
<br><font size=2 face="sans-serif">(1) An "expired" expression
refers to an expression that can no longer be evaluated. For example, when
I "inspect" an expression that results in an object, and the VM
that that object lives in termiantes, the expression has expired. That is,
the object can no longer be inspected becuase it no longer exists. A user
deleting an expression is different - i.e. the request came from the user
(i.e. from the outside). An "expiration" comes from an
implementation of an expression (i.e. from the inside). </font>
<br>
<br><font size=2 face="sans-serif">Note, that the "expiration"
depends on an implementation. For an "inspected" expresion an
exipration occurrs when the inspected object can no longer be seen (garbage
collected, VM dies). For a "watch item", an expiration may never
occurr, as a watch item is an expression that can be evaluated in many
different contexts.</font>
<br>
<br><font size=2 face="sans-serif">(2) Regarding event firing... it is up
to the model to fire an event whenever the value changes. This is because
it is only the implementation knows when the value has changed and when to
evaluate. The generic debug UI does not know when to evaluate an expression
- only the underlying implementation. For example, and
"inspected" expression evaluates when first inspected, and then
its value is updated (but the expression is not re-evaluated) when a thread
in its associated VM suspends. A "watch item" will evaluate only
when a thread suspends in a specific location.</font>
<br>
<br><font size=2 face="sans-serif">(3) Regarding "turning off" an
expression. An implementation could choose to "disable" an
expression. This would seem reasonable for "watch items".</font>
<br>
<br><font size=2 face="sans-serif">Darin</font>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>Dave_Dykstal@xxxxxxx</b></font>
<br><font size=1 face="sans-serif">Sent by:
platform-debug-dev-admin@xxxxxxxxxxx</font>
<p><font size=1 face="sans-serif">11/28/2001 02:12 PM</font>
<br><font size=1 face="sans-serif">Please respond to
platform-debug-dev</font>
<br>
<td><font size=1 face="Arial"> </font>
<br><font size=1 face="sans-serif"> To:
platform-debug-dev@xxxxxxxxxxx</font>
<br><font size=1 face="sans-serif"> cc:
</font>
<br><font size=1 face="sans-serif"> Subject:
Re: [platform-debug-dev] Proposal: Debug
Expressions</font></table>
<br>
<br><font size=2 face="sans-serif"><br>
Darin --</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="sans-serif"><br>
Just a couple of questions from someone not intimately familiar with the
debugger details. </font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="sans-serif"><br>
-- What is an "expired" expression -- one that cannot be
evaluated because it's components are out of scope, one that has be marked
"disabled" by the user, or one that has just been deleted by the
user? </font><font size=3 face="Times New Roman"><br>
</font><font size=2 face="sans-serif"><br>
-- You mention that expressions must fire an event when the value of an
expression has changed. Expressions may also be asked for their
value, for example by UI hitting reaching a suspend point with a watched
expression. Is it the responsibility of the model to fire the event
whenever the expression changes value or only in response to a request for
the expression to be reevaluated?</font><font size=3 face="Times New
Roman"> <br>
</font><font size=2 face="sans-serif"><br>
and a comment:</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="sans-serif"><br>
-- It seems that an expression may not be able to be evaluated not only
because its dependencies are not met (wrong model, component variable out
of scope, ...) but also because a user has requested that it not be
evaluated until some other point in time -- so there should be some way of
manually turning off evaluation of an expression.</font><font size=3 face
="Times New Roman"> <br>
</font><font size=2 face="sans-serif"><br>
-- Dave</font>
<br>
<br>
--=_alternative 0056334686256B13_=--
--__--__--
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-debug-dev
End of platform-debug-dev Digest
