- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Manifest...

by StÃ©phane Ducasse

> Why do the Manifest.* classes have no class comments? There will be one chapter to explain them. Now yes we can improve but too many things to do :) > > This is highly confusing, as these things are created without any notification, > so at least they should have an auto-generated comment which states what they are good for. > > cami

Jan. 19, 2013

Re: [Pharo-project] TxTextMorph based on new text model

by StÃ©phane Ducasse

This is really nice. Tristan started to look at what you are doing because we proposed him to enhance textModel as part of an internship with us. Stef On Jan 18, 2013, at 9:30 PM, Denis Kudriashov wrote: > Hello. > > I publish configuration at TxText repository based on proposed repackaging. > > 2013/1/15 Camillo Bruni <camillobruni(a)gmail.com> > > On 2013-01-15, at 12:44, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > Yes. > > I want to do it. But today I busy. Tomorrow I hope I can make it. > > no hurry :) I set up the jenkins build, it will trigger as soon as you push the configuration :) > > > I actually want to split package to TxText-Model, TxText-Layout, TxText-UI, > > TxTextTests-Model, TxTextTests-Layout > > nice! >

Jan. 19, 2013

Re: [Pharo-project] Where should SmalltalkHub bugs be reported?

by StÃ©phane Ducasse

On Jan 18, 2013, at 2:06 PM, Sean P. DeNigris wrote: > Nicolas Petton wrote >> The username is only there if you are logged in. If not, it's not >> there. Do you think it should always be left out? > > Now I'm not so sure. This "two dialogs that can't be ignored" behavior is > new to Pharo 2.0. Maybe Pharo should just go back to the original behavior? can you open a bug entry because I do not like this smell :) > > > > -- > View this message in context: http://forum.world.st/Where-should-SmalltalkHub-bugs-be-reported-tp4663973p… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Jan. 19, 2013

Re: [Pharo-project] Class initialisation after loading

by Eliot Miranda

On Fri, Jan 18, 2013 at 2:38 PM, Frank Shearar <frank.shearar(a)gmail.com>wrote: > On 18 January 2013 21:49, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > phhh, let me try again :) > > > > > > On Fri, Jan 18, 2013 at 8:47 AM, Frank Shearar <frank.shearar(a)gmail.com> > > wrote: > >> > >> On 17 January 2013 17:45, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> > > >> > > >> > > >> > On Thu, Jan 17, 2013 at 3:25 AM, Igor Stasenko <siguctua(a)gmail.com> > >> > wrote: > >> >> > >> >> After some thought i decided to contribute my 2cents. > >> >> > >> >> First, i think it is impossible to introduce a (re)initialization > >> >> logic which would suit all different scenarios. > >> >> Because it is really depends on what is stored in class variables > >> >> and/or > >> >> pools > >> >> and if you add subclasses and then instances into the soup, you might > >> >> end up with something > >> >> which is really hard to safely reinitialize, because it may have some > >> >> inconsistent state at different stages > >> >> of initialization. It also, sometimes an order of initialization is > >> >> important. > >> > > >> > > >> > Yes, but on *can* write idempotent class initialization code. So that > >> > if > >> > the system does reinitialize on every load old code may break until > its > >> > fixed, but new code will have the advantage of always being correctly > >> > initialized. Note that in the VMMaker class reinitializations of the > >> > core > >> > VM classes (the interpreter, garbage collector, jit, etc) are done *on > >> > each > >> > launch of the simulator*, and *each vm generation*, let alone on each > >> > package load :). [ I'm not recommending this :) ]. > >> > > >> > One thing I do is when creating singletons for sentinels etc I check > >> > whether > >> > they've been initialized. e.g. > >> > > >> > initialize > >> > Sentinel ifNil: [Sentinel := Object new] > >> > >> Knowing full well that I know next to nothing about concurrency in the > >> image, and so realising that this might be a complete non-issue: lazy > >> initialization and concurrency do not mix well. > > > > > > Agreed, but the two can be decoupled. For example one can build the > state > > and then assign it. Assignment is currently atomic so there are no > > multicore issues here (yet :) ). Further, assignments are not suspension > > points so a sequence of (just) assignments are guaranteed to occur > without > > interruption. And (I'm sure you realize, for give the pedantry) the > above > > example isn't lazy, it is eager. It simply refuses to create another > > Sentinel if one exists already. > > So because of the assignment guarantees we won't have two processes > entering the ifNil: block? (I'll try extract one foot from my mouth > and maybe replace it with another...) > > In this particular case things seem pretty innocuous: let's say two > processes enter the #initialize. They both manage to enter the ifNil: > (I'm aware this is compiled away to jumps, but the impact of this I > don't know) through a time-of-check-time-of-use race, and you end up > generating two objects. But one's simply lost. As long as references > to Sentinel don't escape the class, no one need know anything at all. > right. but good point. i hadn't thought of this case. the scenarios i'm thinking of are those where one is loading/updating a monticello or fuel package or similar or redefining a class initialize method. in these scenarios there's only likely to be one thread of control running the initialize. > > frank > > >> But I do agree with your sentiment: idempotency is highly desirable, > >> and somehow forcing non-idempotent class initialisation to fail > >> quickly and noisily sounds like a good plan. > >> > >> frank > > > > -- > > best, > > Eliot > > -- best, Eliot

