Suggestions for using treemaps in Dolphin IDE

Hi,

I am working on a treemap implementation for Dolphin right now. It can
be used in most places where a normal TreeView can be used. One just has
to provide a block to determine the size of a leaf.

As for real testing I need some test applications. Right now I have a
working File Browser similar to SequioaView. The next thing is an
integration into Ians Profiler.

Does anybody has sugesstions for another IDE tool/goodie where using
treemaps would make sense?

Further information about treemaps can be found at
http://www.cs.umd.edu/hcil/treemap-history/index.shtml and
http://www.win.tue.nl/sequoiaview/ .

CU,

Udo

"Udo Schneider" <[hidden email]> wrote in message
news:[hidden email]...
| Hi,
|
| I am working on a treemap implementation for Dolphin right now. It can
| be used in most places where a normal TreeView can be used. One just has
| to provide a block to determine the size of a leaf.
|
| As for real testing I need some test applications. Right now I have a
| working File Browser similar to SequioaView. The next thing is an
| integration into Ians Profiler.
|
| Does anybody has sugesstions for another IDE tool/goodie where using
| treemaps would make sense?

Memory usage: show relation between
number-of-instances/size-of-instances/class in an image.
Would be nice if you can take a snapshot of these numbers. Run the
application-under-development and watch what the application is using by
subtracting the snapshot numbers from the actual numbers.

Anyway, thanks for the pointers, its interesting stuff.

Pieter


| Further information about treemaps can be found at
| http://www.cs.umd.edu/hcil/treemap-history/index.shtml and
| http://www.win.tue.nl/sequoiaview/ .
|
| CU,
|
| Udo
|

Pieter Emmelot wrote:
> Memory usage: show relation between
> number-of-instances/size-of-instances/class in an image.
> Would be nice if you can take a snapshot of these numbers. Run the
> application-under-development and watch what the application is using by
> subtracting the snapshot numbers from the actual numbers.
That's a very good idea. What do you exactly mean by size of an
instance? I would define "size of an instance" using the number of
instance variables ... and they are the same over all instances of a
class. I can think of a special case with indexed classes. E.g.
displaying according to the number of elements of a collection.

I'm not sure whether it's possible to exmine these number in a runtime
version? Maybe the used methods are part of the development system and
will get stripped.

BTW: Did you take a look at Chris Uppal's "Space Breakdown"
(http://www.metagnostic.org/DolphinSmalltalk/SpaceBreakdown.html). I
think I'll try to enhance this using treemaps as you suggested (this
will safe me the work of writing these functions again ;-).


> Anyway, thanks for the pointers, its interesting stuff.
Once you get the structure it's very easy (ok. calculating the whole
stuff is another story ;-). I hope I'll be able to generalize the
TreeMapView so that others might use it as well.

CU,

Udo

Udo Schneider wrote:

> Does anybody has sugesstions for another IDE tool/goodie where using
> treemaps would make sense?

It sounds interesting.

Other applications where the data is essentially tree-shaped, and where it
might be worthwhile to have a visual impression of how big each subtree is:

XML objects.

Method definition trees (where the nodes "below" a method are the
methods/selectors that it refers to).

The class hierarchy itself is worth considering as an example -- it is easy to
navigate from code, it's familiar (making it easy to see exactly what the TM's
doing), and it *changes*.  (I mention this last part because *I* forgot to
code/test for dynamic trees in the first version of my ListTreeView -- leading
to seriously broken code.)

Perhaps a nested TODO list where the size of an entry is the effort (or
whatever) associated with a task and all its subtasks.

    -- chris

Chris Uppal wrote:
> XML objects.
That's a good (and very generic!) thing. Never thought about this. I can
actually think of two ways defining the "size" of a node:
a) by the number of CDATA characters below this node
b) by the number of childnodes

Did I miss something obvious?

> Method definition trees (where the nodes "below" a method are the
> methods/selectors that it refers to).
How would you define the size of such a node? I can think of using the
number of message sends in a method? But I have many methods where the
least sended message is the most important one (#, as a negative
example). I would like to assign some kind of factor to determine the
importance of a sended message .... but how do I define "importance"?

