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

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

by Max Leske

> On 24 Jul 2015, at 22:48, stepharo <stepharo(a)free.fr> wrote: > > HI > > while working on a lecture I saw that we have about 75 cases like: > > aStream nextPut: $(. > .... > aStream nextPut: $). > > > > storeOn: aStream > "Store a description of the elements of the complement rather than self." > > aStream nextPut: $(. > absent storeOn: aStream. > aStream nextPut: $); space; nextPutAll: #complement. > > > printElementsOn: aStream > aStream nextPut: $(. > self size > 100 > ifTrue: [aStream nextPutAll: 'size '. > self size printOn: aStream] > ifFalse: [self keysSortedSafely > do: [:key | aStream print: key; > nextPutAll: '->'; > print: (self at: key); > space]]. > aStream nextPut: $) > > we have surroundedBy: aString > > surroundedBy: aString > ^ self class streamContents: [ :s| > s nextPutAll: aString. > s nextPutAll: self. > s nextPutAll: aString ]. > > But only working on aString. > To me it looks like it ia class for having it on stream. > > What do you think? > Iâm not sure about #surroundedBy:, but I would definitely vote for a nicer way of doing that, yes.

July 25, 2015

Re: [Pharo-dev] Roassal CI

by stepharo

I can do it. Alex is it ok? Stef Le 24/7/15 22:47, Torsten Bergmann a Ã©crit : > +1 > > > > > stepharo <stepharo(a)free.fr>schrieb: > > In that case we should remove the contribution one. > > > Le 23/7/15 19:29, Tudor Girba a Ã©crit : > > The main Roassal2 on Pharo 5 job is here: > > https://ci.inria.fr/moose/job/roassal2/ > > Doru > > On Thu, Jul 23, 2015 at 7:27 PM, Torsten > Bergmann<astares(a)gmx.de <mailto:astares@gmx.de>> wrote: > > https://ci.inria.fr/pharo-contribution/job/Roassal/ > > only has a Pharo 20 and 30 version. > > What about 40 and 50? > > Thanks > T. > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow" > >

July 25, 2015

