- Pharo-dev - lists.pharo.org

Re: [Pharo-project] MicroSqueak Was: Re: [update 1.2] #12188

by StÃ©phane Ducasse

> Now that John Maloney has released MicroSqueak as MIT > (http://web.media.mit.edu/~jmaloney/microsqueak/) shouldn't be worth to > analize it and see if that can be used as an alternative to build the > Pharo Kernel. Yes we already started. Now I think that producing microsqueak for pharo should just be the easy part. Because after you want to be able to load package and not a large mess. So this is why we did the two in parallel since august - trying to recompile a kernel (for example as specified by pharo kernel) and fixing all the packages problems we could find. So we build - tools to analyse the system - read a GNU ST based bootstrap - read chacharas (we did not read spoon because we could not find it) - We were thinking that in parallel we would use an approach like chacharas (dynamic creation of a kernel based on an expression definitively cool). gabriel started to have a look at to build a micro kernel. So now that we have one we will check it. > I know that Pavel (and now also Nicolas) have done a lot of work in > getting PharoCore stripped to a minimal kernel. > But as I understand, PharoKernel idea is to part from a core image, > reorganize packages, _unload_ what isn't needed and then shrink the > image to get a kernel image. Not necessarily. It was just starting somewhere. > The approach of John Maloney's MicroSqueak is the inverse, parting from > a source code representation and from there to aggregate code until have > a full image. I think that this is the way to go. But there is a middle man missing. > Of course the image from John hasn't all the improvements that Squeak > and Pharo have made to the core classes and that will mean a lot of > effort to reapply in order to get a modern image. It should not be that difficult. The core image does not have to have everything. It can be simple and part of it can be overload/overridden. Now the process to go from seed (microsqueak pharo name) to pharo kernel is really important because we will find all kinds of dead skeleton in the drawers :) > But I wonder, and not meaning to discourage any possibility, if isn't > worth to discuss the technical effort required and the pros/cons of each > approach and if isn't possible a reutilization of knowledge for this > very wanted goal of Pharo. We already did that :) And we will continue to learn and build. Stef > > Cheers > > -- > 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

Oct. 11, 2010

Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ?

by StÃ©phane Ducasse

On Oct 11, 2010, at 6:02 PM, James Foster wrote: > > On Oct 11, 2010, at 8:07 AM, StÃ©phane Ducasse wrote: > >> Hi guys >> >> there is a HUGE HUGE HUGE difference between >> (1) namespace at the language level and we do not want that the way german did it. > > StÃ©phane, > > Are you suggesting that the approach GermÃ¡n Leiva demonstrated at ESUG last month is "at the language level"? Could you elaborate? no time to elaborate sorry I have boring documents to write. Now this is at the language level because as a programmer I have to write it when I write my class. Look at point 2 items: you as a nice programmer do not care that your class is defined in bootstrap or normal. Stef > > James > >> Give us some times and we will try different solutions and see what come out >> (2) systemDictionary at the infrastructure level. >> We are working on that since Squeak Kernel Cleaning Project >> here we want the tools to be able to use another environment so that we can >> - bootstrap the compiler with itself >> - load different version of code (for Moose) to build report on Pharo 1.2 from pharo 1.1 >> - bootstrap the kernel >> - build atomic loading. >> We are working on 2 and this is what nick needs. >> I will not talk about namespace at the lnaguage level. No time for that. >> >> 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

Oct. 11, 2010

Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ?

by StÃ©phane Ducasse

On Oct 11, 2010, at 5:53 PM, Schwab,Wilhelm K wrote: > Nick, > > I'm certainly no expert on DST, but I will gladly help where I can. You're starting a PhD program? Is Stef your advisor? That would put you in good hands. noury luc and me :) Indeed nick you should ahve a look at VisualWorks Distributed Smalltalk. I remember now that in 3 min I could browse your browser from my machine wayback in 2002. Stef > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Nick Papoylias [npapoylias(a)gmail.com] > Sent: Monday, October 11, 2010 11:43 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ? > > I am currently concerned with remote programming (debugger, browser, compiler e.t.c) in Pharo from one image (or environment) to another, so that this infrastructure can be used in the field of autonomous robotics to ease the development cycle. > > So we should definitely exchange ideas ! Cause there surely is more than one way to go (plain sockets and API, rST, remote SystemDictionary and environment, to name a few..) > > We should keep in touch ! > > Nick > > On Mon, Oct 11, 2010 at 5:16 PM, Serge Stinckwich <serge.stinckwich(a)gmail.com<mailto:serge.stinckwich@gmail.com>> wrote: > 2010/10/11 Nick Papoylias <npapoylias(a)gmail.com<mailto:npapoylias@gmail.com>>: >> Hallo to all, >> >> I am starting my Ph.D on 'languages and environments for autonomous >> robotics' -- and pharo will be a huge part of it. > > Hi Nick, > > Great to see that another guy will work in the domain of embedded > systems&autonomous robots with Smalltalk ! > > I already talked with Noury or Luc about that. This is really > important to share code as we are a small community, especially code > to interface with existing robotics systems like ROS, OROCOS or > Player/Stage. I will start soon to work on how to integrate Smalltalk > with ROS: http://www.ros.org/wiki/ > > Regards, > -- > 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<mailto:Pharo-project@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

