September 2013 - Pharo-dev - lists.pharo.org

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=linu… 3 regressions found. Graphics.Tests.Primitives.ColorTest.testAsHTMLColor Graphics.Tests.Primitives.ColorTest.testColorFrom Graphics.Tests.Primitives.ColorTest.testFromString

Sept. 6, 2013

[update 3.0] #30374

by Marcus Denker

30374 ----- 11433 Move ClassVars in Color referring to named colors to a color cache https://pharo.fogbugz.com/f/cases/11433 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1240.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Text-Core-MarcusDenker.12.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Graphics-Primitives-MarcusDen…

Sept. 6, 2013

Re: [Pharo-dev] Should Job use SystemAnnouncer?

by Camillo Bruni

On 2013-09-06, at 04:52, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Sep 4, 2013, at 12:12 , Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> On 2013-09-03, at 18:57, Stephan Eggermont <stephan(a)stack.nl> wrote: >>> Camillo wrote: >>>> in this case it is only the instance of Job which knows the status. >>>> Thread-safeness is not an issue since the progress bar is pure approximation. >>> >>> The problem is not approximation. Objects are not reentrant, getting the value >>> out of a model while it is reorganizing its datastructure is likely to give interesting >>> and difficult to reproduce results (dividing by 0, nil-pointer exceptions). >>> >>>> that does not work properly and inaccurately reports long running jobs, for instance >>>> when running tests. Usually tests take far less than 1 ms, in which case this scheme >>>> works perfectly. However from time to time you have 1 test that runs for a couple of >>>> seconds. If you run 5000 tests you have to run quite a few tests to get that 1% update >>>> margin, so very often the UI does not correctly report the current status. >>> >>> That is not a solvable problem. A progress bar depends on a value increasing from >>> min to max. The model is responsible for making reasonable steps. >> >> ok, different question, how do you solve this very use-case without polling? >> >> >> 1. run test 1 [1ms] >> ..... >> N. run test N [1ms] >> ------------------------------------------- >> Progress Bar update limit reached after >> a) either N update calls >> b) N ms >> => next update will happen in >> a) N calls >> b) N ms >> ------------------------------------------- >> N+1. run test N+1 [1000 ms] >> >> That means that the UI shows the wrong value (run test N) instead of the current >> progress value (run test N+1), which is not interesting. >> The model, in this case the test runner, properly informed the UI about every change, >> but the update limitations in the ProgressBarMorph cannot properly detect such a case. >> - either you update way to often => performance overhead >> - or you update not often enough => inaccurate progress indication when progress step times differ a lot >> >> There is simply no way you can properly solve this case without active polling. > > Sure there is. (Assuming tests are run at lower-than GUI priority so it actually gets a chance to update without forced refresh directly from the code) > - Record the state of Job when it's announced. > - Check a boolean for whether a GUI update is already scheduled. > - If not, check the last update time > - If update interval since then has passed, send an invalidate to the GUI (with you as model, painting current value of the state last recorded in you), and record the new update time > - If less than interval, set the GUI update schedule boolean to true, fork of a process (at a higher-than-current priority) which waits for the remainder before doing the same as the none-delayed path, then resetting the GUI update boolean. ... which is 2 tmes more complicated than polling, but ok, it is possible

Sept. 6, 2013

[update 3.0] #30373

by Marcus Denker

30373 ----- 7097 Class Quadrangle only is used in Tests https://pharo.fogbugz.com/f/cases/7097 3829 Pangrams https://pharo.fogbugz.com/f/cases/3829/Pangrams Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/RPackage-Tests-MarcusDenker.1… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Graphics-Primitives-MarcusDen… http://smalltalkhub.com/mc/Pharo/Pharo30/main/FreeType-MarcusDenker.628.diff

Sept. 6, 2013

Re: [Pharo-dev] OSProcess for Pharo3.0

by Esteban Lorenzano

