March 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Is there a way to get a merge from a configurationOf?

by Dale Henrichs

On 03/01/2011 01:24 PM, stephane ducasse wrote: > Hi > > I would like to know how I can get all the changes (like the merge button in MC) of a configurationOf.... > > Stef Stef, The MetacelloBrowser is getting close to providing something like that ... this morning I just added the ability to get the changes of a loaded package against the stable version, so being able to do so against an arbitrary version is not far from being there ... then firing off a command to open a changes view for each changed package in a config could be done ... Asking about merge means that you would like a merge window for each package in a configuration that has a later version in the repository or only merge for dirtied packages ... Give me some more details about what you are trying to do and I (or Alexandre) can add it to the MetacelloBrowser then you could take it for a spin ... Dale

March 1, 2011

Re: [Pharo-project] About RPackage

by Tudor Girba

This was the main problem in the original implementation because the logic of the organizer also depended on this. So, we took it out and I find this way better :). Of course, we can create a helper method for compatibility reasons, but no internal logic should depend on this. Cheers, Doru On 1 Mar 2011, at 22:59, StÃ©phane Ducasse wrote: > Another point > > RPackage>>named: aString > > | newPackage | > newPackage := self new name: aString ;yourself. > "self organizer registerPackage: newPackage." > ^ newPackage > > does not register the package and this looks suspicion to me. > > > In addition I do not remember the exact logic but the pattern with PackageInfo is that > > PackageInfo named: #foo creates the package if it does exist > > PackageInfo class>>named: aString > ^ PackageOrganizer default packageNamed: aString ifAbsent: [(self new packageName: aString) register] > > So do you remember because it may be better to have the same creation protocol. > > Stef > > >> Hi cyrille/doru and others. >> >> I do not understand why >> RPackage organizer packages contains System? >> >> In fact all the categories are mapped to packages and I wonder why. >> I imagine that this is to avoid to have mostSpecific* logic of packageInfo, >> but it means that in such a case we should merge categories to get back the package we have right now >> else we will end up with loading/saving problems. >> >> >> Stef > > -- www.tudorgirba.com "Be rather willing to give than demanding to get."

March 1, 2011

Re: [Pharo-project] About RPackage

by StÃ©phane Ducasse

Another point RPackage>>named: aString | newPackage | newPackage := self new name: aString ;yourself. "self organizer registerPackage: newPackage." ^ newPackage does not register the package and this looks suspicion to me. In addition I do not remember the exact logic but the pattern with PackageInfo is that PackageInfo named: #foo creates the package if it does exist PackageInfo class>>named: aString ^ PackageOrganizer default packageNamed: aString ifAbsent: [(self new packageName: aString) register] So do you remember because it may be better to have the same creation protocol. Stef > Hi cyrille/doru and others. > > I do not understand why > RPackage organizer packages contains System? > > In fact all the categories are mapped to packages and I wonder why. > I imagine that this is to avoid to have mostSpecific* logic of packageInfo, > but it means that in such a case we should merge categories to get back the package we have right now > else we will end up with loading/saving problems. > > > Stef

March 1, 2011

Re: [Pharo-project] About RPackage

by Tudor Girba

Hi Stef, This was the decisions that two of us (I mean me and you) took :). Categories are mapped one-to-one to RPackages. The reason is that this is the simplest path to replace categories in the system. The second step is to map the current Monticello package to RPackages so that we can load existing Monticello packages. The third step is to provide saving only of individual RPackages. Thus, Monticello should not save multiple RPackages into one Monticello package, but only make it easy to store each one in a separate package. Once this is achieved, we can merge an RPackage with a Monticello package, which means that the package that you see in the image is directly storable in a transparent way. Cheers, Doru On 1 Mar 2011, at 22:44, StÃ©phane Ducasse wrote: > Hi cyrille/doru and others. > > I do not understand why > RPackage organizer packages contains System? > > In fact all the categories are mapped to packages and I wonder why. > I imagine that this is to avoid to have mostSpecific* logic of packageInfo, > but it means that in such a case we should merge categories to get back the package we have right now > else we will end up with loading/saving problems. > > > Stef -- www.tudorgirba.com "Presenting is storytelling."

