- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Problem with inspector

by Mariano Martinez Peck

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 > > > > > > instead of > > > > Why? Thanks > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 8, 2010

[Pharo-project] Problem with inspector

by morod

Hi i'm new to smalltalk and Pharo and my inspector show instead of Why? Thanks

Oct. 8, 2010

Re: [Pharo-project] XTream was Re: Ocean (was Re: Less plugins, more Smalltalk code!)

by Nicolas Cellier

2010/10/8 Sven Van Caekenberghe <sven(a)beta9.be>: > > On 07 Oct 2010, at 21:41, Nicolas Cellier wrote: > >> Yes, every time I must warn and apologize because I'm guilty of hijacking the name. > > [....] > > Thank you Nicolas, for the elaborate explanation (I should have checked the wiki on SS first myself). > > With your latest updates, everything loads and all tests are green in Pharo 1.1.1 > > Is this a correct summary then ? > > You started Squeak XTreams based on both ideas in VW Xtreams and your own, at a time when VW Xtreams was not MIT licensed (and maybe incomplete). Your goal was/is not API level compatibility with VW Xtreams. Squeak XTreams values backwards compatibilty/integration a bit more, speed is important as well. > > I haven't looked deep enough into Squeak Xtreams yet. Reading the high level descriptions (slides and website docs) of VW Xtreams I get this warm feeling of 'Yes, this is it, this all makes perfect sense, feels good'. But apart from some historical influences, the relation with Squeak Xtreams seems rather limited. > Yes that's a correct description of the past and present. The futur is opened, and the main options for Squeak Xtream are: 1) change goals to get closer to VW - with a compatible API and lot of mud underneath to glue the implementation on squeak 2) stay at a proof of concept experimental level 3) continue developping independantly as a replacement for Stream There is a lot of buzz recently, and a renewed interest in VW Xtream. So there is a chance to gather enough force to attempt a squeak port, whether based on Squeak Xtream experiments or not. But it's not to me alone to answer this challenge. Nicolas > Sven > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 8, 2010

Re: [Pharo-project] Cmd-t in OB?

by Alexandre Bergel

> Gofer project loadStable: 'OB'. > Gofer project loadDevelopment: 'OB'. > Gofer project loadStable: 'OB' group: #( 'Tests' 'Javascript'). > Gofer project loadBleedingEdge: 'OB'. > Gofer project load: 'OB' version: '1.1.4'. Yes yes yes !! Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 8, 2010

Re: [Pharo-project] 12186 image quit problem

by Igor Stasenko

2010/10/8 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > > > On Fri, Oct 8, 2010 at 7:15 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: >> >> >> On Fri, Oct 8, 2010 at 5:06 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>> 2010/10/8 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >>> > Hi Marcus, >>> > is that really all what happened between 12172 and 12186? >>> > >>> > update12186 >>> > Issue 3071: fixing timestamp tests >>> > Issue 3068: Non portable SmalltalkImage>>platformName >>> > deprecationWarning >>> > Issue 3063: removing explain >>> > Issue 3039: There should not be any configuration on Core >>> > It doesn't explain the problems with VM versions and in 12186 I cannot >>> > build >>> > the PharoKernel (it hangs without error in unload phase) >>> > -- Pavel >>> > >>> please , tell me if it keep hanging after you doing: >>> >>> WeakArray restartFinalizationProcess. >>> >>> it seems like a deadlock with WeakArray's FinalizationLock or >>> FinalizationSemaphore. >> >> it hangs for me... >> -- Pavel > > with the MCMethodDefinition>>shutdown hack it work well so, at least we know what causing it. Now i wonder, what may cause that WeakArray classPool at: #FinalizationLock get locked by some other process and not released anymore? > -- Pavel > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 8, 2010

Re: [Pharo-project] 12186 image quit problem

by Igor Stasenko

2010/10/8 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > > > On Fri, Oct 8, 2010 at 5:06 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> 2010/10/8 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >> > Hi Marcus, >> > is that really all what happened between 12172 and 12186? >> > >> > update12186 >> > Issue 3071: fixing timestamp tests >> > Issue 3068: Non portable SmalltalkImage>>platformName deprecationWarning >> > Issue 3063: removing explain >> > Issue 3039: There should not be any configuration on Core >> > It doesn't explain the problems with VM versions and in 12186 I cannot >> > build >> > the PharoKernel (it hangs without error in unload phase) >> > -- Pavel >> > >> please , tell me if it keep hanging after you doing: >> >> WeakArray restartFinalizationProcess. >> >> it seems like a deadlock with WeakArray's FinalizationLock or >> FinalizationSemaphore. > > it hangs for me... hmm. strange. i can't reproduce this anymore (even after taking fresh 12186 image). > -- Pavel > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 8, 2010

Re: [Pharo-project] 12186 image quit problem

by Pavel Krivanek

On Fri, Oct 8, 2010 at 7:15 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com>wrote: > > > On Fri, Oct 8, 2010 at 5:06 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> 2010/10/8 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >> > Hi Marcus, >> > is that really all what happened between 12172 and 12186? >> > >> > update12186 >> > Issue 3071: fixing timestamp tests >> > Issue 3068: Non portable SmalltalkImage>>platformName deprecationWarning >> > Issue 3063: removing explain >> > Issue 3039: There should not be any configuration on Core >> > It doesn't explain the problems with VM versions and in 12186 I cannot >> build >> > the PharoKernel (it hangs without error in unload phase) >> > -- Pavel >> > >> please , tell me if it keep hanging after you doing: >> >> WeakArray restartFinalizationProcess. >> >> it seems like a deadlock with WeakArray's FinalizationLock or >> FinalizationSemaphore. > > > it hangs for me... > > -- Pavel > with the MCMethodDefinition>>shutdown hack it work well -- Pavel

