- Pharo-dev - lists.pharo.org

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

CI

by Camillo Bruni

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] moose 4.9

by Usman Bhatti

On Wed, Oct 30, 2013 at 12:23 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Yes. Right away. > > Could anyone please move the build job to run on Pharo 3.0? > That should be too difficult with zero-conf scripts for Pharo 3.0. I can do it. I'd like to keep the 4.9 job in the jenkins for a few days until downstream projects adapt themselves. So, I'll create a new job Moose 5.0 with Pharo 3.0 on the jenkins and we'll remove the current job in a few days. Is that ok with you? > > Doru > > > On Wed, Oct 30, 2013 at 11:29 AM, Andrei Chis <chisvasileandrei(a)gmail.com>wrote: > >> Super. >> So this means we finally more to Pharo 3? >> >> Andrei >> >> >> On Wed, Oct 30, 2013 at 10:38 AM, Tudor Girba <tudor(a)tudorgirba.com>wrote: >> >>> We are happy to announce version 4.9 of the Moose Suite: >>> http://moosetechnology.org/download/4.9 >>> >>> >>> This is a minor release still based on Pharo 2.0. The differences from >>> Moose 4.8 are: >>> >>> The Mondrian engine was removed. The transition to Roassal is now >>> complete. >>> - Small fixes in Roassal layouts and rendering. >>> - Small fix in FAMIX regarding manipulation of accesses. >>> - Small visual fix in Glamour for rendering splitters in tables. >>> >>> A list of issues addressed in this release can be found at: >>> http://code.google.com/p/moose-technology/issues/list?can=1&q=status=Fixed%… >>> >>> The Moose Suite 4.9 comes for each platform as a separate bundle: >>> - Moose Suite 4.9 for Mac >>> >>> https://dl.dropboxusercontent.com/u/18323746/Moose/moose_suite_4_9-mac.zip >>> - Moose Suite 4.9 for Windows >>> >>> https://dl.dropboxusercontent.com/u/18323746/Moose/moose_suite_4_9-win.zip >>> - Moose Suite 4.9 for Linux >>> >>> https://dl.dropboxusercontent.com/u/18323746/Moose/moose_suite_4_9-linux.zip >>> >>> The Moose Suite 4.9 can also be loaded in a Pharo 2.0 image either from >>> the Configuration Browser, or by executing the following script: >>> >>> Gofer new >>> smalltalkhubUser: 'Moose' project: 'Moose'; >>> package: 'ConfigurationOfMoose'; >>> load. >>> ((Smalltalk at: #ConfigurationOfMoose) >>> project version: '4.9-snapshot') load >>> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Oct. 30, 2013

Re: [Pharo-dev] moose 4.9

by Tudor Girba

Yes. Right away. Could anyone please move the build job to run on Pharo 3.0? Doru On Wed, Oct 30, 2013 at 11:29 AM, Andrei Chis <chisvasileandrei(a)gmail.com>wrote: > Super. > So this means we finally more to Pharo 3? > > Andrei > > > On Wed, Oct 30, 2013 at 10:38 AM, Tudor Girba <tudor(a)tudorgirba.com>wrote: > >> We are happy to announce version 4.9 of the Moose Suite: >> http://moosetechnology.org/download/4.9 >> >> >> This is a minor release still based on Pharo 2.0. The differences from >> Moose 4.8 are: >> >> The Mondrian engine was removed. The transition to Roassal is now >> complete. >> - Small fixes in Roassal layouts and rendering. >> - Small fix in FAMIX regarding manipulation of accesses. >> - Small visual fix in Glamour for rendering splitters in tables. >> >> A list of issues addressed in this release can be found at: >> http://code.google.com/p/moose-technology/issues/list?can=1&q=status=Fixed%… >> >> The Moose Suite 4.9 comes for each platform as a separate bundle: >> - Moose Suite 4.9 for Mac >> https://dl.dropboxusercontent.com/u/18323746/Moose/moose_suite_4_9-mac.zip >> - Moose Suite 4.9 for Windows >> https://dl.dropboxusercontent.com/u/18323746/Moose/moose_suite_4_9-win.zip >> - Moose Suite 4.9 for Linux >> >> https://dl.dropboxusercontent.com/u/18323746/Moose/moose_suite_4_9-linux.zip >> >> The Moose Suite 4.9 can also be loaded in a Pharo 2.0 image either from >> the Configuration Browser, or by executing the following script: >> >> Gofer new >> smalltalkhubUser: 'Moose' project: 'Moose'; >> package: 'ConfigurationOfMoose'; >> load. >> ((Smalltalk at: #ConfigurationOfMoose) >> project version: '4.9-snapshot') load >> > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 30, 2013

Re: [Pharo-dev] moose 4.9

by Andrei Chis

Super. So this means we finally more to Pharo 3? Andrei On Wed, Oct 30, 2013 at 10:38 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > We are happy to announce version 4.9 of the Moose Suite: > http://moosetechnology.org/download/4.9 > > > This is a minor release still based on Pharo 2.0. The differences from > Moose 4.8 are: > > The Mondrian engine was removed. The transition to Roassal is now complete. > - Small fixes in Roassal layouts and rendering. > - Small fix in FAMIX regarding manipulation of accesses. > - Small visual fix in Glamour for rendering splitters in tables. > > A list of issues addressed in this release can be found at: > http://code.google.com/p/moose-technology/issues/list?can=1&q=status=Fixed%… > > The Moose Suite 4.9 comes for each platform as a separate bundle: > - Moose Suite 4.9 for Mac > https://dl.dropboxusercontent.com/u/18323746/Moose/moose_suite_4_9-mac.zip > - Moose Suite 4.9 for Windows > https://dl.dropboxusercontent.com/u/18323746/Moose/moose_suite_4_9-win.zip > - Moose Suite 4.9 for Linux > > https://dl.dropboxusercontent.com/u/18323746/Moose/moose_suite_4_9-linux.zip > > The Moose Suite 4.9 can also be loaded in a Pharo 2.0 image either from > the Configuration Browser, or by executing the following script: > > Gofer new > smalltalkhubUser: 'Moose' project: 'Moose'; > package: 'ConfigurationOfMoose'; > load. > ((Smalltalk at: #ConfigurationOfMoose) > project version: '4.9-snapshot') load >

Oct. 30, 2013

VirtualBox with host-only interface on Mavericks

by Max Leske

For all of you who use VirtualBox on OS X with host-only interfaces: VirtualBox on Mavericks will prevent the OS from shutting down if you have host-only interfaces configured (and will clutter your dock with VirtualBox iconsâ¦). You may use the attached bash script to fix the symptoms (thereâs no solution yet). You will need to edit the script to match the number of host-only interfaces you have configured. Cheers, Max

Oct. 30, 2013