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

Re: [Pharo-project] Kernel

by Alexandre Jasmin

On Fri, 04 Mar 2011 13:51:46 +0100, Benjamin wrote: > I finally success (with the help of Igor) to trace and create a new > Smalltalk kernel based on Pharo. The new born weight 2.2Mb and includes > 230 classes ;) Your image helps me a lot. I'm trying to get the Squeak VM compiling with Adobe Alchemy. Alchemy is a C compiler targeting the flash VM. My initial approach is to stub about all entry points expect for ioBeep() which prints a debug message. But I had problems loading a normal image. I think it's just too big for flash to handle. In any case this kernel image worked wonderfully! Thanks!

March 7, 2011

Re: [Pharo-project] Demo image for school (Link to download)

by Marcus Denker

On Mar 7, 2011, at 10:42 AM, Igor Stasenko wrote: > http://dl.dropbox.com/u/2753738/Demo.zip > ... in addition, a VM and the .sources is needed. https://gforge.inria.fr/frs/download.php/24391/PharoV10.sources.zip and a copy of a new VM (cog or the latest Squeak VM) e.g for mac: http://squeakvm.org/mac/release/Squeak%205.7.4.zip -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 7, 2011

[Pharo-project] Demo image for school (Link to download)

by Igor Stasenko

http://dl.dropbox.com/u/2753738/Demo.zip -- Best regards, Igor Stasenko AKA sig.

March 7, 2011

Re: [Pharo-project] Issue 3784 in pharo: ImageForDevelopers uses SHWorkspace which is not defined in the image

by pharo＠googlecode.com

Comment #6 on issue 3784 by Torsten....(a)astares.de: ImageForDevelopers uses SHWorkspace which is not defined in the image http://code.google.com/p/pharo/issues/detail?id=3784 Issue 3780 has been merged into this issue.

March 7, 2011

Re: [Pharo-project] Issue 3780 in pharo: DEVImageWOrkspace in prebuilt Pharo 1.2 gives DNU due to missing SHWorkspace class

by pharo＠googlecode.com

Updates: Status: Duplicate Mergedinto: 3784 Comment #4 on issue 3780 by Torsten....(a)astares.de: DEVImageWOrkspace in prebuilt Pharo 1.2 gives DNU due to missing SHWorkspace class http://code.google.com/p/pharo/issues/detail?id=3780 (No comment was entered for this change.)

March 7, 2011

Re: [Pharo-project] Issue 3784 in pharo: ImageForDevelopers uses SHWorkspace which is not defined in the image

by pharo＠googlecode.com

Comment #5 on issue 3784 by Torsten....(a)astares.de: ImageForDevelopers uses SHWorkspace which is not defined in the image http://code.google.com/p/pharo/issues/detail?id=3784 => I already proposed to use Workspace instead of SHWorkspace. see http://code.google.com/p/pharo/issues/detail?id=3780 However the "introduction workspaces" are now not not styled anymore. Dont know how to activate styling there. (if one types in the workspaces styling is activated automatically - but it should be switched on by default as it was before)

March 7, 2011

Re: [Pharo-project] Issue 3780 in pharo: DEVImageWOrkspace in prebuilt Pharo 1.2 gives DNU due to missing SHWorkspace class

by pharo＠googlecode.com

Comment #3 on issue 3780 by Torsten....(a)astares.de: DEVImageWOrkspace in prebuilt Pharo 1.2 gives DNU due to missing SHWorkspace class http://code.google.com/p/pharo/issues/detail?id=3780 Same as http://code.google.com/p/pharo/issues/detail?id=3784

March 7, 2011

Re: [Pharo-project] Pharo 1.2 and test failures

by laurent laffont

