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

Re: [Pharo-dev] argh, tests are failing!

by Guillermo Polito

Two other things: - if you choose to change the priority of the delivery process to the same priority as the running test process (i.e., 40) you would still need to tell the scheduler to give some chance to run to the other one. You can do that by yielding Processor yield - About timeouts: Denis implemented not so long ago an automatic timeout for tests. So if tests take more than a specified amount they are timed out and failed by default. Check TestCase >> defaultTimeLimit ^self class defaultTimeLimit TestCase class >> defaultTimeLimit ^DefaultTimeLimit ifNil: [DefaultTimeLimit := 1 minutes] So you may want to use that mechanism to timeout instead of hardcoding the timeouts of semaphores in each of the tests. Moreover, the mechanism created by Denis will automatically kill any processes created during a test run, to ensure you leave the system somehow "clean". So you may have that into account also. On Tue, Sep 12, 2017 at 9:46 AM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > But the thing is that those processes you are creating for delivery are > running in priority 30. This means that it may happen that they may not run > any time soon (even those 200ms) if there are processes scheduled with > higher priorities. > > So, the thing is that test is not a unit test at all. It depends a lot on > the running environment. Solutions for that: > - you change the priority of the delivery process for test purposes > - Or, for testing purposes you don't create a new process, you just > execute synchronously > > If you want really to test the fact that you are creating and running a > separate process, then you should also try to let explicit the processes > you created run. This means, if the active process that is running the > tests (usually priority 40) does not suspend itself, no processes of > priority 30 will be able to run. Ways to suspend the active process and let > lower priority ones run are: > - calling suspend (Processor activeProcess suspend) but this is dangerous > because somebody should resume it afterwards from a separate process > - using a delay > - some I/O like sockets or async files > > On Mon, Sep 11, 2017 at 7:40 PM, Juraj Kubelka <juraj.kubelka(a)icloud.com> > wrote: > >> Hi Guillermo, >> >> I have not found better solution. Waiting without a timeout threshold is >> not nice and makes it difficult to run all tests. >> If you have better idea how to sync and test two processes, I will >> appreciate it. >> Otherwise I will use a higher timeout. >> >> Cheers, >> Juraj >> >> El 11-09-2017, a las 06:55, Guillermo Polito <guillermopolito(a)gmail.com> >> escribiÃ³: >> >> Hi Juraj, >> >> think that it may really depend on the machine and the state of the >> system. Slower slave machines could not really work with that timeout... >> >> The question is how could we make such test more robust. >> >> On Sun, Sep 10, 2017 at 6:41 PM, Juraj Kubelka <juraj.kubelka(a)icloud.com> >> wrote: >> >>> Hi, >>> >>> I have checked the EventRecorderTests and it works on my computer. The >>> only reason that it might not work on other cases is that there an assert >>> for 'semaphore waitTimeoutMSecs: 200â. I can put higher timeout if >>> necessary. The timeout 200 has worked for couple of years, right?. There >>> might be another issue. >>> >>> Cheers, >>> Juraj >>> >>> El 10-09-2017, a las 10:13, Guillermo Polito <guillermopolito(a)gmail.com> >>> escribiÃ³: >>> >>> Hi all, >>> >>> Since a couple of builds we have consistently failing the following >>> tests: >>> >>> >>> - GT.EventRecorder.Tests.Core.GTEventRecorderTest.testDeliverNow2 >>> <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >>> - GT.EventRecorder.Tests.Core.GTEventRecorderTest.testNotDeliv >>> eredDataShouldBeResent >>> <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >>> - Kernel.Tests.Processes.MutexTest.testFailedCriticalSectionSh >>> ouldUnblockWaitingOne >>> <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >>> - ReleaseTests.Categorization.ProperMethodCategorizationTest.t >>> estHashMethodNeedsToBeInComparingProtocol >>> <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >>> - ReleaseTests.Categorization.ProperMethodCategorizationTest.t >>> estHashMethodNeedsToBeInComparingProtocol >>> <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >>> - ReleaseTests.Categorization.ProperMethodCategorizationTest.t >>> estHashMethodNeedsToBeInComparingProtocol >>> <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >>> - ReleaseTests.Categorization.ProperMethodCategorizationTest.t >>> estHashMethodNeedsToBeInComparingProtocol >>> <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >>> - ReleaseTests.Categorization.ProperMethodCategorizationTest.t >>> estHashMethodNeedsToBeInComparingProtocol >>> <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >>> - ReleaseTests.Categorization.ProperMethodCategorizationTest.t >>> estHashMethodNeedsToBeInComparingProtocol >>> <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >>> - ReleaseTests.Categorization.ProperMethodCategorizationTest.t >>> estHashMethodNeedsToBeInComparingProtocol >>> <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >>> >>> >>> >>> Green builds are the only hard metric to say if the build is healthy or >>> not. >>> >>> - We should not integrate anything until the build is green again... >>> >>> Also, we spent with Pablo a lot of time to have a green build in all >>> platforms... I'd like to spend my time in other fun stuff than the CI :/ >>> >>> -- >>> >>> Guille Polito >>> >>> Research Engineer >>> French National Center for Scientific Research - *http://www.cnrs.fr* >>> <http://www.cnrs.fr/> >>> >>> >>> *Web:* *http://guillep.github.io* <http://guillep.github.io/> >>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>> >>> >>> >> >> >> -- >> >> Guille Polito >> >> Research Engineer >> French National Center for Scientific Research - *http://www.cnrs.fr* >> <http://www.cnrs.fr/> >> >> >> *Web:* *http://guillep.github.io* <http://guillep.github.io/> >> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >> >> >> > > > -- > > > > Guille Polito > > > Research Engineer > > French National Center for Scientific Research - *http://www.cnrs.fr* > <http://www.cnrs.fr> > > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Sept. 12, 2017

