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

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

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

by Oscar Nierstrasz

See: http://github.com/SquareBracketAssociates/ Cheers, - on

Oct. 11, 2010

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

by Tudor Girba

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."

Oct. 11, 2010

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

by Henrik Johansen

On Oct 10, 2010, at 3:13 08PM, StÃ©phane Ducasse 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. I.e. it already does what Nicolas suggested. (As per the Symbol>>#cull: thread) Cheers, Henry > > >> The compiler uselessly insist on #ifNotNil: argument being a zero/one arg block. >> Thus we cannot write this xtream sentence >> >> process ifNotNil: #terminate. >> >> When the argument is not a block, Compiler should avoid inlining and >> just send a normal message. >> >> cheers >> >> Nicolas >> >> _______________________________________________ >> 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] [Moose-dev] pharo sprint / moose dojo - october 23-24, bern

by Laval Jannik

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

Oct. 11, 2010

Re: [Pharo-project] 12186 image quit problem

by StÃ©phane Ducasse

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 Stef > Ok, I opened an issue: http://code.google.com/p/pharo/issues/detail?id=3091 > > The patch works for me, Thank you Igor. > > Cheers, > -- Pavel > > On Sun, Oct 10, 2010 at 6:46 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 10 October 2010 17:40, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > > Sig, > > > > Have you thought about using a Mutex? Maybe I'm missing something in life, but long ago I decided the #forMutualExclusion is *beyond* private. Semaphores are wonderful for #wait/#signal. But for #critical:, I use Mutex which won't deadlock a thread with itself. > > > > yes, i thought about it. It wont help in this situation, > because if you start modifying dictionary inside a loop, which > scanning its elements (like #do:) > you'll have very unpleasant results. > > All HostSystemMenusProxy doing during #finalize is removing itself > from weakregistry (which is complete nonsense, since weak registry > cleaning itself from dead stuff anyways). > So, > self protected: [ > valueDictionary expiredValuesDo: [:finItem | > finItem finalizeValues ]. > ]. > > actually triggers a bug/mistake in HostSystemMenusProxy , which leads > to deadlock. > :) > > > 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: Sunday, October 10, 2010 7:56 AM > > To: Pharo-project(a)lists.gforge.inria.fr > > Subject: Re: [Pharo-project] 12186 image quit problem > > > > OKay, now i see what the problem: > > > > <weak registry protected> > > <finalize items> > > <HostSystemMenusProxy>>finalize> > > .... > > <HostSystemMenusProxy class>>unregister> > > <weak registry protected> > > > > > > In my WeakRegistry, a #finalize message sent while registry semaphore locked, > > so, in case if object in #finalize trying to manipulate with registry > > then it going to deadlock. > > > > Then following piece: > > > > WeakRegistry>>finalizeValues > > > > self protected: [ > > valueDictionary expiredValuesDo: [:finItem | > > finItem finalizeValues ]. > > ]. > > > > should be rewritten as: > > > > | expired | > > expired := OrderedCollection new. > > self protected: [ > > valueDictionary expiredValuesDo: [:finItem | expired add: finItem ] > > ]. > > expired do: #finalizeValues. > > > > > > But either way, HostSystemMenusProxy should not attempt remove itself > > from registry during #finalize (and causing a deadlock), > > since its pointless. > > > > > > -- > > 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. > > _______________________________________________ > 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] Issue 3090: Context not included in ImageSegment when saving morph to file

by Adrian Lienhard

For convenience, this is the link to the issue: http://code.google.com/p/pharo/issues/detail?id=3090 I suspect that this bug is related to the new block closures. Adrian On Oct 11, 2010, at 07:15 , Sheridan Mahoney wrote: > I've just re-entered the Pharo world after a long(ish) absence, and wanted to report a > new bug submission; here's the breakdown: > > Pharo image: dev > Pharo core version: Pharo-1.1.1-- Latest update: #11414 > Virtual machine used: 4.0.3.2202 Unix VM > OS: Ubuntu Lucid Lynx 10.04 > Class browser used if applicable: SystemBrowser default > > > Steps to reproduce: > > 1. start pharo > 2. open a Shout workspace > 3. select the just-opened workspace > 4. Ctrl-right button to get the meta-click window > 5. select 'save morph in file' > 6. hit 'ok' to proffered name for file > 7. a message box comes up that reads 'please wait while objects are > counted'. > 8. shortly after that an error is generated: > 'Error: this context was not included in the ImageSegment' > > > > I'm planning on doing more research, but wanted to get the issue reported. > > Cheers, > Sheridan > > PS - so far I really like 1.1.1 !!! Good work, gang! > > _______________________________________________ > 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

[Pharo-project] [update 1.2] #12188

by StÃ©phane Ducasse

12188 ----- - Issue 3086: MCMethodDefinition>>shutdown hack to avoid lock down. - Issue 2875: PharoKernel Part 11. Thanks Pavel Krivanek and Nicolas Paes Stef

Oct. 11, 2010

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

by StÃ©phane Ducasse

> > > ? > In any way, passing anything else than block literal as argument should work. You mean in the implementation or in the semantics? Read my mail. This is a question of semantics. The argument of iftrue:ifFalse: are thunk (piece of code with frozen execution). > This is smalltalk, not C with static types. consistency and elegance as nothing to do with absence of static types. With such a change we can break a lot of uniformity and break potential type inferencers. And I do not see the advantage, beside having a clunky system. Stef

Oct. 11, 2010

Re: [Pharo-project] another little OB "bug"

by Mariano Martinez Peck

On Mon, Oct 11, 2010 at 10:18 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > I investigated PluggableListMorph and ListMorph, the problem you > describe is there (likely this should be fixed in Pharo). In > > Name: OB-Morphic-lr.149 > Author: lr > Time: 11 October 2010, 10:17:53 am > UUID: 285339d9-f9da-4c6d-98b9-e09ea154c91e > Ancestors: OB-Morphic-lr.148 > > - more efficient fix for list updating > > I try to remember the current scroll position before updating any OB > list, so I guess this works around the problem (indeed the UI feels > better after the change). > Indeed, it works perfect :) Thanks lukas > > I am not sure if this fix is safe. It works well in my images, but it > might break some assumption of Morphic and destroy your image in the > worst case. > I like to be betatester and be in the bleeding edge :) > > Lukas > > On 10 October 2010 18:39, Lukas Renggli <renggli(a)gmail.com> wrote: > > I am not sure if I understand your question correctly, but presumably > > your method is too long or you have too many methods in one class or > > protocol. OB punishes you for this :-) > > > > Lukas > > > > 2010/10/10 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> Hi. Me again. Not sure if it is a bug but I don't like it. If you do, no > >> problem then ;) > >> > >> Suppose you are working with a method that it is in the half of the > method > >> pane of OB. Once you save it or run test on it for example, the "scroll" > and > >> the method pane is updated so that THAT method is first, above. And > >> sometimes this is quite annoying for me. > >> > >> Cheers > >> > >> Mariano > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > > > > > > > -- > > Lukas Renggli > > www.lukas-renggli.ch > > > > > > -- > 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] 12186 image quit problem

