- Pharo-dev - lists.pharo.org

Re: [Pharo-project] ECompletion/Shout bug

by Nicolas Cellier

These are not really nested if, but rather a kind of caseOf: implemented with elseif. It's not to say that the style is ideal... I did not read the code, and don't know what a range is, nor if it has subclass specializations. If so, maybe some actions could simply be dispatched to range. Nicolas Le 23 avril 2012 10:58, Esteban Lorenzano <estebanlm(a)gmail.com> a Ã©crit : > he... is not related with the error, but... did you see this method? > > guessTypeOf: aNumber > Â Â Â Â | range | > Â Â Â Â self configureSelectorsOnly. > Â Â Â Â recurseCount > 10 ifTrue: [ ^ nil ]. > Â Â Â Â recurseCount := recurseCount + 1. > Â Â Â Â range := ranges at: aNumber. > Â Â Â Â ^ range isSelf > Â Â Â Â Â Â Â Â ifTrue: [ theClass ] > Â Â Â Â Â Â Â Â ifFalse: > Â Â Â Â Â Â Â Â Â Â Â Â [ range isSuper > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [ theClass superclass ] > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [ range isConstant > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [ range asType ] > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [ range isArgument > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [ self guessArgument: range ] > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [ range isTemporaryVariable > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [ self guessTempVarClass: range ] > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [ range isInstanceVariable > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [ self guessInstVarClass: range ] > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [ range isClassVariable > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [ self guessClassVarClass: range ] > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [ range isGlobal ifTrue: [ self guessGlobal: aNumber ] ] ] ] ] ] ] ] > > > when I was younger, at informatics school, they told me that "3 nested ifs means bad design, with no doubt"... what about 7? > > > On Apr 23, 2012, at 10:30 AM, Esteban Lorenzano wrote: > >> yes, I can reproduce this one... taking care of it now :) >> >> On Apr 23, 2012, at 10:11 AM, StÃ©phane Ducasse wrote: >> >>> Note that the bug shows up if you edit the code in the result of the implementors. >>> Esteban can you reproduce the bug? >>> >>> Stef >>> >>> On Apr 23, 2012, at 9:18 AM, StÃ©phane Ducasse wrote: >>> >>>> Hi >>>> >>>> I get a bug with OCompletion/Ecompletion >>>> >>>> TextEditor>>changeEmphasis >>>> >>>> try to type >>>> >>>> Â Â menuList nextPut: >>>> >>>> and you get a bug. >>>> >>>> Now in addition I do not understand what I see in the debugger: >>>> >>>> As you see model returns a debugger and the debugger title show FlatMessageListBrowser >>>> >>>> Stef >>>> >>>> >>>> >>>> <Screen Shot 2012-04-23 at 9.08.45 AM.pdf> >>> >>> >> > >

April 23, 2012

Re: [Pharo-project] [ANN] Styled Text Editor for Cuis 4.0 Smalltalk

by Norbert Hartl

Am 23.04.2012 um 12:25 schrieb Janko MivÅ¡ek: > > > Dne 23. 04. 2012 12:08, piÅ¡e Sven Van Caekenberghe: > >> On 23 Apr 2012, at 11:43, GÃ¶ran Krampe wrote: > >>> Having skimmed this thread I must say that I am amazed how easy we fall into Squeak vs Pharo flamewars - haven't we gotten past that by now? > >> Yes, we should be past that, but just quickly skimming the thread, it seems as if Chris Muller was the first to include the Squeak vs Pharo discussion into this thread. > > No, it was Marcus, be fair please. But I agree with Marcus observations > here. > It doesn't really matter who started it. We all like to come over this. It can happen and the only thing making it worse is to talk about the fact that it happened. Regarding the styled text editor it is highly bound to the changes that have been made to Cuis. So there is close to no chance to have a common codebase. It will be a fork anyway. And what I heard it will be a lot of work to adapt it anyway. Norbert

April 23, 2012

Re: [Pharo-project] [ANN] Styled Text Editor for Cuis 4.0 Smalltalk

by Sven Van Caekenberghe