Re: [Pharo-dev] argh, tests are failing!

by Guillermo Polito

But the thing is that those processes you are creating for delivery are running in priority 30. This means that it may happen that they may not run any time soon (even those 200ms) if there are processes scheduled with higher priorities. So, the thing is that test is not a unit test at all. It depends a lot on the running environment. Solutions for that: - you change the priority of the delivery process for test purposes - Or, for testing purposes you don't create a new process, you just execute synchronously If you want really to test the fact that you are creating and running a separate process, then you should also try to let explicit the processes you created run. This means, if the active process that is running the tests (usually priority 40) does not suspend itself, no processes of priority 30 will be able to run. Ways to suspend the active process and let lower priority ones run are: - calling suspend (Processor activeProcess suspend) but this is dangerous because somebody should resume it afterwards from a separate process - using a delay - some I/O like sockets or async files On Mon, Sep 11, 2017 at 7:40 PM, Juraj Kubelka <juraj.kubelka(a)icloud.com> wrote: > Hi Guillermo, > > I have not found better solution. Waiting without a timeout threshold is > not nice and makes it difficult to run all tests. > If you have better idea how to sync and test two processes, I will > appreciate it. > Otherwise I will use a higher timeout. > > Cheers, > Juraj > > El 11-09-2017, a las 06:55, Guillermo Polito <guillermopolito(a)gmail.com> > escribiÃ³: > > Hi Juraj, > > think that it may really depend on the machine and the state of the > system. Slower slave machines could not really work with that timeout... > > The question is how could we make such test more robust. > > On Sun, Sep 10, 2017 at 6:41 PM, Juraj Kubelka <juraj.kubelka(a)icloud.com> > wrote: > >> Hi, >> >> I have checked the EventRecorderTests and it works on my computer. The >> only reason that it might not work on other cases is that there an assert >> for 'semaphore waitTimeoutMSecs: 200â. I can put higher timeout if >> necessary. The timeout 200 has worked for couple of years, right?. There >> might be another issue. >> >> Cheers, >> Juraj >> >> El 10-09-2017, a las 10:13, Guillermo Polito <guillermopolito(a)gmail.com> >> escribiÃ³: >> >> Hi all, >> >> Since a couple of builds we have consistently failing the following tests: >> >> >> - GT.EventRecorder.Tests.Core.GTEventRecorderTest.testDeliverNow2 >> <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >> - GT.EventRecorder.Tests.Core.GTEventRecorderTest.testNotDeliv >> eredDataShouldBeResent >> <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >> - Kernel.Tests.Processes.MutexTest.testFailedCriticalSectionSh >> ouldUnblockWaitingOne >> <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >> - ReleaseTests.Categorization.ProperMethodCategorizationTest.t >> estHashMethodNeedsToBeInComparingProtocol >> <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >> - ReleaseTests.Categorization.ProperMethodCategorizationTest.t >> estHashMethodNeedsToBeInComparingProtocol >> <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >> - ReleaseTests.Categorization.ProperMethodCategorizationTest.t >> estHashMethodNeedsToBeInComparingProtocol >> <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >> - ReleaseTests.Categorization.ProperMethodCategorizationTest.t >> estHashMethodNeedsToBeInComparingProtocol >> <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >> - ReleaseTests.Categorization.ProperMethodCategorizationTest.t >> estHashMethodNeedsToBeInComparingProtocol >> <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >> - ReleaseTests.Categorization.ProperMethodCategorizationTest.t >> estHashMethodNeedsToBeInComparingProtocol >> <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >> - ReleaseTests.Categorization.ProperMethodCategorizationTest.t >> estHashMethodNeedsToBeInComparingProtocol >> <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >> >> >> >> Green builds are the only hard metric to say if the build is healthy or >> not. >> >> - We should not integrate anything until the build is green again... >> >> Also, we spent with Pablo a lot of time to have a green build in all >> platforms... I'd like to spend my time in other fun stuff than the CI :/ >> >> -- >> >> Guille Polito >> >> Research Engineer >> French National Center for Scientific Research - *http://www.cnrs.fr* >> <http://www.cnrs.fr/> >> >> >> *Web:* *http://guillep.github.io* <http://guillep.github.io/> >> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >> >> >> > > > -- > > Guille Polito > > Research Engineer > French National Center for Scientific Research - *http://www.cnrs.fr* > <http://www.cnrs.fr/> > > > *Web:* *http://guillep.github.io* <http://guillep.github.io/> > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> > > > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Sept. 12, 2017

Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])

