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

Re: [Pharo-dev] LDAP - licensing....

by StÃ©phane Ducasse

Hi olivier I migrated the code and added a configuration with metadata for the catalog. And indeed it would be nice to do a pass on the chapter because it looks strange to me. Stef On Sep 28, 2013, at 11:48 AM, Olivier Auverlot <olivier.auverlot(a)gmail.com> wrote: > Yes, as Stef says, I use LDAPlayer everyday at work and it run fine :-) > > Some month ago, I wrote a draft of an article about LDAPlayer. If you read french, you can download it from http://perso.numericable.fr/~oauverlo/pharo/ldap.pdf > > The article isn't completed but contains some informations. I plan to rewrite it... > > Best regards > Olivier ;-) > > > Le 27 sept. 2013 Ã 22:45, phil(a)highoctane.be a Ã©crit : > >> Ah ah, thanks!! >> >> I am doing some Stamp with RabbitMQ over here. Works. >> >> /Phil > >

Sept. 28, 2013

Re: [Pharo-dev] LDAP - licensing....

by Olivier Auverlot

Yes, as Stef says, I use LDAPlayer everyday at work and it run fine :-) Some month ago, I wrote a draft of an article about LDAPlayer. If you read french, you can download it from http://perso.numericable.fr/~oauverlo/pharo/ldap.pdf The article isn't completed but contains some informations. I plan to rewrite it... Best regards Olivier ;-) Le 27 sept. 2013 Ã 22:45, phil(a)highoctane.be a Ã©crit : > Ah ah, thanks!! > > I am doing some Stamp with RabbitMQ over here. Works. > > /Phil

Sept. 28, 2013

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

by Max Leske

On 23.09.2013, at 15:46, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 23 September 2013 14:34, Max Leske <maxleske(a)gmail.com> wrote: >> >> On 23.09.2013, at 15:20, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> >>> On 23 September 2013 14:17, 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. >>>> >>>> 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. >>> >>> Especially since locks don't compose. If you _really_ cared about >>> accessing something concurrently, you'd share immutable data >>> structures. >> >> I don't quite follow. Could you elaborate? > > Hopefully it's uncontroversial to assert that locks don't compose. > > If you only ever have one thread of execution, you don't have any > concurrency issues, and locks serve no purpose. > > If you do have multiple threads of execution, then you have a few > choices for sharing data: > * you can use a lock around mutable data (but lock-using blocks of > code don't compose, so you end up with loads of bugs or deadlocks or > nests of locks, or all of the above) > * you can share a _copy_ of data. > > In the latter case, you can share an actual copy, or share a pointer > to a structure that can't change. If it can't change, you can't have a > reader accidentally reading something from a structure halfway through > the writer writing to it. > > Sharing some immutable chunk of state lets you save the memory taken > up by a copy, but also prevents all the race condition things you > usually get with shared mutable state. > > frank Thanks Frank, I get it now. And I agree. > > >>> frank >>> >>>> 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. 28, 2013

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

by Max Leske

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 On 24.09.2013, at 02:33, btc(a)openInWorld.com wrote: > Nicolas Cellier wrote: >> >> The reason why I don't like the explicit "copy", is because this is the >> default behaviour. >> In place mutation is an (evil) exception. >> I'm personnally fine with current conventions: >> - sort, shuffle, reverse, replace: are imperative, thus you are telling >> collection, sort yourself ! >> - sorted clearly sounds as a sorted copy for me. >> If ever a change was to be made, I would much prefer this to happen on >> opposite naming, sort -> inPlaceSort, or sortYourself :) >> It's like telling the programmer, hey - a stateful mutation is really what >> you want, is it? >> > > Conventions should encourage good programming practice. Although it makes perfect sense on hearing it, I was explicitly not aware of the convention between 'sort' and 'sorted'. For me, the small difference in letters used between the two doesn't provide a wide enough distinction. Also, regarding not mutating state, I guess I knew that in the back of my head, but it has not generally been an explicit concern of mine while programming. Convention should encourage good programming. So I like the suggestion of inPlaceSort & sortYourself. As well as being more intention revealing, the less desirable methods are made less attractive by using a longer name. Perhaps another naming convention could be mutatedSort, or mutSort as a hint that the programmer should consider using these in conjunction with mutexes, or at own risk. > > cheers -ben > > > >> >> 2013/9/23 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> >> >>> +1 >>> Now I understand the point of max with the name sort/sorted because this >>> is not explicit to me too :) >>> I laways have to think. >>> >>> On Sep 23, 2013, at 6:28 PM, Nicolas Cellier < >>> nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> >>> 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. 28, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation/label=wi… 1 regressions found. Zinc.Tests.ZnServerTests.testEntityTooLarge

Sept. 28, 2013

Re: [Pharo-dev] [Issue Tracker] input of submitters/bug fixers needed

by StÃ©phane Ducasse

Agreed. stef On Sep 28, 2013, at 5:39 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > we have a couple of statuses that come close to that: > > Resolved Postponed > > indeed Postponed should be close to stale and I understand Sean concerns. > > Yes, that sounds like it could work. If we standardize on using Postponed when closing issues where it's not clear if it's actually resolved, that would be a definite improvement. > > - s > Cheers, > Sean > > View this message in context: Re: [Issue Tracker] input of submitters/bug fixers needed > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 28, 2013

Re: [Pharo-dev] [Issue Tracker] input of submitters/bug fixers needed

by Sean P. DeNigris

we have a couple of statuses that come close to that:Â > Resolved Postponed indeed Postponed should be close to stale and I understand Sean concerns.Â Yes, that sounds like it could work. If we standardize on usingÂ PostponedÂ when closing issues where it's not clear if it's actually resolved, that would be a definite improvement. - s ----- Cheers, Sean -- View this message in context: http://forum.world.st/Issue-Tracker-input-of-submitters-bug-fixers-needed-t… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 28, 2013

Re: [Pharo-dev] LDAP - licensing....

by phil＠highoctane.be

Ah ah, thanks!! I am doing some Stamp with RabbitMQ over here. Works. /Phil

Sept. 27, 2013

Re: [Pharo-dev] LDAP - licensing....

by StÃ©phane Ducasse

Hi phil I migrated it to SmalltalkHub under PharoExtras/LDAP I'm writing the configuration since I love doing that. Stef On Sep 27, 2013, at 6:15 PM, phil(a)highoctane.be wrote: > Hello, > > I am looking for an LDAP integration for Pharo 2.0 > > After googling, I found LDAPlayer > > On Squeaksource: > > http://www.squeaksource.com/@O_tBkvZNK0GC3Hlz/Ghl6udGE > > I saw from the mailing lists that Olivier Auverlot did some work on that. > > It would be good to have such a thing on Smalltalkhub. > > Maybe I missed it but the query returned no results there. > > Thx > Phil >

Sept. 27, 2013

Re: [Pharo-dev] LDAP - licensing....

by StÃ©phane Ducasse

BTW olivier uses it heavily for his daily work. stef On Sep 27, 2013, at 6:15 PM, phil(a)highoctane.be wrote: > Hello, > > I am looking for an LDAP integration for Pharo 2.0 > > After googling, I found LDAPlayer > > On Squeaksource: > > http://www.squeaksource.com/@O_tBkvZNK0GC3Hlz/Ghl6udGE > > I saw from the mailing lists that Olivier Auverlot did some work on that. > > It would be good to have such a thing on Smalltalkhub. > > Maybe I missed it but the query returned no results there. > > Thx > Phil >

Sept. 27, 2013