- Pharo-dev - lists.pharo.org

Re: [Pharo-project] ToolSet

by Antony Blakey

IMO discovery is a preferable model to registration, using either pragmas or pragma-like constructs. In Commando I do this: createCommands LSDCommando thisMethodReturnsAListOfCommands. .... and commandStructureTransformers LSDCommando thisMethodReturnsAListOfCommandTransformers. ... where the thisMethod... methods are empty. To collect all the methods that generate commands I do a senders-of-XXX-in-descendents-of-Class- that-have-an-LSDYYY-reference search. You could do more sophisticated filter after the search by bytecode analysis. One benefit of discovery is that (IMO) reuse is conceptually easier because (in the case you are talking about in this thread) the concept of 'being-a-command' is separated from 'in-the-world-menu'. Squeak has pragmas now, which people might prefer to traditional reflection. Personally I don't. On 29/10/2008, at 8:49 AM, StÃ©phane Ducasse wrote: > I like the idea. > What I learned curving etoy is that we need a Menu Registration for > the world menu too. > > Stef > > On Oct 28, 2008, at 8:26 PM, Igor Stasenko wrote: > >> 2008/10/28 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >>> Hi, >>> >>> we should decide how we will manipulate with tools. A lot of tools >>> classes are referenced directly - that is wrong because you cannot >>> then use different set of tools (for example a dummy toolset for no >>> tools at all). >>> In the KernelImage I added a registration mechanism for tools so >>> they >>> were called for example ToolSet default browser. There were no >>> ToolSet >>> subclasses and there was only a test if the default ToolSet is not >>> nil. That was not optimal solution. >>> >>> The current philosophy of ToolSet class supposess that you will send >>> messages directly to ToolSet class and you will not get real tools >>> classes at all. However the set of this messages would be very long >>> and Squeak wants sometimes directly the class (for comparison etc.) >>> >> >> I think, it would be nicer, instead of use a predefined methods, >> use a >> dictionary in a form 'tool name'->class and DNU pattern which >> then can respond with proper class when you send message like: >> >> Smalltalk tools browser >> >> here , a 'Smalltalk tools' should return a registry , and then >> registry in #doesNotUnderstand: should lookup a dictionary by >> #browser key. >> >> Also, if you want to add new, or replace old tool you just write: >> >> Smalltalk tools register: Workspace name: #workspace >> Smalltalk tools register: Transcript name: #transcriptWindow >> ...etc... >> >> as well as remove: >> Smalltalk tools remove: #workspace >> >> With this approach, the number/kinds of tools is arbitrary. They can >> be freely replaced at any moment without subclassing or writing >> methods. >> In vanilla image, we need only a single method, which can populate a >> default tool set. >> Also note, i'm not using a ToolSet class, i think 'Smalltalk tools' >> or >> 'SmalltalkImage tools' is much more elegant. >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Some defeats are instalments to victory. -- Jacob Riis

Oct. 28, 2008

Re: [Pharo-project] ToolSet

by Michael Rueger