by Nicolas Cellier

Hi Torsten, it's early enough for that change to happen in all dialects, no backward compatibility support necessary, no deprecation policy, so if Pharo comes with good selectors we can make them universal. Nicolas 2017-09-11 19:06 GMT+02:00 Torsten Bergmann <astares(a)gmx.de>: > And me ... > > Squeak and Cuis have the same name/implementation for - pin, unpin, > isPinned, setPinned: (private) as we have in Pharo > now (now also in the same method categories) and unnecessary > differences/incompatibilities in the Kernel would not make much sense. > > If it would really be necessary to change them it would only make sense to > change them equally on all Open-Smalltalk > VM based systems. Currently I also do not see any necessity. > > If there are clashes for Calypso tabs then why not change it there (with > more specific method names like #isPinnedTab. #isPinnedToWindow > or #isPinnedToBrowser) > > Bye > T. > > > Gesendet: Montag, 11. September 2017 um 14:16 Uhr > Von: "Esteban Lorenzano" <estebanlm(a)gmail.com> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] Maybe better pinning messages? (inspired by > [Pinning Objects in Pharo]) > > yes, me :) > > I do not see a reason to change them, tbh. > for me they are comprensible as they are now and it does not adds more > information pinInMemory or pinMemory. > > Esteban > > > > > On 11 Sep 2017, at 11:56, Denis Kudriashov <dionisiydk@gmail.com[mailto:d > ionisiydk(a)gmail.com]> wrote: > > Anybody else? > > 2017-08-31 10:29 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com[ > mailto:pavel.krivanek@gmail.com]>: > > > 2017-08-31 10:24 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com[mailto:d > ionisiydk(a)gmail.com]>: > Hi. > > We now have very generic message names: > - pin > - unpin > - setPinned: > - isPinned > > Problem that they collide with possible domain related names. > For example I implemented pinning of tabs in Calypso and I found that I > overrides #pin and #isPinned messages. Then I fix it with different names. > Probably menus also uses pin word but without overrides > > What you think about renaming pinning messages? Something like: > - pinMemory > > I would use pinInMemory > > -- Pavel > > > - unpinMemory > - isMemoryPinned > - setPinnedMemory: > - pinMemoryDuring: (if we will introduce it) > > I think it is easy to do now because not much code uses pinning > >

Sept. 11, 2017

Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])

by Peter UhnÃ¡k

