- Pharo-dev - lists.pharo.org

[Pharo-project] Fwd: Is mac hostmenu cleanup ready for inclusion?
by StÃ©phane Ducasse Dec. 28, 2009

Dec. 28, 2009

Hi mike today: no fun no smalltalk -> just project writing. so this evening I will do an update. Stef Begin forwarded message: > From: Michael Rueger <m.rueger(a)acm.org> > Date: December 28, 2009 10:07:38 AM GMT+01:00 > To: stephane ducasse <stephane.ducasse(a)free.fr> > Subject: Re: Is mac hostmenu cleanup ready for inclusion? > > Michael Rueger wrote: >> not yet, a couple of fixes missing. > > there is now a new test and HostMenu package in the inbox. > You need to save and quit the image after the update. > > People should also test if the double paste is gone, otherwise I need to come up with new test scripts... > > Michael >

1 0

[Pharo-project] How to get item under a menu?
by Adrian Kuhn Dec. 28, 2009

Dec. 28, 2009

How can I get the item under a menu? TestRunner is built with the ToolBuilder. The lists are specified with the pluggableListSpec and I can provide a selector that builds the menu. When building the menu I can add selector for the menu entries. As it seems, the item unter the menu is never known to me. Neither when building the menu nor when performing a menu item action. So what I did is the following (an obvious hack) buildMenu: aMenu | morph index | morph := thisContext sender receiver; index := morph rowAtLocation: Sensor currentPoint. itemUnderMenu := list at: index ifAbsent: nil. itemUnderMenu ifNil: [ ^ aMenu ]. ^ aMenu title: itemUnderMenu; add: 'action' action: #action; yourself action self performActionWith: itemUnderMenu Can I get this done without a thisContext hack? --AA

1 0

Re: [Pharo-project] Issue with gofer/metacello
by Dale Henrichs Dec. 27, 2009

Dec. 27, 2009

