I found code. It was work only in my test where I show progress of "(1 to:
1000) do: [:i | 1 seconds wait]".
stack := executionProcess suspendedContext stack reversed.
progressContext := stack detect: [:each | each receiver isKindOf:
SequenceableCollection] ifNone: [nil].
progressContext ifNil: [^self].
info := progressContext progressInfo.
"And here you can show progress as "
info currentPosition asString, '/', info endPosition asString.
Context>>progressInfo
^self receiver fetchProgressInfoFrom: self
Interval>>fetchProgressInfoFrom: aContext
^PtyProgressInfo currentPosition: (aContext tempAt: 3) end: self size
2015-12-08 9:58 GMT+01:00 Denis Kudriashov <dionisi...@gmail.com>:
> Few years ago I try another approach which was work in my test.
>
> Instead of code rewriting to make loop iteration announcing steps you can
> track periodically (in background) process which progress you want to
> report. You can scan full call stack of it suspended context for loops and
> analyse it progress variables (index and bounds). You can provide required
> meta information to find exact places you want (like you doing with your
> rewriting approach).
> Plus of my approach that it is not touch runnable code which not required
> progress reporting. And it should not influence performance of target
> process.
>
> Best regards,
> Denis
>
> 2015-12-07 18:16 GMT+01:00 Hernán Morales Durand <hernan.mora...@gmail.com
> >:
>
>> Hi Sven
>>
>> 2015-12-06 17:34 GMT-03:00 Sven Van Caekenberghe <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.
>>
>>
>>
>>> 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 <steph...@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
>>> >>
>>> >
>>> >
>>>
>>>
>>>
>>
>
