May 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] O2 in 1.1
by Geert Claes May 19, 2010

May 19, 2010

Just loaded O2 in 1.1 and when I start it I get the warning "The method Collection asSortedArray has been deprecated. Use asArray sort" How do I actually change my default system browser back? -- View this message in context: http://forum.world.st/O2-in-1-1-tp2221821p2221821.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

3 4

[Pharo-project] impossible to move window :)
by StÃ©phane Ducasse May 19, 2010

May 19, 2010

is it me or the latest beta introduced a nice behavior that make sure that you cannot move windows anymore? Stef

2 4

[Pharo-project] NetNameResolver in Pharo 1.1
by Lukas Renggli May 19, 2010

May 19, 2010

In Pharo 1.0 there were some problems with the network stack (namely the NetNameResolver) and the IP6 code was reverted shortly before release, see the following issue for details: http://code.google.com/p/pharo/issues/detail?id=1884 Today I was checking with Stef for the presence of these problems in Pharo 1.1, but we could not reproduce neither on Mac, Windows nor Linux. Does anybody have problems with the following expressions in Pharo 1.1? NetNameResolver localHostAddress. NetNameResolver addressForName: 'www.yahoo.com'. Or are we doing the wrong thing to reproduce? Lukas -- Lukas Renggli www.lukas-renggli.ch

6 13

[Pharo-project] CollaborActive Book ...
by Geert Claes May 19, 2010

May 19, 2010

Is there an easier way to upload, insert and replace pictures in the Collaboractive Book? -- View this message in context: http://forum.world.st/CollaborActive-Book-tp2222835p2222835.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

1 0

[Pharo-project] about condenseChanges
by StÃ©phane Ducasse May 19, 2010

May 19, 2010

Hi marcus/others I did a condenseChanges and I'm planning to issue a new image. I wanted to avoid to put it in the stream of updates because since it takes a long time everybody can be penalized but at the same time we will not have the same flow if we start from 1.0 and press update. Thoughts? Stef

3 3

[Pharo-project] [update 1.1] #11367
by stephane ducasse May 19, 2010

May 19, 2010

11367 ----- - Issue 2435: Cleanup for release does not work due to changes in NaturalLanguageTranslator - Issue 2442: Add an help entry in WorldMenu - condense changes I will issue a new image soon Stef

1 0

[Pharo-project] Pharo 1.1: String-> arithmetic
by Veronica Isabel Uquillas Gomez May 19, 2010

May 19, 2010

Hi Stef, In Pharo 1.1 the class String has not the protocol arithmetic and its methods... why? Got errors when running some tests. Could I add them with a new version of Torch? Vero

3 4

May 19, 2010

