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

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

[Pharo-project] ToolSet

by Pavel Krivanek

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.) The default tools are: browser changeList changeSorter changedMessageSet classCommentVersionsBrowser classListBrowser debugger dualChangeSorter hierarchyBrowser instanceBrowser lexicon messageNames messageSet packagePaneBrowser pointerFinder protocolBrowser versionsBrowser Cheers, -- Pavel

Oct. 28, 2008

Re: [Pharo-project] Merging one-click and pharo-dev

by Marcus Denker

On 27.10.2008, at 20:29, StÃ©phane Ducasse wrote: > I do not know. > >> Looks ok, just one minor change, the bundle version in the >> info.plist reads 3.8.18b1U, but it should read 3.8.18b4U >> >> I note this app doesn't have the freetype plugins for any >> platforms, are they needed? Or is that a pending feature awaiting for >> font work in the pharo image? > I did put them into the first one-click (I just copied over from Sophie for the mac version). The win version is not up-to-date, there is a bug=tracker item about that. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Oct. 28, 2008

[Pharo-project] Fwd: [squeak-dev] Re: Test Server

by StÃ©phane Ducasse

Begin forwarded message: > From: stephane ducasse <stephane.ducasse(a)free.fr> > Date: October 28, 2008 8:19:42 AM CEST > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org > >, Noury Bouraqadi <bouraqadi(a)ensm-douai.fr> > Cc: Alexandre Bergel <Alexandre.Bergel(a)inria.fr>, An open mailing > list to discuss any topics related to an open-source Smalltalk <pharo-project(a)lists.gforge.inria.fr > > > Subject: Re: [squeak-dev] Re: Test Server > > Thanks for the update. > Now I cannot do everything. So other people should also have a look > at your code and give feedback > so that we integrate it or at least give you feedbakc. > The refactoring of installer that did matthew is great. > Now it would be good if you/he could take into account the remark of > lukas about the different instances lying around. > > Stef > > > On Oct 27, 2008, at 10:30 PM, Keith Hodges wrote: > >> Alexandre Bergel wrote: >>> Hi! >>> >>> I've been told that Keith and maybe few others are working on a test >>> server. >>> In a 10 minutes seaside coding session I did a small application >>> that >>> displays a result of a SUnit test. >>> Is there anything like this around? >>> >>> Cheers, >>> Alexandre >> >> Yes... 'SUnit improved' has a TestReporter, since Jan/Feb 2007. >> >> It is designed to be invoked from the command line on any image, >> and to >> work headless if desired. >> >> It generates results to files, the idea being that the progress can >> be >> observed remotely via ftp or http. >> >> Failures and Errors are generated in a file form that can be viewed >> remotely, but selected failures/errors can be run by doiting the >> line of >> the output file. >> >> There is one file which has a byte written per test so that you can >> see >> progress remotely just by looking at the file size in a web /dir/ftp >> browser. >> >> There are also custom icons for apache to show pass/fail/errors etc >> though I am not sure where I have put them. >> >> === >> >> Please please please, you pharo guys, actually look at SUnit >> improved, >> before doing other things with SUnit, I put a lot of effort in to it, >> over the past 2 years. >> >> The latest suite defining and building architecture is really cool. >> It >> uses less code than the old system and is better factored to achieve >> more. For those of us that are interested in developing packages that >> everyone can use, we need a coherant story accross the board so >> that we >> can write tests and flag which images we expect them to work in. >> 'SUnit >> improved' has this in TestCaseVersioned. >> >> ClassClonerTestResource is another case in point, I wrote it so >> that we >> can test the class side of DateAndTime, etc, but still the wheel gets >> reinvented again and again. >> >> A really useful addition which I have been planning for ages, but you >> would be welcome to have a go at, would be excellent if SSpec specs >> could be run in the same ui. >> >> cheers >> >> Keith >> >> p.s. Bob the Builder update to follow >> >> >

Oct. 28, 2008

Re: [Pharo-project] Bob

by StÃ©phane Ducasse

Ok we have to digest that. Jannik started to expand what I wrote on Installer and the next step is Sake than Bob I want to have all that three package well reviewed, documented, advertized. Now personally I should learn Sake. On Oct 27, 2008, at 10:50 PM, Keith Hodges wrote: > Dear All, > > Bob is slowly taking shape, I am perhaps a day away from alpha, but I > don't have much spare time this week, so I expect that this will not > be > available until next week. > > If you would like to contribute, I am hanging around in squeak irc > most > (uk) evenings. > > some docs follow, > > cheers > > Keith > > .... > > ======= > * > Bob the Builder* > > */Your Build is defined as a Class/* > > To add your own 'Build' process to Bob, create a subclass of BobBuild, > with your process defined as a SakeTask returned from the class method > #build. When Bob starts his work in BobBuild-c-#taskMain, he collects > all of these tasks, and sorts them according to their dependencies. > > /*Your build can depend upon other builds*/ > > So your build can specify which other builds it depends upon, for > example: > > BobBuildMyWebServer-#build > > ^ self define: [ :task | > task dependsOn: { BobBuildSeasideOneClick build }. > > .... ... ... ]. > > /*Repositories are watched and builds run when changes are spotted*/ > > Sake-Scheduler is used to run periodic tasks. These tasks can do many > useful things, as well as running #taskMain. Scheduled tasks are > used to: > > 1. Periodically collect data that either Bob/users may need in their > work (e.g. BobPeriodicallyReadMantis ) > 2. Periodically update the Bob server image with the latest code from > contributors (e.g. BobPeriodicallyWatchRepositories ) > > You can add your own periodic tasks by subclassing ScheduledTask, > however some tasks are designed to be extended, by adding (extension) > instance methods. > > e.g. BobPeriodicallyWatchRepositories-#taskWatchPackages (watches the > squeaksource Packages repository for updates) > if you wish to invoke bob following an update to your repository this > example shows how. > > BobPeriodicallyWatchRepositories >> #taskWatchTasks > > ^ SakeTask checkUrl: 'http://www.squeaksource.com/Tasks/feed.rss' > onChanged: [ Installer sake install: 'Tasks'. > BobBuild taskMain run. ]. > > /*Configuration*/ > > Your build process 'task' #build is defined on the class side of > your Build > class. If your task has a number of "const" parameters that configure > the task, these should also be defined on the class side. For example, > the location of a working directory would be returned from > #configWorkingDir > > /*Metadata - build numbers etc*/ > > The metadata for each Build task is specified on the instance side of > the class, e.g. #build0001, #build0002. > Your task definition in #build automatically uses the most recent > metadata method. > > example metadata: > > MyBuild>>#build0001 > > info name: 'Squeak3.11-basic'. > info moniker: '311'. > info codeName: 'Kipper'. > info by: 'kph'. > info image: 'bzr://bzr.warwick.st/squeak/3.10'. > info candidate: false. > info release: false. > info overwrite: true. > info comment: 'testing'. > > > /*Only build if necessary*/ > > It is very important that your build only runs when absolutely > necessary. If your build is manually invoked by an increment in build > number (i.e. info overwrite: false) then the existence of the output > directory with that build number is enough to determine that the build > has already been run. > > If your build is automatically invoked by updates to particular > repositories, then the versions of those packages need to be > recorded in > the metadata. The metadata is written to a file in the output > directory. > Subsequent builds should compare the current metadata with that in the > file to see whether the build needs to be re-run. > > If your build is a derivative of a released product, then you only > need > to build if the dependant has #info release = true. > > > > _______________________________________________ > 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