I think it's possible to produce a diff of all ConfigurationOfXXX between a built and the previous one, downloadable from Hudson. Then when something change we can know which ConfigurationOfXXX has been updated and then detect the cause of a new failing test. Laurent On Mon, Mar 7, 2011 at 12:17 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > On 06.03.2011, at 21:24, Mariano Martinez Peck wrote: > > I think there is no magic here. If you want daily build images, then you > have 2 options: > > 1) Always use ALL last version of everything > 2) Use last metacello version. Someone needs to update each configuration. > > 3) copy a fixed set of mczs to a repository and use the baseline > > I thought that all mczs are copied to a let's say pharo 1.2 repository. In > this case you don't need metacello versions because it loads the newest > version which is always true. Well, it is always true if integrating fixes > means that the changed package is put into that specific repository. But it > doesn't seem to be like that so I have to read it again :) If the packages > are taken from their own repositories than I don't see another way than to > nail the version in the metacello config and update as soon as a package is > updated. A tool like the browser will ease this step. > > Norbert > > If you want 2), then the PEOPLE needs to update configuration. There is no > magic. Don't expect to always use the last code. If you want to use 1), > perfect. But don't expect that the image is always working perfect: most > repositories are public, so people can commit crap, and even more, some > repositories are shared with squeak so someone can commit something that > doesn't work with Pharo. > > We have to choose. > > To implement 2) then the Hudson script should be updated so that it loads > the bleedingEdge: symbolic version of ConfigurationOfPharo. > > cheers > > mariano > > On Sun, Mar 6, 2011 at 8:48 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > >> >> On Mar 6, 2011, at 11:29 AM, StÃ©phane Ducasse wrote: >> >> well, I provided a fix already. And it seems that 3 mails to the list and >> the mentioning withing this mail does not make it visible. It needs an >> integration step or just to load the newest ImageForDevelopers >> >> How to tell? >> >> I think the ConfigurationOfPharo needs to be updated... >> >> Probably. Do you know what was the problem? Because I can have a look but >> I need to know what went wrong. >> >> I am all in all not happy with the process we have... we should fix it. >> >> I would not be that negative. I think that we are building an >> infrastructure and learning how to use it. >> Generating one single image is easy. Generating an infrastructure to be >> able to manage multiple images over different >> setup in another story. I think that metacello is getting there and also >> knowledge. This is why I spent time writing and fixing the >> metacello chapter. Now there is more than 30 pages and with the latest >> important features like symbolic configuration. >> >> I spent 2 hours to integrate one single changes for shout last week-end, >> so I know the pain now I think that the situation will >> get better. Then else I would like to know your solution and roadmap? >> For me this is clear: metacello and distributions are the way. I like that >> alex and dale are pushing tools on top of Metacello >> because we have first class spec and dependencies and we can use them to >> get to a much better stage and we will get there. >> >> Stef >> >> I agree with Stef ... the solution is going to involve both tools and >> process and at the moment Metacello tools are almost non-existent (Alex and >> I are trying to change that ... excellent effort Alex!) and we are still >> learning the process ... >> >> The integration process for Pharo dev should parallel the process for >> creating PharoCore ... I'm not familiar with the PharoCore integration >> process , but after a bug is submitted for fixing, someone changes a script >> or a config to get the change included in the next PharoCore build ... the >> same thing needs to happen for Pharo Dev ... the Pharo dev configuration has >> to be edited to include the proposed fixes ... >> >> The developer submitting the change _could_ update the configuration or >> the "owner" of the configuration could update the config or .... >> >> I can imagine more possibilities ... right now it probably makes sense for >> an owner to make the changes ... that way if there are configuration issues >> the owner is responsible for fixing the issues the owner could also filter >> the changes, much the same way that the bugfixes for PharoCore are filtered >> ... once the manual process settles down we can look at improving the >> process and tool support incrementally... >> >> Dale >> >> >> > >

March 7, 2011

Re: [Pharo-project] what is petitAnalyser and why does it belong to Core in ConfigurationOfPetitParser?

by StÃ©phane Ducasse

ok this is what I thought :) On Mar 7, 2011, at 8:07 AM, Lukas Renggli wrote: > The package PetitAnalyzer adds reflective facilities (querying, > rewriting, tranformation) to PetitParser. PetitAnalyzer is not > required to write and execute grammers. Typically you only need to > load the package PetitParser. I haven't written the configuration > myself, so I don't know how it is setup. > > Lukas > > On Monday, 7 March 2011, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> what is petitAnalyser and why does it belong to Core in ConfigurationOfPetitParser? >> >> Stef >> > > -- > Lukas Renggli > www.lukas-renggli.ch >

March 7, 2011

Re: [Pharo-project] what is petitAnalyser and why does it belong to Core in ConfigurationOfPetitParser?

by Lukas Renggli

> PetitAnalyzer adds this semantic analysis phase > and annotates the AST. No, PetitParser has nothing to do with the AST package of RB. What you are talking about is AST-Analyzer, and that's in the RB repository. Lukas -- Lukas Renggli www.lukas-renggli.ch

March 7, 2011