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

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

by Mariano Martinez Peck

Hi Miguel. Sorry I was in a mini-holidays. thanks for the push :) Two weeks before (or similar) before this email, I've already created the repositories: http://www.squeaksource.com/Pharo10Metacello and http://www.squeaksource.com/Pharo11Metacello I didn't send any email because I was not sure about certain points. I want to discuss them now: 1) Problem: know which project version must be used for a particular pharo version. There are two solutions: a) When a developer commites ConfigurationOf to a particular repo, it makes sure the #lastVersion answer the correct one. b) When a developer commites ConfigurationOf to a particular repo, it makes sure the #load will load the correct version. a) is more complicated and require more time for the developer. It means you will have separate branches for each pharo version. The information is spread. with b) all the information is together in only one ConfOf in your own repo. Once it is needed, you just commit it to a particular Pharo repository and just change the #load I think b) is muuuuch easier. So...everybody knows how to install something "ConfigurationOf load". 2) Problem: projects may refer to other projects. And the referenced projects can be anywhere (for example, metacello repository). Example of ConfigurationOfOmniBrowser >> baseline11: project: 'Refactoring-Core' with: [ spec className: 'ConfigurationOfRefactoringBrowser'; loads: #('Refactoring-Core' ); file: 'ConfigurationOfRefactoringBrowser'; repository: ' http://www.squeaksource.com/MetacelloRepository' ]; So....ok., ConfigurationOfOmniBrowser will be in Pharo10Metacello (example). But...it will load the ConfigurationOfRefactoringBrowser from MonticelloRepository....WRONG!!! solution? a) change everything by hand....crap b) use repositoryOverride: b) can be used, but the problem (if I understood correclty) is that it replaces ALL repositories. So, you need to have EVERYTHING in that repo in order to work. 3) Problem: people will start to submit, may not maintain anymore, etc. I wouldn't make gloabl write such repositories. We should only give access to those that need it For me the most complicated problem is b). Ideas? Cheers Mariano On Wed, Aug 4, 2010 at 7:29 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > >> > > > > I have read the discussions and yes that would be good but some things > > concern me: > > - Repository size (maybe this is not a problem but the squeak source > > downtime come to mind) > memory disc is cheap > > > - Load in the squeak source when sync is being done. > yes > > > - Who syncs the packages, Metacello when uploadingÂ¡ Some webmaster? A > > cron? > the commiter press a button: "archive" and as a side effect all the > packages are recursively pulled up and save :) > > > - What about conflicting names in packages. > I would not bother right now. > > > - Maybe RFB-MiguelCoba.25 in ConfigurationOfRFB ask it from lukas repo > > and ConfigurationOfOtherPackage requires RFB-MiguelCoba.25 from > > squeaksource RFB repository and for any reason the packages are distinct > > (maybe a bug was found and republished in lukas repo with the same > > version number, but squeaksource version was copied before the fix was > > done) > > the one loaded by the config should be the one saved. > > > Maybe those problems never show. Anyway, the idea of having all > > available is good, but maybe not a task of Metacello, but as an > > independent effort. Metacello will just use the redundant repositories > > when installing a package. > > > > > > Cheers > > > >> > >> Else this is great. > >> > >> Stef > >> > >> > >> On Aug 4, 2010, at 11:41 AM, Adrian Lienhard wrote: > >> > >>> Hi Miguel, > >>> > >>> Thanks! It's great to see progress on this front! > >>> > >>> Cheers, > >>> Adrian > >>> > >>> On Aug 4, 2010, at 10:21 , Miguel Enrique CobÃ¡ MartÃnez wrote: > >>> > >>>> 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 > >>>> > >>>> -- > >>>> Miguel CobÃ¡ > >>>> http://miguel.leugim.com.mx > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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 > > > > -- > > Miguel CobÃ¡ > > http://miguel.leugim.com.mx > > > > > > _______________________________________________ > > 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. 12, 2010

Re: [Pharo-project] Inter-image communication

by Ralph Boland

