Here is my take on it. http://smalltalkhub.com/#!/~Latsabben/GafletFremgangFremviser
Best regards, Henrik From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Hernán Morales Durand Sent: Tuesday, December 8, 2015 12:28 AM To: Pharo Development List <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] displayingProgress on demand Hi Thierry 2015-12-07 14:43 GMT-03:00 Thierry Goubier <thierry.goub...@gmail.com<mailto:thierry.goub...@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 <s...@stfx.eu<mailto:s...@stfx.eu> <mailto:s...@stfx.eu<mailto:s...@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