> for me they are comprensible as they are now and it does not adds more information pinInMemory or pinMemory. it is not about comprehension, but about not mixing meta and domain selectors. On Mon, Sep 11, 2017 at 7:06 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > And me ... > > Squeak and Cuis have the same name/implementation for - pin, unpin, > isPinned, setPinned: (private) as we have in Pharo > now (now also in the same method categories) and unnecessary > differences/incompatibilities in the Kernel would not make much sense. > > If it would really be necessary to change them it would only make sense to > change them equally on all Open-Smalltalk > VM based systems. Currently I also do not see any necessity. > > If there are clashes for Calypso tabs then why not change it there (with > more specific method names like #isPinnedTab. #isPinnedToWindow > or #isPinnedToBrowser) > > Bye > T. > > > Gesendet: Montag, 11. September 2017 um 14:16 Uhr > Von: "Esteban Lorenzano" <estebanlm(a)gmail.com> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] Maybe better pinning messages? (inspired by > [Pinning Objects in Pharo]) > > yes, me :) > > I do not see a reason to change them, tbh. > for me they are comprensible as they are now and it does not adds more > information pinInMemory or pinMemory. > > Esteban > > > > > On 11 Sep 2017, at 11:56, Denis Kudriashov <dionisiydk@gmail.com[mailto:d > ionisiydk(a)gmail.com]> wrote: > > Anybody else? > > 2017-08-31 10:29 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com[ > mailto:pavel.krivanek@gmail.com]>: > > > 2017-08-31 10:24 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com[mailto:d > ionisiydk(a)gmail.com]>: > Hi. > > We now have very generic message names: > - pin > - unpin > - setPinned: > - isPinned > > Problem that they collide with possible domain related names. > For example I implemented pinning of tabs in Calypso and I found that I > overrides #pin and #isPinned messages. Then I fix it with different names. > Probably menus also uses pin word but without overrides > > What you think about renaming pinning messages? Something like: > - pinMemory > > I would use pinInMemory > > -- Pavel > > > - unpinMemory > - isMemoryPinned > - setPinnedMemory: > - pinMemoryDuring: (if we will introduce it) > > I think it is easy to do now because not much code uses pinning > >

Sept. 11, 2017

Re: [Pharo-dev] argh, tests are failing!

by Juraj Kubelka

Hi Guillermo, I have not found better solution. Waiting without a timeout threshold is not nice and makes it difficult to run all tests. If you have better idea how to sync and test two processes, I will appreciate it. Otherwise I will use a higher timeout. Cheers, Juraj > El 11-09-2017, a las 06:55, Guillermo Polito <guillermopolito(a)gmail.com> escribiÃ³: > > Hi Juraj, > > think that it may really depend on the machine and the state of the system. Slower slave machines could not really work with that timeout... > > The question is how could we make such test more robust. > > On Sun, Sep 10, 2017 at 6:41 PM, Juraj Kubelka <juraj.kubelka(a)icloud.com <mailto:juraj.kubelka@icloud.com>> wrote: > Hi, > > I have checked the EventRecorderTests and it works on my computer. The only reason that it might not work on other cases is that there an assert for 'semaphore waitTimeoutMSecs: 200â. I can put higher timeout if necessary. The timeout 200 has worked for couple of years, right?. There might be another issue. > > Cheers, > Juraj > >> El 10-09-2017, a las 10:13, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> escribiÃ³: >> >> Hi all, >> >> Since a couple of builds we have consistently failing the following tests: >> >> GT.EventRecorder.Tests.Core.GTEventRecorderTest.testDeliverNow2 <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >> GT.EventRecorder.Tests.Core.GTEventRecorderTest.testNotDeliveredDataShouldBeResent <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >> Kernel.Tests.Processes.MutexTest.testFailedCriticalSectionShouldUnblockWaitingOne <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >> ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >> ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >> ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >> ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >> ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >> ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >> ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >> >> >> Green builds are the only hard metric to say if the build is healthy or not. >> >> - We should not integrate anything until the build is green again... >> >> Also, we spent with Pablo a lot of time to have a green build in all platforms... I'd like to spend my time in other fun stuff than the CI :/ >> >> -- >> >> Guille Polito >> >> Research Engineer >> French National Center for Scientific Research - http://www.cnrs.fr <http://www.cnrs.fr/> >> >> >> Web: http://guillep.github.io <http://guillep.github.io/> >> Phone: +33 06 52 70 66 13 <tel:+33%206%2052%2070%2066%2013> > > > > -- > > Guille Polito > > Research Engineer > French National Center for Scientific Research - http://www.cnrs.fr <http://www.cnrs.fr/> > > > Web: http://guillep.github.io <http://guillep.github.io/> > Phone: +33 06 52 70 66 13

Sept. 11, 2017

Re: [Pharo-dev] argh, tests are failing!

by Stephane Ducasse

> > >> > As Pavel said, the iceberg version that is included in the system is the > one described in > > BaselineOfIDE >> loadIceberg > > Metacello new > baseline: 'Iceberg'; > repository: 'github://pharo-vcs/iceberg:v0.5.7'; > load. > (Smalltalk classNamed: #Iceberg) enableMetacelloIntegration: true. > > So updating that method with the new iceberg version and pushing that to > Pharo should be enough. > Good to know that. > In any case, my mail was there just to raise the issue of the failing > tests. We should care about failing tests, and I'll cry out loud everytime > they are broken, just to make it explicit. > I agree.

Sept. 11, 2017

Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])

