[ANN] Documentation for Omnibrowser

Dear Squeakers,

Our paper on Omnibrowser has been published finally.
http://www.iam.unibe.ch/~scg/Archive/Papers/Berg07cOmnibrowser.pdf

Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.software-artist.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Very cool. Good work.

2007/4/24, Bergel, Alexandre <[hidden email]>:

--
Damien Cassou

Bergel, Alexandre wrote:
> Dear Squeakers,
>
> Our paper on Omnibrowser has been published finally.
> http://www.iam.unibe.ch/~scg/Archive/Papers/Berg07cOmnibrowser.pdf 

Thanks for this, Alexandre. I'm reading the paper and I'd also like to
install the Omnibrowser on squeakmap but it doesn't want to load in 3.9.
Does it not work for 3.9?

--
brad fuller
www.bradfuller.com
+1 (408) 799-6124

On Apr 25, 2007, at 3:59 PM, Brad Fuller wrote:

> Thanks for this, Alexandre. I'm reading the paper and I'd also like to
> install the Omnibrowser on squeakmap but it doesn't want to load in  
> 3.9.
> Does it not work for 3.9?

OmniBrowser is included in Squeak 3.9, so you don't have to load  
anything. In the open menu, select 'Image Browser.'

Colin

Colin Putney wrote:
>
> On Apr 25, 2007, at 3:59 PM, Brad Fuller wrote:
>
>> Thanks for this, Alexandre. I'm reading the paper and I'd also like to
>> install the Omnibrowser on squeakmap but it doesn't want to load in 3.9.
>> Does it not work for 3.9?
>
> OmniBrowser is included in Squeak 3.9, so you don't have to load
> anything. In the open menu, select 'Image Browser.'
Gee.. that makes  a log of sense ;-)  Why not name it OmniBrowser?
Because it's now a framework?

And, why does most class browsers you bring up have their title as
"System Browser"? I realize they are browsing the "system", but don't
you think it ought to reflect what you just selected in the menu? (not
specially asking you, Colin). So, for instance, to get the
"OmniBrowser", you select the "Image Browser" in the menu and the
resulting application window title is "System Browser". Hmm... that's
gotta be confusing. Application naming should be consistent throughout
the environment, don't you think?

--
brad fuller
www.bradfuller.com
+1 (408) 799-6124

Hi,

2007/4/26, Brad Fuller <[hidden email]>:
> Thanks for this, Alexandre. I'm reading the paper and I'd also like to
> install the Omnibrowser on squeakmap but it doesn't want to load in 3.9.
> Does it not work for 3.9?

OmniBrowser is installed and updated in the squeak-dev image:
http://damien.cassou.free.fr/squeak-dev/

For an image based on 3.9, you have version 95-2.
Newer versions are in folder beta/ and are based on Squeak 3.10-alpha.

OmniBrowser has changed a lot between the original 3.9 release and the
version on the squeak-dev image. For example Actors and Actions are
not used anymore. Commands replace them.

With the squeak-dev image, you'll also get syntax-highlighting, code
completion, refactorings...

--
Damien Cassou

Thanks for providing this document. I still wading my way through it
but it's nice to have such in-depth information. Thanks also to Damien
for including it in squeak-dev, which is shaping up very nicely!
However, I have a problem which may or may not be related but it
seemed to appear after I installed OB. On opening "image browser" or
indeed "class browser" I get "MessageNotUnderstood:
Array>>similarSpeciesInstance:". As far as I can tell
"similarSpeciesInstance:" was added some time ago but I suspect also
that other things I have installed may have removed/over-written it.
Any tips on how this problem has arisen and what to do about it?

2007/5/3, Derek O'Connell <[hidden email]>:
> However, I have a problem which may or may not be related but it
> seemed to appear after I installed OB. On opening "image browser" or
> indeed "class browser" I get "MessageNotUnderstood:
> Array>>similarSpeciesInstance:". As far as I can tell
> "similarSpeciesInstance:" was added some time ago but I suspect also
> that other things I have installed may have removed/over-written it.
> Any tips on how this problem has arisen and what to do about it?

Can you give more information?

- What is your image?
- How did you installed OmniBrowser?
- Why did you installed OmniBrowser?

--
Damien Cassou

The original image is squeak-dev 95-2 updated a few times, so I did
not install OB but simply updated it along with other packages. Have
to admit to a bit of confusion since the Package Universe Browser
shows the following installed (and the fact that until this doc was
posted I ignored OB altogether):

