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

Eclipse icons in Pharo

by Yuriy Tymchuk

You know, a thing about that icons... It was predicted long time ago Cheers. Uko Sent from my iPhone

Oct. 30, 2013

Image Stability

by Camillo Bruni

Failing Tests ------------- Seems like our test splitup did not work properly: https://ci.inria.fr/pharo/job/Pharo-3.0/ The tests starting with A-L did not run since a while! >From what I get quite a bunch of tests are failing. Pending Processes + Default Username ------------------------------------ There is a strange amount of processes hanging around in the image. Plus there was a report that a default user name was set in the image (Not sure if that still persists, since I directly set mine with startup preferences). Was a new image version ben uploaded manually? Unstable Image + VM ------------------- Additionally since a while the image became much more unstable after running the tests twice (I know not a common case, but it should NEVER provoke a VM crash), see here: https://ci.inria.fr/pharo/view/3.0-Analysis/job/Pharo-3.0-Test-Twice/buildT… >From what I get, ReleaseTest>>testObsoleteBehaviors provokes a VM crash.

Oct. 30, 2013

Re: [Pharo-dev] Using Gutenberg

by Yuriy Tymchuk

You are talking about Pier-Gutenberg? A thing for books? On 30 Oct 2013, at 14:37, Torsten Bergmann <astares(a)gmx.de> wrote: > Gutenberg - how to use it? How to install, how is the process... > Any links? > > thx > T. >

Oct. 30, 2013

Re: [Pharo-dev] CI

by Camillo Bruni

thanks for the details On 2013-10-30, at 14:39, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > I tried. Got Error #500 error :Empty or too short HTTP message: '' > I think this is due to yesterday maintenance. > It will be fixed soon. > > For further informations, mails from the CI guys (both sent yesterday): > > mail1 > > Dear users, > > A maintenance has to be performed on the network hardware of the CloudStack service (software update of the switches). As a consequence, the slaves will not be available for a few minutes between 4.25pm and 4.45pm. Meanwhile, some Jenkins jobs might fail because of unreachable slaves. > > Please accept our apologies for the inconvenience, > > mail2 > > Dear users, > > Unfortunately this maintenance was not without impact. The CloudStack > hypervisors have briefly lost their iSCSI link. As a consequence, the > primary storage pools are now in an inconsistent state. > > From your point of view, some slaves might be unreachable and the > CloudStack operations may fail. > > The IT team is now working on the issue. If you are interested in the > details, you can have a look at > https://wiki.inria.fr/ciportal/Event_20131030_cs > > Sorry for this new unavailability, CI is somehow facing an unlucky > period. > > > 2013/10/30 Camillo Bruni <camillobruni(a)gmail.com> > Could someone else try rebooting all our jenkins instances including all slaves? > - host name resolving is horribly slow on all slaves, the only thing that helps is rebooting > - windows slaves are all down due to CI issue (being addressed by the CI maintainers) > - I don't have access to the CI admin site, due to a Error 500 > > >

Oct. 30, 2013

Re: [Pharo-dev] CI

by ClÃ©ment Bera

I tried. Got *Error #500* error :Empty or too short HTTP message: '' I think this is due to yesterday maintenance. It will be fixed soon. For further informations, mails from the CI guys (both sent yesterday): mail1 Dear users, A maintenance has to be performed on the network hardware of the CloudStack service (software update of the switches). As a consequence, the slaves will not be available for a few minutes between 4.25pm and 4.45pm. Meanwhile, some Jenkins jobs might fail because of unreachable slaves. Please accept our apologies for the inconvenience, mail2 Dear users, Unfortunately this maintenance was not without impact. The CloudStack hypervisors have briefly lost their iSCSI link. As a consequence, the primary storage pools are now in an inconsistent state. >From your point of view, some slaves might be unreachable and the CloudStack operations may fail. The IT team is now working on the issue. If you are interested in the details, you can have a look at https://wiki.inria.fr/ciportal/Event_20131030_cs Sorry for this new unavailability, CI is somehow facing an unlucky period. 2013/10/30 Camillo Bruni <camillobruni(a)gmail.com> > Could someone else try rebooting all our jenkins instances including all > slaves? > - host name resolving is horribly slow on all slaves, the only thing that > helps is rebooting > - windows slaves are all down due to CI issue (being addressed by the CI > maintainers) > - I don't have access to the CI admin site, due to a Error 500 > > >

Oct. 30, 2013

Using Gutenberg

by Torsten Bergmann

Gutenberg - how to use it? How to install, how is the process... Any links? thx T.

Oct. 30, 2013

Re: [Pharo-dev] CI

by Igor Stasenko

