- Pharo-dev - lists.pharo.org

[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