- Pharo-dev - lists.pharo.org

[Pharo-project] Migration Manual for Pharo 1.1 ?

by Johannes Rasche

Hi Folks, I just wanted to install my work on version 1.1 and was surprised to discover changes which leave me alone to find out for myself how to change my code : WorldMenu (I wrote a subclass of PasteUpMorph) NaturalLanguageTranslator (what is the "gettext package" mentioned in the class comment? - cannot find a menu to edit translations - hidden sowhere?) possibly more surprises to come .... some backwardcompatibilty support would have been nice and some examples But I like to point out as well, that Pharo is improving from release to release - thanks for that !!!! Thanks in advance Johannes Rasche Hagelberger Str. 56 10965 Berlin mail: johannesrasche(a)me.com skype: johannesrasche www: http://myNeat.de fon: +49-30-7469 4425 (skypeIn) fax: +49-30-315 66 821

Oct. 11, 2010

Re: [Pharo-project] [squeak-dev] Xtreams : first embryonary port on Squeak

by Julian Fitzell

This still seems confusing. Could we just have a new SqueakSource project called "Xtreams" (small T + an S)? It's not like projects are expensive to create... Julian On Sat, Oct 9, 2010 at 11:33 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > So, I started a quick port of VW Xtreams to Squeak this evening. > Only the Xtreams-Core and the trivial Xtreams-Terminals (no > file/pipe/socket/pointer). > You'll find code at http://www.squeaksource.com/XTream. > My previous experimental Xtream project has been renamed SqueaXTream > to reduce confusion, but still sits in the same project. > Please find my report below.

Oct. 11, 2010

Re: [Pharo-project] Adding a new font in System like DejaVu fonts

by Henrik Johansen

On Oct 10, 2010, at 12:49 40PM, nullPointer wrote: > > Now I know is possible add a new font, for use cross platform like DejaVu. I > know Juan Vuletich did that but I donÂ´t know found the place of that is > explained. Is heard do that? Whuups, might've sent you in a wild goose chase, sorry :/ Was thinking of http://forum.world.st/DemoMode-should-not-change-Fonts-only-sizes-td2538706… , which I interpreted as linking to a description of how he builds the font source. Clearly that only includes the end result ready for import. Anyways, as can be seen from the AAFonts.zip, you basically need a bmp with the font glyphs, as well as a text file containing offsets for each character. You could achieve that through printscreen and manual creation of offsets txt, or using a more automated tool similar to f.ex. http://www.angelcode.com/products/bmfont/ . CC'ing Juan in case he has time to comment on what his process is specifically. > takes very space of image when the font is > added? About as much space as the bmp's, ie depends on what sizes you want to include. Cheers, Henry

Oct. 11, 2010

Re: [Pharo-project] [squeak-dev] Re: 12186 image quit problem

by Igor Stasenko