Jan. 19, 2013

Re: [Pharo-project] Class initialisation after loading

by Frank Shearar

On 18 January 2013 21:49, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > phhh, let me try again :) > > > On Fri, Jan 18, 2013 at 8:47 AM, Frank Shearar <frank.shearar(a)gmail.com> > wrote: >> >> On 17 January 2013 17:45, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> > >> > >> > >> > On Thu, Jan 17, 2013 at 3:25 AM, Igor Stasenko <siguctua(a)gmail.com> >> > wrote: >> >> >> >> After some thought i decided to contribute my 2cents. >> >> >> >> First, i think it is impossible to introduce a (re)initialization >> >> logic which would suit all different scenarios. >> >> Because it is really depends on what is stored in class variables >> >> and/or >> >> pools >> >> and if you add subclasses and then instances into the soup, you might >> >> end up with something >> >> which is really hard to safely reinitialize, because it may have some >> >> inconsistent state at different stages >> >> of initialization. It also, sometimes an order of initialization is >> >> important. >> > >> > >> > Yes, but on *can* write idempotent class initialization code. So that >> > if >> > the system does reinitialize on every load old code may break until its >> > fixed, but new code will have the advantage of always being correctly >> > initialized. Note that in the VMMaker class reinitializations of the >> > core >> > VM classes (the interpreter, garbage collector, jit, etc) are done *on >> > each >> > launch of the simulator*, and *each vm generation*, let alone on each >> > package load :). [ I'm not recommending this :) ]. >> > >> > One thing I do is when creating singletons for sentinels etc I check >> > whether >> > they've been initialized. e.g. >> > >> > initialize >> > Sentinel ifNil: [Sentinel := Object new] >> >> Knowing full well that I know next to nothing about concurrency in the >> image, and so realising that this might be a complete non-issue: lazy >> initialization and concurrency do not mix well. > > > Agreed, but the two can be decoupled. For example one can build the state > and then assign it. Assignment is currently atomic so there are no > multicore issues here (yet :) ). Further, assignments are not suspension > points so a sequence of (just) assignments are guaranteed to occur without > interruption. And (I'm sure you realize, for give the pedantry) the above > example isn't lazy, it is eager. It simply refuses to create another > Sentinel if one exists already. So because of the assignment guarantees we won't have two processes entering the ifNil: block? (I'll try extract one foot from my mouth and maybe replace it with another...) In this particular case things seem pretty innocuous: let's say two processes enter the #initialize. They both manage to enter the ifNil: (I'm aware this is compiled away to jumps, but the impact of this I don't know) through a time-of-check-time-of-use race, and you end up generating two objects. But one's simply lost. As long as references to Sentinel don't escape the class, no one need know anything at all. frank >> But I do agree with your sentiment: idempotency is highly desirable, >> and somehow forcing non-idempotent class initialisation to fail >> quickly and noisily sounds like a good plan. >> >> frank > > -- > best, > Eliot

Jan. 18, 2013

Re: [Pharo-project] Why I love SmallLint

by ClÃ©ment Bera

