- Pharo-dev - lists.pharo.org

Re: [Pharo-project] thanks for pharoconf

by Alain Plantec

yes! thanks!!! Cheers Alain Le 27/05/12 00:12, Tudor Girba a Ã©crit : > Hi, > > I had a good time at PharoConf. > > Thanks for organizing it. > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Beauty is where we see it." > > > >

May 27, 2012

Re: [Pharo-project] class message

by Denis Kudriashov

I found problem. Proxy classes in SMock and Mocketry are subclasses of ProtoObject which not implements #class. But proxy classes use "self class" in some methods (like #printOn: implementation). I add #class implementation from Object to ProtoObject and all SMock and Mocketry tests become green. So questions: Is ProtoObject should implement #class? Can we move #class method from Object to ProtoObject? 2012/5/27 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > > no, the other way around, now #class is NOT bytecoded, and therefore > is managed as a normal message send. > > > > > > That is much better. Thanks! I like progress even if it breaks old > code. > > > > :) > > But we always try to minimize else we would go much faster and btw class > should not break older code :) > > > > It did break Mocketry (http://www.squeaksource.com/Mocketry) > > > > Thank's for report. > > Try to fix it today. > > Now I dont know how #class message can broke something. When I found > answer I try to explain > > Thanks denis. > I'm curious too. > > Stef >

May 27, 2012

Re: [Pharo-project] thanks for pharoconf

by Luc Fabresse

Yes, thanks to organizers and every participants for all of this positive energy! #Luc 2012/5/27 Sven Van Caekenberghe <sven(a)beta9.be> > +1 > > On 27 May 2012, at 00:12, Tudor Girba wrote: > > > Hi, > > > > I had a good time at PharoConf. > > > > Thanks for organizing it. > > > > Cheers, > > Doru > > > > > > -- > > www.tudorgirba.com > > > > "Beauty is where we see it." > > I liked it a lot as well: interesting content, interesting people, > motivational. > > Thx, > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > >

May 27, 2012

Re: [Pharo-project] class message

by StÃ©phane Ducasse

> > no, the other way around, now #class is NOT bytecoded, and therefore is managed as a normal message send. > > > > That is much better. Thanks! I like progress even if it breaks old code. > > :) > But we always try to minimize else we would go much faster and btw class should not break older code :) > > It did break Mocketry (http://www.squeaksource.com/Mocketry) > > Thank's for report. > Try to fix it today. > Now I dont know how #class message can broke something. When I found answer I try to explain Thanks denis. I'm curious too. Stef

May 27, 2012

Re: [Pharo-project] class message

by Denis Kudriashov

Hello 2012/5/26 Milan Mimica <milan.mimica(a)gmail.com> > On 26 May 2012 20:53, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> > >> > What has changed in implementation "class" message in between Pharo 1.3 >> and 1.4? Is it compiled inline now or something like that? >> > >> > no, the other way around, now #class is NOT bytecoded, and therefore is >> managed as a normal message send. >> > >> > That is much better. Thanks! I like progress even if it breaks old code. >> >> :) >> But we always try to minimize else we would go much faster and btw class >> should not break older code :) >> > > It did break Mocketry (http://www.squeaksource.com/Mocketry) > > Thank's for report. Try to fix it today. Now I dont know how #class message can broke something. When I found answer I try to explain Best regards, Denis

May 27, 2012

Re: [Pharo-project] thanks for pharoconf

by Sven Van Caekenberghe

+1 On 27 May 2012, at 00:12, Tudor Girba wrote: > Hi, > > I had a good time at PharoConf. > > Thanks for organizing it. > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Beauty is where we see it." I liked it a lot as well: interesting content, interesting people, motivational. Thx, Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

May 27, 2012

Re: [Pharo-project] thanks for pharoconf

by StÃ©phane Ducasse

yes igor. You are a great enabler. We should finish events, athens, opal and release 2.0 ;) > +1 > > i got a hyper-motivation injection because of it .. :) > > On 27 May 2012 00:12, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Hi, >> >> I had a good time at PharoConf. >> >> Thanks for organizing it. >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "Beauty is where we see it." >> >> >> >> > > > > -- > Best regards, > Igor Stasenko. >

May 27, 2012

Re: [Pharo-project] thanks for pharoconf

by StÃ©phane Ducasse

thanks for coming :) I went to bed at 9:00 exhausted but happy. Now working on fixing RPackage, events and a couple more. Stef PS: we ate all the chocolate. > Hi, > > I had a good time at PharoConf. > > Thanks for organizing it. > > Cheers, > Doru

May 27, 2012

Re: [Pharo-project] class message

by StÃ©phane Ducasse

> :) > But we always try to minimize else we would go much faster and btw class should not break older code :) > > It did break Mocketry (http://www.squeaksource.com/Mocketry) > I would also suspect it breaks things like WriteBarrier and Magma and similar stuff performing magic. How mockery used the fact that class was not a send message? Stef

May 27, 2012

Re: [Pharo-project] building and installing a morph in the background

by Tudor Girba

Hi Igor, I tried adding it outside of the addDeferredUIMessage as well: process := [ newMorph := aBlockWhoseValueReturnsAMorph value. WorldState addDeferredUIMessage: [...] ] newProcess. However, the problem seems to be the same. If you, or someone else, would have time to look into it, here is how to reproduce: Download the latest moose image: http://ci.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/arti… Run: | browser | browser := GLMTabulator new. browser column: #numbers. browser transmit to: #numbers; andShow: [:a | a list display: [:x | 1 to: x] ]. browser transmit from: #numbers; toWatcher; andShow: [:a | a list title: [:x | 'Large presentation for ', x asString]; display: [:x | x to: (x * 1000)] ]. (browser openOn: 42) left: 0; top: 0. (GLMWatcherWindow uniqueInstance toggleOpen) left: 300; top: 100 . Time millisecondsToRun: [ (browser panes first port: #selection) value: 10 ] . The relevant code is in GLMWatcherWindow>>addContent: The interesting thing is that if I print the amount of time, it goes fast (close to 0s), but the UI is still blocked. Cheers, Doru On 27 May 2012, at 04:23, Igor Stasenko wrote: > On 27 May 2012 01:58, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Hi, >> >> process := [ >> WorldState addDeferredUIMessage: [ >> newMorph := aBlockWhoseValueReturnsAMorph value. >> self contentsMorph >> removeAllMorphs; >> addMorph: newMorph fullFrame: (LayoutFrame fractions: (0@0 corner: 1@1)) >> ] >> ] newProcess. > > Sure thing, because you still building your morph in UI thread (inside > a block which you pass > to addDeferredUIMessage. > > To make it clear, WorldState addDeferredUIMessage: > can be rephrased as: > > WorldState evaluateThisBlockInUIProcess: > > So, moving > newMorph := aBlockWhoseValueReturnsAMorph value. > outside of this block will do the thing. -- www.tudorgirba.com "Speaking louder won't make the point worthier."

May 27, 2012