[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-debug-dev] Memory View Infrastructure Review: Part 1
|
Mikhail -
The memory view and its renderings are going to be synchronized at all
times.
The scrolling, the cursor (i.e. highlighted cell in the table), and the
column size (number of bytes to be shown per column) are synchronized.
If you scroll in one view, the other view will always follow to show the
same range of memory from the memory block.
Thanks
Samantha
"Mikhail
Khodjaiants"
<mikhailk@xxxxxxx To
> <platform-debug-dev@xxxxxxxxxxx>
Sent by: cc
platform-debug-de
v-admin@eclipse.o Subject
rg Re: [platform-debug-dev] Memory
View Infrastructure Review: Part 1
10/14/2004 02:28
PM
Please respond to
platform-debug-de
v
Looks good to me. Just one question: how the visible content of the memory
view and it's renderings are synchronized? If you scroll the content of the
memory view what happens with the renderings?
Thanks,
Mikhail
----- Original Message -----
From: "Samantha Chan" <chanskw@xxxxxxxxxx>
To: <platform-debug-dev@xxxxxxxxxxx>
Sent: Wednesday, October 13, 2004 6:15 PM
Subject: Re: [platform-debug-dev] Memory View Infrastructure Review: Part 1
>
>
>
>
> Hi -
>
> To help you display your renderings, I am going to propose allowing debug
> implementers to show renderings in the Memory View using a split pane. I
> have played around a little to have the Memory View handle rendering
> events. Here's a screen capture of a prototype:
>
> (Embedded image moved to file: pic17075.jpg)
>
> In the "Super Memory View", the view uses a sashform to display a memory
> view and a rendering view. On the left, the view shows a memory block
in
> raw hex format. On the right, the view shows all the renderings that are
> associated with the memory block being shown on the left. You can have
> multiple memory blocks from a debug session. Each memory block can have
> multiple renderings.
>
> I am going to provide definitions to the standard rendering types: ASCII,
> EBCDIC, Signed Integer and Unsigned Integer. However, these rendering
> types will not be bound to any memory block. You will have to bind the
> renderings to your own memory block type. I do not want to force every
> debug adapters to take these renderings.
>
> One challenge to this approach is that it is unclear where a rendering
> should be displayed. For example, suppose you want to define a rendering
> type that is only to be displayed by a rendering view and not the Memory
> view. (e.g. you want to show your disassembly rendering in a special
> rendering view.) How can we allow debug implementers to specify where a
> rendering should be displayed? How can the Memory view figure out that
it
> should not be displaying this special rendering type. To solve this
> problem, I propose to introduce another element, viewBinding, in the
> memoryRenderings extension point. This element consist of a rendering id
> and a list of view ids. The view ids describe where a rendering type
> should
> be displayed. Before displaying a rendering, a rendering view should
> check that its view id is listed in the viewBinding element of the
> rendering's type. This viewBinding element is optional. If there is no
> viewBinding element defined for a rendering type, the rendering type is
> bound to the Memory view by default.
>
> With this new approach, you can easily display standard renderings in the
> Memory View. All you have to do is to bind the rendering types to your
> memory blocks. Optionally, you can create fancy rendering types and
> special
> rendering views.
>
> Let me know what you think about this design. Thanks...
>
> Samantha
>
>
>
>
>
> "Mikhail
> Khodjaiants"
> <mikhailk@xxxxxxx To
> > <platform-debug-dev@xxxxxxxxxxx>
> Sent by: cc
> platform-debug-de
> v-admin@eclipse.o Subject
> rg Re: [platform-debug-dev] Memory
> View Infrastructure Review: Part 1
>
> 10/08/2004 11:07
> AM
>
>
> Please respond to
> platform-debug-de
> v
>
>
>
>
>
>
> Samantha,
>
> Thanks for your reply. What I am trying to do is to find a compromise (as
> Thomas mentioned in his posting) between the "traditional" memory
> presentations used by many IDE's and your approach. I like the idea of
> having special rendering views, especially for "exotic" renderings
> (viewing
>
> memory as an image is a good example).
> This is what I suggest. Instead of using the raw hex format exclusively
to
> show a memory block in the Memory view, provide a way to use a
> client-specified rendering and allow to change it dynamically. There will
> be
> only one view tab per memory block in the Memory view. And the clients
can
> implement as many rendering views as they wish.
> Using this approach I can implement the "traditional" renderings (hex,
> hex+ASCII, decimal, float, etc) and switch between them in the same view
> tab
> of the Memory view and I can also have a special rendering view to
display
> the same block as a disassembly.
> Regarding "getPaddedString", I think that it should be moved to the
> presentation level.
>
> Thank you,
> Mikhail
> ----- Original Message -----
> From: "Samantha Chan" <chanskw@xxxxxxxxxx>
> To: <platform-debug-dev@xxxxxxxxxxx>
> Sent: Thursday, October 07, 2004 6:54 PM
> Subject: Re: [platform-debug-dev] Memory View Infrastructure Review: Part
> 1
>
>
>>
>>
>>
>>
>> Hi Mikhail -
>>
>> Thanks very much for your feedback. Here's my response to your
comments.
>>
>> The Memory View is supposed to show a memory block in raw hex format.
> The
>> renderings are supposed to be shown in a separate view. I have
>> experimented with putting renderings into the Memory View. However, I
>> found it to be confusing and limiting.
>>
>> Firstly, having renderings show up in the Memory View makes the view
>> confusing and hard to navigate. The Memory View currently shows all
>> memory
>> blocks related to the current debug session. If the view also displays
>> all
>> the renderings for the memory blocks, the view gets very clustered.
>> Imagine having 3 memory blocks and 2 renderings for each of them,
that's
>> already have 6 tabs in the view! Having so many tabs at the same time
>> makes the view hard to navigate. When switching between renderings,
>> finding
>> a rendering belonging to a particular memory block is very difficult.
>> (There are too many tabs, and as a result, the tabs cannot show the
> entire
>> tab name.)
>>
>> Secondly, having a separate rendering view allows the user to see more
>> than
>> one rendering at a time. If we have put the renderings into the Memory
>> View as well, then the user is limited to look at rendering one at a
> time.
>> However, user often finds it useful to see a memory block in its raw hex
>> format as well as other rendering formats at the same time. So, I do not
>> think putting such limitation onto the user is such a good idea.
>>
>> Having a separate rendering view gives debug implementers the
flexibility
>> to create a rendering view that is suitable for their needs. It's up to
>> the
>> developers to figure out what a rendering really means. For example,
you
>> may want to display your ASCII rendering with one code page while
someone
>> else may wish to display the same renderingt in another code page. This
>> is
>> why the ASCII and decimal renderings were not considered as standard
>> renderings.
>>
>> Looking at your note, it is not clear to me what you are looking for in
>> terms of displaying renderings. Are you saying that we should also
> display
>> renderings in the Memory view? Are you trying to get the Memory View
to
>> show the default renderings defined for a particular memory block?
> Please
>> clarify.
>>
>> "getPaddedString" is for getting a string to represent any byte that is
>> unavailable for display. I thought it should be something that's
>> customizable. This string should also be consistent across all
> renderings
>> from the same debug session or IMemoryBlockRetrieval. That's why I have
>> made this method part of the IExtendedMemoryBlockRetrieval interface.
> Are
>> you thinking that this method belongs more to the UI and should be made
>> part of the IMemoryBlockModelPresentation interface instead?
>>
>> Thanks...
>>
>> Samantha
>>
>>
>>
>>
>> "Mikhail
>> Khodjaiants"
>> <mikhailk@xxxxxxx
To
>> > <platform-debug-dev@xxxxxxxxxxx>
>> Sent by:
cc
>> platform-debug-de
>> v-admin@eclipse.o
Subject
>> rg Re: [platform-debug-dev] Memory
>> View Infrastructure Review: Part 1
>>
>> 10/07/2004 02:03
>> PM
>>
>>
>> Please respond to
>> platform-debug-de
>> v
>>
>>
>>
>>
>>
>>
>> Hi,
>>
>> We (QNX) have concerns regarding the UI portion of the proposed model.
>> The idea of contributed renderings is excellent, but having special
views
>> to
>> present the standard renderings as ascii, decimal, etc is very unusual.
>> Currently the Memory view presents the data using the hardcoded Hex
>> rendering and allows only one tab (rendering) per memory block. Is there
>> any
>> reason for this? Why the default renderings defined for a particular
>> memory
>>
>> block type can't be used to present the data?
>>
>> I have also minor comments for the core part.
>> The "IExtendedMemoryBlockRetrieval" interface contains the
>> "getPaddedString"
>> method. Why this method is included in the core?
>> And the methods of the "IMemoryBlockListener" interface begin with
>> uppercase
>> letters.
>>
>> Thanks, Mikhail
>> ----- Original Message -----
>> From: "Darin Wright" <Darin_Wright@xxxxxxxxxx>
>> To: <platform-debug-dev@xxxxxxxxxxx>
>> Sent: Wednesday, October 06, 2004 3:36 PM
>> Subject: [platform-debug-dev] Memory View Infrastructure Review: Part 1
>>
>>
>> Samantha,
>>
>> I have read/reviewed the support in org.eclipse.debug.core relating to
> the
>> memory view infrastructure: i.e. extension point, classes and
interfaces.
>> I want to be sure that I have a clear understanding of the core
>> infrastructure before I move on to the UI portion of the infrastructure.
>> Since there may be other interested parties, I suggest we conduct the
>> review on this mailing list in an open fashion.
>>
>> To start, here's my understanding of the "memory view model": Arbitrary
>> memory blocks can be retrieved from debuggees (this was always part of
> the
>> model). A memory block can be rendered in N different ways (N >= 0). A
>> memory block has a data type associated with it which defines the type
of
>> data contained in the memory block - for example, character data,
>> numerical data, or image data. The types of memory are open ended and
>> client defined (however, the platform could provide some renderings for
>> common types such as ASCII). The monitoring of memory blocks can be
>> expensive (in terms of size and communication with a debuggee). Thus, a
>> memory block manager is used to manage actively monitored memory blocks.
>> Similarly, since the mapping of memory block types to possible
renderings
>> is 1:N, there is a memory block rendering manager that manages the
active
>> renderings of currently monitored memory blocks. A memory block
>> implementation can be responsible for change notification itself (i.e.
>> notification of changes in its bytes), or it can let the client (memory
>> view) manage/compute changes.
>>
>> Here's a list of design issues that need to be considered (please let me
>> know your opinion):
>> * The memory renderings extension point uses the fully qualified name of
> a
>> Java class to identify types of memory blocks. This is used to bind
> memory
>> blocks to default renderings and available renderings. Using a class
name
>> is fragile and inflexible (i.e. changing an implementation class name
>> breaks extension points). It is also complex since the current
>> implementation uses the class/interface hierarchy to determine all
>> renderings for a memory block. Instead we should define an additional
>> method IExtendedMemoryBlock.getMemoryBlockType(), which returns a string
>> uniquely identifying the memory block type (i.e. its content/data type).
>> Is there a reason that we need complexity of multiple inheritance to
>> define memory block types?
>> * There is confusion in the naming scheme for the memory renderings
>> extension point and implementation interfaces/classes. The extension
> point
>> is called "memoryRenderings", however the IMemoryRendering interface is
> an
>> actual instance of a rendering, not an extension. I think the "type
>> pattern" which is used commonly in the debug platform should also be
used
>> here. That is, the extension point should be renamed to
>> "memoryRenderingTypes" to represent a class of renderings. Then, a
memory
>> rendering type can have a factory to create renderings (instances) of
its
>> type. IMemoryRendering will represent an actual rendering (as it does
>> now), and IMemoryRenderingInfo will be renamed to IMemoryRenderingType.
>> * The rendering_property element is a sub-element of a rendering
element,
>> and it is thus redundant to specify a renderingId (it is inherent in the
>> rendering element it is a child of). The attribute should be removed.
The
>> memory renderings manager treats the property elements as both top-level
>> elements and children elements when initializing extension point
>> information - but only one format should be allowed (i.e. only as a
child
>> element of a rendering element).
>> * Memory blocks have an undocumented lifecycle (which should be
>> documented). The delete() method is called when the block is removed
from
>> the memory block manager, but there is no corresponding init() when the
>> block is added (this method should be added, and to be consistent with
>> other lifecycle methods, delete() should be renamed to dispose()). Also
>> doc that memory blocks are automatically disposed (removed) from the
>> manager when their target terminates. Memory renderings have a similar
>> lifecycle that needs to be documented - i.e. renderings are
automatically
>> removed for terminated targets, and for removed memory blocks. Should
>> renderings have lifecycle methods too?
>>
>> Other questions:
>> * Are rendering properties optional in a rendering extension?
>> * What does it mean to use a default rendering factory for a rendering
>> extension? (Answer from reading code: it means that the rendering is
>> created with the same memory block as the original. I suppose this means
>> that a factory can change the bytes in the memory block? Is that the
sole
>> purpose of a rendering factory?)
>> * The factory specified for hex renderings is ill-specified in plug-in
> XML
>> ? it refers to a non-existant class
>> (org.eclipse.debug.internal.ui.views.memoryHexRenderingFactory - note
the
>> missing "." between memory and HexRenderingFactory). This means the
>> default factory is being used. However the rendering that the hex
factory
>> creates (HexRendering) is no different than a default rendering. So why
>> does it exist?
>> * Can one provide non-textual renderings? For example, render bytes as
an
>> image? (I didn't get to the UI code yet, but I presume this is possible)
>> * What types of rendering properties are used/supported? What are
dynamic
>> renderings? So far, I can see only this explicit use of properties, but
>> it?s not clear to me what a dynamic rendering is.
>>
>> I did not change any code yet, but I modifed the memoryRenderings schema
>> to reflect my understanding of things:
>> * I modified the wording in the memoryRenderings schema to note that the
>> extension point becomes public in 3.1, and added references to the
memory
>> block type identifier. Deprecated the memoryBlockClass attribute of the
>> default renderings and rendering binding elements. Removed renderingId
>> from the renderingProperty element.
>>
>> Other review notes:
>> * As a matter of style/consistency with other extension points, the
names
>> of elements in the memoryRenderings extension point should be changed
> from
>> "rendering_property" to "renderingProperty", etc.
>> * An example extension should be included in the schema (in an Example
>> section), and API information should be provided in the API section -
> i.e.
>> describing the API references from the example.
>> * The "Supplied Implementation" section should describe what the debug
>> platform provides - i.e. a HEX rendering.
>> * I have other review notes for the code (i.e. written on printouts),
not
>> included here
>>
>>
>> Thanks,
>>
>> Darin
>> _______________________________________________
>> platform-debug-dev mailing list
>> platform-debug-dev@xxxxxxxxxxx
>> http://dev.eclipse.org/mailman/listinfo/platform-debug-dev
>>
>> _______________________________________________
>> platform-debug-dev mailing list
>> platform-debug-dev@xxxxxxxxxxx
>> http://dev.eclipse.org/mailman/listinfo/platform-debug-dev
>>
>>
>> _______________________________________________
>> platform-debug-dev mailing list
>> platform-debug-dev@xxxxxxxxxxx
>> http://dev.eclipse.org/mailman/listinfo/platform-debug-dev
>>
>
> _______________________________________________
> platform-debug-dev mailing list
> platform-debug-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-debug-dev
>
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-debug-dev