Lukas, With Gofer-dkh.105, I was able to survive the upgrade from Gofer-lr.83 to Gofer-dkh.105. Gofer-lr.83 was the base version of Gofer used during bootstrapping. The change that broke the camel's back was removing the #version iv from GoferOperation. preGofer-dkh.105 there was no accessor for #version so direct access was required. postGofer-dkh.105 an accessor is required and the loader is used as part of the loading process and my subclass of the loader is there to smooth over the changes that have been made to the Gofer API over time - the code in Metacello needs to be able to run both before and after a new version of Gofer is installed. If we had true "atomic load" we'd be able to survive this set of changes, but without it I'm not sure what can be done other than using different bootstrapping code depending upon which version of Gofer is loaded ... which bangs into the other changes to the API that have been made since Gofer-lr.83. Gofer-lr.83 dates back to pharo1.0-10493 which is when Gofer started to be pre-loaded into the RC1 images. There appear to be versionNumber parsing errors in the older versions of Gofer, that prevent me from using Gofer to determine which package is loaded, so I may have to resort to direct Monticello access to detect the loaded package versions, either that or some kind of check as the the methods that are available in Gofer and infer the "version" of Gofer that is loaded ... Once I have my hands on the "version" of Gofer that is loaded, I can arrange to have the correctly compatible Metacello code loaded on top and we're off to the races. Dale ----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: | argh! | lukas is it possible to lower the pain of dale? | | Stef | | On Dec 27, 2009, at 10:27 PM, Dale Henrichs wrote: | | > The latest Gofer API is not backward compatible with the earlier | versions of the Gofer API. This means that I need to have different | versions of Metacello to use with the different versions of Gofer. | Unfortunately, I can't use Gofer to detect which version of Gofer is | loaded because of the API changes. So I will have to write more code | than I'd like to detect which version of Gofer is pre-installed. The | API changes also impact the bootstrapping code. | > | > Solving these problems are a larger project than I can undertake on | a Sunday and I _am_ on vacation the coming week as well. | > | > So until further notice, if you want to use Metacello 1.0-beta.17 | (or earlier) in Pharo you will have to manually ensure Gofer-lr.83 (or | earlier) is loaded into your image before attempting to load any | Metacello configurations. I'm not sure that you use Gofer to load an | earlier version of itself (I'll be finding out in the next few | days)... | > | > Metacello 1.0-beta.18 works with Gofer-lr.107 (in pharo 1.0-10502). | If you want to use Metacello 1.0-beta.18 (currently in development, so | it's subject to change). You will have to manually bootstrap Metacello | by executing: | > | > Gofer new | > gemsource: 'metacello'; | > package: 'ConfigurationOfMetacello'; | > load. | > (Smalltalk at: #ConfigurationOfMetacello) perform: | #ensureMetacello18. | > ((Smalltalk at: #ConfigurationOfMetacello) project version: | '1.0-beta.18') load: 'ALL'. | > | > before loading your configuration. | > | > I won't release 1.0-beta.18 until I've resolved the bootstrapping | problem. I'm pretty sure that there is a technical solution, but it | will take several days for me to get it implemented. | > | > Dale | > | > ----- "Dale Henrichs" <dale.henrichs(a)gemstone.com> wrote: | > | > | Version 1.0-beta.18 (development) should have fixes for the | latest | > | Gofer. 1.0-beta.18 is currently in #development so it is | automatically | > | loaded. When I get the chance to test the Metacello fixes with | 10502, | > | I'll #release 1.0-beta.18 (and will be automatically loaded). | > | | > | Dale | > | ----- "Alexandre Bergel" <alexandre(a)bergel.eu> wrote: | > | | > | | Hi Lukas, | > | | | > | | In a fresh 10502 I evaluated: | > | | -=-=-=-=-=-=-=-=-= | > | | [ Gofer gofer load ] | > | | on: Error | > | | do: [ :err | err retry ]. | > | | Gofer gofer recompile. | > | | Gofer new | > | | squeaksource: 'Mondrian'; | > | | addPackage: 'ConfigurationOfMondrian'; | > | | load. | > | | (Smalltalk at: #ConfigurationOfMondrian) perform: | #loadLastStable. | > | | -=-=-=-=-=-=-=-=-= | > | | | > | | I have the same error. | > | | The error comes from: | > | | | > | | -=-=-=-=-=-=-=-=-= | > | | MetacelloMCProject>>updateProject | > | | "load the latest version of the configuration package" | > | | | > | | | mcLoader | | > | | (mcLoader := self loader) == nil | > | | ifTrue: [ mcLoader := self project loaderClass on: nil ]. | > | | mcLoader doingLoads: [ | > | | | gofer | | > | | gofer := Gofer new. | > | | MCWorkingCopy | > | | managersForClass: self configuration class | > | | do: [:mgr | | > | | gofer add: (GoferPackageReference name: mgr packageName | > | | repository: mgr repositoryGroup) versionReference. | > | | Transcript cr; show: 'Loading -> ', mgr packageName, ' <-' | ]. | > | | gofer load ]. | > | | ^true | > | | -=-=-=-=-=-=-=-=-= | > | | | > | | Cheers, | > | | Alexandre | > | | | > | | On 27 Dec 2009, at 17:27, Lukas Renggli wrote: | > | | | > | | >> After proceeding these warnings, I have a rollback: MNU | > | | >> GoferPackageReference class>>name:repository: | > | | > | > | | > Can you evaluate | > | | > | > | | > [ Gofer gofer load ] | > | | > on: Error | > | | > do: [ :err | err retry ]. | > | | > Gofer gofer recompile. | > | | > | > | | > ? I don't have any senders of #name:repository: to | > | | > GoferPackageReference. | > | | > | > | | > Lukas | > | | > | > | | > -- | > | | > Lukas Renggli | > | | > http://www.lukas-renggli.ch | > | | > | > | | > _______________________________________________ | > | | > Pharo-project mailing list | > | | > Pharo-project(a)lists.gforge.inria.fr | > | | > | > | | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > | | > | > | | | > | | -- | > | | _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | > | | Alexandre Bergel http://www.bergel.eu | > | | ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. | > | | | > | | | > | | | > | | | > | | | > | | | > | | _______________________________________________ | > | | 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

1 0

Re: [Pharo-project] Issue with gofer/metacello
by Dale Henrichs Dec. 27, 2009

Dec. 27, 2009

The latest Gofer API is not backward compatible with the earlier versions of the Gofer API. This means that I need to have different versions of Metacello to use with the different versions of Gofer. Unfortunately, I can't use Gofer to detect which version of Gofer is loaded because of the API changes. So I will have to write more code than I'd like to detect which version of Gofer is pre-installed. The API changes also impact the bootstrapping code. Solving these problems are a larger project than I can undertake on a Sunday and I _am_ on vacation the coming week as well. So until further notice, if you want to use Metacello 1.0-beta.17 (or earlier) in Pharo you will have to manually ensure Gofer-lr.83 (or earlier) is loaded into your image before attempting to load any Metacello configurations. I'm not sure that you use Gofer to load an earlier version of itself (I'll be finding out in the next few days)... Metacello 1.0-beta.18 works with Gofer-lr.107 (in pharo 1.0-10502). If you want to use Metacello 1.0-beta.18 (currently in development, so it's subject to change). You will have to manually bootstrap Metacello by executing: Gofer new gemsource: 'metacello'; package: 'ConfigurationOfMetacello'; load. (Smalltalk at: #ConfigurationOfMetacello) perform: #ensureMetacello18. ((Smalltalk at: #ConfigurationOfMetacello) project version: '1.0-beta.18') load: 'ALL'. before loading your configuration. I won't release 1.0-beta.18 until I've resolved the bootstrapping problem. I'm pretty sure that there is a technical solution, but it will take several days for me to get it implemented. Dale ----- "Dale Henrichs" <dale.henrichs(a)gemstone.com> wrote: | Version 1.0-beta.18 (development) should have fixes for the latest | Gofer. 1.0-beta.18 is currently in #development so it is automatically | loaded. When I get the chance to test the Metacello fixes with 10502, | I'll #release 1.0-beta.18 (and will be automatically loaded). | | Dale | ----- "Alexandre Bergel" <alexandre(a)bergel.eu> wrote: | | | Hi Lukas, | | | | In a fresh 10502 I evaluated: | | -=-=-=-=-=-=-=-=-= | | [ Gofer gofer load ] | | on: Error | | do: [ :err | err retry ]. | | Gofer gofer recompile. | | Gofer new | | squeaksource: 'Mondrian'; | | addPackage: 'ConfigurationOfMondrian'; | | load. | | (Smalltalk at: #ConfigurationOfMondrian) perform: #loadLastStable. | | -=-=-=-=-=-=-=-=-= | | | | I have the same error. | | The error comes from: | | | | -=-=-=-=-=-=-=-=-= | | MetacelloMCProject>>updateProject | | "load the latest version of the configuration package" | | | | | mcLoader | | | (mcLoader := self loader) == nil | | ifTrue: [ mcLoader := self project loaderClass on: nil ]. | | mcLoader doingLoads: [ | | | gofer | | | gofer := Gofer new. | | MCWorkingCopy | | managersForClass: self configuration class | | do: [:mgr | | | gofer add: (GoferPackageReference name: mgr packageName | | repository: mgr repositoryGroup) versionReference. | | Transcript cr; show: 'Loading -> ', mgr packageName, ' <-' ]. | | gofer load ]. | | ^true | | -=-=-=-=-=-=-=-=-= | | | | Cheers, | | Alexandre | | | | On 27 Dec 2009, at 17:27, Lukas Renggli wrote: | | | | >> After proceeding these warnings, I have a rollback: MNU | | >> GoferPackageReference class>>name:repository: | | > | | > Can you evaluate | | > | | > [ Gofer gofer load ] | | > on: Error | | > do: [ :err | err retry ]. | | > Gofer gofer recompile. | | > | | > ? I don't have any senders of #name:repository: to | | > GoferPackageReference. | | > | | > Lukas | | > | | > -- | | > Lukas Renggli | | > http://www.lukas-renggli.ch | | > | | > _______________________________________________ | | > Pharo-project mailing list | | > Pharo-project(a)lists.gforge.inria.fr | | > | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | | > | | | | -- | | _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | | Alexandre Bergel http://www.bergel.eu | | ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. | | | | | | | | | | | | | | _______________________________________________ | | 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

3 2

[Pharo-project] Feedback on issue 1703
by Mariano Martinez Peck Dec. 27, 2009

Dec. 27, 2009

Does someone has something to comment for http://code.google.com/p/pharo/issues/detail?id=1703 ? Thanks Mariano

2 1

[Pharo-project] Happy new year in advance :)
by StÃ©phane Ducasse Dec. 27, 2009