Some time back I posted (to Squeak) the idea of doing development using two images. One image would be your development image, i.e. the image you would eventually release as your product. It would be a restricted version of the image you have in Squeak/Pharo now. The other image would be your software development tool image, roughly analogous to what the Eclipse development environment is. The advantage of such a set up would be that changes to your development image would not blow up your tool image. You could also leave out anything from your development image you didn't actually need in you product such as perhaps editors, debuggers, windows, etc. depending upon what software your product actually needed. I have no plans to actually try this anytime soon. But I am wondering: Would RemoteSmalltalk be helpful in (be a foundation for) creating such a utility? Regards, Ralph Boland Le 11/08/2010 20:17, Sean P. DeNigris a ?crit : > > > St?phane Ducasse wrote: >> >> rst? >> RemoteSmalltalk? >> > > rst = RemoteSmalltalk = SO COOL!!! > > I easily shared objects from a Pharo 1.1 image with 4 other local images - > including a Squeak 4.1 image! > > > For a hoot: > > 1. In a Pharo 1.1 image with rST installed doit: > "Transcript open. > RSTSamples serverStartup" > > 2. In a Squeak 4.1 image with rST installed doit: > "RSTBroker > startOnPort: self clientPort > logging: false. > > remoteTranscript := ('Transcript@' , self serverBrokerID) asLocalObject. > remoteTranscript show: 'everything is ok! (from client side)'; > cr" > > 3. Pick up jaw after you see that the squeak image has sent a message to the > Pharo image's Transcript, whose contents now appear as 'everything is ok! > (from client side)' > > n.b. According to the docs, in both images, doit: "RSTBroker stop" > > > How to load: > I have no write access to rST, so the required packages can be loaded as > follows: > "Gofer new > squeaksource: 'KomHttpServer'; > package: 'DynamicBindings'; > load. > > Gofer new > squeaksource: 'KomHttpServer'; > package: 'KomServices'; > load. > > Gofer new > squeaksource: 'SPDProjectUpdates'; > package: 'rST'; > load." > > Thanks for the pointer! > > 1. This seriously frees me to play with objects in different forks and > versions because I know I can beam the live objects to another image > whenever I want, and not have them stranded. > 2. This seems like it should be perfect for scripting an image, but what > shared object would allow arbitrary code to be run on the server? I played > with Workspace, but got lost down the delegation rabbit hole > > Sean > > p.s. I got it loading with minimal changes - just had to fix the underscore > assignments, and break the dependency to an old version of KomServices.

Aug. 12, 2010

[Pharo-project] license reminder

by StÃ©phane Ducasse

Dear pharoers, please do not forget to sign the license agreement and send it to me (you can by surface mail or scanned pdf). http://code.google.com/p/pharo/wiki/LicenseAgreement Stef

Aug. 12, 2010

Re: [Pharo-project] little pictures of you :)

by laurent laffont

I'm tired of creating accounts everywhere :( Laurent On Thu, Aug 12, 2010 at 8:38 AM, Serge Stinckwich < serge.stinckwich(a)gmail.com> wrote: > 2010/8/12 Peter Hugosson-Miller <oldmanlink(a)gmail.com>: > > Looks simple enough :-) > > > > http://gravatar.com/oldmanlink > > Cool ! > > What is interesting is that they provide an API to include the images > in a website. > > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 12, 2010

Re: [Pharo-project] little pictures of you :)

by Norbert Hartl

On 12.08.2010, at 08:38, Serge Stinckwich wrote: > 2010/8/12 Peter Hugosson-Miller <oldmanlink(a)gmail.com>: >> Looks simple enough :-) >> >> http://gravatar.com/oldmanlink > > Cool ! > > What is interesting is that they provide an API to include the images > in a website. It is much easier than that. You only need the generate image links that have an url in the form http://www.gravatar.com/avatar/ + MD5 hash of the email address [1] So you can either take the profile link people included in responses in this thread or you create the link from their email address btw. mine is http://gravatar.com/nhartl Norbert [1] http://en.gravatar.com/site/implement/

Aug. 12, 2010

Re: [Pharo-project] Inter-image communication

by Adrian Lienhard

Hi Sean, Thanks for sharing this. Is there a way you can put this online permanently, e.g., in a small blog post? I'm sure this is going to be of interest to other people... Cheers, Adrian On Aug 11, 2010, at 20:17 , Sean P. DeNigris wrote: > > > StÃ©phane Ducasse wrote: >> >> rst? >> RemoteSmalltalk? >> > > rst = RemoteSmalltalk = SO COOL!!! > > I easily shared objects from a Pharo 1.1 image with 4 other local images - > including a Squeak 4.1 image! > > > For a hoot: > > 1. In a Pharo 1.1 image with rST installed doit: > "Transcript open. > RSTSamples serverStartup" > > 2. In a Squeak 4.1 image with rST installed doit: > "RSTBroker > startOnPort: self clientPort > logging: false. > > remoteTranscript := ('Transcript@' , self serverBrokerID) asLocalObject. > remoteTranscript show: 'everything is ok! (from client side)'; > cr" > > 3. Pick up jaw after you see that the squeak image has sent a message to the > Pharo image's Transcript, whose contents now appear as 'everything is ok! > (from client side)' > > n.b. According to the docs, in both images, doit: "RSTBroker stop" > > > How to load: > I have no write access to rST, so the required packages can be loaded as > follows: > "Gofer new > squeaksource: 'KomHttpServer'; > package: 'DynamicBindings'; > load. > > Gofer new > squeaksource: 'KomHttpServer'; > package: 'KomServices'; > load. > > Gofer new > squeaksource: 'SPDProjectUpdates'; > package: 'rST'; > load." > > Thanks for the pointer! > > 1. This seriously frees me to play with objects in different forks and > versions because I know I can beam the live objects to another image > whenever I want, and not have them stranded. > 2. This seems like it should be perfect for scripting an image, but what > shared object would allow arbitrary code to be run on the server? I played > with Workspace, but got lost down the delegation rabbit hole > > Sean > > p.s. I got it loading with minimal changes - just had to fix the underscore > assignments, and break the dependency to an old version of KomServices. > -- > View this message in context: http://forum.world.st/Inter-image-communication-tp2320723p2321673.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 12, 2010