by Pavel Krivanek

Ok, I opened an issue: http://code.google.com/p/pharo/issues/detail?id=3091 <http://code.google.com/p/pharo/issues/detail?id=3091>The patch works for me, Thank you Igor. Cheers, -- Pavel On Sun, Oct 10, 2010 at 6:46 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 10 October 2010 17:40, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > > Sig, > > > > Have you thought about using a Mutex? Maybe I'm missing something in > life, but long ago I decided the #forMutualExclusion is *beyond* private. > Semaphores are wonderful for #wait/#signal. But for #critical:, I use > Mutex which won't deadlock a thread with itself. > > > > yes, i thought about it. It wont help in this situation, > because if you start modifying dictionary inside a loop, which > scanning its elements (like #do:) > you'll have very unpleasant results. > > All HostSystemMenusProxy doing during #finalize is removing itself > from weakregistry (which is complete nonsense, since weak registry > cleaning itself from dead stuff anyways). > So, > self protected: [ > valueDictionary expiredValuesDo: [:finItem | > finItem finalizeValues ]. > ]. > > actually triggers a bug/mistake in HostSystemMenusProxy , which leads > to deadlock. > :) > > > 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: Sunday, October 10, 2010 7:56 AM > > To: Pharo-project(a)lists.gforge.inria.fr > > Subject: Re: [Pharo-project] 12186 image quit problem > > > > OKay, now i see what the problem: > > > > <weak registry protected> > > <finalize items> > > <HostSystemMenusProxy>>finalize> > > .... > > <HostSystemMenusProxy class>>unregister> > > <weak registry protected> > > > > > > In my WeakRegistry, a #finalize message sent while registry semaphore > locked, > > so, in case if object in #finalize trying to manipulate with registry > > then it going to deadlock. > > > > Then following piece: > > > > WeakRegistry>>finalizeValues > > > > self protected: [ > > valueDictionary expiredValuesDo: [:finItem | > > finItem finalizeValues ]. > > ]. > > > > should be rewritten as: > > > > | expired | > > expired := OrderedCollection new. > > self protected: [ > > valueDictionary expiredValuesDo: [:finItem | expired add: finItem > ] > > ]. > > expired do: #finalizeValues. > > > > > > But either way, HostSystemMenusProxy should not attempt remove itself > > from registry during #finalize (and causing a deadlock), > > since its pointless. > > > > > > -- > > 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. > > _______________________________________________ > 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 little OB "bug"