OmniBrowser 0.337
OmniBrowser-Full 0.7
OmniBrowser-Morphic 0.5
OmniBrowser-Standard 0.183
ShoutOmniBrowser tween.5

Things I may actually have installed include: null, DuoSystemBrowser,
VPVideoMorph, MultiColumn Lists, OSProcess, RIO, GraphViz, FSM,
Connectors... I think that's it :-0

Happy to help you track down what has happened but since my Squeak/ST
experience is patchy a bit of hand-holding will be needed.

2007/5/3, Derek O'Connell <[hidden email]>:
I think the problem comes from the upgrades. In fact, OB has changed a
lot since 95-2 and you have different implementations loaded together
in your image.  I sent a mail about this. I would advice you to use a
more recent image (http://damien.cassou.free.fr/squeak-dev).

Even with a new image, upgrading OB is currently not a good solution.
This is because at least two installed packages (DynamicProtocols and
OmniBrowserFixes) overrides some methods. Upgrading OB would then
remove those overrides. I don't know what I can do for this :-(

--
Damien Cassou

Oh dear. This is one of my pet niggles about the current state of
affairs re various releases, ie, it's difficult, for me at least and I
suspect others, to choose and stick to one image. A quick search of my
top level Squeak directory gives me ~1G of image files! I'm partly to
blame since during my experiment-by-loading-everything-in-sight
sessions I will typically download and use the image that
works/supports whatever particular package I'm investigating at that
time. Consequently I have various experimental code scatter over many
of these 32 images and you can guarantee that if I export a change-set
it won't cleanly import into another image. Hopefully I will
eventually reach the skill level that allows me to fix things on the
fly in these situations but I have to say even when I reach that level
I still won't look forward to doing it because it happens too often
and would be a distraction from my whatever I'm doing (Squeak-wise).
True it would provide good learning experience but for a newbie(ish)
it sorely dents my motivation.

I not blaming you, Damien, or anyone else specifically for this but
then the multitude of ways to load stuff into Squeak or update
existing packages, not to mention the "Update" button, leaves me in
total confusion about the best way to keep current without breaking
things. Thoughts on this as well as ways to manage various unrelated
bits of code are more than welcome!

PS: Downloading another image now my rant is over ;-)

2007/5/3, Derek O'Connell <[hidden email]>:
I have exactly the same problem :-) I want to have the very last
possible versions of the tools I use. This is why I maintain
squeak-dev and squeak-web. Everyday, before starting working, I
decompress the last squeak-dev image version and I load my code in
using Monticello. I even change my image more than once a day. This is
to be sure my code can be loaded from scratch.

--
Damien Cassou

Interesting. Do you run your own Monticello server? It might help
others if you do a "Day in the life of..." type article.

2007/5/3, Derek O'Connell <[hidden email]>:
> Interesting. Do you run your own Monticello server? It might help
> others if you do a "Day in the life of..." type article.

Why would I need another monticello server than squeaksource?

--
Damien Cassou

Hmmm, maybe for stuff not ready for release or not meant to be
released. Don't know, that's why I ask.

2007/5/3, Derek O'Connell <[hidden email]>:
> Hmmm, maybe for stuff not ready for release or not meant to be
> released. Don't know, that's why I ask.

I don't use SqueakSource for releases. So, I commit often directly to
squeaksource without wondering if it's a release or not.

--
Damien Cassou

Damien Cassou wrote:

> Even with a new image, upgrading OB is currently not a good solution.
> This is because at least two installed packages (DynamicProtocols and
> OmniBrowserFixes) overrides some methods.
Ouch
> Upgrading OB would then
> remove those overrides. I don't know what I can do for this :-(
>
Not include packages that include overrides?
At least for fixes, move them into their intended permanent home...

For extensions, refactor them and the base package until the override is
no longer needed.

Daniel

2007/5/4, Daniel Vainsencher <[hidden email]>:
Sometimes there is no other solution than doing an override.

> At least for fixes, move them into their intended permanent home...

This is not possible because the fixes are trait-specific and OB must
be backward compatible.


> For extensions, refactor them and the base package until the override is
> no longer needed.

I refactored DynamicProtocols so that I don't have an override for it
anymore. The code is really ugly however.

OBSystemBrowser>>addTo: root class: classSel comment: commentSel
metaclass: metaclassSel
        "Adds the dynamic protocols to the metagraph"
        |class metaclass method|
        super addTo: root class: classSel comment: commentSel metaclass: metaclassSel.
       
        "Get back the meta nodes from the root. Really ugly"
        class := root children detect: [:node | node name =  'Class'].
        metaclass := root children detect: [:node | node name =  'Metaclass'].
        method := class children anyOne children first.
       
        DynamicProtocols
                installDPOnClass: class
                metaClass: metaclass
                method: method.
        ^ root

