April 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] Problem with implementors of

by StÃ©phane Ducasse

Hi ben I do not really understand but when I edit a method in the implementor code pane after the cancel accept discard dialog does not work and I cannot do anything. Stef

April 21, 2012

Re: [Pharo-project] Feedback about SmallLint

by Lukas Renggli

On 21 April 2012 14:00, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > 2) RBContainsRule is not clear for me. " 'Checks for the common code > fragment: "(aCollection detect: [:each | ''some condition''] ifNone: [nil]) > ~= nil". contains: can simplify this code to "aCollection contains: [:each | > ''some condition'']". Not only is the contains: variant shorter, it better > signifies what the code is doing.'" > That is not very true. #contains answers true or false, while > detect:ifNone:[] answers whatever, and in your example it is nil. So, the > answer will be different and hence it is not the same. Ok, in your example, > you compare after with == nil... but... I don't really see a use case. For > example, in my case it detected: > > classNamed: className > > Â Â Â ^ (migrations > Â Â Â Â Â Â detect: [:m | m sourceClassName = className ] > Â Â Â Â Â Â ifNone: [ ^ self globalClassNamed: className ]) > Â Â Â Â Â Â targetClass. Thank you for pointing out. I have previously seen similar issues with this rule. I committed an improved version that should return less false-positives, and that finds a few more related issues. > 3) RBLawOfDemeterRule: maybe you can exclude string concatenation?Â (#,) > because it detected a lot of messages like this: > signalWith: aGlobalName and: aSelector > Â Â Â ^ self signal: 'Method ', aGlobalName, '>>#', aSelector, ' not found.' > > Also, what about excluding messages like #asXXX. For example, here it > detected "self signature asByteArray". Is that completly breaking the law of > demeter? mmm I don't think so. > > verifySignatureFrom: aDecoder > > Â Â Â | streamSignature | > Â Â Â streamSignature := ByteArray new: self signature size. > Â Â Â aDecoder nextEncodedBytesInto: streamSignature. > Â Â Â (self signature asByteArray = streamSignature) ifFalse: [ > Â Â Â Â Â Â FLBadSignature > Â Â Â Â Â Â Â Â Â signalCurrentSignature: self signature > Â Â Â Â Â Â Â Â Â streamSignature: streamSignatureÂ ]. Arguably this is a problem in your code: You could for example use streams or a formatter to build complicated strings; and you could ask the signature if it is the same as a stream signature. It is kind of arbitrary from when on a chain of selectors is considered a violation of the law of demeter ... Maybe the number should be higher? Maybe this number should be even different if these are unary, binary or keyword messages? As with any violation this is just a suggestion. > 4) RBSentNotImplementedRule:Â I didn't understand why it has selected: > > largeIdentityHash > > Â Â Â <primitive: 75> > Â Â Â self primitiveFailed > > both messages are implemented :( The rule checks if self-sends are implemented in the class hierarchy, and if super-sends are implemented in the superclass hierarchy of the method. For example, when you inherit from ProtoObject then #primitiveFailed is not implemented. In your case the problem might never show up in practice -- for example because your class is abstract and all subclasses implement the message; or because you use #doesNotUnderstand: -- but still I think the rule is correct. > 5) RBClassInstVarNotInitializedRule could be smarter and search not only for > #initialize but for #initializeXXX. Lots of times, I initialize my objects > with data, using a particular nitialize method, such as: > initializeWithBehaviors: someBehaviors extensionMethods: > someExtensionMethods > so the rule says there is no initialize...but I have that one ;) The rule only checks for the presence of an #initialize method (the only method that is automatically called by the system upon loading of a class) if the class defines variables. It does not check if (and where) the variable is actually assigned. Now if you have classes initialize each other or if you initialize your variables lazily that rule complains. I agree with the author of the rule that this is bad style and worth to think about. > That's all the feedback so far. It helped me to find some things to improve > so thanks! Please don't call it "SmallLint". Since at least 2003 the tool is called "Smalltalk Code Critics", see for example http://www.cincomsmalltalk.com/blog/blogView?entry=3236371324. I think it has been renamed even before 2000, but I can't find the slides of John anymore. Lukas -- Lukas Renggli www.lukas-renggli.ch

April 21, 2012

Re: [Pharo-project] Unresponsive 1.4 image

by StÃ©phane Ducasse

