[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [dsdp-dd-dev] Re: FW: Load/save/fill memory operations
|
Hi -
That's the first time I have seen people fighting for work! :)
Re: reading / writing on a job.
I agree. Any interaction with the memory block should be done on a job to
avoid blocking the UI thread.
Re: verify option
My concern here is performance. Writing and reading memory could take a
long time. I am not sure if verifying the write operation to a memory
block should be an UI's responsibility. For example, when the user modifies
memory using a memory rendering, UI does not try to verify memory after
modification. Would catching DebugException from the memory block be
enough? (IMemoryBlockExtension#setValues(...) throws DebugException if
there is an error.)
In addition, I imagine that the verification will be done by the action /
dialog that's doing the import. Since we do not want to hold up the UI
thread during verification, the verification will be done on a job. If
verification fails some time later, how are we going to report the error?
Popping up an error dialog some time after the import operation could be
annoying if the user is already doing something else.
Re: CopyToClipboardAction
I don't think reusing CopyTableRenderingToClipboard action is going to work
very well. The action goes through the rendering to ask for its content
and put it onto the clipboard. In an export operation, we are exporting
raw memory. We don't want the exported content to be rendered in any way.
Otherwise, the import operation will be complex to write. The import
operation has to know how memory was previously rendered and exported in
order to decode the file and write it back to a memory block again. I
think both the import / export actions should be done independent of any
rendering. They should only talk directly to a memory block.
Re: Support for expression in the import / export dialog
It would be useful if the user wants to export / import a chunk of memory
from a register / variable. User can simply enter a register name /
variable name during an import / export. Since the actions are
retargettable, clients can override that action to provide customized
dialog to support expression evaluation.
Would it help if I assign this feature to one of you so that others know
that you are working on this feature?
Thanks...
Samantha
John Cortell
<john.cortell@fre
escale.com> To
Sent by: "Williams, Ted"
dsdp-dd-dev-bounc <ted.williams@xxxxxxxxxxxxx>,
es@xxxxxxxxxxx <dsdp-dd-dev@xxxxxxxxxxx>
cc
04/04/2006 12:30 Subject
AM [dsdp-dd-dev] Re: FW:
Load/save/fill memory operations
Please respond to
Device Debugging
developer
discussions
Ted,
I'll be more than happy to yield this feature to you :-) I've got a million
other things to do, so I have no problem letting this one go. This is a
must-have feature for our first Eclipse based product, and that's why I was
going to jump on it. If you were planning on contributing this anytime in
the next six months or so, that would work for us. And of course, I'll be
more than happy to work with you on the feature if you'd like to team up on
it.
See my comments inlined below:
At 09:36 PM 4/3/2006, Williams, Ted wrote:
John,
Yes, I've been planning to contribute such a feature, but (oops) I
wasn't aware of the bugzilla. If you're planning to implement this
soon,
I'll hold off. :-)
I understand the feature will be extensible, but I'd like to add a
few
thoughts in addition to what I see in the bugzilla.
- The reading/writing should happen on a Job. Large chunks can take
substantial time to transfer to and from embedded targets. The cancel
flag should be checked periodically, between read and write requests.
Definitely.
- Would a verify option (checkbox in the dialog, read and compare
after
write during the download) be useful?
Sure.
- There may be some overlap with the "copy to clipboard" action.
Maybe
copy and paste could be shortcuts to import/export actions or at
least
some of the code could be reused? Export to textual is similar to
copy.
Indeed, there's overlap, but I'm not sure there will be a good mapping
between copy&paste and the actions. If we can think of copy&paste as an
import/export action with a fixed, pre-defined set of parameters...but even
there, the destinations are quite different. I imagine there's potential
for code reuse but not a direct link between the two sets of actions.
- Any thoughts on supporting expressions in the address field of the
import/export dialog?
I think Samantha and I were envisioning import/export being retargetable
actions that could be invoked from, say, the context menu of the variable
view and expression. To that extent, expressions would be supported, but
such an action would bring up the dialog with the physical ptr/variable
value/address as the start address, pre-populated in the dialog. Whether we
should directly support expressions in the dialog...I suppose, but I don't
see a pressing need for it.
John_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
