- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Grease conflicts #packages with RPackage

by Mariano Martinez Peck

Anyone? On Wed, Aug 28, 2013 at 2:12 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi guys, > > I was trying to build a new image with latest Pharo 2.0 with all the > frameworks I use. While installing, I get a dnu in: > > packageFromOrganizer: anRPackageOrganizer > "This method returns the package this method belongs to. > It takes into account classes and traits. > If the method is in no package, returns nil by now" > self flag: 'TODO: use anRPackageOrganizer, or better delegate to > anRPackageOrganizer'. > ^self origin packages > detect: [ :each | > (each includesSelector: self selector ofClassName: self origin > theNonMetaClass originalName) > or: [ each includesSelector: self selector ofMetaclassName: self origin > theNonMetaClass originalName]] > ifNone: [ nil ] > > because "each" (which was GRPackage) dnu #includesSelector:ofClassName: > > Problem is that "self origin" answers GRPackage. And GRPackage DOES > implement a CLASS side method #packages that answers instances of > GRPackage.....not RPackage... > > So...which one do we prefix? GRPackage class #packages to #greasePackages? > > BTW, there are yet more class side implementations of #packages, which are > basically subclasses for the HelpSystem (CustomHelp). So we have for > example SUnitAPIDocumentation, RegexAPIDocumentation, ProfStefAPIHelp, HelpAPIDocumentation, AnnouncementsAPIDocumentation. > > Guess we should update the HelpSystem as well? > > Let me know and I open issues/submit fixes. > > Cheers, > > -- > Mariano > http://marianopeck.wordpress.com > -- Mariano http://marianopeck.wordpress.com

Sept. 6, 2013

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

by Goubier Thierry

Le 06/09/2013 14:13, Marcus Denker a Ã©crit : > > > So you want more change in 2.0? You can have that, but you need to accept instability. There is no way to have both more changes and more stability. I'm OK for that. 3.0 is just plainly too unstable, and this is the way it should be. But 2.0 shouldn't be considered a dead platform ;) 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] [regression reporter]regression occurred

by Camillo Bruni

Ah right, let's try manually :), and yeah it's not always easy to modify these core UI things without breaking it ;) On 2013-09-06, at 09:17, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Maybe some class #initialize did not run ? > Remember: existing class initializers are only run when the source code text changes. > > On 06 Sep 2013, at 14:08, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> >> On 2013-09-06, at 09:03, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> On 2013-09-06, at 08:59, no-reply(a)ci.inria.fr wrote: >>>> 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 >>> >>> >>> Fernando this is all yours :) >> >> >> Arg, seems like this image is unusable in UI mode and fails on the same things as the three testss :( > >

Sept. 6, 2013

Re: [Pharo-dev] [regression reporter]regression occurred

by Marcus Denker

On Sep 6, 2013, at 2:17 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Maybe some class #initialize did not run ? > Remember: existing class initializers are only run when the source code text changes. > I added explicitly a call to initializeâ¦ the strange thing is that the change set seemed to work fine. Maybe we need to load it as a change set. > On 06 Sep 2013, at 14:08, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> >> On 2013-09-06, at 09:03, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> On 2013-09-06, at 08:59, no-reply(a)ci.inria.fr wrote: >>>> 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 >>> >>> >>> Fernando this is all yours :) >> >> >> Arg, seems like this image is unusable in UI mode and fails on the same things as the three testss :( > >

Sept. 6, 2013

Re: [Pharo-dev] [regression reporter]regression occurred

by Sven Van Caekenberghe

Maybe some class #initialize did not run ? Remember: existing class initializers are only run when the source code text changes. On 06 Sep 2013, at 14:08, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-09-06, at 09:03, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> On 2013-09-06, at 08:59, no-reply(a)ci.inria.fr wrote: >>> 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 >> >> >> Fernando this is all yours :) > > > Arg, seems like this image is unusable in UI mode and fails on the same things as the three testss :(

Sept. 6, 2013

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

by Goubier Thierry

Le 06/09/2013 12:34, Esteban Lorenzano a Ã©crit : > > 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 :) This looks like a very nice 2.0. >> 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. Then I would look in current situation maybe something like 2, 2S and 3; shifting to 2S, 3 (and maybe 4) for 3 freeze; later 3, 3S, 4. > the effort of maintaining multiple versions is exponential, not linear. Yes, but you're shifting part of the work to others. And their support of multiple versions is exponential. 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] OSProcess for Pharo3.0

by Marcus Denker

On Sep 6, 2013, at 2:12 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 06/09/2013 12:34, Esteban Lorenzano a Ã©crit : >> >> 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 :) > > This looks like a very nice 2.0. > So you want more change in 2.0? You can have that, but you need to accept instability. There is no way to have both more changes and more stability. Marcus

Sept. 6, 2013

Re: [Pharo-dev] [regression reporter]regression occurred

by Camillo Bruni

On 2013-09-06, at 09:03, Camillo Bruni <camillobruni(a)gmail.com> wrote: > On 2013-09-06, at 08:59, no-reply(a)ci.inria.fr wrote: >> 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 > > > Fernando this is all yours :) Arg, seems like this image is unusable in UI mode and fails on the same things as the three testss :(

Sept. 6, 2013

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

by Igor Stasenko

+1 even more than that: it makes no sense to update something like progress bar on the screen at a rate higher than 20-30 per second, because humans will be unable to notice that anyways.. so if you updating screen more often, know that you just wasting cpu cycles for nothing. That's why the progress bar update should be decoupled from actual job progress and should be updated only when World UI cycle does that but not ASAP. On 6 September 2013 09: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. > > Cheers, > Henry > > -- Best regards, Igor Stasenko.

Sept. 6, 2013

Re: [Pharo-dev] [regression reporter]regression occurred

by Camillo Bruni

On 2013-09-06, at 08:59, no-reply(a)ci.inria.fr wrote: > 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 Fernando this is all yours :)

Sept. 6, 2013