by Lukas Renggli

I investigated PluggableListMorph and ListMorph, the problem you describe is there (likely this should be fixed in Pharo). In Name: OB-Morphic-lr.149 Author: lr Time: 11 October 2010, 10:17:53 am UUID: 285339d9-f9da-4c6d-98b9-e09ea154c91e Ancestors: OB-Morphic-lr.148 - more efficient fix for list updating I try to remember the current scroll position before updating any OB list, so I guess this works around the problem (indeed the UI feels better after the change). I am not sure if this fix is safe. It works well in my images, but it might break some assumption of Morphic and destroy your image in the worst case. Lukas On 10 October 2010 18:39, Lukas Renggli <renggli(a)gmail.com> wrote: > I am not sure if I understand your question correctly, but presumably > your method is too long or you have too many methods in one class or > protocol. OB punishes you for this :-) > > Lukas > > 2010/10/10 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> Hi. Me again. Not sure if it is a bug but I don't like it. If you do, no >> problem then ;) >> >> Suppose you are working with a method that it is in the half of the method >> pane of OB. Once you save it or run test on it for example, the "scroll" and >> the method pane is updated so that THAT method is first, above. And >> sometimes this is quite annoying for me. >> >> Cheers >> >> Mariano >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > -- Lukas Renggli www.lukas-renggli.ch

Oct. 11, 2010

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

by Sven Van Caekenberghe