sound cool. Estenban we need more :) On May 19, 2010, at 2:45 AM, Dale Henrichs wrote: > Yes, I don't think that it is a good idea to modify the configuration when it is published in the PharoXXMetacelloRepository. > > In the end the reason for this discussion revolves around the desire to provide a simple method for developers/users to load projects that are "known/tested to work in PharoXX". > > Creating a PharoXXMetacelloRepository means that we have a "white list" of configurations that are"known/tested to work in PharoXX". > > GoferProjectLoader provides an API for loading projects from a target repository. The API makes it very simple to load a particular project by name, without having to specify more details about the version of groups involved. It also means that one can arrange to do special things under the cover of the GoferProjectLoader, like point to a different repository based upon the version of Pharo that it is running in ... > > I think that what we need in addition to a "white list" of projects, a "white list" of _versions_ that are "known/tested to work in PharoXX." > > I think it would be straightforward to subclass/extend the GoferProjectLoader to add the notion of a version/group "white list" that records the exact configuration/version/group(s) that have been tested and known to work. This same extension to GoferProjectLoader can automatically include an overrideRepositories: to ensure that all projects/packages are loaded from the PharoXXMetacelloRepository repository... > > By default, the GoferProjectLoader loaded into PharoXX would point to PharoXXMetacelloRepository and use the "white list" of versions. > > Once a developer/user has become comfortable using PharoXX, he/she can configure GoferProjectLoader to suit his/her needs as well as directly load Configurations/versions that are not on the "white list" (using Metacello directly) without requiring any changes to the configurations or where they originated from... > > So in the end the following expression will do things differently depending upon a) which version of Pharo it is executed in and b) whether or not you are using the 'default' GoferProjectLoader: > > Gofer project load: 'SqueakDBX'. > > All while using the same Configuration... > > Dale > > StÃ©phane Ducasse wrote: >> Yes I think that this is what dale proposed. >> Dale is off line today but he will probably comment >> Stef >> >> On May 18, 2010, at 10:59 AM, Tudor Girba wrote: >> >> >> >>> Hi, >>> >>> I like this approach: >>> 1. Projects can continue to be built independently. For example, in Moose, we have already a process with multiple configurations (one for each repository) depending on each other. >>> 2. When ready, the Configurations and all related packages are "published" in the PharoXXMetacelloRepository. Having a package per Configuration makes it easy to copy it. >>> >>> The only problem is that the code of Configuration mentions explicitly the repository (especially in the case of having nested Configurations, I point to a configuration by specifying the repository, package, and class). So, I guess the simplest thing here would be to provide the default "load" method to already override dynamically all repositories with the PharoXXMetacelloRepository. >>> >>> Cheers, >>> Doru >>> >>> >>> On 18 May 2010, at 09:32, StÃ©phane Ducasse wrote: >>> >>> >>> >>>> I understand nicolas. Now my agenda is more than full. >>>> and the proposal is here. Simple >>>> >>>> ========================================================== >>>> One repo per version Pharo1.0, Pharo11 ... MetacelloRepository >>>> containing **published** configurationOfXXX >>>> -> all the dependent packages are copied locally + configuration ready to load using load. >>>> >>>> A project >>>> contain its single/or several configurationOfMyProject with the complete history >>>> people commit the config to their repository and if they want they **publish** from their repository to the version repository >>>> a version. This version is frozen -> all the dependent packages are copied locally + configuration ready to load using load. >>>> >>>> For Pharo core or pharo packages that we maintain we want to maintain it as a project. >>>> with its own repository and packages. >>>> >>>> We can use automatic build server to validate the status or migration between different repositories >>>> ========================================================== >>>> >>>> >>>> Stef >>>> >>>> On May 17, 2010, at 11:00 PM, Nicolas Cellier wrote: >>>> >>>> >>>> >>>>> The meaning of my message was don't do it for squeak, but do it for yourself. >>>>> I don't doubt the mailing list is a mine of information, but even in >>>>> the best mine you need to dig a lot before extracting the gold >>>>> nuggets. >>>>> Of course, I've got no right to control your agenda, who am I ? >>>>> You can consider the subject close, and I won't find your attitude >>>>> shocking at all. >>>>> But next time, consider writing a rationale for your own, it will >>>>> increase quality of Pharo decision process. >>>>> >>>>> Best regards >>>>> >>>>> Nicolas >>>>> >>>>> 2010/5/17 StÃ©phane Ducasse >>>>> <stephane.ducasse(a)inria.fr> >>>>> : >>>>> >>>>> >>>>>> nicolas >>>>>> >>>>>> all the information is in the metacello mailing-list and we already posted many mails on that topics in this mailing list. >>>>>> I'm sorry but I do not have the time to repeat again what we said. Now since I'm in a really good mood >>>>>> in a nutshell >>>>>> >>>>>> one repo per version Pharo1.0, Pharo11 ... MetacelloRepository >>>>>> containing configurationOfXXX frozen = all the dependent packages are copied locally + configuration ready to load using load. >>>>>> >>>>>> a project >>>>>> contain its single/or whatever configurationOfMyProject >>>>>> people publish the config to their repository and if they want they push from their repository to the version repository >>>>>> a version that they freeze (may be using tags) >>>>>> >>>>>> For Pharo core or pharo packages that we maintain we want to maintain it as a project. >>>>>> with its own repository and packages. >>>>>> >>>>>> Then we have a server that load configuration and barks if something wrong happen. And may be we kick out >>>>>> the configurationofXXX from MetacelloRepositories >>>>>> >>>>>> >>>>>> >>>>>>> Steph, >>>>>>> I understand how boring it may seem: >>>>>>> - you already discussed the subject over and over >>>>>>> - you already took decisions >>>>>>> and now we come later with new proposals, and ask you to reconsider >>>>>>> the work again... >>>>>>> >>>>>>> >>>>>> more than that. :) >>>>>> It looks like if we did not talk or think about what we are doing. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> As for the Preferences/Settings, Pharo choices are probably very weel thought. >>>>>>> >>>>>>> However, every solution will come with trade offs, and it would be >>>>>>> good to have a rationale justifying the choices you made, and perhaps >>>>>>> more importantly justifying why you did abandon some solutions, >>>>>>> because some questions might be repeated in Pharo 1.2, 1.3, 2.0 ... >>>>>>> and find different answers in different context. Note that Squeak >>>>>>> evolutions might have influence on Pharo too, and it's part of the >>>>>>> context... >>>>>>> >>>>>>> I strongly encourage you to establish your rationale on Pharo grounds >>>>>>> - independently of Andreas proposals, put it on the Pharo wiki and let >>>>>>> us know the URL. >>>>>>> >>>>>>> You also know that Squeak goals are not exactly those of Pharo w.r.t. >>>>>>> backward compatibility, so Squeak can't just blindly replicate Pharo >>>>>>> solutions without a rationale. >>>>>>> >>>>>>> The merit of Andreas proposal is to try and establish such a >>>>>>> rationale. Without it, we're bound to repeat discussions again and >>>>>>> again, >>>>>>> >>>>>>> >>>>>> So to fix the problem consider that as our proposal. >>>>>> >>>>>> Stef >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> >>>> >>> -- >>> >>> www.tudorgirba.com >>> >>> >>> "Every thing has its own flow." >>> >>> >>> >>> >>> _______________________________________________ >>> 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] [Moose-dev] rome
by Cyrille Delaunay May 19, 2010

