Is there a way to see the specific value of the selected object in a different view? For instance, one could provide an extension to print the contents of an array. Currently the resolved value is printed next to the object address, in the table view. That's usually very crowded.

The inspector is not better. First of all, it does not show the resolved value of the inspected object anywhere. It does show the resolved values for each field, but it does so instead of the actual class name of the field, and I think both informations are important.

It would be nice to have a view for showing the resolved value of the selected object, and also show it in the inspector. This way you can have a compact view in the table, and a detailed view in another pane. This also seems to be the way YourKit works.

I'm not clear exactly what you mean by the resolved value of an object because surely that is just the fields which comprise the object, with their values. In general that is as much as can be displayed for an object, except for some special cases where the tool will display internal values (eg java.lang.String).

If I select an object in (for example) a tree view, the inspector shows details of the object including its fields, under the "Attributes" tab. If the object is an array it shows the values of each element in the array, with its Java object type where applicable. The exception is where further resolution has occurred as above, when the type is not displayed.

Is your request to show the Java type of fields which have been resolved in this way?

Could you give more details of exactly what you would hope to see in the Inspector, maybe with an example, or possibly raise a suggestion as an Eclipse bugzilla?

I'm not clear exactly what you mean by the resolved value of an object because surely that is just the fields which comprise the object, with their values. In general that is as much as can be displayed for an object, except for some special cases where the tool will display internal values (eg java.lang.String).

That's exactly what I meant. I wrote a couple of name resolvers for my types (for instance, in my app we intern strings in a custom char array), so I need to see the resolved value. Sometimes this can be a long string, for instance for lists or maps.

Quote:

If I select an object in (for example) a tree view, the inspector shows details of the object including its fields, under the "Attributes" tab. If the object is an array it shows the values of each element in the array, with its Java object type where applicable. The exception is where further resolution has occurred as above, when the type is not displayed.

Yes, the field view is nice, but in the pane above the field table it would be good to display the resolved value as well.

You can copy the value (Context Menu on the object, copy, value)
and paste it into the notes view.

You can also copy a selection e.g. ctrl-C and paste it (that gives the table headings too).

You can save a value to disk - that for huge arrays that gives the full value rather than a value truncated at approximately 1024 characters.

Yes, that's what I do sometimes.

Quote:

We could modify the inspector view - either another row in the top part of the split pane or another tab at the bottom. We don't want to clutter the screen too much more however.

I would go for another row, for completeness. I think it's important, and if you're worried about clutter you can remove the super class (that is usually easy to find) or the string 'no GC root', which could instead be turned into another visual indicator, like a special icon next to the object address.

Regardless, I think the view is a good idea because it can be closed, or placed anywhere. Is there an extension point for that? I'd be happy to contribute a prototype (I'm not familiar with the code base though)

I've tried an extra row in the top - it then produces scroll bars, so the top would need to be bigger. I don't think removing items is right either. Also I like the inspector view on the left hand side as a narrow column, and the details are not then any more visible than in the main query table. Hover text does appear, but that's not great.

A text view tab with line wrapping would have plenty of space - it is just harder to program. It also might allow better selection/copying.

I've tried an extra row in the top - it then produces scroll bars, so the top would need to be bigger. I don't think removing items is right either. Also I like the inspector view on the left hand side as a narrow column, and the details are not then any more visible than in the main query table. Hover text does appear, but that's not great.

Fair enough. I am still convinced that not showing the user-defined string for a type mostly defeats the purpose of having these extensions points.

Quote:

A text view tab with line wrapping would have plenty of space - it is just harder to program. It also might allow better selection/copying.

Agreed, spacing, selection and copying are very important. I reiterate my offer to help with this view, but I need a bit of guidance. Is there an extension point I can target? I'd need a notification of the currently selected object (similar to how the Inspector panel operates)

>Agreed, spacing, selection and copying are very important. I reiterate my offer to help with this view, but I need a bit of guidance. Is there an extension point I can target? I'd need a notification of the currently selected object (similar to how the Inspector panel operates)

Thank you for your offer. There isn't an extension point - please take a look at:

I was suggesting an extra tab as well as Statics, Attributes, and Class Hierarchy.

I'm not sure a new extension point is necessary - unless we had a more general text/image/composite object name/description resolver and put that into the tab. At the moment RGB and Images appear in a box at the bottom of the Inspector view. This could be generalized to the tab.

The window doesn't have scroll bars - though you can scroll if required by moving the cursor. Normally the window is big enough (with the 1024 character limit of String values) and added scroll bars look a bit ugly.

I don't know if this is the right place to discuss this, but I'd like to tutor a Google Summer of Code project for adding scripting support to MAT OQL. I think there's a reasonable chance this will be approved, last year we had quite a nice crop of projects:

I'd be interested in using Scala as the scripting language, so I see it as an alternative next to OQL support. I think it could be developed as a separate plugin, but it would be nice to collaborate and maybe find other areas where a motivated student can help. Anyone interested in the MAT team?

It sound interesting, though I don't know how many users are ready to write in Scala. Perhaps a division of work is to ensure MAT is dynamic aware for additional/removal of extensions, and then have Scala, Javascript scripting modules use the extensions etc. Unfortunately I don't have much spare time at the moment.