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 >>> >> >>> > >>> > >>> >>> >>> >> >