Igor Stasenko wrote: > Sometimes you want to stub out a tools to make them inaccessible. Or > replace them with different ones. > For instance, one would like to redirect Transcript output to file, or > suppress debugger / browser / inspector. The proposed solution is more a symptom fix than a real solution. You want to make the number of access points as small as possible, so you have e.g. one point where to turn off the debugger. By that I mean turning off the debugger and not trick the system by stubbing it out. Same for access to Transcript. There shouldn't really be *any* direct reference to Transcript to begin with, but rather a small but effective logging API, e.g. Josef's toothpick. We Smalltalkers (I just happen to reply to Igor here, I'm including myself in this remark too ;-) ) tend to use magic tricks just because we can, but that doesn't mean it is good engineering. Michael

Oct. 28, 2008

Re: [Pharo-project] ToolSet

by StÃ©phane Ducasse

I like the idea. What I learned curving etoy is that we need a Menu Registration for the world menu too. Stef On Oct 28, 2008, at 8:26 PM, Igor Stasenko wrote: > 2008/10/28 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >> Hi, >> >> we should decide how we will manipulate with tools. A lot of tools >> classes are referenced directly - that is wrong because you cannot >> then use different set of tools (for example a dummy toolset for no >> tools at all). >> In the KernelImage I added a registration mechanism for tools so they >> were called for example ToolSet default browser. There were no >> ToolSet >> subclasses and there was only a test if the default ToolSet is not >> nil. That was not optimal solution. >> >> The current philosophy of ToolSet class supposess that you will send >> messages directly to ToolSet class and you will not get real tools >> classes at all. However the set of this messages would be very long >> and Squeak wants sometimes directly the class (for comparison etc.) >> > > I think, it would be nicer, instead of use a predefined methods, use a > dictionary in a form 'tool name'->class and DNU pattern which > then can respond with proper class when you send message like: > > Smalltalk tools browser > > here , a 'Smalltalk tools' should return a registry , and then > registry in #doesNotUnderstand: should lookup a dictionary by > #browser key. > > Also, if you want to add new, or replace old tool you just write: > > Smalltalk tools register: Workspace name: #workspace > Smalltalk tools register: Transcript name: #transcriptWindow > ...etc... > > as well as remove: > Smalltalk tools remove: #workspace > > With this approach, the number/kinds of tools is arbitrary. They can > be freely replaced at any moment without subclassing or writing > methods. > In vanilla image, we need only a single method, which can populate a > default tool set. > Also note, i'm not using a ToolSet class, i think 'Smalltalk tools' or > 'SmalltalkImage tools' is much more elegant. > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 28, 2008

Re: [Pharo-project] problem with update 10120 ?

by Adrian Lienhard

thanks, it works. Adrian On Oct 28, 2008, at 22:10 , StÃ©phane Ducasse wrote: > I redid an update > > Stef > > >> Thanks. >> We got some problems with the network and I could not check. >> I removed the problem for the moment. >> Lukas the Type removal does not work :) >> I will commit the etoy removal I did. >> >> Stef >> >> On Oct 28, 2008, at 8:48 PM, Damien Pollet wrote: >> >>> I'm getting this when I update from 10118: >>> This package depends on the following classes: >>> AnObsoleteSymbolListType >>> AnObsoleteDataType >>> You must resolve these dependencies before you will be able to load >>> these definitions: >>> FullVocabulary >>> PlayerType >>> ScriptNameType >>> UserCustomEventNameType >>> >>> >>> -- >>> Damien Pollet >>> type less, do more [ | ] http://people.untyped.org/damien.pollet >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 28, 2008

Re: [Pharo-project] ToolSet

by Gary Chambers

It is not always good practice to do "deep" examination... each level can be a facade... (e.g. "Smalltalk tools browser" might be better as "SmalltalkTools browser")... Regards, Gary. ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, October 28, 2008 7:26 PM Subject: Re: [Pharo-project] ToolSet > 2008/10/28 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >> Hi, >> >> we should decide how we will manipulate with tools. A lot of tools >> classes are referenced directly - that is wrong because you cannot >> then use different set of tools (for example a dummy toolset for no >> tools at all). >> In the KernelImage I added a registration mechanism for tools so they >> were called for example ToolSet default browser. There were no ToolSet >> subclasses and there was only a test if the default ToolSet is not >> nil. That was not optimal solution. >> >> The current philosophy of ToolSet class supposess that you will send >> messages directly to ToolSet class and you will not get real tools >> classes at all. However the set of this messages would be very long >> and Squeak wants sometimes directly the class (for comparison etc.) >> > > I think, it would be nicer, instead of use a predefined methods, use a > dictionary in a form 'tool name'->class and DNU pattern which > then can respond with proper class when you send message like: > > Smalltalk tools browser > > here , a 'Smalltalk tools' should return a registry , and then > registry in #doesNotUnderstand: should lookup a dictionary by #browser > key. > > Also, if you want to add new, or replace old tool you just write: > > Smalltalk tools register: Workspace name: #workspace > Smalltalk tools register: Transcript name: #transcriptWindow > ...etc... > > as well as remove: > Smalltalk tools remove: #workspace > > With this approach, the number/kinds of tools is arbitrary. They can > be freely replaced at any moment without subclassing or writing > methods. > In vanilla image, we need only a single method, which can populate a > default tool set. > Also note, i'm not using a ToolSet class, i think 'Smalltalk tools' or > 'SmalltalkImage tools' is much more elegant. > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 28, 2008

