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