by Torsten Bergmann

And me ...Â Squeak and Cuis have the same name/implementation for - pin, unpin, isPinned, setPinned: (private) as we have in Pharo now (now also in the same method categories) and unnecessary differences/incompatibilities in the Kernel would not make much sense. If it would really be necessary to change them it would only make sense to change them equally on all Open-Smalltalk VM based systems.Â Currently I also do not see any necessity. If there are clashes for Calypso tabs then why not change it there (with more specific method names like #isPinnedTab. #isPinnedToWindow or #isPinnedToBrowser) Bye T. Â Gesendet:Â Montag, 11. September 2017 um 14:16 Uhr Von:Â "Esteban Lorenzano" <estebanlm(a)gmail.com> An:Â "Pharo Development List" <pharo-dev(a)lists.pharo.org> Betreff:Â Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo]) yes, me :) Â I do not see a reason to change them, tbh. for me they are comprensible as they are now and it does not adds more information pinInMemory or pinMemory. Â Esteban Â Â On 11 Sep 2017, at 11:56, Denis Kudriashov <dionisiydk@gmail.com[mailto:dionisiydk@gmail.com]> wrote:Â Anybody else? Â 2017-08-31 10:29 GMT+02:00 Pavel Krivanek <pavel.krivanek@gmail.com[mailto:pavel.krivanek@gmail.com]>: Â Â 2017-08-31 10:24 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com[mailto:dionisiydk@gmail.com]>: Hi. Â We now have very generic message names: - pin - unpin - setPinned: - isPinned Â Problem that they collide with possible domain related names.Â For example I implemented pinning of tabs in Calypso and I found that I overrides #pin and #isPinned messages. Then I fix it with different names. Probably menus also uses pin word but without overrides Â What you think about renaming pinning messages? Something like: - pinMemory Â I would use pinInMemory Â -- Pavel Â - unpinMemory - isMemoryPinned - setPinnedMemory: - pinMemoryDuring: (if we will introduce it) Â I think it is easy to do now because not much code uses pinning

Sept. 11, 2017

Re: [Pharo-dev] Build #111

by Torsten Bergmann

If we can keep it green each day with a new build number will be a release day ;) Have fun T.Â Â Gesendet:Â Montag, 11. September 2017 um 18:23 Uhr Von:Â "Stephane Ducasse" <stepharo.self(a)gmail.com> An:Â "Pharo Development List" <pharo-dev(a)lists.pharo.org> Betreff:Â Re: [Pharo-dev] Build #111 Thanks you guys!!! Â Â On Mon, Sep 11, 2017 at 5:31 PM, Denis Kudriashov <dionisiydk@gmail.com[mailto:dionisiydk@gmail.com]> wrote: I add another push request Â 2017-09-11 17:16 GMT+02:00 Guillermo Polito <guillermopolito@gmail.com[mailto:guillermopolito@gmail.com]>: Ahh It's a different one! Â On Mon, Sep 11, 2017 at 5:14 PM, Denis Kudriashov <dionisiydk@gmail.com[mailto:dionisiydk@gmail.com]> wrote: But this SemaphoreTest is not mine :). Now I only improve MutexTest Â 2017-09-11 17:09 GMT+02:00 Guillermo Polito <guillermopolito@gmail.com[mailto:guillermopolito@gmail.com]>: Hi all, Â since the build #111 there is a new version of iceberg. I'll let Esteban get into the details of that. From what respects to me, this build fixes 9 failing tests: Â https://github.com/pharo-project/pharo/pull/267[https://github.com/pharo-pr… Â The build has however one failing test that fails randomly: Â https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… Â Â Kernel.Tests.Processes.SemaphoreTest.testMutualExclusion[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/lastCompletedBuild/testReport/Kernel.Tests.Processes/SemaphoreTest/testMutualExclusion/] Â Denis has proposed a solution for that, so we will have a green build back soon :) Â -- Â Â Â Guille Polito Â Research Engineer French National Center for Scientific Research - http://www.cnrs.fr[http://www.cnrs.fr] Â Â Web: http://guillep.github.io[http://guillep.github.io] Phone: +33 06 52 70 66 13 Â Â -- Â Â Â Guille Polito Â Research Engineer French National Center for Scientific Research - http://www.cnrs.fr[http://www.cnrs.fr] Â Â Web: http://guillep.github.io[http://guillep.github.io] Phone: +33 06 52 70 66 13