> The class hierarchy itself is worth considering as an example -- it is easy to
> navigate from code, it's familiar (making it easy to see exactly what the TM's
> doing), and it *changes*.  (I mention this last part because *I* forgot to
> code/test for dynamic trees in the first version of my ListTreeView -- leading
> to seriously broken code.)
Right now TreeMapView uses a model very similar to MoenTreeView. If you
create a TreeMapView on a TreeModel the TreeMapModel is transparently
build behind the scenes. I considered adding a granular change support
but dropped that idea very fast. If only one node changes it's size you
basically have to recalculate the whole map again. So my change support
consits basically of some methods which rebuild the whole model once a
change in the orgiginal TreeModel is detected.

I'm considering to not rebuild the whole tree if nodes are just
added/deleted. However - even in this case the whole map needs to be
calculated.


> Perhaps a nested TODO list where the size of an entry is the effort (or
> whatever) associated with a task and all its subtasks.
This would be nice to have. My focus right now is adding TM support to
tools related to development so that everyone who wants to use TMs in
Dolphin has an example with functionalities from the image.

Thanks for your input.

CU,

Udo

"Udo Schneider" <[hidden email]> wrote in message
news:3fc2538c$[hidden email]...
| Pieter Emmelot wrote:
| > Memory usage: show relation between
| > number-of-instances/size-of-instances/class in an image.
| > Would be nice if you can take a snapshot of these numbers. Run the
| > application-under-development and watch what the application is using by
| > subtracting the snapshot numbers from the actual numbers.
| That's a very good idea. What do you exactly mean by size of an
| instance? I would define "size of an instance" using the number of
| instance variables ... and they are the same over all instances of a
| class. I can think of a special case with indexed classes. E.g.
| displaying according to the number of elements of a collection.

Yes, memory usage of variableByteSubclasses (like String) and
variableSubclasses (like Array) will vary per instance but 'normal'
subclasses instances have constant size.

| I'm not sure whether it's possible to exmine these number in a runtime
| version? Maybe the used methods are part of the development system and
| will get stripped.

I didn't mean to use this tool in a stripped image. I was thinking of a way
to show the numbers for specific code (instead of the whole image).
Something like:
    snapshot := MemoryUsage now.
    MyApplicationShell show.
    actual := MemoryUsage now.
    MemoryUsageTreeMap showOn: actual - snapshot

| BTW: Did you take a look at Chris Uppal's "Space Breakdown"
| (http://www.metagnostic.org/DolphinSmalltalk/SpaceBreakdown.html). I
| think I'll try to enhance this using treemaps as you suggested (this
| will safe me the work of writing these functions again ;-).

Looking forward ;-) I think it will be a nice combination.

Good luck,
Pieter



| > Anyway, thanks for the pointers, its interesting stuff.
| Once you get the structure it's very easy (ok. calculating the whole
| stuff is another story ;-). I hope I'll be able to generalize the
| TreeMapView so that others might use it as well.
|
| CU,
|
| Udo
|

Udo Schneider wrote:

> I can
> actually think of two ways defining the "size" of a node:
> a) by the number of CDATA characters below this node
> b) by the number of childnodes
>
> Did I miss something obvious?

Not that I can think of.

> > Method definition trees (where the nodes "below" a method are the
> > methods/selectors that it refers to).
> How would you define the size of such a node?

Perhaps the number of child nodes traversing the tree down to some specified
depth -- the idea being that methods would be "big" if they expanded out to a
lot of code.

    -- chris

Pieter Emmelot wrote:
  > I didn't mean to use this tool in a stripped image. I was thinking
of a way
> to show the numbers for specific code (instead of the whole image).
> Something like:
>     snapshot := MemoryUsage now.
>     MyApplicationShell show.
>     actual := MemoryUsage now.
>     MemoryUsageTreeMap showOn: actual - snapshot

So basically one needs a good way to display the differences between the
space ued by different instances/class/objects/whatsoever.

I'll work on that. Thanks for your help/suggestions.


CU,

