January 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Class initialisation after loading

by Frank Shearar

On 19 January 2013 02:02, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > 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. I've been bitten too many times not to be leery of that particular case :). I had a nasty bug with a lazy initialisation in a 3rd party library where a TCP server kept a thread pool. If the thread pool was nil it would make a new one (so the Delphi equivalent of f ifNil: [f := blah]). On application shutdown, a thing running in that threadpool could call back to the TCP server. In particular, the TCP server would ask all threads to terminate and then nil the pool... and one of the threads would call back and reinitialise a whole new threadpool. The last thing the application did was wait for all threads to finish, and knew this by decrementing a counter. Only that cause-a-new-threadpool thread would try decrement the counter of a brand new threadpool. The application would happily wait forever for a notification from a thread that was long dead! The solution was simplicity itself: strip out the lazy initialization, and you don't get a second threadpool accidentally made. frank >> 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] [ANN] Headless support for Cog Cocoa VM

by Stephan Eggermont

This doesn't work open CogVM-release-noflash-noArgs.app Pier3.image & Jan 19 11:20:51 Stephan-Eggermonts-iMac [0x0-0x2f92f9].org.seaside-project[36832]: This interpreter (vers. 6502) cannot read image file (vers. 6505). Jan 19 11:20:51 Stephan-Eggermonts-iMac [0x0-0x2f92f9].org.seaside-project[36832]: Press CR to quit... Jan 19 11:20:52 Stephan-Eggermonts-iMac ReportCrash[36836]: Failed to create CSSymbolicatorRef for launchd Jan 19 11:20:52 Stephan-Eggermonts-iMac com.apple.launchd.peruser.501[207] ([0x0-0x2fa2fa].org.squeakfoundation.Squeak[36835]): Job appears to have crashed: Segmentation fault Jan 19 11:20:52 Stephan-Eggermonts-iMac ReportCrash[36836]: Saved crash report for launchd[36835] version ??? (???) to /Users/stephan/Library/Logs/DiagnosticReports/launchd_2013-01-19-112052_Stephan-Eggermonts-iMac.crash

Jan. 19, 2013

Re: [Pharo-project] [Pharo-users] [ANN] Headless support for Cog Cocoa VM

by StÃ©phane Ducasse

I would like thank officially Square [i] for this gift to the community. Thank again. Further work in this direction should be supported by the association and the consortium. Stef On Jan 18, 2013, at 8:14 PM, Mariano Martinez Peck wrote: > Hello there, > > For a long time, Pharaoers and Squakers have been asking for headless support in the Cocoa VMs just as we have with Carbon VMs. Carbon is becoming a legacy framework so people needed this. > > I wanted to thanks Square [i] International for sponsoring me to implement such a support. Not only have they sponsored the development but they have also agreed to release it under MIT license for the community. This headless support will be included in the official Pharo VM and will be, therefore, accessible to everybody. > > The project is not yet finished but I do have a demo/prototype that I wanted to share with you so that you can test it and give me feedback. This VM should only work starting at OSX 10.6. > > How to use it? Basically it works this way: to have headless, just edit the Info.plist and set the flag LSBackgroundOnly to 1 (add the key if it is not present): > > <key>LSBackgroundOnly</key> > <true/> > > When doing this, you don't even need the -headless anymore since, setting LSBackgroundOnly to 1, will cause the same effect (being the flag almost mandatory). If you don't want headless, put it to false or don't even put the key. If you don't set LSBackgroundOnly to 1 but send -headless, the VM will still be headless but you will see a little flash. If this flash bothers you, then set the flag. I am trying to get a way to avoid the "flash" while also avoiding to set LSBackgroundOnly to 1, but I still couldn't find it. Anyway, I think we can live with the current situation. > > How to test it? You should run the image with something like RFB or Seaside or whatever you can and then confirm if it is working even if you are headless. As a matter of testing, I saved an image with seaside running in the port 5555. You can get both, this Seaside image and the VM with headless from: https://www.dropbox.com/sh/r7qk49bxywk2xce/6N7-fdyx6V > So if you run the VM headless with that image and go to localhost:5555, you should see that Seaside is running. > > I would appreciate if you can test it. And please let me know in which version of OSX you tried. Of course, the more of you who can test it, the better. Notice that this VM was compiled with LLVM GCC 4.2 and it may have some problems in older OSX versions (but I think it shouldn't). I still couldn't compile a VM with GNU GCC 4.2 as I get a crash :( > > Expected results? In headless mode, anything should be displayed (no window, no menu, no item in the dock and nothing appear when switching apps). When running headfull, everything should be normal. > > Where is the code? The code I have modified to the VM is committed to my own fork of the VM: https://gitorious.org/~marianopeck/cogvm/marianopecks-blessed > Once the code is ready, I will do a pull request so that it can be integrated. > > Thanks everyone for the testing and feedback. Once again, thanks Square [i] International for sponsoring this great feature. Also thanks Esteban Lorenzano and Mark Smith for their incredible help. > > This was just the first prototype. I will keep you informed about possible progress. > > Best regards, > > -- > Mariano > http://marianopeck.wordpress.com

Jan. 19, 2013

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

by StÃ©phane Ducasse

Hi jan do you have an example of such tagging? Right now we are also thinking that we want three kinds of rules - 1 whose result is either zero because there is no problem or zero because we flag the false positives - 2 more fuzzy one where we should have flase positive defined per package - 3 more statistical rules (long methods, large number of instance variables) We are checking how we can find decent threshold values not generating thousands of warnings and also if we want to embed false positives for them too. May be they are just good for trend analysis and when you want to spot ugly code but you do not care to have them under your nose systematically. For the rules I'm also changing the implementation to make sure that we can customized the list of selectors, thresholds â¦. without having to recompile a method. This way people will be able to use their own conventions. Stef On Jan 18, 2013, at 6:24 PM, Jan Vrany wrote: > Hi Stef, > > while massaging SmallLint rules, you should also have look at > Smalltalk/X version of SmallLint [1] as we have ported > Pharo version and improved some rules. I have also added > a tagging system. That's useful for some rules are only > good if you want to ensure portable code, some are simply > broken and some stupid, etc. Having them properly classified > would help us all. > > Tell me once you finish your ride, I'll merge changes back :-) > > Jan > > [1] http://www.exept.de/cgi-bin/viewvc.cgi/stx/goodies/refactoryBrowser/lint/ > > to checkout issue: > > cvs -d :pserver:cvs@cvs.smalltalk-x.de:/cvs/stx co stx/goodies/refactoryBrowser/lint/ > > > On 18/01/13 17:06, StÃ©phane Ducasse 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 >> >> >> > >

Jan. 19, 2013

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