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

Re: [Pharo-project] [ANN] Pharo Metacello Universes

by StÃ©phane Ducasse

> Hi, > Cool, I'll update Gofer Project Loader to understand this repositories... > what we are going to do with MetacelloRepository? I would like to keep the name metacelloRepositories. > Cheers, > Esteban > > On 2010-08-04 05:21:55 -0300, Miguel Enrique CobÃ¡ MartÃnez <miguel.coba(a)gmail.com> said: > >> Hi all, >> I have created three new repositories on squeaksource: >> http://www.squeaksource.com/UniverseForPharo10 >> http://www.squeaksource.com/UniverseForPharo11 >> http://www.squeaksource.com/UniverseForPharo12 >> They are the repositories for the current versions of Pharo. The idea is >> that each new release add a new UniverseForXXX repository and populates >> it with the current UniverseForXXX packages of the stable release. >> Right now they are mostly empty, but should be populated by the >> community and the ConfigurationOfXXX maintainers. >> Most ConfigurationOfXXX packages in >> http://www.squeaksource.com/MetacelloRepository >> should be copied to UniverseForPharo10. Which versions? The last known >> version that is working correctly on Pharo 1.0. This will be the >> official universe for Pharo1.0. No ConfigurationOfXXX should be stored >> on UniverseForPharo10 if it is not working correctly on Pharo10. >> Then two things can follow: >> - If the package already has ConfigurationOfXXX package versions that >> work in Pharo 1.1, those versions should be copied to >> UniverseForPharo11. >> - If the ConfigurationOfXXX only works for Pharo1.0 and the maintainer >> want to create the configuration for Pharo 1.1, he/she must copy the >> last working configuration for the package from UniverseForPharo10 to >> UniverseForPharo11. There he/she can start modifying the package until >> it works correctly in Pharo1.1 (use the blessing: tags wisely to avoid >> marking a broken configuration as released) >> This will permit to populate the UniverseForPharo11 based on the last >> working package versions from UniverseForPharo10. From that point they >> will likely diverge because of maintenance releases to the packages in >> any UniverseForXXX repository. >> The same will must be done to migrate from UniverseForPharo11 to >> UniverseForPharo12. You get the idea. >> With time, MetacelloRepository should be deprecated in favor of this >> UniverseForXXX repositories. >> Anyone is free to copy a working version from a previous Universe to a >> new Universe. They have read/write permissions to all. >> This setup will avoid the problems we are having right now with the >> in-image changes that are rendering the ConfigurationOfXXX unusable in >> distinct releases of Pharo. >> What this means to the end user: >> - For released version of Pharo >> They will have to use gofer this way: >> Gofer new >> squeaksource: 'UniverseForPharo10'; "Or UniverseForPharo11" >> project: 'ConfigurationOfMagma'; >> load. >> ConfigurationOfMagma project latestVersion load. >> - For next releases of Pharo >> Gofer loadFromUniverse: 'Magma'. "Or with GoferProjectLoader" >> ConfigurationOfMagma project latestVersion load. >> All this depends on conventions to find the appropriate universe for >> each pharo release, and also in the support from tools (like gofer in >> this example or the GoferProjectLoader if it is part of the core image). >> The universe functionality of the tools right now rely on the >> SystemVersion current majorMinorVersion string for deciding which >> repository to connect to. This could be improved surely but for now it >> works. >> I'm loading a new version of Gofer to PharoInbox with this functionality >> added so if you want to load directly from the universes with gofer do: >> Gofer upgrade. >> Gofer loadFromUniverse: 'YourPackageAlreadyInAUniverse'. >> But wait to this change to be treated by Stephane or Lukas before >> attempt it. >> Right now there is only Magma in the three repositories, but it >> shouldn't be hard for the maintainers of the other Configurations to >> help populate the universes from Pharo1.0, Pharo1.1 and Pharo1.2. >> This will benefit us as a community because the universes for the >> released pharo versions will be mostly untouched (only maintenance >> releases) and people will have the freedom to modify the configuration >> in the unstable (currently UniverseForPharo12) universe without >> affecting the users of the stable versions. >> Also, this will avoid to have a lot of conditionals inside the >> ConfigurationOfXXX classes, because a given class will target a specific >> Pharo release (the version on the newest universes could even delete the >> methods for the old universe, because will likely won't work in the new >> universe, deleting unnecessary and legacy code from the configuration) >> Comments and improvements welcome > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 4, 2010

Re: [Pharo-project] Telling the OS that the VM wants focus

