- Pharo-dev - lists.pharo.org

About SqNumberParser
by StÃ©phane Ducasse Oct. 30, 2013

Oct. 30, 2013

Hi nicolas We would really like to have only one number parser in Pharo as well as handling the 1.0s syntax marcus raised a question that I could not answer. Do you habve nfrmation to share with us so that we can take a decision? Stef so the strange thing is that this is *explicitly* implemented in SqNumberParser to not allow 2.0s - do not allow single s without following digits as ScaledDecimal It is not explained why this is a good idea. In general, we need to merge the whole NumberParser hierarchy into one class, i don't understand why we have three classes now.

5 10

missing updates: 30503 30504
by Camillo Bruni Oct. 30, 2013

Oct. 30, 2013

What happened with those updates? Why are there no images? If something like this happens, the git exporter needs to be properly reset, otherwise we don't have consecutive numbers :/ We really need to invest a couple of sprints in creating an integration UI, ben and I started this 2 years ago and it lies dormant since then. The current way is just too brittle...

8 34

smalltalkhub down
by Sebastian Sastre Oct. 30, 2013

Oct. 30, 2013

heads up o.O

5 6

Pharo presentation at Smalltalk 2013
by StÃ©phane Ducasse Oct. 30, 2013

Oct. 30, 2013

http://www.slideshare.net/pharoproject/2013smalltalksconference-pharo-is-yo… Stef

4 3

Changing non-copying selectors to #...InPlace
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. 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

3 2

Image Stability
by Camillo Bruni Oct. 30, 2013

Oct. 30, 2013

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.

2 2

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