Dec. 27, 2009

Hi guys I just want to thank you for your positive energy. We had a dream with marcus about a better Smalltalk and this is happening. This is cool. It was not easy but the community is moving - more than we would ever thought after all these years trying to push with less success. Our vision for pharo is described on the pharo web site :) http://www.pharo-project.org/about Now my personal challenge/vision is the following: - I want Pharo to be a cool vehicule for innovation. - I want Pharo to be a solid vehicule for companies to succeed making a living with "Smalltalk" --- I put "" because I would like to avoid to get bound until the end of my life with just a Smalltalk :) but I would love to see companies starting in France around Pharo if you are interested contact me :) Let us really invent the future building on the past. If you want to help, check the mailing-list - you can see our open-process: open and pragmatic communication, discussing and learning are key for us -- sorry for the volume of mails. Spread the word: Pharo is what we will make it to be. Don't always trust what others write between the lines on us. ;-D Check by yourself (drink a beer with us before) and study history - all is in there. Stef

2 1

Re: [Pharo-project] [Metacello] Re: Issue with gofer/metacello
by Dale Henrichs Dec. 27, 2009

Dec. 27, 2009

Doru, I've seen that ... more changes to the gofer api were made after I did my initial port:( I'm writing an email to the pharo list covering the problem and will cc it here as well. Dale ----- "Tudor Girba" <tudor.girba(a)gmail.com> wrote: | Hi Dale, | | I did, but there seems to be an error during the bootstrapping of the | | metacello in a new Pharo image. | | Cheers, | Doru | | | On 27 Dec 2009, at 20:06, Dale Henrichs wrote: | | > Doru, | > | > Have you tried 1.0-beta.18 with the "latest gofer"? | > | > Dale | > ----- "Tudor Girba" <tudor.girba(a)gmail.com> wrote: | > | > | Hi, | > | | > | The problem is that Metacello is not quite working with the | latest | > | Gofer. | > | | > | Cheers, | > | Doru | > | | > | | > | On 27 Dec 2009, at 17:39, Alexandre Bergel wrote: | > | | > | > Hi Lukas, | > | > | > | > In a fresh 10502 I evaluated: | > | > -=-=-=-=-=-=-=-=-= | > | > [ Gofer gofer load ] | > | > on: Error | > | > do: [ :err | err retry ]. | > | > Gofer gofer recompile. | > | > Gofer new | > | > squeaksource: 'Mondrian'; | > | > addPackage: 'ConfigurationOfMondrian'; | > | > load. | > | > (Smalltalk at: #ConfigurationOfMondrian) perform: | #loadLastStable. | > | > -=-=-=-=-=-=-=-=-= | > | > | > | > I have the same error. | > | > The error comes from: | > | > | > | > -=-=-=-=-=-=-=-=-= | > | > MetacelloMCProject>>updateProject | > | > "load the latest version of the configuration package" | > | > | > | > | mcLoader | | > | > (mcLoader := self loader) == nil | > | > ifTrue: [ mcLoader := self project loaderClass on: nil ]. | > | > mcLoader doingLoads: [ | > | > | gofer | | > | > gofer := Gofer new. | > | > MCWorkingCopy | > | > managersForClass: self configuration class | > | > do: [:mgr | | > | > gofer add: (GoferPackageReference name: mgr packageName | > | > repository: mgr repositoryGroup) versionReference. | > | > Transcript cr; show: 'Loading -> ', mgr packageName, ' <-' | ]. | > | > gofer load ]. | > | > ^true | > | > -=-=-=-=-=-=-=-=-= | > | > | > | > Cheers, | > | > Alexandre | > | > | > | > On 27 Dec 2009, at 17:27, Lukas Renggli wrote: | > | > | > | >>> After proceeding these warnings, I have a rollback: MNU | > | >>> GoferPackageReference class>>name:repository: | > | >> | > | >> Can you evaluate | > | >> | > | >> [ Gofer gofer load ] | > | >> on: Error | > | >> do: [ :err | err retry ]. | > | >> Gofer gofer recompile. | > | >> | > | >> ? I don't have any senders of #name:repository: to | > | >> GoferPackageReference. | > | >> | > | >> Lukas | > | >> | > | >> -- | > | >> Lukas Renggli | > | >> http://www.lukas-renggli.ch | > | >> | > | >> _______________________________________________ | > | >> Pharo-project mailing list | > | >> Pharo-project(a)lists.gforge.inria.fr | > | >> | > | | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > | >> | > | > | > | > -- | > | > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | > | > Alexandre Bergel http://www.bergel.eu | > | > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. | > | > | > | > | > | > | > | > | > | > | > | > | > | > _______________________________________________ | > | > Pharo-project mailing list | > | > Pharo-project(a)lists.gforge.inria.fr | > | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- | > project | > | | > | -- | > | www.tudorgirba.com | > | | > | "From an abstract enough point of view, any two things are | similar." | | -- | www.tudorgirba.com | | "What is more important: To be happy, or to make happy?"

1 0

[Pharo-project] Collection>>select: aBlock ifNoneTakeAsDefault: aDefaultValue
by Bart Gauquie Dec. 27, 2009

Dec. 27, 2009

Dear all, While developing some code, I made following extension of the Collection protocol: select: aBlock ifNoneTakeAsDefault: aDefaultValue |result| result := self select: aBlock. (result isEmpty) ifTrue: [^self class with: aDefaultValue] ifFalse: [^result]. Maybe this could be added to the Pharo 1.1 Collection clazz? Or do we want to keep the interface of Collection as small as possible (which is also a good idea!). Kind Regards, Bart -- imagination is more important than knowledge - Albert Einstein Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein The true sign of intelligence is not knowledge but imagination. - Albert Einstein Gravitation is not responsible for people falling in love. - Albert Einstein

6 9

[Pharo-project] Issue 1182: Right clicking in the System browser brings up the debugger
by Danny Chan Dec. 27, 2009

Dec. 27, 2009

Hi! This issue http://code.google.com/p/pharo/issues/detail?id=1182 is closed, but I see the same behaviour in the current pharo1.0-10502-rc1dev09.12.2 image. I also get the same exception when I press escape in the code pane. Danny

1 0

[Pharo-project] Loading latest Seaside 3.0 in latest Pharo 1.1
by Ramiro Diaz Trepat Dec. 27, 2009

Dec. 27, 2009

Is there a proper and simple way to do this with Gofer ? Thanks

2 1