Re: [Pharo-dev] displayingProgress on demand

Dec. 8, 2015

      Hi Henrik

I checked, thank you for sharing an elegant approach (although my issue
with automatic code transformation remains).

May you comment why you implemented another progress bar?
Does support stacked progress bars?
Do you plan to add labels?

HernÃ¡n

2015-12-07 21:04 GMT-03:00 Henrik Nergaard <henrin10@student.uia.no>:
...
Here is my take on it.
http://smalltalkhub.com/#!/~Latsabben/GafletFremgangFremviser
Best regards,
Henrik
*From:* Pharo-dev [mailto:pharo-dev-bounces@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.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