On 30 October 2013 13:49, Camillo Bruni <camillobruni(a)gmail.com> wrote: > Could someone else try rebooting all our jenkins instances including all > slaves? > - host name resolving is horribly slow on all slaves, the only thing that > helps is rebooting > - windows slaves are all down due to CI issue (being addressed by the CI > maintainers) > - I don't have access to the CI admin site, due to a Error 500 > > > i tried (via https://ci.inria.fr/dashboard) but i have same problem here - Error 500. -- Best regards, Igor Stasenko.

Oct. 30, 2013

Preventing wrong use of Collection>>#randomForPicking

by Max Leske

To continue the discussion on this topic (stemming from issue 11635) Iâm starting a new thread. Please share your thoughts. >From the other thread: > Also open for discussion is the use of Collection>>randomForPicking and Collection>>mutexForPicking in other methods (such as #atRandom). I think it shouldn't be too big a problem to make those methods use individual Random instances and to remove the two class variables from Collection. #randomForPicking answers a Random stored in a class variable. Access to this variable is protected by a Mutext stored in a class variable (#mutexForPicking). The problem, as revealed by issue 11635, is of course that you have to know that you may only use that Random object if you also protect access to it with the class side Mutex. Otherwise race conditions can occur. #atRandom is one prominent user of #randomForPicking and #mutexForPicking. Henrikâs thoughts: > As for #atRandom using Random new, the performance hit and seed quality would be much greater concerns, as the Random instance would only be used once per invocation. > At this point in time there's no good alternatives to the current approach, but renaming the mutex/shared variable to reflect its singular use would be one possible improvement, I guess. So one possibility would be rename these methods, for example to #atRandomMutex and #atRandomRandom (no, I havenât given much thought to the names :) ). Max

Oct. 30, 2013

Changing non-copying selectors to #...InPlace

by Max Leske

To continue the discussion on this topic (stemming from issue 11635) Iâm starting a new thread. Please share your thoughts. Form the other thread: > Personally I'm for more intention revealing selectors; I quite like #shuffled and #shuffleInPlace. If we can agree on a different naming scheme we should then apply it to other methods aswell of course (e.g. #sorted, #sortInPlace). My proposition is to keep the selectors named #â¦d (#shuffled, #sorted, etc.), which operate on a copy, and rename the others (#shuffle, #sort, etcâ¦) to #â¦InPlace (#shuffleInPlace, #sortInPlace, etc.). The rational behind this is that (to my mind) the current scheme is not intention revealing (e.g. #shuffle vs. #shuffled). Which is especially problematic for newcomers. Max

Oct. 30, 2013

Re: [Pharo-dev] 11635: Race condition in SequenceableCollection>>shuffle

by Max Leske

Name: SLICE-Issue-11635-Race-condition-in-SequenceableCollectionshuffle-MaxLeske.2 Author: MaxLeske Time: 30 October 2013, 1:41:57.198092 pm UUID: c3d51645-7e81-4997-b74c-545bf7ef60b0 Ancestors: Dependencies: Collections-Abstract-MaxLeske.231, Collections-Unordered-MaxLeske.175 made changes as detailed on the mailing list * shuffle ^ self shuffleBy: Random new * shuffled ^ self copy shuffle * removed #shuffledBy: * Matrix uses #shuffleBy: (on an explicit copy) instead of #shuffledBy: On 01.10.2013, at 17:06, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Sep 28, 2013, at 10:59 , Max Leske <maxleske(a)gmail.com> wrote: > >> Thanks for the feedback guys. >> >> Based on the discussion I propose a different set of changes: >> >> 1. >> shuffle >> ^ self shuffleBy: Random new >> >> 2. >> shuffled >> ^ self copy shuffle >> >> 3. remove #shuffledBy: (if you're specific enough to use a custom Random instance you can also create a copy of the collection yourself if you want to) >> >> >> I leave the matter of renaming the methods for further discussion. Personally I'm for more intention revealing selectors; I quite like #shuffle and #shuffleInPlace. If we can agree on a different naming scheme we should then apply it to other methods aswell of course (e.g. #sort, #sortInPlace). >> >> Also open for discussion is the use of Collection>>randomForPicking and Collection>>mutexForPicking in other methods (such as #atRandom). I think it shouldn't be too big a problem to make those methods use individual Random instances and to remove the two class variables from Collection. >> >> Cheers, >> Max > > +1 from me on all three suggestions, as you might guess. :) > > As for #atRandom using Random new, the performance hit and seed quality would be much greater concerns, as the Random instance would only be used once per invocation. > At this point in time there's no good alternatives to the current approach, but renaming the mutex/shared variable to reflect its singular use would be one possible improvement, I guess. > > Cheers, > Henry

Oct. 30, 2013