October 2008 - Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] ToolSet

by Igor Stasenko

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.

Oct. 28, 2008

Re: [Pharo-project] Re: [Pkg] Installer: Installer-Core-AlexandreBergel.244.mcz

by David RÃ¶thlisberger

Perfect. Thanks a lot, Keith! David >>> Installing a mc package already does some pretty sophisticated >>> pattern matching in the method InstallerMonticello>>mcThing, >>> allowing you to install the latest version, the latest version >>> from a particular author, or a specific version. >> Could you briefly tell us how to use #mcThing to load the latest >> version of a given package? Do we have to adapt #mcSortFileBlock or is >> there a direct way to load the latest version? Do you have an example? > It is unusual to the point of not expecting it in squeakland, but > installer is one piece of code that has some basic documentation see: > http://installer.pbwiki.com/Installer (and or the class comment). AFAIK > the refactoring has not effected the api documented, since it was > designed to be refactored from the outset. > > for an example of getting the latest see "Installer >> #upgrade" > > e.g. typically > > "latest package" > > Installer ss project: 'Installer'; install: 'Installer-Core'. > > "latest package by author kph" > > Installer ss project: 'Installer'; install: 'Installer-Core-kph'. > > "latest package by kph or mtf" > > Installer ss project: 'Installer'; install: #('Installer-Core-kph' > 'Installer-Core-mtf'). > > cheers > > Keith > > _______________________________________________ > 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] ScriptLoader>>installingInstaller

by StÃ©phane Ducasse

This is done. Stef On Oct 28, 2008, at 11:38 AM, David RÃ¶thlisberger wrote: > >> Because we want to make sure that if something wrong happen in >> Installer then all our infrastrcuture does not get impacted. >> Now from time to time we should update this method. > > I understand. But I think it's time to update this method now to get > the latest version of Installer, because the one we use right now is > really old and hard to understand (all behavior is contained in a > huge class Intaller...). > The latest version of Installer is much better built up and contains > useful new features that would make our life much easier to maintain > ScriptLoader for instance. > > David > >> When we are working on something we DO NOT want to get impacted by >> possible other problems. >> This is also why we did not loaded the latest version of OB> I do >> not want to have tools breaking under my feet >> when I need then to work NOW. >> Stef >> On Oct 23, 2008, at 6:13 PM, Alexandre Bergel wrote: >>> Dear List, >>> >>> I was wondering why this method contains: >>> fileToLoad := files detect: [ :aFile | aFile >>> beginsWith:'InstallerAll-md.1' ] ifNone: [ nil ]. >>> >>> It always load InstallerAll-md.1 >>> Why not to load the last version of Installer-Core? Will it be >>> okay to put "fileToLoad := files first" instead? >>> (files is a sorted collection in a decreasing order of version >>> numbers). >> > > _______________________________________________ > 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] Re: Arrggh - Squeak FFI in 3.10 again?!

by StÃ©phane Ducasse

On Oct 28, 2008, at 2:15 PM, Michael Rueger wrote: > StÃ©phane Ducasse wrote: > >> - should we include FFI really in the distribution (I would vote >> for if it does not put mess). > > To my understanding the point was to make it easily loadable, not > necessarily including it by default. > I'm not strongly against it but I would vote against including it in > the base distribution. You mean in the core. Yes. Now the package should be really easily loadable. I did not check the bug and the fix mentioned. > > > Michael > > _______________________________________________ > 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