July 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] About nextPutAll: $(

by stepharo

Probably that the gain is not enough. This is just annoying to not have surrounding. Le 27/7/15 18:20, Peter UhnÃ¡k a Ã©crit : > > is performance so critical that using $( rather than '(' > gains a lo > > There's visual gain that I've mentioned. If you replace $( with '(' > then my argument about visibility fails. $( is very distinct. > > Maybe it is also a useful pattern for markup languages: > > aStream between: '<HEAD>' and: '</HEAD>' putAll: [ > ... nextLevelIn ... ]. > > > I don't think it's a good practice to generate individual tags by > hand, you should have more abstraction. > > Pillar has > > PRHTMLTag>>with: aString > stream << $> << aString << '</' << name << $> > > Apart from it being hard to read due to </> it's so simple that it > doesn't matter and you have little to no gain in trying to make it > "nicer". > > Peter >

July 27, 2015

Re: [Pharo-dev] about quality assistant

by stepharo

>>> Then again, skip works as former âfalse positiveâ. But in my opinion >>> âfalse positiveâ is not a good name from the logical point of view. >>> You have a rule that detects if you have no #yourself message in the >>> end of a cascade. Now do people really mark this as âfalse positiveâ >>> if the rule detects cascades that have #yourself message in the end? >>> Or they do it if they donât want to see the critic? Then itâs not >>> false positive, then they just want to hide or âskipâ the rule. >> Sorry but I do not understand your argument. >> For me this is simple: >> the rule tells me something is wrong and it is not. >> -> so I mark it as false positive. > > One more use case: at the moment most of âuselessâ reports has > the RBClassNotReferencedRule. If you have a class that is not > referenced and it is reported by the rule, it is definitely not a > false positive. But never the less, maybe you want to ban it, because > the class is a configuration (or something similar). So maybe it makes > sense to leave only a single âbanâ option, and then allow user to > provide a detail about the ban (whether it was a false positive, or > user simply does not care). I see Ban = do not report it again. Do not show it as a problem. You can call it: "not a problem" > > Yuriy > >> >>> This is fun part from statistics to name things as false positives. >>> But if we program a rule in such way, that it is fuzzy, I think that >>> itâs not correct to call it as false positive. Maybe itâs critics >>> are useless more times that they are helpful, and if the critic is >>> correct, the issue is not that important. Then probably we should >>> just remove the rule or rewrite it. >>> >>> Now with useless button, the only reason is to collect data on which >>> rules are actually useless to people [1], so we can take a look at >>> them in a first place. It doest not affect the functionality. >> >> I do not like useless. Because it is too violent and unclear. >> Please again have a look at the vocabulary used in the CodeCritics >> and the chapter that describes it. >> Or you should fix everything but we should not have two different >> vocabularies. >> There is enough confusing terms in Pharo so that we do not add more. >> >> Stef >> >> >>> >>> Uko >>> >>> [1]: http://renraku.inf.usi.ch/rules >>> >>> >>>> >>>> Stef >>>> >>>>> >>>>> Uko >>>>> >>>>>> On 23 Jul 2015, at 22:29, stepharo <stepharo(a)free.fr >>>>>> <mailto:stepharo@free.fr>> wrote: >>>>>> >>>>>> HI yuriy >>>>>> >>>>>> it would be good that quality assistant uses the same vocabulary >>>>>> than codecritics. >>>>>> for example >>>>>> skip -> ban? >>>>>> marks as false positif? >>>>>> >>>>>> Stef >>>>>> >>>>> >>>>> >>>> >>>> >>> >> >

July 27, 2015

Re: [Pharo-dev] about quality assistant

by stepharo

I do not like useless. Because it is too violent and unclear. >> +1 on this. >> >> For example, in the class RTRoassalExample, there are many methods. Too much for the quality assistant. Finally, I did not press âuselessâ because I still think this is a useful rule, but not for that class. > This is sad, and shows that I completely failed with that button. Yes This is not clear that this is a button about feedback > Because ideally you had to press it so I can know that this rule had a useful case for somebody > > Uko > >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > >

July 27, 2015

Re: [Pharo-dev] about quality assistant

by stepharo

> How is it different from false positive on a method or a class. Please > do not misunderstand me, but this is a part of story telling. This is the same. We should be able to say: this rule is in general correct but for this specific case (method, class, package) it is not correct (false positive) > If you donât want to see a critic (of a class or a method), you mark > it as false positive. I do not understand "don't want to see a critic" I do not want to get reminded that I should take action to address a quality problem when I know that there is none. > Now you can also ban rule on the level of a class or package, so you > will not see the critics about it. Exact. There is an overlap between ban a rule at package level and marking it as a false positive. Banning is do not check false positive is I run it and I tell you that it is wrong. So people have to decide what they want. > For me this two stories are intersecting. Why not simply say: âIf you > donât want to see this critic anymore (for any reason), then you can > ban it on the level of method, class, tag, package, or whole systemâ. > This way the story is simpler. We could but we lose a granularity. When I ban a rule I do not want to run it. While a false positive could be reevaluated if I change me code we could have a button that say rerun false positives. >>> Then again, skip works as former âfalse positiveâ. But in my opinion >>> âfalse positiveâ is not a good name from the logical point of view. >>> You have a rule that detects if you have no #yourself message in the >>> end of a cascade. Now do people really mark this as âfalse positiveâ >>> if the rule detects cascades that have #yourself message in the end? >>> Or they do it if they donât want to see the critic? Then itâs not >>> false positive, then they just want to hide or âskipâ the rule. >> Sorry but I do not understand your argument. >> For me this is simple: >> the rule tells me something is wrong and it is not. >> -> so I mark it as false positive. >> >>> This is fun part from statistics to name things as false positives. >>> But if we program a rule in such way, that it is fuzzy, I think that >>> itâs not correct to call it as false positive. Maybe itâs critics >>> are useless more times that they are helpful, and if the critic is >>> correct, the issue is not that important. Then probably we should >>> just remove the rule or rewrite it. >>> >>> Now with useless button, the only reason is to collect data on which >>> rules are actually useless to people [1], so we can take a look at >>> them in a first place. It doest not affect the functionality. >> >> I do not like useless. Because it is too violent and unclear. >> Please again have a look at the vocabulary used in the CodeCritics >> and the chapter that describes it. >> Or you should fix everything but we should not have two different >> vocabularies. >> There is enough confusing terms in Pharo so that we do not add more. > > I understand. I will re-read the vocabulary and fix discrepancies. But > please read my argument bout duplicated behavior of banking and > marking as false positive, I think that it may be confusing. I'm not against your arguments I do not understand them. > > Also âUseless" button does not do anything besides sending me an > information that this critic was useless to somebody. Ideally there > should be no button like this and I should be able to collect user > actions that they perform. So far I do not understand skip and useless difference. Now I get it. There are two different action. One is about feedback and the other is banning/ > But from server/privacy/time perspective it was easier for me to make > a simple button. Would be nice to have an advanced data collection, > but I am not sure that I will have time now to program all that, so if > it is bothering so much, I can simply remove it. In fact by crawling the metadata of package we can see if a rule is useless: people will ban it. > > Uko > >> >> Stef >> >> >>> >>> Uko >>> >>> [1]: http://renraku.inf.usi.ch/rules >>> >>> >>>> >>>> Stef >>>> >>>>> >>>>> Uko >>>>> >>>>>> On 23 Jul 2015, at 22:29, stepharo <stepharo(a)free.fr >>>>>> <mailto:stepharo@free.fr>> wrote: >>>>>> >>>>>> HI yuriy >>>>>> >>>>>> it would be good that quality assistant uses the same vocabulary >>>>>> than codecritics. >>>>>> for example >>>>>> skip -> ban? >>>>>> marks as false positif? >>>>>> >>>>>> Stef >>>>>> >>>>> >>>>> >>>> >>>> >>> >> >

July 27, 2015

Re: [Pharo-dev] Event handling insanity

by Thierry Goubier

Le 27/07/2015 15:42, Igor Stasenko a Ã©crit : > Nothing here is about things to fix, > but rather about how impossible to debug event handling in system that > runs and relies on very same events.. Esay Igor, just use a code event tracer as for example Jejak, and all you describe below won't happen. Or an event logger, or metalinks, or anything. I don't understand. You have the tools, why don't you use them? Thierry > I had very annoying problem with mouse move handling and processing it > correctly, and i finally solved the problem after number of attempts to > track down where problem lies in.. > > So, here is small list of problems i faced: > > - broken image (image won't start up) , because i send unimplemented > message in critical place, thus image simply non-responsible/crashing > immediately after startup. Easy to fix (sarcasm) > > - debugger window spam on every event (because of DNU/other exception). > A slightly friendlier problem than above :) > > - and last one, if you break some event handling/delivery, even if image > "behaves" you simply left without events doing what is needed, means you > got another form of a broken image, which you cannot use anymore and > need to start over and revert the changes you made. > > - veeeerrrrryyy slow event handling, because of printing every event > into transcript , trying to see where the shit lies. > > - decrypting kilometers long event traces to see what goes where > > But when things finally start work properly, you feel excited :) > > -- > Best regards, > Igor Stasenko.

July 27, 2015

Re: [Pharo-dev] about quality assistant

by Yuriy Tymchuk

> On 27 Jul 2015, at 18:11, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Would be nice to have an advanced data collection, but I am not sure that I will have time now to program all that > > There is already data collection for spotter and there was chatter about making the collection tool more generic, but I don't think any progress is on that. > > So what exactly is "Useless" for? If there was some input box where I could describe why I think its useless in that particular context or whateverâ¦ Yes, there should be an input box, it will be aded there as soon as Iâm done with other issues and the button remains. > > However I have question about two more cases, not sure if even possible to implement > > case 1: > ~~~~~~~~~~~~~~~~~~~~~~~~ > beFinal > self isFinal: true > ~~~~~~~~~~~~~~~~~~~~~~~~ > "Unary "accessing" method without explicit return" > > #beSomething is quite common pattern (even recommended in Kent's Best Practice Patterns), maybe it should check for name 'be'<Uppercase> before applying the critic? This is a good proposal. Would be nice to hear other opinions. Maybe we can open an issue on the bug tracker so people can comment. > > > case 2: > in Roassal it's very common to create a shape but return an element > ~~~~~~~~~~~~~~~~~~~~~~~~ > RTEllipse new > size: 14; > color: Color black; > element > ~~~~~~~~~~~~~~~~~~~~~~~~ > or > ~~~~~~~~~~~~~~~~~~~~~~~~ > RTBox new > elementOn: aModel > ~~~~~~~~~~~~~~~~~~~~~~~~ > > but of course it complains about missing ";yourself". > > However I do not really want to ban the critic, because there may other legitimate applications in the method/class; and in Roassal-heavy code it's a nuisance. > So it would require context-aware checks (probably user-defined?) like "if receiver is subclass of RTShape then don't apply this (yourself) ruleâ. Yes, itâs a very good point. It is in my plans to see how we can allow frameworks to provide their own critics and interact/override the default ones. For now all I can suggest is to ban the critic on the level of the class, or if we will reach the common sense there can be a ban on the level of package tag, so you can keep all the roassal-related classes in one tag and ban the rule for them. Uko > > Cheers, > Peter > > >

