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

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

Re: [Pharo-project] 12186 image quit problem

by Igor Stasenko

On 8 October 2010 19:54, Alexander LazareviÄ <laza(a)blobworks.com> wrote: > Igor, > > maybe this just passed me by, but is this supposed to work only with > some finalization support in the vm? So is PharoCore1.2 only usable > with a very recent vm? Which VMMaker version is needed or what does > your squeak -version say? > In that case I did not say a word! ;) > nope, it should work w/o problems with older vms. It runs w/o problems in windoze with following vms: Smalltalk vmVersion 'Squeak3.10.2 of 11 February 2010 [latest update: #9314]' WeakFinalizationList hasNewFinalization false Smalltalk vmVersion 'Squeak4.1 of 17 April 2010 [latest update: #9957]' WeakFinalizationList hasNewFinalization true > Alex > > 2010/10/8 Igor Stasenko <siguctua(a)gmail.com>: >> 2010/10/8 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >>> >>> On Fri, Oct 8, 2010 at 12:43 PM, Marcus Denker <marcus.denker(a)inria.fr> >>> wrote: >>>> >>>> On Oct 8, 2010, at 12:39 PM, Pavel Krivanek wrote: >>>> >>>> > 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) >>>> > >>>> No, we loaded: >>>> >>>> Issue 3002: Â Â A new finalization code ready for integration in Pharo >>>> http://code.google.com/p/pharo/issues/detail?id=3002 >>> >>> ok, can you reproduce this on your VM? >>> - take prebuilt 12186 >>> - run the image with a file as argument that contains: >>> Â SmalltalkImage current snapshot: true andQuit: true. >>> -Â run the image with a file as argument that contains: >>> 5 timesRepeat: [Smalltalk garbageCollect]. >>> SmalltalkImage current snapshot: false andQuit: true. >>> >> >> The problem is in MCMethodDefinition>>shutdown. >> >> Saving works, if i change it to: >> >> shutDown >> " Â Â Â WeakArray removeWeakDependent: Definitions." >> Â Â Â Â Definitions := nil. >> >> Not sure what happens there.. >> >> Also, it runs without fix, if i do: >> >> WeakArray restartFinalizationProcess. >> 5 timesRepeat: [Smalltalk garbageCollect]. >> SmalltalkImage current snapshot: false andQuit: true. >> >> >> >>> -- 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. >> >> _______________________________________________ >> 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 -- Best regards, Igor Stasenko AKA sig.

Oct. 8, 2010

Re: [Pharo-project] 12186 image quit problem

by Alexander LazareviÄ

Igor, maybe this just passed me by, but is this supposed to work only with some finalization support in the vm? So is PharoCore1.2 only usable with a very recent vm? Which VMMaker version is needed or what does your squeak -version say? In that case I did not say a word! ;) Alex 2010/10/8 Igor Stasenko <siguctua(a)gmail.com>: > 2010/10/8 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >> >> On Fri, Oct 8, 2010 at 12:43 PM, Marcus Denker <marcus.denker(a)inria.fr> >> wrote: >>> >>> On Oct 8, 2010, at 12:39 PM, Pavel Krivanek wrote: >>> >>> > 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) >>> > >>> No, we loaded: >>> >>> Issue 3002: Â Â A new finalization code ready for integration in Pharo >>> http://code.google.com/p/pharo/issues/detail?id=3002 >> >> ok, can you reproduce this on your VM? >> - take prebuilt 12186 >> - run the image with a file as argument that contains: >> Â SmalltalkImage current snapshot: true andQuit: true. >> -Â run the image with a file as argument that contains: >> 5 timesRepeat: [Smalltalk garbageCollect]. >> SmalltalkImage current snapshot: false andQuit: true. >> > > The problem is in MCMethodDefinition>>shutdown. > > Saving works, if i change it to: > > shutDown > " Â Â Â WeakArray removeWeakDependent: Definitions." > Â Â Â Â Definitions := nil. > > Not sure what happens there.. > > Also, it runs without fix, if i do: > > WeakArray restartFinalizationProcess. > 5 timesRepeat: [Smalltalk garbageCollect]. > SmalltalkImage current snapshot: false andQuit: true. > > > >> -- 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. > > _______________________________________________ > 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] DejaVu vs Bitmap DejaVu / missing fonts folder

by Alain Plantec

Maybe you can make it work with TT fonts. In order to install them, open the Settings browser then Under Appearance/Standard Fonts, click on the Launch button of "Update font from system" and then choose another font. Cheers Alain Le 08/10/2010 18:40, Alain Plantec a Ã©crit : > Le 08/10/2010 14:37, Veronica Isabel Uquillas Gomez a Ã©crit : >> Hi, >> >> I would like to know if i am the only one having the indentation >> problem when using bitmap fonts. >> >> The Torch dashboard makes use of small and big DejaVu Sans fonts. For >> configuring it the fonts folder is needed (that now is gone in the >> last version pharo 1.1.1 dev, why?). >> Got the suggestion of using the new DejaVu package and I tried... >> However, they are Bitmap DejaVu fonts and I have the problem of text >> indentation. >> I show the changed source code in popup views. With DejaVu sans fonts >> the text appears as it is written (first image), but with Bitmap >> fonts not -- all is aligned to the left, and it is impossible to read >> a method like that (second image). >> >> Do I need to set something else for those fonts to work? > Hi Veronica, > > After the loading, to install them: > DejaVuHolder installFull. > or > DejaVuHolder installSizes: #(5 7 8 9 10 11 24) > if you only want a subset > >> Any idea why do I have this problem? > I've tried with the 1.1.1 version on Linux and the indentation seems > ok also with small fonts (5, 6, 7). > See the screenshot. > > Cheers > Alain > >> Can the fonts folder be include again in the distribution? >> >> Best regards, >> Veronica Uquillas >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> 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