Oct. 11, 2010

Re: [Pharo-project] Another finalization concern: error handling

by Igor Stasenko

On 11 October 2010 22:49, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > The most important words in there are "critical section." Â Carry on :) > Oh, please. This is not too hard to code. My mind rolling around following choice(s) (there may be others i don't see). What would be a proper way to handle error during #finalize. [ executor finalize ] on: Error do: [:ex | self handleFinalizationError: ex "where self is registry" ]. or: [ executor finalize ] on: Error do: [:ex | executor handleFinalizationError: ex ]. of course, i should catch this error in test, so i can verify that: a) test is get notified upon synthetically made error b) no matter what i do inside error handler (up to 'Processor activeProcess terminate'), a finalization process continues working (or restarts without losing remainder of executors). Also, i used #ensure: and #ifCurtailed: but i tend to forget where they are applicable and how. So, little help in this regard will be wellcome. > Bill > -- Best regards, Igor Stasenko AKA sig.

Oct. 11, 2010

Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ?

by StÃ©phane Ducasse

On Oct 11, 2010, at 5:25 PM, Nick Papoylias wrote: > > > On Mon, Oct 11, 2010 at 5:11 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > > For example there currently exist a setter in the class side for 'migratting' in a new environment, that just alters the class knowledge about the new namespace and does not erase it's record from the old namespace. > where? > > Class>>environment: (as far as I understand the class changes it's environment, without erasing itself from the old one and adding itself to the new one) clearly a bug. Cna you open a ticket? if you could write a test it would be excellent. In fact this method was never build with multiple environment in mind :) > > Is this intented ? What is the underlying design ? Should we add an environment: setter in the subclass message, so that we integrate namespaces with the current Browser ? Should Behavior always return Smalltalk globals, or there should be a setter to be able to migrate a whole hierarchy of classes elsewhere ? > > Normally a class should be able to return its environment and it can be different to Smalltalk globals, for example > we want to have to environments so that we can load Opal in one to modify the other Opal compiler that we will running. > > Up to now marcus was using the old compiler to compile the new but in the future we only want one compiler and still been able to > change it. > > 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

Oct. 11, 2010

Re: [Pharo-project] Pharo by Example has moved to github

by StÃ©phane Ducasse