On 23 Apr 2012, at 12:25, Janko MivÅ¡ek wrote: > Dne 23. 04. 2012 12:08, piÅ¡e Sven Van Caekenberghe: > >> On 23 Apr 2012, at 11:43, GÃ¶ran Krampe wrote: > >>> Having skimmed this thread I must say that I am amazed how easy we fall into Squeak vs Pharo flamewars - haven't we gotten past that by now? > >> Yes, we should be past that, but just quickly skimming the thread, it seems as if Chris Muller was the first to include the Squeak vs Pharo discussion into this thread. > > No, it was Marcus, be fair please. No, he responded to Chris' mail, which was, let's say somewhat biased and suggestive in the context of the discussion. How would you react if I said, in a normal discussion about some technical or design aspect of Aida/Web that 'nobody should bother with an alternative web framework since we already have Seaside which is perfect' ? Sven PS: (The qoute above is *not* what I think at all, about either Aida/Web or Seaside ;-)

April 23, 2012

Re: [Pharo-project] [ANN] Styled Text Editor for Cuis 4.0 Smalltalk

by Janko MivÅ¡ek

Dne 23. 04. 2012 12:08, piÅ¡e Sven Van Caekenberghe: > On 23 Apr 2012, at 11:43, GÃ¶ran Krampe wrote: >> Having skimmed this thread I must say that I am amazed how easy we fall into Squeak vs Pharo flamewars - haven't we gotten past that by now? > Yes, we should be past that, but just quickly skimming the thread, it seems as if Chris Muller was the first to include the Squeak vs Pharo discussion into this thread. No, it was Marcus, be fair please. But I agree with Marcus observations here. Best regards Janko -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

April 23, 2012

Re: [Pharo-project] [ANN] Styled Text Editor for Cuis 4.0 Smalltalk

by Sven Van Caekenberghe

Hi GÃ¶ran, On 23 Apr 2012, at 11:43, GÃ¶ran Krampe wrote: > Hi folks! > > Having skimmed this thread I must say that I am amazed how easy we fall into Squeak vs Pharo flamewars - haven't we gotten past that by now? Yes, we should be past that, but just quickly skimming the thread, it seems as if Chris Muller was the first to include the Squeak vs Pharo discussion into this thread. > Now, the most interesting part is IMHO not discussed - how does the leadership of Pharo view this work? Is it meriting enough to be a blessed project for Pharo? > > Just curious because it does present an interesting case - an important part being primarily developed in *another* Smalltalk than Pharo (Cuis). Just cloning it off into Pharo and forking seems... less optimal. Any ideas or thoughts? I am not familiar with the subject, but it seems like a nice editor was written on top of a specific GUI framework on top of Cuis, a nice, clean Smalltalk. The question of porting seems like asking to convert an very GUI intensive app from the Microsoft Windows API to the Apple Cocoa API, or vice versa. How realistic can that be, without forking ? Sven

April 23, 2012

Re: [Pharo-project] [ANN] Styled Text Editor for Cuis 4.0 Smalltalk

by GÃ¶ran Krampe

Hi folks! Having skimmed this thread I must say that I am amazed how easy we fall into Squeak vs Pharo flamewars - haven't we gotten past that by now? Now, the most interesting part is IMHO not discussed - how does the leadership of Pharo view this work? Is it meriting enough to be a blessed project for Pharo? Just curious because it does present an interesting case - an important part being primarily developed in *another* Smalltalk than Pharo (Cuis). Just cloning it off into Pharo and forking seems... less optimal. Any ideas or thoughts? regards, GÃ¶ran

April 23, 2012

Re: [Pharo-project] Feedback about SmallLint

by StÃ©phane Ducasse