by StÃ©phane Ducasse

On Aug 4, 2010, at 1:56 PM, Max Leske wrote: > Nice idea! Hadn't thought of Growl. > The idea would be to call Growl via Alien/FFI? or that the VM is growl compliant. > > > On 04.08.2010, at 11:55, StÃ©phane Ducasse wrote: > >> why not growl events? >> >> On Aug 4, 2010, at 10:38 AM, Max Leske wrote: >> >>> Ok, thanks. >>> Would be nice if at some point in the future unhandled exceptions would notify the OS automatically (for instance). >>> >>> >>> On 04.08.2010, at 00:34, John M McIntosh wrote: >>> >>>> Many things come to mind, one is to use some of the old text to voice features of squeak and have the computer yell at you when it's ready... That should work on all platforms that support sound. >>>> >>>> More subtle and complex would be to use Alien/FFI and talk to the operating system's notification/alert API. >>>> >>>> On 2010-08-03, at 12:51 AM, Max Leske wrote: >>>> >>>>> Hi folks >>>>> >>>>> The project I'm currently working on requires that I have to wait frequently for computations / operations to complete. To control the status I used progress bars wherever possible. Now, since the operations might take several minutes I like to sometimes switch to another Desktop, maybe read an e-mail or an article. >>>>> I'd find it rather useful if the OS would notify me that the VM needs my attention as soon as the operations have completed or if there was an error during execution, so that I don't have to go and check every 30 seconds. Is there an existing way to do this? If not, I'd like to propose this as a feature for a future release (although I don't have an inkling how one would accomplish this...). >>>>> >>>>> Cheers, >>>>> Max >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> -- >>>> =========================================================================== >>>> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 >>>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >>>> =========================================================================== >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 4, 2010

Re: [Pharo-project] Gofer support for Universes

by Esteban Lorenzano

Hi, GoferProjectLoader does that, and I think it does it fine (althought is my child, he)... and it is not at core versions because no body has decided so, yet... but stef can change his mind :) Cheers, Esteban On 2010-08-04 05:27:07 -0300, Miguel Enrique CobÃ¡ MartÃnez <miguel.coba(a)gmail.com> said: > StÃ©phane, Lukas, > > I have uploaded > > Gofer-Core-MiguelCoba.124 > Gofer-Tests-MiguelCoba.117 > > to PharoInbox repository on squeaksource. > > They are based on the versions of gofer in Pharo 1.0 > Gofer-Core-MarkusDenker.117 > Gofer-Tests-MarkusDenker.116 > > and add universes support to gofer. > > What do you think, are they worth integrating to mainstream gofer? > Does this functionality belongs to Gofer? I know of GoferProjectLoader, > but it isn't part of PharoCore, so that discards it right now. > > What is the procedure to merge it to trunk gofer, if so decided, so that > a > > Gofer upgrade > > in any Pharo image gets this new version? > > Cheers

Aug. 4, 2010

Re: [Pharo-project] [ANN] Pharo Metacello Universes

by Esteban Lorenzano