Ok for me do the simplest thing for you. This was just a meta remark. Stef On Oct 11, 2010, at 5:32 PM, Lukas Renggli wrote: >>> Excellent, can I also push the Seaside Book there? >> >> If you want. Now I do not see the interest of git when we use it as svn. And I would prefer to host the book on an inria server >> because I know that this is backup by someboyd else than me. >> and for a book I do not want to fork it (or people can fork it but I do not care of what they will do with their fork). > > The problem is that the sync with Pier does not work with SVN. You can > only update and backup by using Git with the SVN backend. > > Lukas > > -- > 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

Oct. 11, 2010

Re: [Pharo-project] R: R: R: R: Problem with inspector

by Frederic Pluquet

Did you expand the category NewInspector and check the two first options ? See my attached screenshot. Once done, close the inspector and reopen it. FrÃ©d ---- FrÃ©dÃ©ric Pluquet UniversitÃ© Libre de Bruxelles (ULB) Assistant http://www.ulb.ac.be/di/fpluquet 2010/10/11 morod <morod(a)tiscali.it> > Iâm sorry but something may be wrong. > > > > My Pharo.image > > > > > > NewInspector installed > > > > > > System settings > > > > I tried again and the result has not changed > > > > > > > > Thanks again for your patience > > > > Morod > > > > *Da:* pharo-project-bounces(a)lists.gforge.inria.fr [mailto: > pharo-project-bounces(a)lists.gforge.inria.fr] *Per conto di *Frederic > Pluquet > *Inviato:* lunedÃ¬ 11 ottobre 2010 00:23 > > *A:* Pharo-project(a)lists.gforge.inria.fr > *Oggetto:* Re: [Pharo-project] R: R: R: Problem with inspector > > > > It's really strange. It works perfectly here. > > > > Step by step: > > > > - Download the last image of Pharo > > - Go to Monticello and load the last package of NewInspector > > - Go to System > Settings > Debugging > NewInspector > > - Check the options > > - Open a new inspector on an object > > > > The new children must appear. > > > > FrÃ©d > > > > > ---- > FrÃ©dÃ©ric Pluquet > UniversitÃ© Libre de Bruxelles (ULB) > Assistant > http://www.ulb.ac.be/di/fpluquet > > 2010/10/10 morod <morod(a)tiscali.it> > > Thanks for your interest, I have done what was suggested, but nothing has > changed. > > > > Morod > > > > *Da:* pharo-project-bounces(a)lists.gforge.inria.fr [mailto: > pharo-project-bounces(a)lists.gforge.inria.fr] *Per conto di *Frederic > Pluquet > *Inviato:* domenica 10 ottobre 2010 17:00 > > > *A:* Pharo-project(a)lists.gforge.inria.fr > > *Oggetto:* Re: [Pharo-project] R: R: Problem with inspector > > > > If you load the last version of NewInspector (posted this morning), you go > to the Settings Browser (System > Settings in the World menu), expand > "Debugging" > "NewInspector" and check the options you want. > > > > FrÃ©d > > ---- > FrÃ©dÃ©ric Pluquet > UniversitÃ© Libre de Bruxelles (ULB) > Assistant > http://www.ulb.ac.be/di/fpluquet > > 2010/10/10 morod <morod(a)tiscali.it> > > Hello, > > > > How can I switch from the two different versions of tool âInspectorâ > > > > Best regards > > > > Morod > > > > *Da:* pharo-project-bounces(a)lists.gforge.inria.fr [mailto: > pharo-project-bounces(a)lists.gforge.inria.fr] *Per conto di *Frederic > Pluquet > *Inviato:* sabato 9 ottobre 2010 14:08 > > > *A:* Pharo-project(a)lists.gforge.inria.fr > > *Oggetto:* Re: [Pharo-project] R: Problem with inspector > > > > Hello, > > > > It's the NewInspector on both pictures but two different versions of this > tool. In the old version, the class and the methods were displayed for each > inspected object. In the current version, there are not displayed (because > the community prefers less children for each object). > > > > FrÃ©d > > ---- > FrÃ©dÃ©ric Pluquet > UniversitÃ© Libre de Bruxelles (ULB) > Assistant > http://www.ulb.ac.be/di/fpluquet > > 2010/10/8 morod <morod(a)tiscali.it> > > Hi Mariano > > > > I tried it with multiple images and the behavior is the same with all the > images. > > > > Sent the sample is made with: > > Pharo-1.1-11411 > > Latest update: #11411 > > > > The first one is my image and the second is taken from the book âPharo by > Exampleâ > > > > Thanks again > > > > Morod > > > > *Da:* pharo-project-bounces(a)lists.gforge.inria.fr [mailto: > pharo-project-bounces(a)lists.gforge.inria.fr] *Per conto di *Mariano > Martinez Peck > *Inviato:* venerdÃ¬ 8 ottobre 2010 21:43 > *A:* Pharo-project(a)lists.gforge.inria.fr > *Oggetto:* Re: [Pharo-project] Problem with inspector > > > > Hi morod, and welcome to Pharo! > > Which Pharo image are you exactly using? (the name of the zip, the image > file or go to System -> About) The first one is your image, right ? and > the second one? where is it from ? > > The difference is that the first image is using the "old" traditional > inspector, while the second picture is using another inspector, which is > called "NewInspector", which provides more information. > > Cheers > > Mariano > > 2010/10/8 morod <morod(a)tiscali.it> > > Hi > > iâm new to smalltalk and Pharo and my inspector show > > > > *Errore. Il nome file non Ã¨ specificato.* > > > > instead of > > > > *Errore. Il nome file non Ã¨ specificato.* > > Why? Thanks > > > > > _______________________________________________ > 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 > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 11, 2010