I have exactly the same code in OBHierarchyBrowser. It can be enhanced
a bit but I think a bigger refactoring is needed in methods creating
metagraphs.

If you have time and solutions, you can commit to OmniBrowser,
OmniBrowserFixes and DynamicProtocols. They are all open to
modifications.

--
Damien Cassou

Damien Cassou wrote:


> If you have time and solutions, you can commit to OmniBrowser,
> OmniBrowserFixes and DynamicProtocols. They are all open to
> modifications.
If you help me get into it, I'll have a look and see if I can help.
Overrides are evil, and I'd like to help kill them.
I doubt that - the world of possible solutions is so large. Do you want
to talk about a particular example?Sorry, I can't, so I have only opinions.
>
>> At least for fixes, move them into their intended permanent home...
>
> This is not possible because the fixes are trait-specific and OB must
> be backward compatible.
Why is it better to maintain the fixes in parallel to the OB mainline as
overrides, rather than as a branch of the OB?
>
>> For extensions, refactor them and the base package until the override is
>> no longer needed.
>
> I refactored DynamicProtocols so that I don't have an override for it
> anymore. The code is really ugly however.
I don't feel I really understand this example. What I see below looks
like an override. Opening a squeak-dev 118 image, OBSB does not seem to
have a method #addTo:*.
Nor does OBHB have code that looks like that in this image. Give me a
specific image, package, class and overriding method, and preferably an
explanation why its needed, and I'll see if there's anything I'd do
different. At the minimum, we'll all learn something about a difficult
packaging subject...

Daniel

2007/5/5, Daniel Vainsencher <[hidden email]>:
> Damien Cassou wrote:
> > If you have time and solutions, you can commit to OmniBrowser,
> > OmniBrowserFixes and DynamicProtocols. They are all open to
> > modifications.
>
> If you help me get into it, I'll have a look and see if I can help.
> Overrides are evil, and I'd like to help kill them.


Please ask any specific question you might have.

OmniBrowser repository: http://source.wiresong.ca/ob
OmniBrowser fixes: http://www.squeaksource.com/OmniBrowserFixes/


> > 2007/5/4, Daniel Vainsencher <[hidden email]>:
> >> Damien Cassou wrote:
> > Sometimes there is no other solution than doing an override.
> I doubt that - the world of possible solutions is so large. Do you want
> to talk about a particular example?Sorry, I can't, so I have only opinions.


You are right. There is always a solution. Sometimes, it's not that
easy to implement however. For example:

OBCmdFindClass>>findClassIn: anEnvironment pattern: pattern
   ...
   potentialClassNames := anEnvironment classNames asArray.
   ...

I want the traits too in this variable. Do you have a better solution
than my override:

OBCmdFindClass>>findClassIn: anEnvironment pattern: pattern
   ...
   potentialClassNames := (anEnvironment classNames, anEnvironment
traitNames) asArray.
   ...

If you have a better solution, please commit to the above
repositories. I would really like to get rid of those overrides.


> >> At least for fixes, move them into their intended permanent home...
> >
> > This is not possible because the fixes are trait-specific and OB must
> > be backward compatible.
>
> Why is it better to maintain the fixes in parallel to the OB mainline as
> overrides, rather than as a branch of the OB?

I don't know. Why not :-) Is it possible to maintain a branch in a
different repository? I think this would solve our overriding
problems. Can you help me in this direction?

> > I refactored DynamicProtocols so that I don't have an override for it
> > anymore. The code is really ugly however.
>
> I don't feel I really understand this example. What I see below looks
> like an override. Opening a squeak-dev 118 image, OBSB does not seem to
> have a method #addTo:*.

OBSB does not have this method currently. DynamicProtocols adds it to
install itself in the browser. So, it's not an override anymore.
However, I have to manually get the nodes I want from the root. I
didn't have this problem before because I added the line installing
the dynamic protocols directly in OBCodeBrowser>>addTo*

Is it clearer now ? The package DynamicProtocols has to modify the
meta graph. I can do it when the meta graph is constructed in
OBCodeBrowser>>addTo* but this would be an override. My current
solution is to reimplement #addTo: in the subclasses I want:
OBSystemBrowser and OBHierarchyBrowser.

Hope you can help.

Bye

--
Damien Cassou