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

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

Re: [Pharo-project] Why I love SmallLint

by Camillo Bruni

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] Why I love SmallLint

by Benjamin

We should definitely use SmallInt with Ulysse :) Ben On Jan 18, 2013, at 10:21 PM, StÃ©phane Ducasse 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

[Pharo-project] Why I love SmallLint

by StÃ©phane Ducasse

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] Manifest...

by ClÃ©ment Bera

I dont know if this can help you but the manifest classes are updated through the codecritics change browser. It keeps in memory the false positive for the future use of code critics 2013/1/18 Camillo Bruni <camillobruni(a)gmail.com> > Why do the Manifest.* classes have no class comments? > > 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. 18, 2013

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

by Denis Kudriashov

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. 18, 2013

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

by Mariano Martinez Peck

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 <http://www.square-i.net/> 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. 18, 2013