December 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] displayingProgress on demand

by Sven Van Caekenberghe

If this would work, that would make many people happy ! It would be basically make tracking progress a no-cost option. > On 08 Dec 2015, at 10:29, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2015-12-08 10:16 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Wishfull thinking: > > you have a tradeoff when you do that, you interrupt running code and so changes timings and synchronisations, your scan takes time, and things below your sampling frequency are not visible. > > That being said, and if you take those factors into account, then your approach is sound. Just don't say it is a miracle solution. > > Yes, of course. I mean that such approach should not has so big impact on performance as direct announcing inside loop. Most time it will spend on updating/drawing progress bar. And it is not comparable to time which required to scan call chain. In most cases call chain has very small deep. And retrieving information about progress looks like trivial operation. Besides this analysing happens only when track process wake up. So It gives seconds to run code without interruption. > > I will try find code. But it was not ready to use solution. Just very little experiment for my UI framework Presenty. >

Dec. 8, 2015

Re: [Pharo-dev] displayingProgress on demand

by Thierry Goubier

2015-12-08 10:29 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2015-12-08 10:16 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> Wishfull thinking: >> >> you have a tradeoff when you do that, you interrupt running code and so >> changes timings and synchronisations, your scan takes time, and things >> below your sampling frequency are not visible. >> >> That being said, and if you take those factors into account, then your >> approach is sound. Just don't say it is a miracle solution. >> > > Yes, of course. I mean that such approach should not has so big impact on > performance as direct announcing inside loop. Most time it will spend on > updating/drawing progress bar. And it is not comparable to time which > required to scan call chain. In most cases call chain has very small deep. > And retrieving information about progress looks like trivial operation. > Besides this analysing happens only when track process wake up. So It gives > seconds to run code without interruption. > Hum you give interesting insights into it, like that the call chain isn't very deep. Good to know :) > > I will try find code. But it was not ready to use solution. Just very > little experiment for my UI framework Presenty. > It could be very nice to have for many long-running computations. I think the models used by Serge in SciSmalltalk / Kendrick? could benefit a lot from that. Thierry

Dec. 8, 2015

Re: [Pharo-dev] displayingProgress on demand

by Denis Kudriashov

2015-12-08 10:16 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Wishfull thinking: > > you have a tradeoff when you do that, you interrupt running code and so > changes timings and synchronisations, your scan takes time, and things > below your sampling frequency are not visible. > > That being said, and if you take those factors into account, then your > approach is sound. Just don't say it is a miracle solution. > Yes, of course. I mean that such approach should not has so big impact on performance as direct announcing inside loop. Most time it will spend on updating/drawing progress bar. And it is not comparable to time which required to scan call chain. In most cases call chain has very small deep. And retrieving information about progress looks like trivial operation. Besides this analysing happens only when track process wake up. So It gives seconds to run code without interruption. I will try find code. But it was not ready to use solution. Just very little experiment for my UI framework Presenty.

Dec. 8, 2015

Re: [Pharo-dev] displayingProgress on demand

by Thierry Goubier

