Hi To let you know finally I used the RewriteRuleBuilder http://myfuncoding.blogspot.cz/2015/02/video-presentation-of-rewrite-tool.ht... which generated the rule and installed the code (the only minor detail is that class methods are not browsed by the rule browser): [ : job | | index | index := 0. job title: 'Starting.'. ``@object1 collect: `@block1 thenDo: [ :fileEntry | index := index + 1. JobProgress progress: 0.1 * index; title: ' Procesing ' , index asString ] ] asJob run Cheers, Hernán 2015-12-07 20:27 GMT-03:00 Hernán Morales Durand <hernan.morales@gmail.com>:
Hi Thierry
2015-12-07 14:43 GMT-03:00 Thierry Goubier <thierry.goubier@gmail.com>:
Hi Hernán,
Le 07/12/2015 18:16, Hernán Morales Durand a écrit :
Hi Sven
2015-12-06 17:34 GMT-03:00 Sven Van Caekenberghe <sven@stfx.eu <mailto:sven@stfx.eu>>:
There is still #do:displayingProgress:
There is Job.
In general, the collection API should not be concerned with GUI matters, does it ?
Believe me when you're executing a large workflow processing 50Gb files with 5 other people expecting feedback from the screen, the least of your concerns is the purity of collection API. I don't know what other coders do, kick your co-workers off the room? Sit to see a blank Pharo screen? To me the key is to have feedback from the system without having to change your 20 iterators in a group of client classes where you NEED to see progress.
Anyway I agree with you Collection should not have GUI dependencies, that's the reason I took a different approach and that's why I asked with an expression like:
SmalltalkImage setDisplayProgressTo: MyClass.
with such kind of expression you never touch the Collection API. You just walk MyClass for every enumeration messsage send (of your interest) and perform a transformation. Note the same "technique" could be applied for logging and/or profiling.
Yes. The Jejak tracer uses a similar technique. I'd guess others do as well.
Will have a look to Jejak, thanks.
We can't have equivalents of all collection methods for displaying
progress, nor can it be a (semi-) global setting.
Sure, that would be the anti-object technology :)
So I implemented a prototype which injects JobProgress code in methods using RBParseSearchTree. On uninstall I plan to recover the previous version of marked methods. No need to touch the Collection API at all, nor a setting. I am sure the same could be done with MethodWrappers but RB can manipulate AST nodes.
However if there is a better idea I would love to hear about it.
Could you put your RBParseTreeRewriter scripts somewhere? I'm interested.
Ok for the first part create a FooClass>>foo: method
foo: aString
aString asFileReference entries collect: [ : fileEntry | self openOnFileNamed: fileEntry fullName ]
this one injects a node inside the Job block:
http://ws.stfx.eu/5H7LNMMLIXEX
For the next one, first add
RBSequenceNode>>addNode: aNode after: anotherNode | index | index := self indexOfNode: anotherNode. index = 0 ifTrue: [ ^ self addNode: aNode ]. statements := statements asOrderedCollection add: aNode afterIndex: index; yourself. aNode parent: self. ^ aNode
but now I am failing to see how to replace #collect: with #collect:thenDo: using the rewriter:
http://ws.stfx.eu/MOWS947F000O
Regards,
Hernán