- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Re: Arrggh - Squeak FFI in 3.10 again?!

by Michael Rueger

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

Oct. 28, 2008

[Pharo-project] Re: Arrggh - Squeak FFI in 3.10 again?!

by StÃ©phane Ducasse

We will. Now the question is - is the bug really fixed? - should we include FFI really in the distribution (I would vote for if it does not put mess). Stef On Oct 28, 2008, at 12:44 PM, Torsten Bergmann wrote: > Hi Kjell, > > I came across your postings on problems on installing Exupery [1] in > Squeak. > > I'm sure your problem is the Installation of FFI in the 3.10 image > again. Arrrgghh!!! > See the bug + fix [2] - just file in the changeset from above > location [2] before loading FFI > and tell me if it works. > > Unfortunately I tried to convince the community several times (see > [3] for an example) to > update the default 3.10 download images: > - since people typically start by downloading an image from the > website > - since FFI is a very often used package for some of us and some > packages depend on it > - since not every new user knows about bug 6980 > > But unfortunately still nobody really cares. Yes there are nice > Installer scripts and friends - > but they dont automatically fix this problem for a fresh 3.10 Squeak > download. > > However I als filed a bug report + fix [4] for Pharo in the hope > that this Squeak distribution will be > more user friendly than the standard Squeak in the future... > > Thx > Torsten > > [1] http://lists.squeakfoundation.org/pipermail/exupery/2008-October/000318.html > [2] http://bugs.squeak.org/view.php?id=6980 > [3] http://tech.groups.yahoo.com/group/squeak/message/132882 > [4] http://code.google.com/p/pharo/issues/detail?id=232 > -- > Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! > Ideal fÃ¼r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer >

Oct. 28, 2008

[Pharo-project] Arrggh - Squeak FFI in 3.10 again?!

by Torsten Bergmann

Hi Kjell, I came across your postings on problems on installing Exupery [1] in Squeak. I'm sure your problem is the Installation of FFI in the 3.10 image again. Arrrgghh!!! See the bug + fix [2] - just file in the changeset from above location [2] before loading FFI and tell me if it works. Unfortunately I tried to convince the community several times (see [3] for an example) to update the default 3.10 download images: - since people typically start by downloading an image from the website - since FFI is a very often used package for some of us and some packages depend on it - since not every new user knows about bug 6980 But unfortunately still nobody really cares. Yes there are nice Installer scripts and friends - but they dont automatically fix this problem for a fresh 3.10 Squeak download. However I als filed a bug report + fix [4] for Pharo in the hope that this Squeak distribution will be more user friendly than the standard Squeak in the future... Thx Torsten [1] http://lists.squeakfoundation.org/pipermail/exupery/2008-October/000318.html [2] http://bugs.squeak.org/view.php?id=6980 [3] http://tech.groups.yahoo.com/group/squeak/message/132882 [4] http://code.google.com/p/pharo/issues/detail?id=232 -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal fÃ¼r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Oct. 28, 2008

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

by Keith Hodges

David RÃ¶thlisberger wrote: > Hi Matthew, > >> 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

Oct. 28, 2008

Re: [Pharo-project] ScriptLoader>>installingInstaller

by David RÃ¶thlisberger

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

Oct. 28, 2008

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

by David RÃ¶thlisberger

Hi Matthew, > 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? > Were you unaware of it? I don't understand why > this is needed. In Pharo we use a pretty old version of Installer, eg. there everything is still contained in one huge Installer class... Cheers, David > On Thu, Oct 23, 2008 at 05:53:06PM +0200, squeak-dev-noreply(a)lists.squeakfoundation.org wrote: >> A new version of Installer-Core was added to project Installer: >> http://www.squeaksource.com/Installer/Installer-Core-AlexandreBergel.244.mcz >> >> ==================== Summary ==================== >> >> Name: Installer-Core-AlexandreBergel.244 >> Author: AlexandreBergel >> Time: 23 October 2008, 5:53:02 pm >> UUID: 2080ff3e-6f59-4f15-91c2-ff07703cbccf >> Ancestors: Installer-Core-kph.243 >> >> added #installLatest: method to Installer >> >> =============== Diff against Installer-Core-kph.243 =============== >> >> Item was added: >> + ----- Method: Installer>>installLatest: (in category 'instanciation') ----- >> + installLatest: packageNameCollectionOrDetectBlock >> + | versions | >> + self addPackage: packageNameCollectionOrDetectBlock. >> + versions := (self availablePackages select: [:e | e beginsWith: packageNameCollectionOrDetectBlock]) asSortedCollection: [:a :b | >> + [(a findBetweenSubStrs: #($.)) allButLast last asInteger > (b findBetweenSubStrs: #($.)) allButLast last asInteger] >> + on: Error do: [:ex | false]]. >> + versions isEmpty ifTrue: [^ self]. >> + self packages removeLast. >> + self addPackage: versions first. >> + >> + ^ self install! >> >

Oct. 28, 2008