Hi Sven

2015-12-06 17:34 GMT-03:00 Sven Van Caekenberghe <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.

��

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.

If you look at how HTTPProgress is implemented/used, as a Notification, that might be a part of a solution, but I would not want to pay that performance price in the general API.

Sure.

��

I think there is no 'free' or 'easy' solution.

Absolutely, this is not an easy problem. It would be cool anyone with enough Java experience can comment how they apply this kind of transformations.

Hern��n

��

> On 06 Dec 2015, at 21:23, stepharo <stepharo@free.fr> wrote:
>
> Probably because it was badly done.
>
>
> Le 6/12/15 20:05, Hern��n Morales Durand a ��crit :
>> Hello everyone,
>>
>> Is there a reason why #collect:displayingProgress: was removed or never included?
>>
>> And as more general question, is there any pointer to automatically add progress bar to iterator messages?
>>
>> For example doing:
>>
>> SmalltalkImage setDisplayProgressTo: MyClass.
>> SmalltalkImage setDisplayProgressTo: MyPackage.
>>
>> and then having all enumeration messages sent in MyClass or MyPackage with a progress bar
>>
>> collect:
>> collect:as:
>> collect:into:
>> collect:thenDo:
>> select:
>> select:as:
>> select:thenDo:
>> select:thenCollect:as:
>> ...
>>
>> Hern��n
>>
>
>