Hi Denis, 2015-12-08 9:58 GMT+01:00 Denis Kudriashov <dionisiydk(a)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). > Do you have that code somewhere? I think it would be interesting to have a general framework for that (since this is a trace/profiling by sampling 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. > Wishfull thinking: you have a tradeoff when you do that, you interrupt running code and so changes timings and synchronisations, your scan takes time, and things below your sampling frequency are not visible. That being said, and if you take those factors into account, then your approach is sound. Just don't say it is a miracle solution. Regards, Thierry > Best regards, > Denis > > 2015-12-07 18:16 GMT+01:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com > >: > >> Hi Sven >> >> 2015-12-06 17:34 GMT-03:00 Sven Van Caekenberghe <sven(a)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(a)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 >>> >> >>> > >>> > >>> >>> >>> >> >

Dec. 8, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50489 Home: https://github.com/pharo-project/pharo-core

Dec. 8, 2015

[pharo-project/pharo-core] ea78f0: 50489

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: ea78f0947d533da23c0281e0c38640bdc042bb3c https://github.com/pharo-project/pharo-core/commit/ea78f0947d533da23c0281e0… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-12-08 (Tue, 08 Dec 2015) Changed paths: A NECompletion-Tests.package/NECContextTest.class/instance/tests/testReceiverTempVar3.st M NECompletion.package/NECContext.class/instance/private/findSourceRangeFor_.st M Nautilus.package/NautilusUI.class/instance/source code area/compileSource_notifying_.st R Polymorph-Widgets.package/TextHighlight.class/README.md R Polymorph-Widgets.package/TextHighlight.class/class/as yet unclassified/on_.st R Polymorph-Widgets.package/TextHighlight.class/definition.st R Polymorph-Widgets.package/TextHighlight.class/instance/accessing/borderColor.st R Polymorph-Widgets.package/TextHighlight.class/instance/accessing/borderColor_.st R Polymorph-Widgets.package/TextHighlight.class/instance/accessing/borderSides.st R Polymorph-Widgets.package/TextHighlight.class/instance/accessing/borderSides_.st R Polymorph-Widgets.package/TextHighlight.class/instance/accessing/borderWidth.st R Polymorph-Widgets.package/TextHighlight.class/instance/accessing/borderWidth_.st R Polymorph-Widgets.package/TextHighlight.class/instance/accessing/color.st R Polymorph-Widgets.package/TextHighlight.class/instance/accessing/color_.st R Polymorph-Widgets.package/TextHighlight.class/instance/accessing/fillWidth.st R Polymorph-Widgets.package/TextHighlight.class/instance/accessing/fillWidth_.st R Polymorph-Widgets.package/TextHighlight.class/instance/accessing/lineNumber.st R Polymorph-Widgets.package/TextHighlight.class/instance/accessing/lineRange.st R Polymorph-Widgets.package/TextHighlight.class/instance/accessing/lineRange_.st R Polymorph-Widgets.package/TextHighlight.class/instance/accessing/textMorph.st R Polymorph-Widgets.package/TextHighlight.class/instance/accessing/textMorph_.st R Polymorph-Widgets.package/TextHighlight.class/instance/draw/drawOn_in_offset_.st R Polymorph-Widgets.package/TextHighlight.class/instance/event/clicked_.st R Polymorph-Widgets.package/TextHighlight.class/instance/initialization/initialize.st R Polymorph-Widgets.package/TextHighlight.class/instance/private/newLineHighlight.st R Polymorph-Widgets.package/TextHighlight.class/instance/private/setLineHighLights.st R Polymorph-Widgets.package/TextHighlight.class/instance/testing/containsPoint_in_.st R Polymorph-Widgets.package/extension/PluggableTextMorph/instance/addHighlightFrom_to_color_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50488.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50489.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50488.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50489.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50489 17209 NEC wrong type guessing https://pharo.fogbugz.com/f/cases/17209 10312 TextHighlightByBounds and TextHighlight are near duplicated classes https://pharo.fogbugz.com/f/cases/10312 17205 DNU when accepting an empty string https://pharo.fogbugz.com/f/cases/17205 http://files.pharo.org/image/50/50489.zip

Dec. 8, 2015

Re: [Pharo-dev] displayingProgress on demand

by Denis Kudriashov

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.morales(a)gmail.com>: > Hi Sven > > 2015-12-06 17:34 GMT-03:00 Sven Van Caekenberghe <sven(a)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(a)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 >> >> >> > >> > >> >> >> >

Dec. 8, 2015

Re: [Pharo-dev] [Pharo5] integration of FastTable needed

by Ferlicot D. Cyril

Le 08/12/2015 08:47, Marcus Denker a Ã©crit : > Hi, > > FastTable recently has seen some important fixes. > > We are seeing people reporting the issues that are fixed again as they are only fixed > in the repository, but these changes are not yet in Pharo5. > > Can the maintainer do a sync? > > In general, these âexternallyâ managed project should sync back once per week if there > are changesâ¦ > > Marcus > I will take a look at all the modifications and push a new config this week. -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Dec. 8, 2015

Re: [Pharo-dev] License agreement - are you kidding me?

by phil＠highoctane.be

On Tue, Dec 8, 2015 at 12:47 AM, webwarrior <reg(a)webwarrior.ws> wrote: > Considering that there are a couple of responses and the fact that you > guys are so easily offended, I will not answer everyone but just state > couple of theses. > > > 0. I will not reveal my real name, because I value privacy. Nickname is > sufficient for identification purposes. Any other information (real > name, address, etc.) is not needed for actually contributing code. Think > of principle of least privilege. > > 1. I could easily make up some human-looking name (Satoshi Nakamoto > anyone?), but will not do it out of principle (see #0). > > 2. Knowing contributor's "real" name would not guard you against any > possible malicious actions from him, because it can't be verified (see > #1). One can also make up address, and even signature, if needed, and I > bet no one would spot it. > > 3. I don't buy argument about requirements of some organizations. Linux > kernel is used in billions of devices and by countless organizations, > and I highly doubt that contributing to Linux requires anything like > singing an agreement or whatever. > You'd be surprised. > > 4. Even in paid services checking a checkbox is usually sufficient for > accepting any license/ToS. > 5. My intentions are mostly of pragmatic nature. To make things that I > use (and that can be useful to Pharo users) be in upstream. > > 6. I don't care whether you drink beer, your political views, or your > interpersonal relationships (however story with Benjamin shows that > perhaps everything's not as great as you paint it). These are all > irrelevant to Pharo development, from my point of view at least. > > 7. If you don't agree with my arguments and stick to your rules, go for > it. I'm in no position to tell you what's the right thing to do. I'll > just end this discussion and leave. > Farewell then. Phil > > ------------------------------ > View this message in context: Re: License agreement - are you kidding me? > <http://forum.world.st/License-agreement-are-you-kidding-me-tp4865853p486591…> > Sent from the Pharo Smalltalk Developers mailing list archive > <http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html> at > Nabble.com. >

Dec. 8, 2015

[Pharo5] integration of FastTable needed

by Marcus Denker

Hi, FastTable recently has seen some important fixes. We are seeing people reporting the issues that are fixed again as they are only fixed in the repository, but these changes are not yet in Pharo5. Can the maintainer do a sync? In general, these âexternallyâ managed project should sync back once per week if there are changesâ¦ Marcus

Dec. 8, 2015