janko open an issue with such cases so that we do not forget it. Stef On Apr 21, 2012, at 2:54 PM, Janko MivÅ¡ek wrote: > Hi guys, > > This code reproduces the blockade in fresh 1.4 OneClick (with or without > Transcript window open): > > [ > (Delay forSeconds: 5) wait. > SmalltalkImage current saveSession. > ] forkAt: Processor userBackgroundPriority > > Note that fork on default priority does not block while on user > background priority it blocks. It does not always block immediately > (sometimes yes sometimes not) but it after image restart it is always > blocked. > > But if you periodically write to Transcript from process on user > background priority, it does not block, even if you heavily browse > around, write to transcript, do manual snapshot: > > [ [true] whileTrue: > [(Delay forMilliseconds: 500) wait. > Transcript show: '.tst.'] > ] forkAt: Processor userBackgroundPriority > > So, it seems not only thread-safe Transcript but something with snapshot > (from a background priority, why?) is in play here. > > SmalltalkImage>>snapshot:andQuit: , shouldnât run it on highest priority > to block all other processes during the preparation for snapshot? > > Hope this helps a bit more > Janko > > > > Dne 21. 04. 2012 11:48, piÅ¡e Igor Stasenko: >> So, this is related to thread-safe transcript code.. >> which using semaphore to synchronize access to transcript stream. >> I guess what happens is that a semaphore is blocked in another >> process, but for some strange reason never released. This leads to >> situation, that any other process which will attempt to write to >> transcript will be blocked as well.. forever. > > Why is input not blocked immediately but after image restart? > > > More investigation: > > > 1. correction: image blocks in any case after restart, regardless if > there is additional writing to Transcript or not. Snapshot namely writes > to Transcript by itself and this is enough to block. > > 1. even if Transcript is closed the image blocks after restart > > This simulated snapshot from the background does NOT block after restart: > > [ > (Delay forSeconds: 5) wait. > SmalltalkImage current saveSession. > ] fork > > This one also not: > > [ | elapsed | > (Delay forSeconds: 5) wait. > elapsed := Time millisecondsToRun: > [SmalltalkImage current saveSession]. > Transcript show: ' in ', (elapsed // 1000) printString, 's '. > ] forkAt: Processor userBackgroundPriority > > > > > > >> >> 2012/4/21 Janko MivÅ¡ek <janko.mivsek(a)eranova.si>: >>> Hi guys, >>> >>> It seems that writing to Transcript from background process causes my >>> freeze after restart. And yes, I have Transcript window open. >>> >>> This is a code snippet in question: >>> >>> AIDASite class>>imageSnapshot >>> ... >>> elapsed := Time millisecondsToRun: >>> [SmalltalkImage current saveSession]. >>> Transcript show: ' in ', (elapsed // 1000) printString, 's '. >>> >>> >>> If I comment out the last line, snapshot doesn't block the image after >>> restart. >>> >>> This is not necessary 1.4 specific problem, because I noticed similar >>> problem in 1.3 also. Just that on 1.3 input freezes immediately while on >>> 1.4 it freezes after restart. >>> >>> Let me investigate a bit further, what if Transcript window is not open? >>> >>> Best regards >>> Janko >>> >>> >>> >>> Dne 20. 04. 2012 21:42, piÅ¡e StÃ©phane Ducasse: >>>> Ok may be nautilus bug. It should be different than janko problem. >>>> >>>> Stef >>>> >>>> On Apr 20, 2012, at 9:39 PM, Sean P. DeNigris wrote: >>>> >>>>> >>>>> StÃ©phane Ducasse wrote >>>>>> >>>>>> on which os? >>>>>> >>>>> >>>>> Mac Lion 10.7.3 >>>>> >>>>> -- >>>>> View this message in context: http://forum.world.st/Unresponsive-1-4-image-tp4574693p4575049.html >>>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>>> >>>> >>>> >>>> >>> >>> -- >>> Janko MivÅ¡ek >>> Aida/Web >>> Smalltalk Web Application Server >>> http://www.aidaweb.si >>> >> >> >> > > -- > Janko MivÅ¡ek > Aida/Web > Smalltalk Web Application Server > http://www.aidaweb.si >

April 21, 2012

Re: [Pharo-project] Unresponsive 1.4 image

by StÃ©phane Ducasse

thanks I'm currently checking some strange behavior with mroph properties. Stef On Apr 21, 2012, at 2:01 AM, phil(a)highoctane.be wrote: > To freeze 1.4 on Win XP SP3, you can try this one out: > > | tm border | > tm := TextMorph new. > tm contentsWrapped: ''; > extent: 100 @ 20. > "this is the important stuff" > (border := AlignmentMorph newRow) position: 200 @ 200; > borderWidth: 1; > borderColor: Color black; > hResizing: #shrinkWrap; > vResizing: #shrinkWrap; > addMorph: tm. > "this just makes the TextMorph easier =to see" > World addMorph: border. > > Then fill in the TextMorph with some text and newlines. > > Then call the halos and resize the right corner for a while, especially letting it go out of screen at the bottom. > > The system will come unresponsive, not obey Cmd-. etc. > > Sometimes it comes back to life but most of the time I've got to kill the process. > > CogVM or StackVM make no difference. > > Maybe there is a huge GC going on but there is no memory display thing (manuia) anymore in 1.4 so I can't tell. > > Hope it helps. > > Phil > > > > 2012/4/20 Paul DeBruicker <pdebruic(a)gmail.com> > > Janko MivÅ¡ek wrote > > > > > > After Ctrl-C in command prompt there is no new PharoDebug.log. > > > > > > > > Instead of Crtl-C do you get anything if you find the process and kill it > with: > > kill -s SIGUSR1 <pid> > > ? > (assuming you're using Cog ) > > -- > View this message in context: http://forum.world.st/Unresponsive-1-4-image-tp4574693p4575089.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > -- > Philippe Back > "Helping you hit the top 3 outcomes you really want to achieve" > > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be | Web: http://philippeback.eu | Blog: > http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges >

April 21, 2012

Re: [Pharo-project] The video about Athens

by StÃ©phane Ducasse

no he did it on mac because he used snapZpro to produce the video Stef s On Apr 21, 2012, at 2:03 PM, Sean P. DeNigris wrote: > > Sean P. DeNigris wrote >> >> I get Generic failure >> fnSpec: #(#bool #ioRegisterSurface #(#ulong #aCairoSurfaceHandle #, >> #void #* #sqSurfaceDispatchPtr #, #int #* #idHolder)) >> module: #SurfacePlugin >> errorCode: 1 >> > > Igor, I guess you didn't run into this on Mac... any ideas why it's still > not working? > > Sean > > -- > View this message in context: http://forum.world.st/The-video-about-Athens-tp4571100p4576317.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

April 21, 2012

Re: [Pharo-project] Late binding class names

by Sean P. DeNigris

Pavel Krivanek-3 wrote > > you may look at WADynamicVariable from Seaside how > to process such context specific globals. > Thanks for the pointer... I checked it out, but Seaside is actually not doing anything with the binding there. Sean -- View this message in context: http://forum.world.st/Late-binding-class-names-tp4575026p4576741.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 21, 2012

Re: [Pharo-project] Notification of inst var added

by Sean P. DeNigris

ezequiel lamonica wrote > > Are you working with Pharo 1.3 ? > Yes, I was... -- View this message in context: http://forum.world.st/Notification-of-inst-var-added-tp4576616p4576696.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 21, 2012

Re: [Pharo-project] Notification of inst var added

by Marcus Denker

On Apr 21, 2012, at 6:27 PM, Sean P. DeNigris wrote: > > Sean P. DeNigris wrote >> >> I was thinking that the SystemChangeNotifier... >> > > Nevermind... I just noticed the new Announcements in 1.4. Very cool! > Yes, in 2.0 we plan to remove SystemChangeNotifier.... -- Marcus Denker -- http://marcusdenker.de

April 21, 2012

Re: [Pharo-project] Notification of inst var added

by Ezequiel Lamonica

Are you working with Pharo 1.3 ? Because I get a #classDefinitionChangedFrom:to: event when an instance variable is added from the pop-up. On 21 April 2012 12:37, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > I was thinking that the SystemChangeNotifier would trigger a class modified > event when an instance variable is added, but I only got a method modified > event when I referenced an unknown name in a method and selected 'declare > instance' from the pop-up. > > How would I know when an instance variable is added? > > Thanks. > Sean > > -- > View this message in context: > http://forum.world.st/Notification-of-inst-var-added-tp4576616p4576616.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

April 21, 2012

Re: [Pharo-project] Notification of inst var added

by Sean P. DeNigris

Sean P. DeNigris wrote > > I was thinking that the SystemChangeNotifier... > Nevermind... I just noticed the new Announcements in 1.4. Very cool! -- View this message in context: http://forum.world.st/Notification-of-inst-var-added-tp4576616p4576685.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 21, 2012