Hi, Cool, I'll update Gofer Project Loader to understand this repositories... what we are going to do with MetacelloRepository? Cheers, Esteban On 2010-08-04 05:21:55 -0300, Miguel Enrique CobÃ¡ MartÃnez <miguel.coba(a)gmail.com> said: > Hi all, > > I have created three new repositories on squeaksource: > > http://www.squeaksource.com/UniverseForPharo10 > http://www.squeaksource.com/UniverseForPharo11 > http://www.squeaksource.com/UniverseForPharo12 > > They are the repositories for the current versions of Pharo. The idea is > that each new release add a new UniverseForXXX repository and populates > it with the current UniverseForXXX packages of the stable release. > > Right now they are mostly empty, but should be populated by the > community and the ConfigurationOfXXX maintainers. > > Most ConfigurationOfXXX packages in > > http://www.squeaksource.com/MetacelloRepository > > should be copied to UniverseForPharo10. Which versions? The last known > version that is working correctly on Pharo 1.0. This will be the > official universe for Pharo1.0. No ConfigurationOfXXX should be stored > on UniverseForPharo10 if it is not working correctly on Pharo10. > > Then two things can follow: > > - If the package already has ConfigurationOfXXX package versions that > work in Pharo 1.1, those versions should be copied to > UniverseForPharo11. > > - If the ConfigurationOfXXX only works for Pharo1.0 and the maintainer > want to create the configuration for Pharo 1.1, he/she must copy the > last working configuration for the package from UniverseForPharo10 to > UniverseForPharo11. There he/she can start modifying the package until > it works correctly in Pharo1.1 (use the blessing: tags wisely to avoid > marking a broken configuration as released) > > This will permit to populate the UniverseForPharo11 based on the last > working package versions from UniverseForPharo10. From that point they > will likely diverge because of maintenance releases to the packages in > any UniverseForXXX repository. > > The same will must be done to migrate from UniverseForPharo11 to > UniverseForPharo12. You get the idea. > > With time, MetacelloRepository should be deprecated in favor of this > UniverseForXXX repositories. > > Anyone is free to copy a working version from a previous Universe to a > new Universe. They have read/write permissions to all. > > This setup will avoid the problems we are having right now with the > in-image changes that are rendering the ConfigurationOfXXX unusable in > distinct releases of Pharo. > > What this means to the end user: > > - For released version of Pharo > > They will have to use gofer this way: > > Gofer new > squeaksource: 'UniverseForPharo10'; "Or UniverseForPharo11" > project: 'ConfigurationOfMagma'; > load. > ConfigurationOfMagma project latestVersion load. > > - For next releases of Pharo > > Gofer loadFromUniverse: 'Magma'. "Or with GoferProjectLoader" > ConfigurationOfMagma project latestVersion load. > > All this depends on conventions to find the appropriate universe for > each pharo release, and also in the support from tools (like gofer in > this example or the GoferProjectLoader if it is part of the core image). > The universe functionality of the tools right now rely on the > SystemVersion current majorMinorVersion string for deciding which > repository to connect to. This could be improved surely but for now it > works. > > I'm loading a new version of Gofer to PharoInbox with this functionality > added so if you want to load directly from the universes with gofer do: > > Gofer upgrade. > Gofer loadFromUniverse: 'YourPackageAlreadyInAUniverse'. > > But wait to this change to be treated by Stephane or Lukas before > attempt it. > > Right now there is only Magma in the three repositories, but it > shouldn't be hard for the maintainers of the other Configurations to > help populate the universes from Pharo1.0, Pharo1.1 and Pharo1.2. > > This will benefit us as a community because the universes for the > released pharo versions will be mostly untouched (only maintenance > releases) and people will have the freedom to modify the configuration > in the unstable (currently UniverseForPharo12) universe without > affecting the users of the stable versions. > > Also, this will avoid to have a lot of conditionals inside the > ConfigurationOfXXX classes, because a given class will target a specific > Pharo release (the version on the newest universes could even delete the > methods for the old universe, because will likely won't work in the new > universe, deleting unnecessary and legacy code from the configuration) > > Comments and improvements welcome

Aug. 4, 2010

Re: [Pharo-project] Telling the OS that the VM wants focus

by Max Leske

Nice idea! Hadn't thought of Growl. The idea would be to call Growl via Alien/FFI? On 04.08.2010, at 11:55, StÃ©phane Ducasse wrote: > why not growl events? > > On Aug 4, 2010, at 10:38 AM, Max Leske wrote: > >> Ok, thanks. >> Would be nice if at some point in the future unhandled exceptions would notify the OS automatically (for instance). >> >> >> On 04.08.2010, at 00:34, John M McIntosh wrote: >> >>> Many things come to mind, one is to use some of the old text to voice features of squeak and have the computer yell at you when it's ready... That should work on all platforms that support sound. >>> >>> More subtle and complex would be to use Alien/FFI and talk to the operating system's notification/alert API. >>> >>> On 2010-08-03, at 12:51 AM, Max Leske wrote: >>> >>>> Hi folks >>>> >>>> The project I'm currently working on requires that I have to wait frequently for computations / operations to complete. To control the status I used progress bars wherever possible. Now, since the operations might take several minutes I like to sometimes switch to another Desktop, maybe read an e-mail or an article. >>>> I'd find it rather useful if the OS would notify me that the VM needs my attention as soon as the operations have completed or if there was an error during execution, so that I don't have to go and check every 30 seconds. Is there an existing way to do this? If not, I'd like to propose this as a feature for a future release (although I don't have an inkling how one would accomplish this...). >>>> >>>> Cheers, >>>> Max >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> -- >>> =========================================================================== >>> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 >>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >>> =========================================================================== >>> >>> >>> >>> >>> _______________________________________________ >>> 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

Aug. 4, 2010

Re: [Pharo-project] about ToolBuilder

by Richard Durr

