Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-debug-dev] Re: platform-debug-dev digest, Vol 1 #23 - 1 msg


>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


I think that this will be OK. Since you own the implementation of an _expression_, you can decide when/how it connects to an engine.

Darin



boxall@xxxxxxxxxx
Sent by: platform-debug-dev-admin@xxxxxxxxxxx

12/05/2001 03:46 PM
Please respond to platform-debug-dev

       
        To:        platform-debug-dev@xxxxxxxxxxx
        cc:        
        Subject:        [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 &quot;expired&quot; _expression_
refers to an _expression_ that can no longer be evaluated. For example, when
I &quot;inspect&quot; 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 &quot;expiration&quot; comes from an
implementation of an _expression_ (i.e. from the inside). </font>
<br>
<br><font size=2 face="sans-serif">Note, that the &quot;expiration&quot;
depends on an implementation. For an &quot;inspected&quot; expresion an
exipration occurrs when the inspected object can no longer be seen (garbage
collected, VM dies). For a &quot;watch item&quot;, 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
&quot;inspected&quot; _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 &quot;watch item&quot; will evaluate only
when a thread suspends in a specific location.</font>
<br>
<br><font size=2 face="sans-serif">(3) Regarding &quot;turning off&quot; an
_expression_. An implementation could choose to &quot;disable&quot; an
_expression_. This would seem reasonable for &quot;watch items&quot;.</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">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp;
&nbsp; &nbsp; &nbsp;platform-debug-dev@xxxxxxxxxxx</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp;
&nbsp; &nbsp; &nbsp;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject:
&nbsp; &nbsp; &nbsp; &nbsp;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. &nbsp;</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="sans-serif"><br>
-- What is an &quot;expired&quot; _expression_ -- one that cannot be
evaluated because it's components are out of scope, one that has be marked
&quot;disabled&quot; 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. &nbsp; Expressions may also be asked for their
value, for example by UI hitting reaching a suspend point with a watched
_expression_. &nbsp;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



_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-debug-dev



Back to the top