July 27, 2015

Re: [Pharo-dev] about quality assistant

by Yuriy Tymchuk

> On 26 Jul 2015, at 10:55, stepharo <stepharo(a)free.fr> wrote: > > >>> I prefer >>> ban this rule = do not run it >>> false positive = rule is ok but wrong here >> >> Do you mean ban rule completely? On which level? For a developer (machine)? > > in the codecritcis the scope is clear. > On a class or a package. > >> Then again, skip works as former âfalse positiveâ. But in my opinion âfalse positiveâ is not a good name from the logical point of view. You have a rule that detects if you have no #yourself message in the end of a cascade. Now do people really mark this as âfalse positiveâ if the rule detects cascades that have #yourself message in the end? Or they do it if they donât want to see the critic? Then itâs not false positive, then they just want to hide or âskipâ the rule. > Sorry but I do not understand your argument. > For me this is simple: > the rule tells me something is wrong and it is not. > -> so I mark it as false positive. One more use case: at the moment most of âuselessâ reports has the RBClassNotReferencedRule. If you have a class that is not referenced and it is reported by the rule, it is definitely not a false positive. But never the less, maybe you want to ban it, because the class is a configuration (or something similar). So maybe it makes sense to leave only a single âbanâ option, and then allow user to provide a detail about the ban (whether it was a false positive, or user simply does not care). Yuriy > >> This is fun part from statistics to name things as false positives. But if we program a rule in such way, that it is fuzzy, I think that itâs not correct to call it as false positive. Maybe itâs critics are useless more times that they are helpful, and if the critic is correct, the issue is not that important. Then probably we should just remove the rule or rewrite it. >> >> Now with useless button, the only reason is to collect data on which rules are actually useless to people [1], so we can take a look at them in a first place. It doest not affect the functionality. > > I do not like useless. Because it is too violent and unclear. > Please again have a look at the vocabulary used in the CodeCritics and the chapter that describes it. > Or you should fix everything but we should not have two different vocabularies. > There is enough confusing terms in Pharo so that we do not add more. > > Stef > > >> >> Uko >> >> [1]: http://renraku.inf.usi.ch/rules <http://renraku.inf.usi.ch/rules> >> >> >>> >>> Stef >>> >>>> >>>> Uko >>>> >>>>> On 23 Jul 2015, at 22:29, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: >>>>> >>>>> HI yuriy >>>>> >>>>> it would be good that quality assistant uses the same vocabulary than codecritics. >>>>> for example >>>>> skip -> ban? >>>>> marks as false positif? >>>>> >>>>> Stef >>>>> >>>> >>>> >>> >>> >> >