About nextPutAll: $(

by stepharo

HI while working on a lecture I saw that we have about 75 cases like: aStream nextPut: $(. .... aStream nextPut: $). storeOn: aStream "Store a description of the elements of the complement rather than self." aStream nextPut: $(. absent storeOn: aStream. aStream nextPut: $); space; nextPutAll: #complement. printElementsOn: aStream aStream nextPut: $(. self size > 100 ifTrue: [aStream nextPutAll: 'size '. self size printOn: aStream] ifFalse: [self keysSortedSafely do: [:key | aStream print: key; nextPutAll: '->'; print: (self at: key); space]]. aStream nextPut: $) we have surroundedBy: aString surroundedBy: aString ^ self class streamContents: [ :s| s nextPutAll: aString. s nextPutAll: self. s nextPutAll: aString ]. But only working on aString. To me it looks like it ia class for having it on stream. What do you think?

July 24, 2015

Re: [Pharo-dev] Roassal CI

by Torsten Bergmann

July 24, 2015

Re: [Pharo-dev] Roassal CI

by stepharo

In that case we should remove the contribution one. Le 23/7/15 19:29, Tudor Girba a Ã©crit : > The main Roassal2 on Pharo 5 job is here: > > https://ci.inria.fr/moose/job/roassal2/ > > Doru > > On Thu, Jul 23, 2015 at 7:27 PM, Torsten Bergmann <astares(a)gmx.de > <mailto:astares@gmx.de>> wrote: > > https://ci.inria.fr/pharo-contribution/job/Roassal/ > > only has a Pharo 20 and 30 version. > > What about 40 and 50? > > Thanks > T. > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

July 24, 2015

Re: [Pharo-dev] [Reflectivity] ... and Roassal

by Sven Van Caekenberghe

Very nice. Yes, interactive visualisation tools raise the level of abstraction beyond the status quo. > On 24 Jul 2015, at 09:53, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Exactly! > > This is what happens when all these tools are readily available in the IDE during development. > > It's often hard to understand the power of these seemingly small things, until you experience their impact on your own problem. > > Cheers, > Doru > > > > On Fri, Jul 24, 2015 at 8:57 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > Yesterday Alex and me played with using Roassal in combination with reflectivity. > > Very quickly (within half an hour, even shorter) we had a view per class that shows coverage for ASTs as trees > like this: > > > <coverage.png> > > > this is > > | t | > t := false. > t ifTrue: [ self bar ] ifFalse: [ 'hello' ]. > ^ 5 > > > and you directly see that I have not yet added support for annotating optimized blocksâ¦ will come soon. > (These views are nice for debugging reflectivityâ¦) > > > The code: > > 1) node-by-node coverage: > > getCoverageOf: aPharoClass whileExecuting: aBlock > " > self new getCoverageOf: CoverageDemoTest whileExecuting: [ CoverageDemoTest new simpleAst ] > " > > | link | > link := MetaLink new > metaObject: #node; > selector: #tagExecuted. > aPharoClass methods do: [ :cm | cm ast nodesDo: [ :node | node link: link ] ]. > aBlock value. > ^ aPharoClass > > > and the code for visalization: > > renderCoverage > | b | > b := RTMondrian new. > > b shape rectangle withTextAbove: #selector. > b nodes: self methods forEach: [ :aMethod | > b shape label > text: [ :astNode | > | aName | > aName := astNode class name copyFrom: 3 to: astNode class name size. > (aName endsWith: 'Node') > ifTrue: [ aName copyFrom: 1 to: aName size - 'Node' size ] > ifFalse: [ aName ] > ] ; > color: Color red; > if: #hasBeenExecuted color: Color green. > b nodes: aMethod ast allChildren. > b edges connectFrom: #parent. > b layout tree. > ]. > > b layout flow. > b build. > ^ b view > > > A second example shows often executed nodes larger (shows another bugâ¦ the one largest should have the same size as the other large ones): > > <executions.png> > > Code: > > > > renderNodeExecutions > | b | > b := RTMondrian new. > > b shape rectangle withTextAbove: #selector. > b nodes: self methods forEach: [ :aMethod | > b shape rectangle > size: [ :astNode | astNode propertyAt: #nbExecutions ifAbsent: [ 0 ] ]. > b nodes: aMethod ast allChildren. > b edges connectFrom: #parent. > b layout tree. > ]. > > b layout flow. > b build. > ^ b view > > > getNodeExecution: aPharoClass whileExecuting: aBlock > " > self new getNodeExecution: CoverageDemoTest whileExecuting: [ > 30 timesRepeat: [ CoverageDemoTest new simpleAst ] ] > " > > | link | > link := MetaLink new > metaObject: [ :node | > | v | > v := node propertyAt: #nbExecutions ifAbsentPut: [ 0 ]. > node propertyAt: #nbExecutions put: v + 1 ]; > selector: #value:; > arguments: #(#node). > aPharoClass methods do: [ :cm | cm ast nodesDo: [ :node | node link: link ] ]. > aBlock value. > ^ aPharoClass > > > These are just very quick and raw experimentsâ¦ but they got us excited about the possibilities when this is all > debugged and readyâ¦ > > Marcus > > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

July 24, 2015

Re: [Pharo-dev] about quality assistant

by Stephan Eggermont

When I say 'this is useless' I might be interested to explain why I think so. Stephan

July 24, 2015

Re: [Pharo-dev] about quality assistant

by stepharo

Le 23/7/15 23:49, Yuriy Tymchuk a Ã©crit : > HI, > > yes, ban may make sense. I think that âfalse positiveâ is a bit incorrect. For example, consider the âprobably missing yourselfâ rule. Even if you are not missing it, the rule is not wrong. It just warns you that you should be carful with this case, because it is easy to screw up something. Now even while this is not a false positive, you want to skip the rule for this method. > > That was the philosophy behind the name. I do not know. We discussed a lot in the past about this vocabulary and it would be good to have one. I do not understand the diff between this is useless and skip. I prefer ban this rule = do not run it false positive = rule is ok but wrong here Stef > > Uko > >> On 23 Jul 2015, at 22:29, stepharo <stepharo(a)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 24, 2015

Re: [Pharo-dev] [Reflectivity] ... and Roassal

by stepharo

This is super cool :) Stef Le 24/7/15 08:57, Marcus Denker a Ã©crit : > Hi, > > Yesterday Alex and me played with using Roassal in combination with > reflectivity. > > Very quickly (within half an hour, even shorter) we had a view per > class that shows coverage for ASTs as trees > like this: > > > > > this is > > | t | > t := false. > t ifTrue: [ self bar ] ifFalse: [ 'hello' ]. > ^ 5 > > > and you directly see that I have not yet added support for annotating > optimized blocksâ¦ will come soon. > (These views are nice for debugging reflectivityâ¦) > > > The code: > > 1) node-by-node coverage: > > getCoverageOf: aPharoClass whileExecuting: aBlock > " > self new getCoverageOf: CoverageDemoTest whileExecuting: [ > CoverageDemoTest new simpleAst ] > " > > | link | > link := MetaLink new > metaObject: #node; > selector: #tagExecuted. > aPharoClass methods do: [ :cm | cm ast nodesDo: [ :node | node link: > link ] ]. > aBlock value. > ^ aPharoClass > and the code for visalization: > > renderCoverage > | b | > b := RTMondrian new. > > b shape rectangle withTextAbove: #selector. > b nodes: self methods forEach: [ :aMethod | > b shape label > text: [ :astNode | > | aName | > aName := astNode class name copyFrom: 3 to: astNode class name size. > (aName endsWith: 'Node') > ifTrue: [ aName copyFrom: 1 to: aName size - 'Node' size ] > ifFalse: [ aName ] > ] ; > color: Color red; > if: #hasBeenExecuted color: Color green. > b nodes: aMethod ast allChildren. > b edges connectFrom: #parent. > b layout tree. > ]. > > b layout flow. > b build. > ^ b view > > > A second example shows often executed nodes larger (shows another bugâ¦ > the one largest should have the same size as the other large ones): > > > Code: > > > > renderNodeExecutions > | b | > b := RTMondrian new. > > b shape rectangle withTextAbove: #selector. > b nodes: self methods forEach: [ :aMethod | > b shape rectangle > size: [ :astNode | astNode propertyAt: #nbExecutions ifAbsent: [ 0 ] ]. > b nodes: aMethod ast allChildren. > b edges connectFrom: #parent. > b layout tree. > ]. > > b layout flow. > b build. > ^ b view > > > getNodeExecution: aPharoClass whileExecuting: aBlock > " > self new getNodeExecution: CoverageDemoTest whileExecuting: [ > 30 timesRepeat: [ CoverageDemoTest new simpleAst ] ] > " > > | link | > link := MetaLink new > metaObject: [ :node | > | v | > v := node propertyAt: #nbExecutions ifAbsentPut: [ 0 ]. > node propertyAt: #nbExecutions put: v + 1 ]; > selector: #value:; > arguments: #(#node). > aPharoClass methods do: [ :cm | cm ast nodesDo: [ :node | node link: > link ] ]. > aBlock value. > ^ aPharoClass > > > These are just very quick and raw experimentsâ¦ but they got us excited > about the possibilities when this is all > debugged and readyâ¦ > > Marcus > > >

July 24, 2015

Re: [Pharo-dev] Surprising auto-categorization behaviour

by stepharo

I should finish my new ones.... too much to finish :) Le 24/7/15 13:57, Marcus Denker a Ã©crit : >> On 24 Jul 2015, at 13:55, Stephan Eggermont <stephan(a)stack.nl> wrote: >> >> Morph>>justDroppedInto:event: is categorized as *Morphic-Base >> >> When writing a new Morph subclass, categorizing all uncategorized >> dirties Morphic-Base and might make you lose code. >> >> Do we really want auto-categorization to categorize as extension >> methods? >> > No! the auto-categorizer should ignore all *categories. > > Marcus > > >

July 24, 2015