Udo

Chris Uppal wrote:


>>>Method definition trees (where the nodes "below" a method are the
>>>methods/selectors that it refers to).
>>
>>How would you define the size of such a node?
>
>
> Perhaps the number of child nodes traversing the tree down to some specified
> depth -- the idea being that methods would be "big" if they expanded out to a
> lot of code.
Please correct me if I'm wrong. This is basically the method length
(based on the method's parse tree here).

How do I incorporate the message references here?

Thanks for your help,

Udo

Udo Schneider wrote:

> > Perhaps the number of child nodes traversing the tree down to some
> > specified depth -- the idea being that methods would be "big" if they
> > expanded out to a lot of code.
> Please correct me if I'm wrong. This is basically the method length
> (based on the method's parse tree here).

That's be one way.  Another way (which I use in one context) would be to get a
list of the Symbols from the method's literal frame.   In either case what I'd
had in mind was that you might determine the "size" by drilling down by more
than one level, so that for instance, Object>>copy would be "big" since it ends
up calling #basicShallowCopy (via #shallowCopy).

> How do I incorporate the message references here?

I'm not sure what you mean ?

In the place where I have a "definition tree" for methods, each method's
children are the selectors it refers to, and the selector's children are the
definitions of that selector (I'm not entirely happy with the way that works,
many selectors have only one definition so there are too many "trivial" nodes
in the tree).  But I'm not sure if that's relevant to your question.

In any case, the definition tree was only a throwaway suggestion, if it turns
out not to have a natural interpretation as a treemap then so be it.  By all
means ignore it; I won't be offended ;-)

    -- chris

On Tue, 02 Dec 2003 13:49:45 +0000, Chris Uppal wrote:
> That's be one way.  Another way (which I use in one context) would be to get a
> list of the Symbols from the method's literal frame.   In either case what I'd
> had in mind was that you might determine the "size" by drilling down by more
> than one level, so that for instance, Object>>copy would be "big" since it ends
> up calling #basicShallowCopy (via #shallowCopy).
Now I understand what you want to achieve ... I'm just not sure how to
implement it. If I take a loook at the methods literal I can filter out
all symbols. AFAIK there is no way to decide (from the litreal frame)
whether the symbol is used in a message send or as a "real literal".

The next thing I'm not quite sure of is how to determine the reciever
class of a message. If I want to go from Object>>copy to
Object>>shallowCopy to Object>>basicSchallowCopy I have to know (while
calculating the size of Object>>copy) that the reciever of #shallowCopy is
an instance of Object (to find the right implementation of #shallowCopy).

Did I get you totally wrong again? :-)


> In the place where I have a "definition tree" for methods, each method's
> children are the selectors it refers to, and the selector's children are the
> definitions of that selector (I'm not entirely happy with the way that works,
> many selectors have only one definition so there are too many "trivial" nodes
> in the tree).  But I'm not sure if that's relevant to your question.
That's "easier". Calculating the method size by summing up all
implementations/references of symbols found in the literal frame.


> In any case, the definition tree was only a throwaway suggestion, if it turns
> out not to have a natural interpretation as a treemap then so be it.  By all
> means ignore it; I won't be offended ;-)
And I thought you allready were offended (due to my poor english).
I was just thinking of another way to name the "size of a method". By
just using the term "complexity of a method" it's much more clear what
is meant by the node size.


CU,

Udo

"Udo Schneider" <[hidden email]> wrote in message
news:[hidden email]...
> On Tue, 02 Dec 2003 13:49:45 +0000, Chris Uppal wrote:
> > That's be one way.  Another way (which I use in one context) would be to
get a
> > list of the Symbols from the method's literal frame.   In either case
what I'd
> > had in mind was that you might determine the "size" by drilling down by
more
> > than one level, so that for instance, Object>>copy would be "big" since
it ends
> > up calling #basicShallowCopy (via #shallowCopy).
> Now I understand what you want to achieve ... I'm just not sure how to
> implement it. If I take a loook at the methods literal I can filter out
> all symbols. AFAIK there is no way to decide (from the litreal frame)
> whether the symbol is used in a message send or as a "real literal".

You can ask a compiled method to supply you with a list of the messages it
actually sends (see CompiledCode>>messages).

Personally I think an interesting area for the application of this
technology would be in the presentation of profiling results. Ian's profiler
has the necessary mechanics, and you could replace (or augment) the various
presentations in his ProfileBrowser.

Regards

Blair the
> > definitions of that selector (I'm not entirely happy with the way that
works,
> > many selectors have only one definition so there are too many "trivial"
nodes
> > in the tree).  But I'm not sure if that's relevant to your question.
> That's "easier". Calculating the method size by summing up all
> implementations/references of symbols found in the literal frame.
>
>
> > In any case, the definition tree was only a throwaway suggestion, if it
turns
> > out not to have a natural interpretation as a treemap then so be it.  By
all

Udo Schneider wrote:

> Now I understand what you want to achieve ... I'm just not sure how to
> implement it. If I take a loook at the methods literal I can filter out
> all symbols. AFAIK there is no way to decide (from the litreal frame)
> whether the symbol is used in a message send or as a "real literal".

That's right, the only way to be certain is to parse the method.  I've found
that for my purposes the literal symbols are a good enough approximation, but
it does depend on what you do with them.

> The next thing I'm not quite sure of is how to determine the reciever
> class of a message. If I want to go from Object>>copy to
> Object>>shallowCopy to Object>>basicSchallowCopy I have to know (while
> calculating the size of Object>>copy) that the reciever of #shallowCopy is
> an instance of Object (to find the right implementation of #shallowCopy).
>
> Did I get you totally wrong again? :-)

No, I don't think so.  It's one of those things that you can't make precise --
if there's more than one definition of a selector then you have to consider
them all.

> > In any case, the definition tree was only a throwaway suggestion, if it
> > turns out not to have a natural interpretation as a treemap then so be
> > it.  By all means ignore it; I won't be offended ;-)
> And I thought you allready were offended (due to my poor english).

Oh dear.  No, I was not offended *at all*, I'm very sorry I gave you that
impression.

    -- chris

If anybody is interested in how TreeMaps in Dolphin might look like I
created a ToGo Applikation similar to SequoiaView.

You can download it at http://www.homeaddress.de/bonsai.zip

Right now I'm implementing some layout alghorithms in a C DLL due to
performance reasons. In addition some clean up and cosmetic issues.

As allways any comments appreciated.

CU,

Udo



Udo Schneider wrote:

If you already downloaded bonsai.zip please delete the file and perform
an anti virus scan with an up-to-date pattern. I was informed that the
file contains a signature of Win32/Pinfi.B (thanks Charlie) which was
obviously not recognized by my virus scanner. Until I can confirm that
state of this ZIP I'll remove it from the download site.

Thanks,

Udo




Udo Schneider wrote:

Hi,

finally some code to publish ;-)

You can find an alpha version of a treemap implementation for Dolphin
Smalltalk at http://www.homeaddress.de/US%20Goodies.zip.

Please note that the current version works (as far as I can say at
least) but should be considererd as an *alpha* version (so save your
image ;-).

I still need to clean up some names and refactor a few issues but at
least it works.

I included three sample applications as demonstration:
  - Bonsai
    A simple file browser which displays the same content as regular
    treeview, moen treeview and treemap
  - An treemap "enhanced" Space Breakdown (requires Chriss Uppals'
    package; see
    http://www.metagnostic.org/DolphinSmalltalk/SpaceBreakdown.html)
  - An treemap "enhanced" Profiler (requires Ians package; see
    http://www.idb.me.uk/goodies5/goodies5.html).

One goal for the Dolphin specific part was to be able to use a treemap
as a 1-to-1 replacement for TreeViews (and for ListViews as well -
although to a limited extent).

This means that most of the Dolphin specific code (especially MVP
related) is independent from the treemap layout and render alghorithms.

Features missing are:
  - Strip Treemap Layout
  - Nested Treemaps
  - Shaded borders


Any feedback/error/suggestion is highly appriciated.

CU,

Udo