On Sep 6, 2013, at 9:33 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 05/09/2013 22:04, StÃ©phane Ducasse a Ã©crit : >>>>> >>>> >>>> Who says that? We always said that we will back-port all imported fixes to 2.0. We will not back-port *everything*, especially >>>> not improvements that are not fixes, because then there would be no difference between Pharo3 and Pharo2 (and these >>>> tend to introduce new problems, making it very hard to stabilize). >>> >>> Are you afraid that by improving Pharo2 on a production-level, you would remove incentives to move to pharo3? >> >> No just that we do not want to stop 3.0. Because changing 20 will introduce bug we are 100% convinced about that. >> The system is still not in a situation where changes are simple and with limited impact. > > As you said, 2.0 has bugs. Look, at one point, we even had a 2.5 in the works (who did it, already? Sean? Sven?). no, we don't bah, we have 2S, which would be the "2.5" if you want. Also Sean made something to install some new issues from 3 in the older version... but that's not a new version, is just that Sean wanted to have some things immediately :) > > >>>> But it is clear that this is a fine line: one persons fix is the others persons bug, so we tend to be conservative. >>>> But nevertheless, all show-stopping bugs should be fixed. >>> >>> I'm OK with that. It's just that I'm updating a fix for a bug on both Pharo2 and Pharo3 by myself just to be able to open a file browser and get correct file permissions. >>> >>> I'm also unable to be sympathetic to a situation where I have two versions of a code just because when deprecating ensureDeleted in 3.0, nobody thought usefull to backport ensureDelete so that we could ensure that code using ensureDelete could work on both versions. >> >> This is simple nobody told us. Open an issue and tag it 20 + code and it will be in the batch of 2.0. > > I'll do. > >>> I also understand that you need 3.0 to be declared unstable to be able to make the necessary improvements in it. >>> >>> But this has the following consequences for non-core development, say SmaCC for example: 2.0 is the platform for unstable, >> No it is not 2.0 is stable. We have production code with it. Now it is not bug free and 1.4 is far from bug free. It is just that you do not get >> touched by these bugs. >> >>> 1.4 is where your stuff is stable (2.0 if you're lucky), and 3.0 is don't develop until it has reached a sufficient level of maturity. >>> I will do things on SmaCC in the near future, but not on 3.0. >> >> this is a mistake to me. Because if you discover bugs we will fix them. Now if you wait one year to move to 3.0 we will be working on 4.0 and >> the story will never ends. > > And there I can only disagree with you. > > * I do want you on an unstable Pharo, something moving and changing fast to be able to aim for the sky and bring me a smile for what tomorrow will bring me... > * I want a stable Pharo, because this is where my work takes place, and there bugs should really get fixed... > * I want old stable Pharo(s), because, if my work goes into production, it may stay there for years. > * And I want a nice path from today's stable to the next stable to be able to port my code as soon as possible (for example, we did OSProcess this time... but I believe there is a chance this work will have to be done again before 3.0 is released ;)) > > Insisting for 3.0 based developpement means I require additional code to the core: OSProcess, FileTree, GitFileTree, SmaCC... Maintaing those for 3.0 is extremely difficult, with very disruptive changes coming often. And one get tired of complaining; at one point I just open a bugfix, create a slice and add a line to my image building makefiles to load the bugfix because bickering about whether it should be integrated or not isn't worth the time spent on it. > > So my suggestion would be more like this: 2.0 stable, 3.0 beta (freeze), and 4.0 alpha (experimental), and maybe different teams for handling each of those (and releases on a six months basis?). that's not possible because that implies manpower that we do not have, and thats, so far, a reality that will not change in the near future. So, what we have is: stable branch (now 2.0), unstable branch (now 3.0), and when we release pharo3, that will become stable and the next branch will be unstable, while 2.0 will fade out. the effort of maintaining multiple versions is exponential, not linear. > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

Sept. 6, 2013

Re: [Pharo-dev] [smaltalk-gsoc-students] Some news of the UIPainter project

by Erwan Douaille

I added it to the tools menu :) 2013/9/6 Erwan Douaille <douailleerwan(a)gmail.com> > > > > 2013/9/6 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > >> How do we open it? >> >> UIPainter open > > And yes i should add it to the tools menu :) > >> Stef >> >> On Sep 5, 2013, at 9:16 PM, Erwan Douaille <douailleerwan(a)gmail.com> >> wrote: >> >> Hi, >> >> The GSoC deadlines is 16 september. It means than i have one week to fix >> bugs and implements some new features. The best way to find bugs is user >> feedbacks. >> >> I will be glad to fix many bugs than you will find. (many bugs found in 5 >> minutes with my mentor ...) >> >> Here is instructions to load UIPainter : >> >> *Gofer new* >> * smalltalkhubUser: 'ErwanDouaille' project: 'UIPainter';* >> * configurationOf: 'UIPainter';* >> * load.* >> *ConfigurationOfUIPainter load* >> >> >> Here is my blog: http://uipainter-gsoc.over-blog.com >> >> Thanks for testing, feedbacks and ideas :) >> >> -- >> Best regards, >> >> Douaille Erwan <douaille.erwan(a)gmail.com> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Smalltalk GSoC students" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to smalltalk-gsoc-students+unsubscribe(a)googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > > -- > Best regards, > > Douaille Erwan <douaille.erwan(a)gmail.com> > -- Best regards, Douaille Erwan <douaille.erwan(a)gmail.com>

Sept. 6, 2013

Re: [Pharo-dev] Can't open image file without write access

by Damien Cassou