Ups, it was not written by Gilad but by Vassili: http://blog.3plus4.org/2008/11/13/how-to-design-a-smalltalk-ui-framework/ On Tue, Aug 3, 2010 at 12:15 AM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > Oh, I'm using it for Mars... but I can remove it anyway, just let me know. > > Cheers, > Esteban > > > On 2010-08-02 17:05:58 -0300, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > said: > > I agree that it should be removed, but this means that many tools need >>> to be rewritten in plain morphic. >>> >> >> do you know which ones? >> Because a lot of buildwith: methods are not used in fact. >> >> Lukas >>> >>> 2010/8/2 Richard Durr <richard.durr(a)googlemail.com>: >>> >>>> +1. >>>> See Gilad's text about least common denominator in UI-widgetery >>>> >>>> On Fri, Jul 30, 2010 at 12:20 PM, stephane ducasse >>>> <stephane.ducasse(a)free.fr> wrote: >>>> >>>>> >>>>> Hi guys >>>>> >>>>> during the sprint I discussed with Gary about ToolBuilder and we think >>>>> that it would be better to remove it >>>>> since a lot of new widgets are not covered so this means that we will >>>>> be >>>>> constantly limiting ourselves. >>>>> Of course ToolBuilder is a nice idea (if we would have several UI >>>>> framework). So far we got only one >>>>> and we would have several we would have to take the smallest common >>>>> denominator. >>>>> Another idea would be to extend toolBuilder to support new widgets. >>>>> So what do you think? >>>>> >>>>> 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 >>>> >>>> >>> >>> >>> -- >>> Lukas Renggli >>> 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 >>> >> > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 4, 2010

[Pharo-project] Issue 2750: Loading an image segment can introduce a class named AnObsoleteFake37SomeName

by Adrian Lienhard

Hi, I filed the following issue (includes a fix) regarding a bug in image segments (actually the bug is related to smart ref streams): http://code.google.com/p/pharo/issues/detail?id=2750 If somebody could take a look to check whether my change makes sense and does not introduce an unintended side effect, that would be great! Thanks, Adrian ___________________ http://www.adrian-lienhard.ch/

Aug. 4, 2010

[Pharo-project] [update 1.2] #12082

by StÃ©phane Ducasse

12082 ----- - Issue 2751: Recover last changes broken. Thanks Henrik Johanssen

Aug. 4, 2010

Re: [Pharo-project] [update 1.2] #12076

by StÃ©phane Ducasse

ok!!!! sorry I need to eat :) On Aug 4, 2010, at 1:07 PM, Henrik Johansen wrote: > On Aug 4, 2010, at 12:46 06PM, StÃ©phane Ducasse wrote: > >>> Why was SmalltalkImage >> os marked as deprecated? >>> I thought the result of previous discussion was that the methods themselves should be moved to separate classes (like OSPlatform), but the delegating method in SmalltalkImage should be kept... >> >> if we have OSPlatform as in Sophie and all the infrastructure there (like isUnix, isMacOS...) do we want to duplicate it in SmalltalkImage? >> (except for compatibility with squeak). >> >> Ideally Smalltalk should be a simple lightweight lobby to access behavior >> >> Smalltalk platform >> -> OSPlatform >> Smalltalk vm >> Smalltalk globals. >> >> Stef > > My point exactly. > I don't mind SmalltalkImage>>osVersion being deprecated, but the "lightweight lobby" delegate method SmalltalkImage >> os has been deprecated as well... > (There is no corresponding SmalltalkImage >> platform as you mentioned) > > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 4, 2010

Re: [Pharo-project] [update 1.2] #12076

by Henrik Johansen

On Aug 4, 2010, at 12:46 06PM, StÃ©phane Ducasse wrote: >> Why was SmalltalkImage >> os marked as deprecated? >> I thought the result of previous discussion was that the methods themselves should be moved to separate classes (like OSPlatform), but the delegating method in SmalltalkImage should be kept... > > if we have OSPlatform as in Sophie and all the infrastructure there (like isUnix, isMacOS...) do we want to duplicate it in SmalltalkImage? > (except for compatibility with squeak). > > Ideally Smalltalk should be a simple lightweight lobby to access behavior > > Smalltalk platform > -> OSPlatform > Smalltalk vm > Smalltalk globals. > > Stef My point exactly. I don't mind SmalltalkImage>>osVersion being deprecated, but the "lightweight lobby" delegate method SmalltalkImage >> os has been deprecated as well... (There is no corresponding SmalltalkImage >> platform as you mentioned) Cheers, Henry

Aug. 4, 2010