Oct. 8, 2010

Re: [Pharo-project] Cmd-t in OB?

by Dale Henrichs

On 10/08/2010 08:26 AM, Alexandre Bergel wrote: >> There is a long thread in the metacello mailing list where those topics >> are being discussed and Dale is right now working in the new code to >> support them. So if you want to be heard please propose those guidelines >> there so they are taken in account. > > Yep, I know the value of a mailing list for a community. However, I simply cannot afford to spend hours reading all (very long) the emails on that topic. Once a Pharo community will be bootstrapped in Chile, then I will be more able to participate on topics that do not directly matter for the university, my employer. > > Writing a six-lines email is as valuable as writing a method of six-line of code, at least to me :-) > > Cheers, > Alexandre Alexandre, Understood, that is why the discussion is taking place on the Metacello list ... There are actually a number of issues that are being addressed by a small set of concepts so a number of us are working through the issues trying to iron out the details ... The actual implementation is not that complicated, but we are making significant additions to the conceptual model so we are taking care (the devil is in the details). In the end you will see something like the following announced as the model for loading projects: Gofer project loadStable: 'OB'. Gofer project loadDevelopment: 'OB'. Gofer project loadStable: 'OB' group: #( 'Tests' 'Javascript'). Gofer project loadBleedingEdge: 'OB'. Gofer project load: 'OB' version: '1.1.4'. along with documentation for specifying the #stableVersion, #developmentVersion and #bleedingEdgeVersion. I think that Mariano and I fully expect to make a pass on the majority of configurations in the MetacelloRepository to update the configs to match the expectations and provide examples. Dale

Oct. 8, 2010

Re: [Pharo-project] 12186 image quit problem

by Pavel Krivanek

On Fri, Oct 8, 2010 at 5:06 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 2010/10/8 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > > Hi Marcus, > > is that really all what happened between 12172 and 12186? > > > > update12186 > > Issue 3071: fixing timestamp tests > > Issue 3068: Non portable SmalltalkImage>>platformName deprecationWarning > > Issue 3063: removing explain > > Issue 3039: There should not be any configuration on Core > > It doesn't explain the problems with VM versions and in 12186 I cannot > build > > the PharoKernel (it hangs without error in unload phase) > > -- Pavel > > > please , tell me if it keep hanging after you doing: > > WeakArray restartFinalizationProcess. > > it seems like a deadlock with WeakArray's FinalizationLock or > FinalizationSemaphore. it hangs for me... -- Pavel

Oct. 8, 2010

Re: [Pharo-project] Cmd-t in OB?

by Dale Henrichs

On 10/08/2010 08:25 AM, Lukas Renggli wrote: > Yeah, I agree, there is definitely a need for Metacello. > > I suggest to make it easier to use, faster and more lightweight. > Currently it is more the opposite. > > I propose something along Gofer, but for Metacello (I believe somebody > already did something like this?): > > 1. loading the latest stable version must be dead simple > > Metacello new project: 'OB'; loadStable > > 2. loading the latest development version must be dead simple > > Metacello new project: 'OB'; loadDevelopment > > 3. specifying what groups to load must be dead simple > > Metacello new project: 'Seaside'; group: 'Tests'; group: 'Javascript'; load > > 4. loading should not require to additional infrastructure to be > loaded into a Pharo image (I imagine a server that has all > configurations preloaded and that returns Gofer scripts that can be > executed in the target image) Lukas, We are headed in exactly this direction. points 1,2 and 3 are directly covered by a combination of the GoferProjectLoader and new features in Metacello. So your expressions would be recast as something like: Gofer project loadStable: 'OB'. Gofer project loadDevelopment: 'OB'. Gofer project loadStable: 'OB' group: #( 'Tests' 'Javascript'). In addition to the notion of #stable and #development we have talked of the notion of #bleedingEdge. The #bleedingEdge loads the latest version of every mcz file...which may be what you were thinking about when you said #loadDevelopment ... Doru's discussion of a 'default' version and the #bleedingEdge are the same idea. So then we'd add the following expression: Gofer project loadBleedingEdge: 'OB'. As for you point 4, I think that that is a future item. I like the idea, but I think that it is not that simple... One of the more subtle things that goes on when loading Metacello configurations is that the current state of the image (i.e., loaded mcz files) is used to calculate what should be loaded ... if a required project is already loaded and especially if it is already at a later version, that project isn't loaded. If the project is at an earlier version then it is upgraded to conform to required version. On top of this, when a project is upgraded, all of the loaded mcz files are upgraded not just those that are specifically requested... With that said, it should be possible to ship a spec of what is loaded in the current image to a server where the calculation is made and a load directive (basically a Gofer script) could be returned, but there are more moving parts in this than I want to tackle at the moment... Unfortunately, a good bit of my time is being consumed at the moment by a GemStone project, but I fully expect to deliver on the above within the next month or so with an early release available within a couple of weeks as we are still hammering out details ... Dale

Oct. 8, 2010