Dear Abigail111, On Tue, Sep 3, 2013 at 10:29 AM, Abigail111 <abigailklinton(a)yahoo.com> wrote: > Hi, i also want to know how to open image files > <http://www.rasteredge.com/how-to/csharp-imaging/open-save-file/> .My > computer support to open images ,but recently,there is something wrong.I wan > to learn some easy way to do it.Thanks. it looks like we are not talking about the same thing. I'm talking about Pharo image files (Pharo3.0.image for example) whereas you are talking about pictures (.png, .jpg...). If you have problems opening pictures, please send a separate email to the user's mailing list (pharo-users(a)lists.pharo.org) or to http://stackoverflow.com/. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Sept. 6, 2013

Re: [Pharo-dev] How to contribute updates

by Henrik Johansen

On Sep 6, 2013, at 10:03 , Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Sep 6, 2013, at 9:53 AM, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > >> >> On Sep 5, 2013, at 3:46 , Stephan Eggermont <stephan(a)stack.nl> wrote: >> >>> works. >>> >>> But that doesn't mean that I have all the answers... >>> >>> Stephan >>> >> +1, I just failed to compete this part of step 5: >> "Publish the package to PharoInbox repository." >> > > I really do not understand why. Did you put your Name and passed? > (yes this is annoyingâ¦) > > Marcus > PEBKAC, it seemsâ¦ I entered username/pass as they were requested, (after a significant delay, since I had to look up the correct ones by logging into smalltalkhubâ¦) Progress seemed to stop after entering these, but before actually publishing anything. When I try it today, it works fine. :/ Testing if the delay between initial attempt, and actual authenticated save might've been the problem now. Cheers, Henry

Sept. 6, 2013

Re: [Pharo-dev] How to contribute updates

by Marcus Denker

On Sep 6, 2013, at 9:53 AM, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Sep 5, 2013, at 3:46 , Stephan Eggermont <stephan(a)stack.nl> wrote: > >> works. >> >> But that doesn't mean that I have all the answers... >> >> Stephan >> > +1, I just failed to compete this part of step 5: > "Publish the package to PharoInbox repository." > I really do not understand why. Did you put your Name and passed? (yes this is annoyingâ¦) Marcus

Sept. 6, 2013

Re: [Pharo-dev] Should Job use SystemAnnouncer?

by Henrik Johansen

On Sep 4, 2013, at 12:12 , Camillo Bruni <camillobruni(a)gmail.com> wrote: > On 2013-09-03, at 18:57, Stephan Eggermont <stephan(a)stack.nl> wrote: >> Camillo wrote: >>> in this case it is only the instance of Job which knows the status. >>> Thread-safeness is not an issue since the progress bar is pure approximation. >> >> The problem is not approximation. Objects are not reentrant, getting the value >> out of a model while it is reorganizing its datastructure is likely to give interesting >> and difficult to reproduce results (dividing by 0, nil-pointer exceptions). >> >>> that does not work properly and inaccurately reports long running jobs, for instance >>> when running tests. Usually tests take far less than 1 ms, in which case this scheme >>> works perfectly. However from time to time you have 1 test that runs for a couple of >>> seconds. If you run 5000 tests you have to run quite a few tests to get that 1% update >>> margin, so very often the UI does not correctly report the current status. >> >> That is not a solvable problem. A progress bar depends on a value increasing from >> min to max. The model is responsible for making reasonable steps. > > ok, different question, how do you solve this very use-case without polling? > > > 1. run test 1 [1ms] > ..... > N. run test N [1ms] > ------------------------------------------- > Progress Bar update limit reached after > a) either N update calls > b) N ms > => next update will happen in > a) N calls > b) N ms > ------------------------------------------- > N+1. run test N+1 [1000 ms] > > That means that the UI shows the wrong value (run test N) instead of the current > progress value (run test N+1), which is not interesting. > The model, in this case the test runner, properly informed the UI about every change, > but the update limitations in the ProgressBarMorph cannot properly detect such a case. > - either you update way to often => performance overhead > - or you update not often enough => inaccurate progress indication when progress step times differ a lot > > There is simply no way you can properly solve this case without active polling. Sure there is. (Assuming tests are run at lower-than GUI priority so it actually gets a chance to update without forced refresh directly from the code) - Record the state of Job when it's announced. - Check a boolean for whether a GUI update is already scheduled. - If not, check the last update time - If update interval since then has passed, send an invalidate to the GUI (with you as model, painting current value of the state last recorded in you), and record the new update time - If less than interval, set the GUI update schedule boolean to true, fork of a process (at a higher-than-current priority) which waits for the remainder before doing the same as the none-delayed path, then resetting the GUI update boolean. Cheers, Henry

Sept. 6, 2013