- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Help with reviewing needed

by StÃ©phane Ducasse

On Sep 23, 2013, at 5:23 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 23/09/2013 17:11, Camillo Bruni a Ã©crit : >> These are all cases with the status "Fix Review Needed" >> >> => load the changes in a fresh 3.0 image > > Some of the fixes are for 2.0 :) > >> => review the changes >> => leave feedback in the issue tracker >> - positive => set the status to "Fix to Include" >> - negative => set the status to "Work Needed" > > I'm not allowed to set the status to "Work Needed" (I'm looking at 11628), so maybe reviewing is not for everybody on the mailing-list? Strange, you have a fogbugz account I imagine so in that case I do not understand anything. Because normally we all can tag entries. > > Thierry > >> On 2013-09-23, at 12:02, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >> >>> These are all closed things in Inbox. >>> >>> What's the help about? >>> >>> Phil >>> >>> >>> >>> On Mon, Sep 23, 2013 at 4:08 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: >>> >>>> Hi, >>>> >>>> It would really be helpful if more people would review: >>>> >>>> https://pharo.fogbugz.com/f/filters/36/Review >>>> >>>> because if it has to wait for me, it might wait for a very long time. >>>> >>>> Marcus >>>> >> > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

Sept. 23, 2013

Re: [Pharo-dev] Help with reviewing needed

by Goubier Thierry

Le 23/09/2013 17:11, Camillo Bruni a Ã©crit : > These are all cases with the status "Fix Review Needed" > > => load the changes in a fresh 3.0 image Some of the fixes are for 2.0 :) > => review the changes > => leave feedback in the issue tracker > - positive => set the status to "Fix to Include" > - negative => set the status to "Work Needed" I'm not allowed to set the status to "Work Needed" (I'm looking at 11628), so maybe reviewing is not for everybody on the mailing-list? Thierry > On 2013-09-23, at 12:02, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > >> These are all closed things in Inbox. >> >> What's the help about? >> >> Phil >> >> >> >> On Mon, Sep 23, 2013 at 4:08 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: >> >>> Hi, >>> >>> It would really be helpful if more people would review: >>> >>> https://pharo.fogbugz.com/f/filters/36/Review >>> >>> because if it has to wait for me, it might wait for a very long time. >>> >>> Marcus >>> > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Sept. 23, 2013

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

by StÃ©phane Ducasse

On Sep 23, 2013, at 3:17 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Here is my 100% personal opinion: > > I don't like the copyShuffle. > To me, the rules are quite clear: > sort shuffle reverse etc... -> perform modification in place > sorted shuffled reversed etc... -> answer a copy > I hope the methods comments are clear. Does PBE tells about these conventions? It would be a good thing. I do not remember. Because probably that we wrote it before. I will log it and see for the next release of PBE. > And I don't like to have mutexes in base library, the less we have, the better. > If a user is going to modify the same object concurrently, he/she takes care of mutual exclusion. > > > 2013/9/23 Max Leske <maxleske(a)gmail.com> > 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. >

Sept. 23, 2013

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

by Henrik Johansen

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

Re: [Pharo-dev] Help with reviewing needed

by Camillo Bruni

These are all cases with the status "Fix Review Needed" => load the changes in a fresh 3.0 image => review the changes => leave feedback in the issue tracker - positive => set the status to "Fix to Include" - negative => set the status to "Work Needed" On 2013-09-23, at 12:02, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > These are all closed things in Inbox. > > What's the help about? > > Phil > > > > On Mon, Sep 23, 2013 at 4:08 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > >> Hi, >> >> It would really be helpful if more people would review: >> >> https://pharo.fogbugz.com/f/filters/36/Review >> >> because if it has to wait for me, it might wait for a very long time. >> >> Marcus >>

Sept. 23, 2013

Re: [Pharo-dev] Help with reviewing needed

by phil＠highoctane.be

These are all closed things in Inbox. What's the help about? Phil On Mon, Sep 23, 2013 at 4:08 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > Hi, > > It would really be helpful if more people would review: > > https://pharo.fogbugz.com/f/filters/36/Review > > because if it has to wait for me, it might wait for a very long time. > > Marcus >

Sept. 23, 2013

Re: [Pharo-dev] [NB] Trying to implement a ReadStream on NBExternalAddress

by Camillo Bruni

Hi Jan, I think I will add the ByteArray accessor to NBExternalAddress today or tomorrow since I need it as well for another project. Concerning the Streams, I think it is the easiest solution to wrap around a ByteArray. Otherwise you could subclass one of the main stream classes and implement your own primitive methods with FFI to read and write bytes. In the worst case you will have to implement all primitive methods with FFI that you find in the StandardFileStream. On 2013-09-22, at 10:12, Jan van de Sandt <jvdsandt(a)gmail.com> wrote: > Hello, > > I'm trying to implement a binary ReadStream that gets its data not from a > Smalltalk collection but from some external memory address. I got this > address from a library call using NativeBoost. > > The NBExternalAddress has methods to access bytes, int's and longs but > there is no method to get a ByteArray starting at a specified offset and > with a specified length. I need a method like this to implement the > ReadStream>>next: method efficiently. > > Is it possible ti implement such a method or are there other ways to > implement a ReadStream efficiently? > > In [1] I read that there was already an idea to implement a nbAddressAt: > method. This would also be using in combination with NativeBoost > class>>#memCopy:to:size > > Regrads, > Jan. > > [1] > http://forum.world.st/Pharo-dev-NB-Review-amp-fixes-amp-ideas-td4698514.html

Sept. 23, 2013

Re: [Pharo-dev] Integration Process

by Esteban A. Maringolo

Please, this is very well received! I have no clue on how to contribute back, it is not a streamlined process. Thank you Camillo. Esteban A. Maringolo 2013/9/23 Camillo Bruni <camillobruni(a)gmail.com>: > > On 2013-09-23, at 05:13, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> >> On Sep 23, 2013, at 6:21 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >>> I spent today 10mins explaining step by step on how to regular Pharo programmers how to create a bugfix for Pharo! >>> >>> THIS IS BAD! >>> >>> There are many more motivated Pharo programmers outside RMoD, and I am sure that quite some >>> of them would actually provide bug fixes. The current bug-report process has a way too steep >>> learning curve. >>> >>> >>> There are a few things we have to change here: >>> >>> 1. make bugs.pharo.org finally work with dots in the email message >>> 2. make bugs.pharo.org automatically send a password reset request (in the worst case we do a redirect/curl on the normal fogbugz site) >>> 3. make the anonymous inbox work on the smalltalkhub >> >> I would not say anonymous... public, yes :) > > yes this is what I meant, committing without having to be added manually to the contributors list.

Sept. 23, 2013

Help with reviewing needed

by Marcus Denker

Hi, It would really be helpful if more people would review: https://pharo.fogbugz.com/f/filters/36/Review because if it has to wait for me, it might wait for a very long time. Marcus

Sept. 23, 2013

Re: [Pharo-dev] Extending HelpTopic

by kilon

ok thank you for the clarifications :) -- View this message in context: http://forum.world.st/Extending-HelpTopic-tp4709645p4709786.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 23, 2013