- i added a test to cover this issue http://code.google.com/p/pharo/issues/detail?id=3092 On 11 October 2010 14:01, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Thanks. > So let's see what is the best choice and tell us. > > > On Oct 11, 2010, at 11:47 AM, Igor Stasenko wrote: > >> On 11 October 2010 12:10, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> I integrate >>> Â Â Â Â Issue 3086: Â Â MCMethodDefinition>>shutdown hack to avoid lock down. >>> Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=3086 >>> >>> >>> >>> Igor can you have a look and let me know: >>> Â Â Â Â 1- if we should rollback Issue 3086: Â Â MCMethodDefinition>>shutdown hack to avoid lock down. >>> Â Â Â Â 2- if we should integrate >>> Â Â Â Â Â Â Â Â Issue 3048: Â Â MC method cache fix >>> Â Â Â Â Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=3048 >>> >>> I will integrate >>> Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=3091 >>> >> >> Wait , MCMethodDefinition is only a consequence (however, removing it >> from weakdependents would be good idea as well ;)). > > Yes I integrate it to avoid system hanging. > > >> The real cultprit is HostSystemMenusProxy , which locks the weak >> registry during finalization. >> Then MCMethodDefinition>>shutdown simply locks at same point (trying >> to obtain semaphore lock). >> Note, that HostSystemMenusProxy locks finalization process, but not >> the process which doing shutdown, >> and then during image startup, a new finalization process get created. >> That's why removing access to weakdependents in >> MCMethodDefinition>>shutdown , kinda solved the issue. >> In reality its not. >> An old weak registry were sending #finalize outside a critical section: >> >> finalizeValues >> Â Â Â "Some of our elements may have gone away. Look for those and activate >> the associated executors." >> Â Â Â | finiObjects | >> Â Â Â finiObjects := nil. >> Â Â Â "First collect the objects." >> Â Â Â self protected:[ >> Â Â Â Â Â Â Â valueDictionary allAssociationsDo:[:assoc| >> Â Â Â Â Â Â Â Â Â Â Â assoc key isNil ifTrue:[ >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â finiObjects isNil >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue:[finiObjects := OrderedCollection with: assoc value] >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse:[finiObjects add: assoc value]] >> Â Â Â Â Â Â Â ]. >> Â Â Â Â Â Â Â finiObjects isNil ifFalse:[valueDictionary finalizeValues: >> finiObjects asArray]. >> Â Â Â ]. >> Â Â Â "Then do the finalization" >> Â Â Â finiObjects isNil ifTrue:[^self]. >> Â Â Â finiObjects do:[:each| each finalize]. >> >> >> So, there two ways to solve it: >> a) perform finalization outside a critical section (see attached) >> b) fix the HostSystemMenusProxy to prevent any manupulation with weak >> registry during finalization. >> >> >> I checked Squeak 4.2 image, and i can also say, that any attempt to >> manipulate weak registry during finalization will also lock down a >> finalization process (see Squeak's WeakRegistry>>finalizeValues & >> WeakKeyDictionary>>finalizeValues) >> >> So, if we going to assume, in future that it is error to modify weak >> registry during finalization, then we should leave the code in >> WeakRegistry as-is, and fix HostSystemMenusProxy instead. >> If not, the we should make sure that #finalize should be sent outside >> weak registry's critical section. >> >> And the last note: if VM supports new finalization, it will happen >> outside a critical section (See the >> bottom of WeakRegistry>>finalizeValues). So any manipulations with >> registry during finalization can't cause lockdown. >> >> >> P.S. forwarded to Squeak-dev, to make Squeakers aware of potential >> danger , when manipulating weak registry during finalization. >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> <WeakRegistry-finalizeValues.st>_______________________________________________ >> 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. 11, 2010

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

by Igor Stasenko

On 11 October 2010 13:53, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> personnally I do not like this form >>> What does it do? >>> >>>> Â process ifNotNil: #terminate. >>> >>> >>> for me it means passes the symbol #terminate as argument to the method ifNotNil: >>> If it has a more magical behavior then I do not know it. >>> >>> Stef >> >> It's exactly the same as using collection do: #something. >> >> FWIW, in 1.2 we already included the compiler changes Levente suggested to me to remove this restriction, so >> >> nil ifNotNil: #squared -> nil >> 4 ifNotNil: #squared -> 16. > > This is still not really readable compared to > Â Â Â Â 4 ifNotNil: [:rec | rec squared] > > For select: #even why not > > Now to me this looks like a hack and again it works because now Symbol are valuable objects. > Too many hacks will only make the system more hackish. > And especially the > Â Â Â Â iftrue: 'foo' ifFalse: 'zork' > This is not a hack, because if you refer to implementation: True>>ifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock ^trueAlternativeBlock value False>>ifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock ^falseAlternativeBlock value so, it answers either 'foo' value , or 'zork' value. And #value could be sent to any object in system: Object>>value ^self What actually shown here is a use of duck typing, because any object, which implemets #value, could be safely passed as argument to #ifTrue:ifFalse: message. It is well consistent with language design. > In Smalltalk this is simple you ut bracket when you do not know if a part should/will be executed. > Now with such change this is not the case anymore. > I think that we are focusing on the wrong point. Changing the language that way does not > bring anything really useful. > > And I would veto such usage in the core for consistency reason. > > Stef > > > _______________________________________________ > 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. 11, 2010

Re: [Pharo-project] 12186 image quit problem

by StÃ©phane Ducasse