May 19, 2010

Hello, Indeed, I started to build a small package, integrating one by one things working in Rome. You can load it from the squeak source repository: www.squeaksource.com/Athens For now, the working canvas are: - RomePluginCanvas (making the binding with cairo) - RomeBalloonCanvas You can see some examples in the class side of RomeDemo. All is not working. You can have a look at RomeDemo >> demoMovingCar, that should work with the RomePluginCanvas and the RomeBalloonCanvas. All that concern fonts is not yet integrated, a lot of thing are already broken in the sophie dev image. So all examples drawing simple form, without text, should work. You can also have a look at the version of Alain plantec, from which I based the package Athens. This is already a condense version of all stuffs from the sophie image. You can load it from: www.squeaksource.source/PharoTaskForces (load te last version of 'Rome'). The next steps are: - Integrate fonts - The class RomeSVGDemo doesn't work 2010/5/17 Tudor Girba <tudor.girba(a)gmail.com> > Hi Cyrille, > > A bird told me that you are working on a Rome plugin. What is the status? > Could we test something? :) > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "The coherence of a trip is given by the clearness of the goal." > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >

5 8

[Pharo-project] Feature: SystemOrganizer class>>default returns SystemOrganization
by Sean P. DeNigris May 19, 2010

May 19, 2010

In Pharo inbox: System-Support-SeanDeNigris.291 Motivation: I was trying to delete a category, and found SystemOrganizer via Method Names. It wasn't immediately obvious how to use it, so I had to whip out SBE to remind me of SystemOrganization. In SystemOrganizer: * Added (overrides Categorizer class>>default): SystemOrganizer class>>default ^ SystemOrganization * updated class comment Sean p.s. also submitted to Squeak inbox -- View this message in context: http://forum.world.st/Feature-SystemOrganizer-class-default-returns-SystemO… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

3 6