Hi Nicolas, You have been working quite quickly, great! I tried to follow your different releases in Pharo 1.1.1, right now I have 433 tests, 3 failures (#testReadWriteLargeAmount), 11 errors (#..base64 and #..multipleBufferSize). If will send you the report. I have been trying some of the examples from the doc pages (google code project), this simple one still fails: ((1 to: 10) reading collecting: [:x | x * x]) rest The readline example is using the non-existing #slicer: method, this simpler version seems to work: |text| text := 'line1\line2\line3\line4' withCRs reading. text := text ender: [ :char | char = Character cr ]. text collect: [ :line | line rest ]. That is a documentation bug though. Sven On 10 Oct 2010, at 22:09, Nicolas Cellier wrote: > Hi again, > I now have ported two more packages > - Xtreams-Transforms > - Xtreams-Substreams > and their tests > > I did not have any portability problem with those... > But that's because I did not handle the Character encoder/decoder. > Consequently, I have 8 tests failing (the Base64 related tests) > Plus 4 other tests failing because of my poor implementation of > #after:do: (forking processes in a SUnit TestCase can't be that > obvious). > > Now, the easy part of the port (copy/paste) is almost ended. > Once we manage a compatible way to handle pragmas, PEG Parser should > port quite easily too. > > Then, the harder work begins: > - File/Socket/Pipe > - Pointers (in External Heap) > - Character encoding/decoding > - Compression/Decompression > > If you think you can help in any of these, please tell. > > Nicolas > > _______________________________________________ > 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] bad bracket autocompletion in Pharo Core 1.2

by Fernando olivero

Hi , it was a enhancement i did starting from a Chris Muller enhancement for Squeak. ISSUE 2653. http://code.google.com/p/pharo/issues/detail?id=2653&can=1&q=auto&colspec=I… I did a test, maybe a good start would be to see if its failing now. Fernando On Oct 9, 2010, at 2:18 PM, Juan Vuletich wrote: > Hi Folks, > > Cuis doesn't include #autoEnclose, so I don't know how it should behave. > > Cheers, > Juan Vuletich > > Mariano Martinez Peck wrote: >> Guille, if I remember correctly (not sure), these new classes like >> TextEditor and Smalltalk editor came from Cuis. Juan (Cuis author) i >> think he is in the mailing list but not read it so frequently. So, for >> this issues maybe you can cc'ed him. >> >> Cheers >> >> Mariano >> >> 2010/10/9 Guillermo Polito <guillermopolito(a)gmail.com >> <mailto:guillermopolito@gmail.com>> >> >> Here is the piece of code that's behaving weird >> >> TextEditor>>dispatchOn: >> >> ... >> ... >> char := aKeyboardEvent keyCharacter. >> openers := '([{'. >> closers := ')]}'. >> ( closers includes: char) ifTrue: [ self blinkPrevParen: >> char ]. >> result := self normalCharacter: aKeyboardEvent. >> (self class autoEnclose and: [ openers includes: char ]) >> not ifTrue: [ ^ result ]. >> suffix := closers at: (openers indexOf: char). >> paragraph text append: suffix asString. >> self moveCursor: [ : position | position ] forward: true >> specialBlock: [ : pos | "no special behavior" ] event: >> aKeyboardEvent . >> self userHasEdited. >> >> ------------------------------------- >> >> So, if I evaluate "TextEditor autoEnclose: false", it is stops >> behaving like that :) >> >> What should be the desired behavior? Having it configurable as it >> is today but fix the strange bracket adding? remove this behavior? >> I can't find now how ParagraphEditor did this. >> >> Guille >> >> >> On Wed, Oct 6, 2010 at 10:34 PM, Guillermo Polito >> <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >> >> Yes, the issue can be reduced to: >> >> open parenthesis (or brackets), then something else (anywhere >> in the editor). >> >> 2010/10/6 Mariano Martinez Peck <marianopeck(a)gmail.com >> <mailto:marianopeck@gmail.com>> >> >> I detected a similar problem: >> >> once you type an opening parenthesis, and then something >> else, it adds a new one at the END of the code >> >> check http://code.google.com/p/pharo/issues/detail?id=2939 >> >> 2010/10/6 Guillermo Polito <guillermopolito(a)gmail.com >> <mailto:guillermopolito@gmail.com>> >> >> http://code.google.com/p/pharo/issues/detail?id=3069 >> >> if you type: >> >> [] -> []] >> >> () -> ()) >> >> {} -> {}} >> >> >> >> >> Bye! >> >> _______________________________________________ >> 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 >> <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 >> <mailto:Pharo-project@lists.gforge.inria.fr> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> ------------------------------------------------------------------------ >> >> >> No virus found in this incoming message. >> Checked by AVG - www.avg.com >> Version: 9.0.862 / Virus Database: 271.1.1/3184 - Release Date: 10/08/10 03:34:00 >> >> > > > _______________________________________________ > 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] Getting my head around low space

by Max Leske

"There is not enough memory to give squeak the amount specified by the 'memory EMBED tag.". Additionally there's a "Premature end of file" error on the image and then the VM crashes (OS X crash dialog). Issuing the same commands with 1 GB memory works fine (no problems with the image). Interestingly I tried to run the task with 3.5 GB in a 5.7b1 VM over night and the low space warning popped up when the progress bar was have as far then when I ran into the same condition using the 4.2.5b1U VM and 1 GB... Any suggestions? I couldn't attach the VM statistics because of the lacking menu integration but if you tell me how to extract the statistics (supposing they are interesting...) I'll happily rerun the task and post the results. Max On 10.10.2010, at 23:47, John M McIntosh wrote: > > On 2010-10-10, at 2:00 PM, Max Leske wrote: > >> I had a first failure with 1 GB. I used the 4.2.5b1U VM. Setting the memory to anything above 1 GB would lead to an error message. I'm now trying the 5.7b1 VM with 3.5 GB. >> >> Max > > So what is the error message? > > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > _______________________________________________ > 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] Issue 3090: Context not included in ImageSegment when saving morph to file