Re: [Pharo-project] Another finalization concern: error handling

by Schwab,Wilhelm K

Sig, The most important words in there are "critical section." Carry on :) Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Monday, October 11, 2010 2:36 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Another finalization concern: error handling On 11 October 2010 21:07, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > As a friend here: when did I say I'd remove all? Remove and process one at a time. I will admit to having a bias toward doing this with a single executor per object, but even if multiples turn out to have value (need to hunt down and read Levente's description of that), the same idea should apply. > Removing and processing one at a time could do the job, but it will be very inefficient (especially on VMs which not support new finalization). Because: - you have to enter critical section for scanning valueDictionary - you then have to leave critical section for sending a single #finalize - then you should start over and look for next element with nil key (if any) So, as i said, devil in details. > Bill > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 11, 2010

Re: [Pharo-project] [squeak-dev] Re: Xtreams port to Squeak - second wave

by Nicolas Cellier

2010/10/11 Levente Uzonyi <leves(a)elte.hu>: >>> >>> These problems should be solved with the latest version of CoreTests. >>> >>> Levente >> >> Thanks! > > I just realized that sometimes the 100 ms timeout is not enough even on Cog > and the test fails, 200 ms works well. It typically happens when running > #testReadWriteLargeAmount. I'd suggest increasing it to 1000 ms or more, to > make sure it doesn't fail with SqueakVM or on slower machines. > > > Levente > Just proceed (in http://www.squeaksource.com/Xtreams) if you want to.

Oct. 11, 2010

Re: [Pharo-project] Another finalization concern: error handling

by Levente Uzonyi

On Mon, 11 Oct 2010, Igor Stasenko wrote: > On 11 October 2010 21:07, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > As a friend here: when did I say I'd remove all? Â Remove and process one at a time. Â I will admit to having a bias toward doing this with a single executor per object, but even if multiples turn out to have value (need to hunt down and read Levente's description of that), the same idea should apply. > Removing and processing one at a time could do the job, but it will be very inefficient (especially on VMs which not support new finalization). Because: - you have to enter critical section for scanning valueDictionary - you then have to leave critical section for sending a single #finalize - then you should start over and look for next element with nil key (if any) So, as i said, devil in details. You can select the executors to a collection and finalize them later, so you don't have to restart the scanning of valueDictionary. Levente > Bill > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 11, 2010