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:

Regards,

Hern��n