Thanks. So let's see what is the best choice and tell us. On Oct 11, 2010, at 11:47 AM, Igor Stasenko wrote: > On 11 October 2010 12:10, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> I integrate >> Issue 3086: MCMethodDefinition>>shutdown hack to avoid lock down. >> http://code.google.com/p/pharo/issues/detail?id=3086 >> >> >> >> Igor can you have a look and let me know: >> 1- if we should rollback Issue 3086: MCMethodDefinition>>shutdown hack to avoid lock down. >> 2- if we should integrate >> Issue 3048: MC method cache fix >> http://code.google.com/p/pharo/issues/detail?id=3048 >> >> I will integrate >> http://code.google.com/p/pharo/issues/detail?id=3091 >> > > Wait , MCMethodDefinition is only a consequence (however, removing it > from weakdependents would be good idea as well ;)). Yes I integrate it to avoid system hanging. > The real cultprit is HostSystemMenusProxy , which locks the weak > registry during finalization. > Then MCMethodDefinition>>shutdown simply locks at same point (trying > to obtain semaphore lock). > Note, that HostSystemMenusProxy locks finalization process, but not > the process which doing shutdown, > and then during image startup, a new finalization process get created. > That's why removing access to weakdependents in > MCMethodDefinition>>shutdown , kinda solved the issue. > In reality its not. > An old weak registry were sending #finalize outside a critical section: > > finalizeValues > "Some of our elements may have gone away. Look for those and activate > the associated executors." > | finiObjects | > finiObjects := nil. > "First collect the objects." > self protected:[ > valueDictionary allAssociationsDo:[:assoc| > assoc key isNil ifTrue:[ > finiObjects isNil > ifTrue:[finiObjects := OrderedCollection with: assoc value] > ifFalse:[finiObjects add: assoc value]] > ]. > finiObjects isNil ifFalse:[valueDictionary finalizeValues: > finiObjects asArray]. > ]. > "Then do the finalization" > finiObjects isNil ifTrue:[^self]. > finiObjects do:[:each| each finalize]. > > > So, there two ways to solve it: > a) perform finalization outside a critical section (see attached) > b) fix the HostSystemMenusProxy to prevent any manupulation with weak > registry during finalization. > > > I checked Squeak 4.2 image, and i can also say, that any attempt to > manipulate weak registry during finalization will also lock down a > finalization process (see Squeak's WeakRegistry>>finalizeValues & > WeakKeyDictionary>>finalizeValues) > > So, if we going to assume, in future that it is error to modify weak > registry during finalization, then we should leave the code in > WeakRegistry as-is, and fix HostSystemMenusProxy instead. > If not, the we should make sure that #finalize should be sent outside > weak registry's critical section. > > And the last note: if VM supports new finalization, it will happen > outside a critical section (See the > bottom of WeakRegistry>>finalizeValues). So any manipulations with > registry during finalization can't cause lockdown. > > > P.S. forwarded to Squeak-dev, to make Squeakers aware of potential > danger , when manipulating weak registry during finalization. > > -- > Best regards, > Igor Stasenko AKA sig. > <WeakRegistry-finalizeValues.st>_______________________________________________ > 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] Compiler pedantic about ifNotNil: argument

by StÃ©phane Ducasse

> personnally I do not like this form >> What does it do? >> >>> process ifNotNil: #terminate. >> >> >> for me it means passes the symbol #terminate as argument to the method ifNotNil: >> If it has a more magical behavior then I do not know it. >> >> Stef > > It's exactly the same as using collection do: #something. > > FWIW, in 1.2 we already included the compiler changes Levente suggested to me to remove this restriction, so > > nil ifNotNil: #squared -> nil > 4 ifNotNil: #squared -> 16. This is still not really readable compared to 4 ifNotNil: [:rec | rec squared] For select: #even why not Now to me this looks like a hack and again it works because now Symbol are valuable objects. Too many hacks will only make the system more hackish. And especially the iftrue: 'foo' ifFalse: 'zork' In Smalltalk this is simple you ut bracket when you do not know if a part should/will be executed. Now with such change this is not the case anymore. I think that we are focusing on the wrong point. Changing the language that way does not bring anything really useful. And I would veto such usage in the core for consistency reason. Stef

Oct. 11, 2010

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

by Nick Papoylias

*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. I am currently playing around with the system (to get the feel of it..) and testing it's programming tools in the context of different namespaces / environments. Specifically I am trying to find out what the implications of having a remote environment over rST for e.g (to browse, debug e.t.c). *Any pointers to related work, suggestions e.t.c are welcomed. * So my question: *Is anybody currently working on integrating namespaces in the system level ? I may have one or two questions and suggestions to make. *Thank you very much ! Nick Papoulias* *

Oct. 11, 2010

[Pharo-project] Fwd: [Moose-dev] Re: pharo sprint / moose dojo - october 23-24, bern

by Laval Jannik