March 1, 2011

[Pharo-project] About RPackage

by StÃ©phane Ducasse

Hi cyrille/doru and others. I do not understand why RPackage organizer packages contains System? In fact all the categories are mapped to packages and I wonder why. I imagine that this is to avoid to have mostSpecific* logic of packageInfo, but it means that in such a case we should merge categories to get back the package we have right now else we will end up with loading/saving problems. Stef

March 1, 2011

Re: [Pharo-project] [BUG]: XMLRPC 1.0-alpha4 calls with -/+ 1 arg fail

by GermÃ¡n Arduino

Hi Sean: I looked into it and seems that the cs introduce a failing test. Will check deeper when have time. Cheers. 2011/2/28 GermÃ¡n Arduino <garduino(a)gmail.com>: > Thanks for the report and .cs. Will look asap. > Cheers. > > 2011/2/28, Sean P. DeNigris <sean(a)clipperadams.com>: >> It seems that 1.0-alpha4 only handles calls with one argument. The problem >> seems to be in following statement from XMLRPCServerRequest>>methodResponse: >> Â Â ret := ((srv key) perform: (srv value) with: (self params)). >> #perform:with: only expects one argument (per the comment) and fails if >> otherwise >> >> A solution is to use #perform:withArguments: like so: >> Â Â Â ret := ((srv key) perform: (srv value) withArguments: self params >> asArray). >> n.b. The parameters are stored in an OrderedCollection, which must be >> converted to an array >> >> Changeset attached: >> http://forum.world.st/file/n3328882/XMLRPCServerRequest-methodResponse.st >> XMLRPCServerRequest-methodResponse.st >> >> HTH, >> >> Sean >> >> -- >> View this message in context: >> http://forum.world.st/BUG-XMLRPC-1-0-alpha4-calls-with-1-arg-fail-tp3328882… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> > > > -- > ================================================= > GermÃ¡n S. Arduino Â <gsa @ arsol.net> Â Twitter: garduino > Arduino Software & Web Hosting Â http://www.arduinosoftware.com > PasswordsPro Â http://www.passwordspro.com > ================================================= > -- ================================================= GermÃ¡n S. ArduinoÂ <gsa @ arsol.net>Â Â Twitter: garduino Arduino Software & Web HostingÂ Â http://www.arduinosoftware.com PasswordsProÂ http://www.passwordspro.com =================================================

March 1, 2011

Re: [Pharo-project] Is there a way to get a merge from a configurationOf?

by Alexandre Bergel

This is currently not supported unfortunately. Cheers, Alexandre On 1 Mar 2011, at 18:24, stephane ducasse wrote: > Hi > > I would like to know how I can get all the changes (like the merge button in MC) of a configurationOf.... > > Stef -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 1, 2011

[Pharo-project] Is there a way to get a merge from a configurationOf?

by stephane ducasse

Hi I would like to know how I can get all the changes (like the merge button in MC) of a configurationOf.... Stef

March 1, 2011

Re: [Pharo-project] Issue 3773 in pharo: should get a better completionDialog

by pharo＠googlecode.com

Comment #1 on issue 3773 by stephane...(a)gmail.com: should get a better completionDialog http://code.google.com/p/pharo/issues/detail?id=3773 OBCompletionRequest is the configuration of the OBCompletionDialog (OBCompletionDialog openOn: aReqest) answer would be good also to merge OBPluggableListMorph into PluggableListMorph

March 1, 2011

[Pharo-project] [update 1.3] #13069

by StÃ©phane Ducasse

13069 ----- - Issue 3737: Behavior>>allSubclasses comment does not match actual implementation. - Issue 3704: remove FakeClassPool adopt: and its senders. Thanks Nicolas Cellier for the idea. - Issue 3691: Cleaning by comparing SimpleMorphic and Morphic. Thanks Fernando Olivero for the feedback.

March 1, 2011