> thanks for the report. > Mariano so far we did not change any of the rules provided by RB. For now we will run small lint and collect information. > > > Ok, I understand. But since I am SmallLintying my packages I guess that my feedback does not hurt for future work (when you do start changing rules). Indeed. > Some more feedback: > > 6) RBAbstractClassRule is confusing. "Checks for references to classes that have subclassResponsibility methods. Such references might be creating instances of the abstract class or more commonly being used as the argument to an isKindOf: message which is considered bad style." In my case, it found FLBenchmarkRunner because it has INSTANCE side messages with subclassResponsability. However, all references to the class FLBenchmarkRunner send class side messages to it. So.... maybe It can exclude class side messages that do not end up sending #new or #basicNew? > > 7) how does the Manifiesto class envolves while the real packages are changed (class and methods are renamed or removed) ? > If a method class is removed then I guess it is easy to remove the metadada associated to them. But what about if a method change? you cannot be sure if the rule exclusion still make sense or not. So, I guess you should remove the metadata as well ? > > 8) RBMethodHasNoTimeStampRule seems to have a problem with Traits because it shows me lots of methods without timestamp and they all result to come from a trait. > > 9) Sometimes, clicking on a method raises an error. Find attached PhaorDebug.log > > 10) RBSubclassResponsibilityNotDefinedRule could show me WHICH are the leaf subclasses that do NOT implement the method ... otherwise it is complicated to find it. > > 11) I don't like storing the Manifiest class in the default/main package. I changed ManifiestFuel to be in Fuel-SmallLint rather than Fuel but then, as soon as I run the rules again, it moves back the class to Fuel. Can't it check if the class already exist in Smalltalk globals and if true just use it and don't move it ? > > 12) It would be nice to group rules by criteria. I saw you have #group in each rule so I guess it is a matter of time to have the UI aware of that, right? > > > Cheers > > > > Stef > > > > > Hi guys. After our meeting at Lille, I did a pass of SmallLint over Fuel project. I have to say that I enjoyed the tool and that. I love the manifiesto idea. I love to store metada and to be able to reject rules and scenarios to avoid having false positives again in the future. In addition, it looks like I had less false positive than with other tools. However, there were a couple of rules that I don't understand or may suggest something: > > > > 1) First, apart form showing the package between parenthesis, I would also show the protocol (category). Because some rules play with that, so it is handy if you can directly see them there, otherwise you need to browse the code. > > > > 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. > > > > > > 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 ]. > > > > > > 4) RBSentNotImplementedRule: I didn't understand why it has selected: > > > > largeIdentityHash > > > > <primitive: 75> > > self primitiveFailed > > > > both messages are implemented :( > > > > > > 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 ;) > > > > > > That's all the feedback so far. It helped me to find some things to improve so thanks! > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com > > <PharoDebug.log>

April 23, 2012

Re: [Pharo-project] completion lets some traces

by StÃ©phane Ducasse

On Apr 23, 2012, at 10:27 AM, Esteban Lorenzano wrote: > with ECompletion? > No, I'm not having a fade out (I do have it with OCompletion, but that's the intended behavior) I will show you because with me it is blurry and looks like a bug. > > Esteban > > On Apr 22, 2012, at 10:44 PM, StÃ©phane Ducasse wrote: > >> Esteban >> >> don't you have the same problem than me with ecompletion? >> I get a slow vanishing of propositions. >> >> Stef >> > >

April 23, 2012

[Pharo-project] Example Redline Smalltalk WEB app ...

by James Ladd

import: 'st.redline.stout.Stout'. Stout < #Web. - initialize super initialize. self get: '/' do: [ 'Hello World from Smalltalk Web' ].

April 23, 2012

Re: [Pharo-project] ECompletion/Shout bug

by Esteban Lorenzano

he... is not related with the error, but... did you see this method? guessTypeOf: aNumber | range | self configureSelectorsOnly. recurseCount > 10 ifTrue: [ ^ nil ]. recurseCount := recurseCount + 1. range := ranges at: aNumber. ^ range isSelf ifTrue: [ theClass ] ifFalse: [ range isSuper ifTrue: [ theClass superclass ] ifFalse: [ range isConstant ifTrue: [ range asType ] ifFalse: [ range isArgument ifTrue: [ self guessArgument: range ] ifFalse: [ range isTemporaryVariable ifTrue: [ self guessTempVarClass: range ] ifFalse: [ range isInstanceVariable ifTrue: [ self guessInstVarClass: range ] ifFalse: [ range isClassVariable ifTrue: [ self guessClassVarClass: range ] ifFalse: [ range isGlobal ifTrue: [ self guessGlobal: aNumber ] ] ] ] ] ] ] ] when I was younger, at informatics school, they told me that "3 nested ifs means bad design, with no doubt"... what about 7? On Apr 23, 2012, at 10:30 AM, Esteban Lorenzano wrote: > yes, I can reproduce this one... taking care of it now :) > > On Apr 23, 2012, at 10:11 AM, StÃ©phane Ducasse wrote: > >> Note that the bug shows up if you edit the code in the result of the implementors. >> Esteban can you reproduce the bug? >> >> Stef >> >> On Apr 23, 2012, at 9:18 AM, StÃ©phane Ducasse wrote: >> >>> Hi >>> >>> I get a bug with OCompletion/Ecompletion >>> >>> TextEditor>>changeEmphasis >>> >>> try to type >>> >>> menuList nextPut: >>> >>> and you get a bug. >>> >>> Now in addition I do not understand what I see in the debugger: >>> >>> As you see model returns a debugger and the debugger title show FlatMessageListBrowser >>> >>> Stef >>> >>> >>> >>> <Screen Shot 2012-04-23 at 9.08.45 AM.pdf> >> >> >

April 23, 2012