by StÃ©phane Ducasse

Thanks! and welcome back. Stef On Oct 11, 2010, at 7:16 AM, Sheridan Mahoney wrote: > I've just re-entered the Pharo world after a long(ish) absence, and wanted to report a > new bug submission; here's the breakdown: > > Pharo image: dev > Pharo core version: Pharo-1.1.1-- Latest update: #11414 > Virtual machine used: 4.0.3.2202 Unix VM > OS: Ubuntu Lucid Lynx 10.04 > Class browser used if applicable: SystemBrowser default > > Steps to reproduce: > 1. start pharo > 2. open a Shout workspace > 3. select the just-opened workspace > 4. Ctrl-right button to get the meta-click window > 5. select 'save morph in file' > 6. hit 'ok' to proffered name for file > 7. a message box comes up that reads 'please wait while objects are > counted'. > 8. shortly after that an error is generated: > 'Error: this context was not included in the ImageSegment' > > > I'm planning on doing more research, but wanted to get the issue reported. > > Cheers, > Sheridan > > PS - so far I really like 1.1.1 !!! Good work, gang! > > _______________________________________________ > 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] Xtreams port to Squeak - second wave

by mkobetic＠gmail.com

"Nicolas Cellier"<nicolas.cellier.aka.nice(a)gmail.com> wrote: > Then, the harder work begins: > - File/Socket/Pipe > - Pointers (in External Heap) > - Character encoding/decoding I just published XtreamsDevelopment(387) with following changes: * abstracted Encoder out of encoded streams to allow implementing our own encodings. * Encoder.Encoders registers known encoders * Encoder.DialectEncoder provides a hook to access dialect specific encoders * added ASCIIEncoder implementing ASCII encoding portably * added VWEncoder wrapping VisualWorks StreamEncoders Obviously VWEncoder won't work in Squeak and should eventually move to a VW specific package. But at the moment it might be useful as an example of how to take advantage of the existing encoders in Squeak. I briefly looked at the Multilingual categories in Pharo and there seem to be quite a few encodings available through the TextConverter hierarchy. You've expressed some reservations about that, but it might be worth taking advantage of those at least initially. Anyway with the above there should be at least an #ascii encoder available for now.

Oct. 11, 2010

[Pharo-project] Issue 3090: Context not included in ImageSegment when saving morph to file

by Sheridan Mahoney

Oct. 11, 2010

[Pharo-project] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b12

by John M McIntosh

I've stuck a version (5.8b12) of the cocoa based os-x squeak cog JIT based VM in my experimental folder. http://homepage.mac.com/johnmci/.Public/experimental/Squeak%205.8b12.app.zip This is based on the latest Cog VM source (oct 10/10/10). Changes to the support logic: (a) Supply file create/mod times & size based on target of symbolic link versus the link file node. (b) Untrusted directory was set wrong, use same default value as 4.2.x VM ~/Library/Preferences/Squeak/Internet/My Squeak/ (c) There is no -pathenc option (d) Attempt to integrate changes into Cog branch to allow you to compile VM from the Cog branch. *** This does not work yet, 90% there, Eliot and I still have some pencil sharping to do... *** Now the big news is that I pushed a version of the Squeak Cog stack VM to the Apple App Store! It's rough, but it's a candidate for review by Apple's special App review committee. It does not have socket support and we are seeing if they allow us to move image/change files in and out of the Documents folder via a desktop machine. I should know more by next weekend. If accepted then I am looking to the Smalltalk community to help in building a viable image to allow people to edit source code on an iPad. Lastly, yes something broken in open/gl on os-x 10.4 I hope to look at the issue this week. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Oct. 11, 2010