July 27, 2015

Re: [Pharo-dev] Event handling insanity

by Chris Muller

On Mon, Jul 27, 2015 at 8:42 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Nothing here is about things to fix, > but rather about how impossible to debug event handling in system that runs > and relies on very same events.. > I had very annoying problem with mouse move handling and processing it > correctly, and i finally solved the problem after number of attempts to > track down where problem lies in.. > > So, here is small list of problems i faced: > > - broken image (image won't start up) , because i send unimplemented > message in critical place, thus image simply non-responsible/crashing > immediately after startup. Easy to fix (sarcasm) > > - debugger window spam on every event (because of DNU/other exception). > A slightly friendlier problem than above :) > > - and last one, if you break some event handling/delivery, even if image > "behaves" you simply left without events doing what is needed, means you got > another form of a broken image, which you cannot use anymore and need to > start over and revert the changes you made. > > - veeeerrrrryyy slow event handling, because of printing every event into > transcript , trying to see where the shit lies. Instead of printing them to Transcript, add the Events to a global OrderedCollection. Extremely fast and now you can even instrospect them. > - decrypting kilometers long event traces to see what goes where Filter what goes in and/or trim your global collection.

July 27, 2015

Re: [Pharo-dev] About nextPutAll: $(

by Peter UhnÃ¡k

> > is performance so critical that using $( rather than '(' > gains a lot? There's visual gain that I've mentioned. If you replace $( with '(' then my argument about visibility fails. $( is very distinct. > Maybe it is also a useful pattern for markup languages: > > aStream between: '<HEAD>' and: '</HEAD>' putAll: [ > ... nextLevelIn ... ]. > I don't think it's a good practice to generate individual tags by hand, you should have more abstraction. Pillar has PRHTMLTag>>with: aString stream << $> << aString << '</' << name << $> Apart from it being hard to read due to </> it's so simple that it doesn't matter and you have little to no gain in trying to make it "nicer". Peter

July 27, 2015

Re: [Pharo-dev] about quality assistant

by Peter UhnÃ¡k

> > Would be nice to have an advanced data collection, but I am not sure that > I will have time now to program all that There is already data collection for spotter and there was chatter about making the collection tool more generic, but I don't think any progress is on that. So what exactly is "Useless" for? If there was some input box where I could describe why I think its useless in that particular context or whatever... However I have question about two more cases, not sure if even possible to implement case 1: ~~~~~~~~~~~~~~~~~~~~~~~~ beFinal self isFinal: true ~~~~~~~~~~~~~~~~~~~~~~~~ "Unary "accessing" method without explicit return" #beSomething is quite common pattern (even recommended in Kent's Best Practice Patterns), maybe it should check for name 'be'<Uppercase> before applying the critic? case 2: in Roassal it's very common to create a shape but return an element ~~~~~~~~~~~~~~~~~~~~~~~~ RTEllipse new size: 14; color: Color black; element ~~~~~~~~~~~~~~~~~~~~~~~~ or ~~~~~~~~~~~~~~~~~~~~~~~~ RTBox new elementOn: aModel ~~~~~~~~~~~~~~~~~~~~~~~~ but of course it complains about missing ";yourself". However I do not really want to ban the critic, because there may other legitimate applications in the method/class; and in Roassal-heavy code it's a nuisance. So it would require context-aware checks (probably user-defined?) like "if receiver is subclass of RTShape then don't apply this (yourself) rule". Cheers, Peter

July 27, 2015