Re: [Pharo-project] problem with update 10120 ?

by StÃ©phane Ducasse

I redid an update Stef > Thanks. > We got some problems with the network and I could not check. > I removed the problem for the moment. > Lukas the Type removal does not work :) > I will commit the etoy removal I did. > > Stef > > On Oct 28, 2008, at 8:48 PM, Damien Pollet wrote: > >> I'm getting this when I update from 10118: >> This package depends on the following classes: >> AnObsoleteSymbolListType >> AnObsoleteDataType >> You must resolve these dependencies before you will be able to load >> these definitions: >> FullVocabulary >> PlayerType >> ScriptNameType >> UserCustomEventNameType >> >> >> -- >> Damien Pollet >> type less, do more [ | ] http://people.untyped.org/damien.pollet >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 28, 2008

Re: [Pharo-project] ToolSet

by Igor Stasenko

2008/10/28 Michael Roberts <mike(a)mjr104.co.uk>: > I'm wondering what problem is exactly trying to be solved? From the > start of the thread it strikes me as over engineered. If tools have > to appear in the model layer, i.e. they are programmatically used then > making them pluggable requires that all different examples of the same > 'tool' respond to the same protocol. If that was the case I would > prefer that Pharo put efforts into the best tool for each category. > i'm not sure we need two debuggers or two pointer finders for example. > In specific cases if you want to resolve UI/headless issues then > perhaps there is a better way. > Sometimes you want to stub out a tools to make them inaccessible. Or replace them with different ones. For instance, one would like to redirect Transcript output to file, or suppress debugger / browser / inspector. This can be useful for different applications, which is targeteg for users, not developers. > For general registration into menus, I consider this UI layer where > the only reference to the tool would likely be loader code to populate > the menu. In that case we already have a registration mechanism I > thought (?) and I don't see the problem with a direct class reference. > > just my 2p > > thanks > > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 28, 2008

Re: [Pharo-project] ToolSet

by Michael Roberts

I'm wondering what problem is exactly trying to be solved? From the start of the thread it strikes me as over engineered. If tools have to appear in the model layer, i.e. they are programmatically used then making them pluggable requires that all different examples of the same 'tool' respond to the same protocol. If that was the case I would prefer that Pharo put efforts into the best tool for each category. i'm not sure we need two debuggers or two pointer finders for example. In specific cases if you want to resolve UI/headless issues then perhaps there is a better way. For general registration into menus, I consider this UI layer where the only reference to the tool would likely be loader code to populate the menu. In that case we already have a registration mechanism I thought (?) and I don't see the problem with a direct class reference. just my 2p thanks Mike

Oct. 28, 2008

Re: [Pharo-project] problem with update 10120 ?

by StÃ©phane Ducasse

Thanks. We got some problems with the network and I could not check. I removed the problem for the moment. Lukas the Type removal does not work :) I will commit the etoy removal I did. Stef On Oct 28, 2008, at 8:48 PM, Damien Pollet wrote: > I'm getting this when I update from 10118: > This package depends on the following classes: > AnObsoleteSymbolListType > AnObsoleteDataType > You must resolve these dependencies before you will be able to load > these definitions: > FullVocabulary > PlayerType > ScriptNameType > UserCustomEventNameType > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 28, 2008

[Pharo-project] problem with update 10120 ?

by Damien Pollet

I'm getting this when I update from 10118: This package depends on the following classes: AnObsoleteSymbolListType AnObsoleteDataType You must resolve these dependencies before you will be able to load these definitions: FullVocabulary PlayerType ScriptNameType UserCustomEventNameType -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Oct. 28, 2008