Sept. 11, 2017

Re: [Pharo-dev] Build #111

by Stephane Ducasse

Thanks you guys!!! On Mon, Sep 11, 2017 at 5:31 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > I add another push request > > 2017-09-11 17:16 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > >> Ahh It's a different one! >> >> On Mon, Sep 11, 2017 at 5:14 PM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >>> But this SemaphoreTest is not mine :). Now I only improve MutexTest >>> >>> 2017-09-11 17:09 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: >>> >>>> Hi all, >>>> >>>> since the build #111 there is a new version of iceberg. I'll let >>>> Esteban get into the details of that. From what respects to me, this build >>>> fixes 9 failing tests: >>>> >>>> https://github.com/pharo-project/pharo/pull/267 >>>> >>>> The build has however one failing test that fails randomly: >>>> >>>> https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20p >>>> ull%20request%20and%20branch%20Pipeline/job/development/ >>>> >>>> Kernel.Tests.Processes.SemaphoreTest.testMutualExclusion >>>> <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >>>> >>>> Denis has proposed a solution for that, so we will have a green build >>>> back soon :) >>>> >>>> -- >>>> >>>> >>>> >>>> Guille Polito >>>> >>>> >>>> Research Engineer >>>> >>>> French National Center for Scientific Research - *http://www.cnrs.fr* >>>> <http://www.cnrs.fr> >>>> >>>> >>>> >>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>> >>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>> >>> >>> >> >> >> -- >> >> >> >> Guille Polito >> >> >> Research Engineer >> >> French National Center for Scientific Research - *http://www.cnrs.fr* >> <http://www.cnrs.fr> >> >> >> >> *Web:* *http://guillep.github.io* <http://guillep.github.io> >> >> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >> > >

Sept. 11, 2017

Re: [Pharo-dev] Build #111

by Denis Kudriashov

I add another push request 2017-09-11 17:16 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > Ahh It's a different one! > > On Mon, Sep 11, 2017 at 5:14 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> But this SemaphoreTest is not mine :). Now I only improve MutexTest >> >> 2017-09-11 17:09 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: >> >>> Hi all, >>> >>> since the build #111 there is a new version of iceberg. I'll let Esteban >>> get into the details of that. From what respects to me, this build fixes 9 >>> failing tests: >>> >>> https://github.com/pharo-project/pharo/pull/267 >>> >>> The build has however one failing test that fails randomly: >>> >>> https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20p >>> ull%20request%20and%20branch%20Pipeline/job/development/ >>> >>> Kernel.Tests.Processes.SemaphoreTest.testMutualExclusion >>> <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >>> >>> Denis has proposed a solution for that, so we will have a green build >>> back soon :) >>> >>> -- >>> >>> >>> >>> Guille Polito >>> >>> >>> Research Engineer >>> >>> French National Center for Scientific Research - *http://www.cnrs.fr* >>> <http://www.cnrs.fr> >>> >>> >>> >>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>> >>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>> >> >> > > > -- > > > > Guille Polito > > > Research Engineer > > French National Center for Scientific Research - *http://www.cnrs.fr* > <http://www.cnrs.fr> > > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >

Sept. 11, 2017