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

Hi,

2007/4/26, Brad Fuller brad@bradfuller.com:

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...

2007/5/3, Derek O'Connell doconnel@gmail.com:

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?

2007/5/3, Derek O'Connell doconnel@gmail.com:

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.

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 :-(

2007/5/3, Derek O'Connell doconnel@gmail.com:

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!

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.

2007/5/3, Derek O'Connell doconnel@gmail.com:

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?

2007/5/3, Derek O'Connell doconnel@gmail.com:

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.

2007/5/4, Daniel Vainsencher danielv@tx.technion.ac.il:

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?

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.

2007/5/5, Daniel Vainsencher danielv@tx.technion.ac.il:

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 danielv@tx.technion.ac.il:

...

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*

...

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.

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...

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

2007/5/7, Daniel Vainsencher danielv@tx.technion.ac.il:

Damien Cassou wrote:

...

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. ...

Why not separate out "find Trait" into its own command?

I don't like that idea. CTRL+f means "find" to me. Not "find class". I don't want to use two key strokes for finding classes or traits. What do other people think? I don't want to choose for everybody.

user probably knows whether something is a trait or class due to the T prefix. BTW, this is a symptom of not having a concept Foo that is a supertype of "class" and "trait", and the obvious methods #isFoo, SystemDict>>fooNames and so forth. We really need this concept, and I would use Behavior, but that's taken to mean something else. Any ideas?

I perfectly agree and I think there are a lot of bugs due to this.

BTW, changing the semantics of the 'find class' action to also find traits just confuses things further by making more people assume that trait is a kind of class.

...

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?

In MC, being a branch simply means that whoever maintains the "main" branch never merges your versions in. Instead, you always merge his versions. Thus technically, you could even maintain the branch in the same repository, though everyone else might find it confusing. So sure, use another repo for clarity. Probably the recommended way to go about this is to contribute all of your changes to the mainline, except that you maintain a very minimal branch with only the overrides. After mainline puts out a new version, you merge it into your branch, to produce a new version of the branch. Then (naturally) make sure that Universes use either only your branch, or only the mainline.

This sounds like a good idea. However, there were a branch before and it didn't work well. I will do it if others agree with you.

...

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.

I see. As Colin says, the problem you're confronting is pretty difficult, and I'll write on that separately. I will note however, that the new solution you're using only avoids overrides in a superficial sense.

I noticed too :-) that's one of the reason I call this a ugly hack.

In fact, your upstream package could tomorrow choose to override (in the inheritance sense) this method in the subclasses, and you'd be back where you started. In fact, it could tomorrow add a new subclass overriding that method, and your overrides would then interfere significantly with its design. This strengthens my feeling that what you are currently maintaining is a branch, not an extension, of OB.

Please do not confuse DynamicProtocols (which is a separate package, like a plugin) and the OmniBrowserFixes. These are completely different packages with different aims.