Re: [Pharo-project] Where should SmalltalkHub bugs be reported?
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? Nico Sean P. DeNigris s...@clipperadams.com writes: Here's a small one... StHub provides a Monticello registration snippet, which is cool: MCHttpRepository location: 'http://smalltalkhub.com/mc/dh83/fisleg/main' user: 'SeanDeNigris' password: '' But in Pharo 2.0, since there is a user but no password, dialogs pop up asking for credentials, which can not be ignored. Since the great majority of uses is for downloading, I think it'd make more sense to leave the username out. Cheers, Sean -- View this message in context: http://forum.world.st/Where-should-SmalltalkHub-bugs-be-reported-tp4663973.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. -- Nicolas Petton http://nicolas-petton.fr
Re: [Pharo-project] Where should SmalltalkHub bugs be reported?
Thanks Camillo :) Nico - Camillo Bruni camillobr...@gmail.com writes: I just opened a google code project, it's been too long since we don't have a proper issue tracker for smalltalkhub: https://code.google.com/p/smalltalk-hub On 2013-01-17, at 18:15, Sean P. DeNigris s...@clipperadams.com wrote: Here's a small one... StHub provides a Monticello registration snippet, which is cool: MCHttpRepository location: 'http://smalltalkhub.com/mc/dh83/fisleg/main' user: 'SeanDeNigris' password: '' But in Pharo 2.0, since there is a user but no password, dialogs pop up asking for credentials, which can not be ignored. Since the great majority of uses is for downloading, I think it'd make more sense to leave the username out. Cheers, Sean -- View this message in context: http://forum.world.st/Where-should-SmalltalkHub-bugs-be-reported-tp4663973.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. -- Nicolas Petton http://nicolas-petton.fr
[Pharo-project] [Jenkins] Old Jenkins to shut down 28.01
Hi, Having two Jenkins setups with very similar URLs us highly confusing (I have edited the wrong project in the past…) Therefore, with the new setup in Place and all projects either already migrated or in the process of being migrated, we should put an end date. On 28.01.2013 we will delete all remaining projects and tell IT to shut down the server and slaves. Marcus
Re: [Pharo-project] [Jenkins] Old Jenkins to shut down 28.01
On Fri, Jan 18, 2013 at 10:26 AM, Marcus Denker marcus.den...@inria.frwrote: On 28.01.2013 we will delete all remaining projects and tell IT to shut down the server and slaves. If you can, you could change the CSS so that background of the website is red. -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill
Re: [Pharo-project] [Jenkins] Old Jenkins to shut down 28.01
On Jan 18, 2013, at 10:46 AM, Damien Cassou damien.cas...@gmail.com wrote: On Fri, Jan 18, 2013 at 10:26 AM, Marcus Denker marcus.den...@inria.fr wrote: On 28.01.2013 we will delete all remaining projects and tell IT to shut down the server and slaves. If you can, you could change the CSS so that background of the website is red. No idea how and I would like to spend my time improving the new setup… Marcus
[Pharo-project] about Loom profiler
Hi alex how Loom compares with the fixes that andreas added to the default profiler. I do not know if the code is in squeak because this code was licensed under GPL. But I would like to know if your profiler takes into account the problems solved by andreas. I did not see an announce of Loom (by the way Loom is the name of large oo memory developed by the original smalltalk team a while ago). http://objectprofile.com/loom-download.html I'm know that some people got problem with our profiler and I would like to see how we can improve it. Stef
[Pharo-project] Method has no time stamp
Hi guys I'm continuing my little ride on the SmallLint rules and I saw the rule Method has no time stamp. Do you you remember why this is a problem and how it could be solved? Stef
Re: [Pharo-project] Where should SmalltalkHub bugs be reported?
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? -- View this message in context: http://forum.world.st/Where-should-SmalltalkHub-bugs-be-reported-tp4663973p4664094.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
[Pharo-project] [update 2.0] #20478
20478 - Issue 7280: When changing the superclasss the class comment and all method categories of all subclasses are gone http://code.google.com/p/pharo/issues/detail?id=7280 Issue 6686: Nautilus should use Dropdown, Tabs or Checkbox to indicate Class/instance-side http://code.google.com/p/pharo/issues/detail?id=6686 Diff information: http://ss3.gemstone.com/ss/Pharo20/Polymorph-Widgets-MarcusDenker.753.diff http://ss3.gemstone.com/ss/Pharo20/NautilusCommon-MarcusDenker.107.diff http://ss3.gemstone.com/ss/Pharo20/Nautilus-MarcusDenker.396.diff http://ss3.gemstone.com/ss/Pharo20/Kernel-MarcusDenker.1286.diff
Re: [Pharo-project] The monkey is back in town
On Wed, Dec 5, 2012 at 1:21 PM, Camillo Bruni camillobr...@gmail.com wrote: more or less: there is another deprecation warning coming from `Smalltalk osVersion` but it works... You can check the ConfigurationOfCI to see how to include it from http://smalltalkhub.com/#!/~dh83/fisleg you don't need FileSystem-Legacy if you use OSProcess from Coral: Gofer new squeaksource3: 'coral'; package: 'OSProcess'; load. -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill
[Pharo-project] [update 2.0] #20479
20479 - Issue 6449: [ENH]: MCHttpRepository Authentication http://code.google.com/p/pharo/issues/detail?id=6449 Diff information: http://ss3.gemstone.com/ss/Pharo20/Tools-MarcusDenker.1011.diff http://ss3.gemstone.com/ss/Pharo20/Tests-MarcusDenker.491.diff http://ss3.gemstone.com/ss/Pharo20/Network-Url-MarcusDenker.82.diff http://ss3.gemstone.com/ss/Pharo20/Monticello-MarcusDenker.744.diff http://ss3.gemstone.com/ss/Pharo20/Gofer-Tests-MarcusDenker.157.diff http://ss3.gemstone.com/ss/Pharo20/Gofer-Core-MarcusDenker.191.diff http://ss3.gemstone.com/ss/Pharo20/CI-Core-MarcusDenker.50.diff
[Pharo-project] [update 2.0] #20480
20480 - Issue 7262: add --save option to TestRunnerCommandLineHandler http://code.google.com/p/pharo/issues/detail?id=7262 Issue 6920: dragging a class from a package to another one does not remove the element from the source package http://code.google.com/p/pharo/issues/detail?id=6920 Diff information: http://ss3.gemstone.com/ss/Pharo20/Nautilus-MarcusDenker.397.diff http://ss3.gemstone.com/ss/Pharo20/HudsonBuildTools20-MarcusDenker.17.diff
Re: [Pharo-project] Class initialisation after loading
On 17 January 2013 17:45, Eliot Miranda eliot.mira...@gmail.com wrote: On Thu, Jan 17, 2013 at 3:25 AM, Igor Stasenko siguc...@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. 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
[Pharo-project] What are the messages where we should always have a super send?
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
[Pharo-project] Manifest...
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
Re: [Pharo-project] What are the messages where we should always have a super send?
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:c...@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
[Pharo-project] [ANN] Headless support for Cog Cocoa VM
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): keyLSBackgroundOnly/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 . 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:, 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
Re: [Pharo-project] TxTextMorph based on new text model
Hello. I publish configuration at TxText repository based on proposed repackaging. 2013/1/15 Camillo Bruni camillobr...@gmail.com On 2013-01-15, at 12:44, Denis Kudriashov dionisi...@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!
Re: [Pharo-project] Manifest...
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 camillobr...@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
[Pharo-project] Why I love SmallLint
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
Re: [Pharo-project] Why I love SmallLint
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
Re: [Pharo-project] Why I love SmallLint
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.duca...@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
Re: [Pharo-project] Class initialisation after loading
On Fri, Jan 18, 2013 at 8:47 AM, Frank Shearar frank.shea...@gmail.comwrote: On 17 January 2013 17:45, Eliot Miranda eliot.mira...@gmail.com wrote: On Thu, Jan 17, 2013 at 3:25 AM, Igor Stasenko siguc...@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
Re: [Pharo-project] Class initialisation after loading
phhh, let me try again :) On Fri, Jan 18, 2013 at 8:47 AM, Frank Shearar frank.shea...@gmail.comwrote: On 17 January 2013 17:45, Eliot Miranda eliot.mira...@gmail.com wrote: On Thu, Jan 17, 2013 at 3:25 AM, Igor Stasenko siguc...@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
Re: [Pharo-project] What are the messages where we should always have a super send?
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.duca...@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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-project] Why I love SmallLint
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 camillobr...@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.duca...@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
Re: [Pharo-project] Class initialisation after loading
On 18 January 2013 21:49, Eliot Miranda eliot.mira...@gmail.com wrote: phhh, let me try again :) On Fri, Jan 18, 2013 at 8:47 AM, Frank Shearar frank.shea...@gmail.com wrote: On 17 January 2013 17:45, Eliot Miranda eliot.mira...@gmail.com wrote: On Thu, Jan 17, 2013 at 3:25 AM, Igor Stasenko siguc...@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
Re: [Pharo-project] Class initialisation after loading
On Fri, Jan 18, 2013 at 2:38 PM, Frank Shearar frank.shea...@gmail.comwrote: On 18 January 2013 21:49, Eliot Miranda eliot.mira...@gmail.com wrote: phhh, let me try again :) On Fri, Jan 18, 2013 at 8:47 AM, Frank Shearar frank.shea...@gmail.com wrote: On 17 January 2013 17:45, Eliot Miranda eliot.mira...@gmail.com wrote: On Thu, Jan 17, 2013 at 3:25 AM, Igor Stasenko siguc...@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
