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

Eclipse icons in Pharo
by Yuriy Tymchuk Oct. 30, 2013

Oct. 30, 2013

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

1 0

CI
by Camillo Bruni Oct. 30, 2013

Oct. 30, 2013

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

3 3

Preventing wrong use of Collection>>#randomForPicking
by Max Leske Oct. 30, 2013

Oct. 30, 2013

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

1 0

11635: Race condition in SequenceableCollection>>shuffle
by Max Leske Oct. 30, 2013

Oct. 30, 2013

Sven suggested posting this on the list for discussion, so here you go: > Maybe this should be discussed on the list, your are going to break API. > > Note that there is also #sort and #sorted with similar copy behavior. > > Also, I am not sure that basic operations should use mutexes to protect themselves by default: there is a cost when you are a single threaded user. Even in Java there are synchronized and non-synchronized versions of collections. IMHO, the protection should happen in your app, and basic collections do not have to be thread safe. > > Sven > >> #shuffle does not use Collection>>mutexForPicking as other users of #randomForPicking demonstrate. This can lead to race conditions (found in our application). >> >> In addition, there are now #shuffle, #shuffled, #shuffleBy: and #shuffledBy: where #shuffled and #shuffledBy: shuffle a copy and answers that. This is very confusing. >> >> I propose a fix where #shuffled and #shuffledBy: are renamed to #copyShuffle and #copyShuffledBy: and moved to the "copying" protocol. #shuffle and #copyShuffle will use the mutex to prevent race conditions.

6 17

moose 4.9
by Tudor Girba Oct. 30, 2013

Oct. 30, 2013

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

3 3

VirtualBox with host-only interface on Mavericks
by Max Leske Oct. 30, 2013

Oct. 30, 2013

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

1 0

Slides of my Lecture this morning..
by Marcus Denker Oct. 30, 2013

Oct. 30, 2013

Hi, I am just visiting Jordi Delgado in Barcelona and I gave a lecture in his course this morning. âAdvanced Reflection in Pharoâ, this is meant to be a lecture after an introduction to standard Smalltalk reflection. SlideShare http://www.slideshare.net/MarcusDenker/lecture-27685035 PDF http://marcusdenker.de/talks/13BarcelonaLecture/ Marcus

6 8

Tests with multiple processes
by Norbert Hartl Oct. 29, 2013

Oct. 29, 2013

Iâm working on project that deals with server to server communication. For the test suite it is necessary to simulate the two ends of the communication within one test. The problem is that in a single threaded environment you make a send call SC from server A to B but the response of B will happen before SC returned. That makes every state change the happens in A after SC bogus from a call flow perspective. There are two approaches that have their own problems. 1) Until now Iâm reordering parts of the call stack to simulate the return of a call before the actual call is sent. But now I have nested sends that make my simple approach not working anymore. I could elaborate my approach by using something like delimited continuations to make a less brittle approach to stack call reordering in order to cope with the problem. That would need some work and the stack in the debugger will look a little bit odd/confusing. 2.) The product will later have a dispatcher process that dispatches each send operation in its own process. That would solve one problem: the timing of when actions happen. But Iâm not sure if it will be easy to orchestrate actions in a way that I would call controlled in order to have reliable tests. Are there any approaches to simulate coroutines in a single thread environment or approaches to deal with multiple processes within one process? It is hard to explain and I hope my description of the problem is understandable thanks in advance, Norbert

6 13

How to change my user name
by Nicolas Cellier Oct. 29, 2013

Oct. 29, 2013

For some reasons, I am LucFabresse in the last Pharo 3.0 that I downloaded. I'd like to restore myself, where can I change the username? (I saw way too much code related...) The menu 'System>Switch User' of course does not work if it ever was the answer (PanelMorph does not understand layout:) I know what bleeding edge means, but all these little annoyances divert me from the contribution job I assigned to myself :( Nicolas

2 2

[Fuel] How to tell Fuel *not* to encode references?
by roberto.minelli＠usi.ch Oct. 29, 2013

Oct. 29, 2013

Hi, Iâm struggling with Fuel and I probably discovered my problem. When trying to serialize an object (that represents a development session, i.e., contains some meta-data (title, author, etc.) and some objects representing actions of the developer) I often encounter problem with some BlockClosureâs which are somewhat corrupt and Fuel crashes and cannot serialize them. We already discussed this issue in this mailing list a while ago with Max. I do not ask directly Fuel to serialize some BlockClosures, so my intuition is that Fuel serializes all the references to the objects I am trying to serialize. Am I right? Is there any way to tell Fuel not to do so? Cheers and thanks for the help, Roberto

4 15