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

Re: [Pharo-dev] [Pharo-users] [ANN] Launching Pharo on Ubuntu

by blake

Very nice. Works on Mint, too. Could use more feedback, maybe: It's not always clear when it's doing something when you create an image. On Mon, Sep 23, 2013 at 5:56 AM, Erwan Douaille <douailleerwan(a)gmail.com>wrote: > Thanks :) > > > 2013/9/23 Camillo Bruni <camillobruni(a)gmail.com> > >> good work! >> >> On 2013-09-23, at 09:13, Damien Cassou <damien.cassou(a)gmail.com> wrote: >> >> > For Ubuntu users who are using my PPA >> > (https://launchpad.net/~pharo/+archive/stable/) you can now launch >> > Pharo from either the Ubuntu Dashboard or the terminal (just type >> > 'pharo'). >> > >> > In both cases, you will see the Pharo Launcher from which you can >> > create new images from templates on the web and launch existing >> > images. http://www.smalltalkhub.com/#!/~Pharo/PharoLauncher >> > >> > No need for manual download of zip files, unpacking, and directory >> > management. The launcher does everything for you. >> > >> > Have fun >> > >> > -- >> > Damien Cassou >> > http://damiencassou.seasidehosting.st >> > >> > "Success is the ability to go from one failure to another without >> > losing enthusiasm." >> > Winston Churchill >> > <pharo-launcher-screenshot.png> >> >> > > > -- > Best regards, > > Douaille Erwan <douaille.erwan(a)gmail.com> >

Sept. 23, 2013

Re: [Pharo-dev] Use pharo users mailing list

by Stephan Eggermont

Hannes wrote: > In reply to this post by Stephan Eggermont > On 9/23/13, Stephan Eggermont <[hidden email]> wrote: > > Kilon wrote > >>Here is a radical suggestion you probably don't want to hear. > >>Close down Pharo users mailing list, redirect everyone to stackoverflow. > > > > Definitely not. Stackoverflow is nearly dead, and seriously unsuitable for > > small languages. > > There are obstacles but one cannot say that it is "seriously > unsuitable". I feel fully qualified to make that statement. Getting voted on by majority views is not exactly what we need. Especially not in a cargo-cult driven profession. > >Good questions will get closed by clueless people. > Mostly if the form does not fit. Nope. there has been a strong change in what is deemed to be an acceptable question on SO in the past years. And not in the right direction. I know several posters here who have been bitten by that. > And if there are Pharo people (maybe earned in another area) with > enough reputation points this may be prevented That would be nice, but isn't the case. Stackoverflow doesn't work like that. > > Good answers will get downvoted because they go against majority > > views. > > Why? Because stackoverflow is an opinion site, dominated by popularity. Nobody says an answer has to be right. Like I said, take a look at questions on OODBs. > >The ranking system is heavily skewed towards popular languages. > > It is based on the number of hits which is naturally less in less > popular languages. > However subcommunities may function well in stackoverflow. No, not really. It means that members of subcommunities have less rights and power. There is no value in subdividing our community further. Stephan

Sept. 23, 2013

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

by Nicolas Cellier

100% agree. Do it right > do it fast. We must not turn usage of the library into something fragile for the sake of speed. We already make the code itself fragile more often than not in term of complexity (harder to understand/test/change). Especially, introduction of shared mutable states (global, class vars, singleton or any other form) should ring an alarm in reviewers head (This is some very old Squeak code in this case, so Squeakers are to blame, but we're all in same bath). 2013/9/23 Henrik Johansen <henrik.s.johansen(a)veloxit.no> > > On Sep 23, 2013, at 3:33 , Max Leske <maxleske(a)gmail.com> wrote: > > >> > >> If a user is going to modify the same object concurrently, he/she takes > care of mutual exclusion. > > > > Agreed. BUT: the Random object used by these methods is the same one > that is used by #atRandom for instance, hence the race condition. There is > no way anyone can safely use these methods without the mutex, single > threaded or not. Calls to methods using that same Random object can be all > over the place and also in the base system. > > > It seems to me an existing Random instance is used in this case mostly* > for performance. > One could argue that since the Random in this case is used for a bulk > operation, for which the object creation cost is largely amortized for > collection sizes > 20, it's acceptable to instead use Random new by > default, which wouldn't suffer from the same race conditions. > While still slower than a mutex-protected version for single-threaded > code, it would also scale correctly if the users (and vm) are actually > multi-threaded. > > [#(1 2 3 4 5 6 7 8 9 10 11 12) shuffle] bench '208,000 per second.' > '222,000 per second.' '223,000 per second.' > [#(1 2 3 4 5 6 7 8 9 10 11 12) shuffleWithMutex] bench '188,000 per > second.' '186,000 per second.''184,000 per second.' > [#(1 2 3 4 5 6 7 8 9 10 11 12) shuffleNewRandom] bench '167,000 per > second.' '166,000 per second.' '167,000 per second.' > > Cheers, > Henry > > * Low seed entropy is another issue, but if purely random shuffling is a > critical requirement, one shouldn't use the default Random generator > anyways... > > >

Sept. 23, 2013

Code functionality assessment

by Natalia Tymchuk

Hello, I wrote another blog post concerning my project on Google Summer of Code, and there's how I assessed the results using Graph-ET. http://nataliatymchuk.blogspot.com/2013/09/code-functionality-assessment.ht… Best regard, Natalia

Sept. 23, 2013