Yeah actually they showed it at the moose lesson this afternoon. The moose team have moose analysis graphs on their jenkins. It could be nice to have it also on the Pharo/rmod jenkins. 2013/1/18 Camillo Bruni <camillobruni(a)gmail.com> > I love to see this! :) > > I just hear today, that apparently for moose they have the process ready to > run metrics on jenkins :) > > On 2013-01-18, at 22:21, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > Hi guys > > > > We will start to have a huge fun :) We are starting to apply > systematically apply SmallLint rules to all Pharo2.0 version and it is > > unbelievable what we will improve. We brainstormed today with Marcus, > Simon and Andre. And I could not resist to run and fix > > on rule :). > > > > Since we believe that simple practices and dummy ideas can have an > impact, I started to run the > > "Method just send super message" and fix the problems that are not in > test classes. > > This is so cool. I could even fix such glitch in Zinc :) > > > > So I'm really happy. > > I will apply rules one by one and fix as much as I can :). > > > > Then in the future, we will apply the result of andre's PhD to create > rules based on our development history. > > So we will have quite cool rules to cover Pharo and also help you to > migrate your code from one version to the other. > > > > http://code.google.com/p/pharo/issues/detail?id=7288 > > > > Stef > > > > > > >

Jan. 18, 2013

Re: [Pharo-project] What are the messages where we should always have a super send?

by Alexandre Bergel

Yes, #setUp and #tearDown For #initialize, having a super may not be that necessary if you working on the class side. Alexandre On Jan 18, 2013, at 12:06 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi > > While looking at SmallLint rule, I saw a rule that ensures that a given method always performs a > super send. > > Here is the current list: > > ^#(#release #postCopy #preBuildWith: #postOpenWith: #noticeOfWindowClose: #initialize postBuildWith:) > > > and I'm cleaning the list because there are VW elements such as postBuildWith: > but do we have some other to add? > > Stef > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 18, 2013

Re: [Pharo-project] Class initialisation after loading

by Eliot Miranda