Begin forwarded message: > From: Tudor Girba <tudor.girba(a)gmail.com> > Date: October 11, 2010 11:38:54 GMT+02:00 > To: Pharo-project(a)lists.gforge.inria.fr > Cc: Moose-related development <moose-dev(a)iam.unibe.ch>, notre liste <lsehub-staff(a)lists.gforge.inria.fr> > Subject: [Moose-dev] Re: [Pharo-project] pharo sprint / moose dojo - october 23-24, bern > Reply-To: Moose-related development <moose-dev(a)iam.unibe.ch> > > Sounds good. We just have to see about the technical details. > > Cheers, > Doru > > > On 11 Oct 2010, at 11:17, Laval Jannik wrote: > >> Hi, >> >> Some guys from North of France cannot come to Bern. >> So we propose to make a shared session with you, but localized at LIFL, Villeneuve d'Ascq. >> >> We can do it during the two days. >> >> http://code.google.com/p/pharo/wiki/PharoSprints >> >> Cheers, >> >> Jannik >> >> >> On Sep 27, 2010, at 22:36 , Tudor Girba wrote: >> >>> Hi, >>> >>> We will organize a joint Pharo sprint / Moose dojo during October 23-24, in Bern (at the Software Composition Group, University of Bern). >>> >>> Some action points are mentioned on the dedicated page (of course, other ideas and interests are welcome as well): >>> http://www.moosetechnology.org/events/2010-10-22-dojo >>> >>> For planning purposes, please let me know if you will attend. >>> >>> Cheers, >>> Doru >>> >>> p.s. In case it is of interest, on October 22, we also have CHOOSE Forum 2010 in Bern, an event on the topic of Domain-Specific Engineering where, among others we'll learn about the role of Smalltalk :) >>> http://choose.s-i.ch/events/forum2010 >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Problem solving should be focused on describing >>> the problem in a way that makes the solution obvious." >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "Value is always contextual." > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev --- Jannik Laval

Oct. 11, 2010

Re: [Pharo-project] 12186 image quit problem

by Igor Stasenko

On 11 October 2010 12:10, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I integrate > Â Â Â Â Issue 3086: Â Â MCMethodDefinition>>shutdown hack to avoid lock down. > Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=3086 > > > > Igor can you have a look and let me know: > Â Â Â Â 1- if we should rollback Issue 3086: Â Â MCMethodDefinition>>shutdown hack to avoid lock down. > Â Â Â Â 2- if we should integrate > Â Â Â Â Â Â Â Â Issue 3048: Â Â MC method cache fix > Â Â Â Â Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=3048 > > I will integrate > Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=3091 > Wait , MCMethodDefinition is only a consequence (however, removing it from weakdependents would be good idea as well ;)). The real cultprit is HostSystemMenusProxy , which locks the weak registry during finalization. Then MCMethodDefinition>>shutdown simply locks at same point (trying to obtain semaphore lock). Note, that HostSystemMenusProxy locks finalization process, but not the process which doing shutdown, and then during image startup, a new finalization process get created. That's why removing access to weakdependents in MCMethodDefinition>>shutdown , kinda solved the issue. In reality its not. An old weak registry were sending #finalize outside a critical section: finalizeValues "Some of our elements may have gone away. Look for those and activate the associated executors." | finiObjects | finiObjects := nil. "First collect the objects." self protected:[ valueDictionary allAssociationsDo:[:assoc| assoc key isNil ifTrue:[ finiObjects isNil ifTrue:[finiObjects := OrderedCollection with: assoc value] ifFalse:[finiObjects add: assoc value]] ]. finiObjects isNil ifFalse:[valueDictionary finalizeValues: finiObjects asArray]. ]. "Then do the finalization" finiObjects isNil ifTrue:[^self]. finiObjects do:[:each| each finalize]. So, there two ways to solve it: a) perform finalization outside a critical section (see attached) b) fix the HostSystemMenusProxy to prevent any manupulation with weak registry during finalization. I checked Squeak 4.2 image, and i can also say, that any attempt to manipulate weak registry during finalization will also lock down a finalization process (see Squeak's WeakRegistry>>finalizeValues & WeakKeyDictionary>>finalizeValues) So, if we going to assume, in future that it is error to modify weak registry during finalization, then we should leave the code in WeakRegistry as-is, and fix HostSystemMenusProxy instead. If not, the we should make sure that #finalize should be sent outside weak registry's critical section. And the last note: if VM supports new finalization, it will happen outside a critical section (See the bottom of WeakRegistry>>finalizeValues). So any manipulations with registry during finalization can't cause lockdown. P.S. forwarded to Squeak-dev, to make Squeakers aware of potential danger , when manipulating weak registry during finalization. -- Best regards, Igor Stasenko AKA sig.

Oct. 11, 2010