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

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

by Jan Vrany

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

[Pharo-project] Manifest...

by Camillo Bruni

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

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

by StÃ©phane Ducasse

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

Re: [Pharo-project] Class initialisation after loading

by Frank Shearar

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

Jan. 18, 2013

[Pharo-project] [update 2.0] #20480

by Marcus Denker

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

Jan. 18, 2013

[Pharo-project] [update 2.0] #20479

by Marcus Denker

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

Jan. 18, 2013

Re: [Pharo-project] The monkey is back in town

by Damien Cassou

On Wed, Dec 5, 2012 at 1:21 PM, Camillo Bruni <camillobruni(a)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

Jan. 18, 2013

[Pharo-project] [update 2.0] #20478

by Marcus Denker

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

Jan. 18, 2013

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

by Sean P. DeNigris

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-tp4663973p… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 18, 2013

[Pharo-project] Method has no time stamp

by StÃ©phane Ducasse

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

Jan. 18, 2013