phhh, let me try again :) On Fri, Jan 18, 2013 at 8:47 AM, Frank Shearar <frank.shearar(a)gmail.com>wrote: > On 17 January 2013 17:45, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > > > > > On Thu, Jan 17, 2013 at 3:25 AM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >> > >> After some thought i decided to contribute my 2cents. > >> > >> First, i think it is impossible to introduce a (re)initialization > >> logic which would suit all different scenarios. > >> Because it is really depends on what is stored in class variables and/or > >> pools > >> and if you add subclasses and then instances into the soup, you might > >> end up with something > >> which is really hard to safely reinitialize, because it may have some > >> inconsistent state at different stages > >> of initialization. It also, sometimes an order of initialization is > >> important. > > > > > > Yes, but on *can* write idempotent class initialization code. So that if > > the system does reinitialize on every load old code may break until its > > fixed, but new code will have the advantage of always being correctly > > initialized. Note that in the VMMaker class reinitializations of the > core > > VM classes (the interpreter, garbage collector, jit, etc) are done *on > each > > launch of the simulator*, and *each vm generation*, let alone on each > > package load :). [ I'm not recommending this :) ]. > > > > One thing I do is when creating singletons for sentinels etc I check > whether > > they've been initialized. e.g. > > > > initialize > > Sentinel ifNil: [Sentinel := Object new] > > Knowing full well that I know next to nothing about concurrency in the > image, and so realising that this might be a complete non-issue: lazy > initialization and concurrency do not mix well. > Agreed, but the two can be decoupled. For example one can build the state and then assign it. Assignment is currently atomic so there are no multicore issues here (yet :) ). Further, assignments are not suspension points so a sequence of (just) assignments are guaranteed to occur without interruption. And (I'm sure you realize, for give the pedantry) the above example isn't lazy, it is eager. It simply refuses to create another Sentinel if one exists already. > But I do agree with your sentiment: idempotency is highly desirable, > and somehow forcing non-idempotent class initialisation to fail > quickly and noisily sounds like a good plan. > > frank > -- best, Eliot

Jan. 18, 2013

Re: [Pharo-project] Class initialisation after loading

by Eliot Miranda

On Fri, Jan 18, 2013 at 8:47 AM, Frank Shearar <frank.shearar(a)gmail.com>wrote: > On 17 January 2013 17:45, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > > > > > On Thu, Jan 17, 2013 at 3:25 AM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >> > >> After some thought i decided to contribute my 2cents. > >> > >> First, i think it is impossible to introduce a (re)initialization > >> logic which would suit all different scenarios. > >> Because it is really depends on what is stored in class variables and/or > >> pools > >> and if you add subclasses and then instances into the soup, you might > >> end up with something > >> which is really hard to safely reinitialize, because it may have some > >> inconsistent state at different stages > >> of initialization. It also, sometimes an order of initialization is > >> important. > > > > > > Yes, but on *can* write idempotent class initialization code. So that if > > the system does reinitialize on every load old code may break until its > > fixed, but new code will have the advantage of always being correctly > > initialized. Note that in the VMMaker class reinitializations of the > core > > VM classes (the interpreter, garbage collector, jit, etc) are done *on > each > > launch of the simulator*, and *each vm generation*, let alone on each > > package load :). [ I'm not recommending this :) ]. > > > > One thing I do is when creating singletons for sentinels etc I check > whether > > they've been initialized. e.g. > > > > initialize > > Sentinel ifNil: [Sentinel := Object new] > > Knowing full well that I know next to nothing about concurrency in the > image, and so realising that this might be a complete non-issue: lazy > initialization and concurrency do not mix well. > Agreed, but the two can be decoupled. For example one can build the state and then assign it. Assignment is currently atomic so there are no multicore issues here (yet :) ). And (I'm sure you realize, for give the pedantry) the above example isn't lazy, it is eager. It simply refuses to create another Sentinel if one exists already. > But I do agree with your sentiment: idempotency is highly desirable, > and somehow forcing non-idempotent class initialisation to fail > quickly and noisily sounds like a good plan. > > frank > -- best, Eliot

Jan. 18, 2013

[Pharo-project] new Cog VMs available

by Eliot Miranda

at http://www.mirandabanda.org/files/Cog/VM/VM.r2673. Fix becomeForward: when the rootTbale overflows. There were two bugs here. One is that initializeMemoryFirstFree: used to clear the needGCFlag so if the rootTable overflowed noteAsRoot:headerLoc:'s setting of the needGCFlag would be undone after the sweep. The other is that rooitTable overflow was indicated by rootTableCount >= RootTableSize which could be undone by becomeForward: freeing roots which need to be removed from the rootTable. At some point in becomeForward the rootTable would fill but at a later point a root would be freed, causing the table to become not full. The fix is two fold. 1. Add an explicit rootTableOverflowed flag instead of relying on rootTableCount >= RootTableSize. 2. move the clearing of the needGCFlag to the GC routines. Remove unnecessary senders of needGCFlag: false, and remove the accessor. As a side effect rewrite primitiveRootTable in terms of a new ObjectMemory>>rootTableObject. Remove the rootTable: accessor. Implement checkAllAccessibleObjectsOkay & checkOkayInterpreterObjects: (used to debug the above). Fix NewObjectMemory initialization to set freeStart at the same time as setting endOfMemory. This allows load-time scans and assert code to use freeStart instead of endOfMemory. Simplify markAndTraceStackPage: ; since the two implementations are distinct they don't need to contain the isCog if-then-else. Implement NewObjectMemory>>shorten:toIndexableSize: so that the last object is correctly shortened (cut back freeStart). Refactor the allocation check filling code into maybeFillWithAllocationCheckFillerFrom:to:. Make longPrintOop: print the class oop. Fix bug in printCallStackOf:currentFP: for widowed contexts. Use fputs for print: instead of printf. Rewrite the stackLimit computation after a moment of clarity. Allow the system to reduce the space for frames by up to an 1/8th. Make sure there's at least as much headroom as asked for. This changes the stack page size from 4096 to 2048 and much reduces the interpreterAllocationReserveBytes. Don't round up interpreterAllocationReserveBytes to a power of two. Integrate the named serial primitives plus Luc Fabresse's latest fix. Improve cygwin HoiwToBuilds with info on latest versions (thanks Ron). -- best, Eliot

Jan. 18, 2013