Re: [Pharo-project] little pictures of you :)

by Serge Stinckwich

2010/8/12 Peter Hugosson-Miller <oldmanlink(a)gmail.com>: > Looks simple enough :-) > > http://gravatar.com/oldmanlink Cool ! What is interesting is that they provide an API to include the images in a website. -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

Aug. 12, 2010

Re: [Pharo-project] little pictures of you :)

by Peter Hugosson-Miller

Looks simple enough :-) http://gravatar.com/oldmanlink Cheers, Peter On Thu, Aug 12, 2010 at 4:32 AM, Serge Stinckwich < serge.stinckwich(a)gmail.com> wrote: > 2010/8/11 Miguel Enrique CobÃ¡ MartÃnez <miguel.coba(a)gmail.com>: > > El miÃ©, 11-08-2010 a las 14:09 +0200, laurent laffont escribiÃ³: > >> +1 to pictures in website. > >> > > > > +1 to pictures in website > > -1 to facebook or external sites, but... > > > > maybe gravatar.com could be used > > +1 > > http://fr.gravatar.com/sergestinckwich > > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 12, 2010

Re: [Pharo-project] Closure bytecodes?

by Eliot Miranda

Hi James, 2010/8/11 James Ladd <james_ladd(a)hotmail.com> > Hi Eliot, > > That is a very nice blog you linked me to. Lots for me to read there. > > I read this ... > > The final bytecode is more interesting. > 143 10001111 llllkkkk jjjjjjjj iiiiiiii Push > Closure Num Copied llll Num Args kkkk BlockSize jjjjjjjjiiiiiiii > This creates a closure, initializing it from the arguments and the current > context. > > I'm missing something, is "num copied llll" the number of temps copied > from the containing method? > It is the number of values copied from the stack that become locals of the closure. In Collection>>inject: thisValue into: binaryBlock "Accumulate a running value associated with evaluating the argument, binaryBlock, with the current value of the argument, thisValue, and the receiver as block arguments. For instance, to sum the numeric elements of a collection, aCollection inject: 0 into: [:subTotal :next | subTotal + next]." | nextValue | nextValue := thisValue. self do: [:each | nextValue := binaryBlock value: nextValue value: each]. ^nextValue the closure [:each | nextValue := binaryBlock value: nextValue value: each] accesses two non-local variables binaryBlock & nextValue. Because binaryBlock is not modified its value can be copied directly but because nextValue is modified it cannot be copied and a shared location must be used to hold the value. So the compiler arranges to create an (in this case one-element) array (an indirection vector) to hold nextValue. The hidden variable holding the indirection vector is not modified so its value (the indirection vector) can be copied. Hence [:each | nextValue := binaryBlock value: nextValue value: each] has two copied values, one the value of binaryBlock and another a hidden Array that holds nextValue. Hence the bytecode: push: (Array new: 1) # create the indirection vector popIntoTemp: 2 # store it as the 3rd temp (after firstValue & binaryBlock) pushTemp: 0 # push firstValue popIntoTemp: 0 inVectorAt: 2 # initialize nextValue with firstValue self # push the receiver of #do: pushTemp: 1 # push the first copied value binaryBlock pushTemp: 2 # push the second copied value, the indirection vector holding nextValue closureNumCopied: 2 numArgs: 1 bytes 31 to 40 # create the closure with 1 arg and 2 copied values pushTemp: 1 # push binaryBlock (the 1st copied value, the 2nd temp after each) pushTemp: 0 inVectorAt: 2 # push nextValue, the 1st slot in the indirection vector which is the 3rd temp pushTemp: 0 # push each send: #value:value: (2 args) # evaluate binaryBlock value: nextValue value: each storeIntoTemp: 0 inVectorAt: 2 # store the result into nextValue (1st slot in indirection vector) blockReturn # return nextValue as the result of the block send: #do: (1 arg) # evaluate self do: [:each|...] pop # discard the result of elf do: [:each|...] pushTemp: 0 inVectorAt: 2 # push nextValue returnTop # return nextValue as the result of inject:into: If this still doesn't make sense look at the version in the first blog post that uses an explicit array and compare it with the above. HTH Eliot > Rgs, James. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 12, 2010

Re: [Pharo-project] Closure bytecodes?

by James Ladd

Hi Eliot, That is a very nice blog you linked me to. Lots for me to read there. I read this ... The final bytecode is more interesting. 143 10001111 llllkkkk jjjjjjjj iiiiiiii Push Closure Num Copied llll Num Args kkkk BlockSize jjjjjjjjiiiiiiii This creates a closure, initializing it from the arguments and the current context. I'm missing something, is "num copied llll" the number of temps copied from the containing method? Rgs, James.

Aug. 12, 2010