January 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] CasInsensitiveOrder map with upper/lower case characters for all latin1 entries

by Henrik Johansen

> On 06 Jan 2016, at 10:09 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hallo Nicolai, > >> On 06 Jan 2016, at 09:58, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> >> >> see issues 17302/17242/17227 >> String>>findString:startindAt:caseSensitive appears to be failing for extended charsets >> String>>compare:caseSensitive seems to be failing for extended charset comparisons >> String>>beginsWithEmpty:caseSensitive: has test failure for some cases >> >> the problem is, the standard character set used for building the CaseInsensitiveOrder map >> only maps characters from the set of ascii characters but it is used in the findString/compare/beginsWith-methods for all byte characters. >> >> Any objections if we fill this map like it is suggested in case 17242 ? >> >> CaseInsensitiveOrder := AsciiOrder copy. >> (0 to: 255) do:[ :v | >> | char upper | >> char := v asCharacter. >> upper := char asUppercase. >> upper isOctetCharacter >> ifFalse: [ upper := char ]. >> CaseInsensitiveOrder at: char asciiValue + 1 put: (CaseInsensitiveOrder at: upper asciiValue + 1) ]. >> >> (the check for #isOctectCharacter is needed because for some entries the correspondending >> uppercase character is not within this character set). >> >> This would solve all three issues. >> >> >> nicolai > > That looks like a beautiful fix that makes perfect sense. > If all tests are green, I see no reason not to do it. > > Thanks and well done (again), > > Sven > > If you use asLowercase as the "canonical" ordering index instead, can you drop the isOctetCharacter test, or are there uppercase characters in latin1 with no corresponding lowercases? I was about to suggest copying the CaseSensitiveOrder mapping instead of the AsciiOrder, since it has an ordering more refined than just A-Z, but that would quickly lead to wanting to extend it to a generic Latin1 sort order rather than just ASCII (Ã© between e and f, for example), which is a can of worms that is hard to solve without making the ordering locale specific... I mean, one could use the default Unicode ordering, but would inevitably receive complaints from, say, Norwegians, that Ã¥ sorts between a and b instead of after z. After all, it only affects the case where compare is used for ordering anyways. Cheers, Henry

Jan. 6, 2016

Re: [Pharo-dev] [ANN] The next Pharo Sprints (Lille)

by phil＠highoctane.be

I have room for a couple people here near Wavre, Belgium. Also, there is the http://creativespark.be/ nearby and I think I can get things shaped for a Pharo sprint or two. Just tell me and I'll arrange for it. Phil On Wed, Jan 6, 2016 at 8:27 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hello, > > We looked at the calendar and fixed the dates for all public sprints that > we will do this > year here locally. These are all Fridays: > > 29 Januar > 26 Feb > 25 March > 29 April > 27 May > > They will be at the Inria Lille, Building B, third floor (RMoD offices). > Remotely, you can join us on Slack or the IRC channel #pharo on > irc.freenode.net server. During the sprint, we will try to synchronize > local and remote Pharo sprinters. > > One nice idea is to organise local sprints yourself. E.g. over the last > sprints we had one in Chile at the same time. > > Marcus > > > >

Jan. 6, 2016

ExternalSemaphoreTable strange mutual exclusion

by Ben Coman

In ExternalSemaphoreTable I noticed two class variables set by class initialization as: ProtectAdd := Semaphore forMutualExclusion. ProtectRemove := Semaphore forMutualExclusion and I'm curious, what are the TWO shared resources that these TWO are meant to protect? it seems there is only one, that being unprotectedExternalObjects. I notice that "ExternalSemaphoreTable class>>safelyUnregisterExternalObject:" stores unprotectedExternalObjects in its local variable "objects" and then up removes an object from it. But "ExternalSemaphoreTable class>>safelyRegisterExternalObject:" also stores unprotectedExternalObjects in its local variable "objects" which it then passes to "ExternalSemaphoreTable class>>collectionBasedOn:withRoomFor:" which takes a copy to grow a new collection to store into unprotectedExternalObjects. Even though its a rare case that the external semaphore might grow at just the same time that an object is being unregistered, and also practically #safelyUnregisterExternalObject: might not be preemptable, this smells bad having two mutual exclusions covering one resource - thus no mutual exclusion at all. Is there something I'm missing? cheers -ben

Jan. 6, 2016

Re: [Pharo-dev] CasInsensitiveOrder map with upper/lower case characters for all latin1 entries

by Sven Van Caekenberghe

Hallo Nicolai, > On 06 Jan 2016, at 09:58, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > see issues 17302/17242/17227 > String>>findString:startindAt:caseSensitive appears to be failing for extended charsets > String>>compare:caseSensitive seems to be failing for extended charset comparisons > String>>beginsWithEmpty:caseSensitive: has test failure for some cases > > the problem is, the standard character set used for building the CaseInsensitiveOrder map > only maps characters from the set of ascii characters but it is used in the findString/compare/beginsWith-methods for all byte characters. > > Any objections if we fill this map like it is suggested in case 17242 ? > > CaseInsensitiveOrder := AsciiOrder copy. > (0 to: 255) do:[ :v | > | char upper | > char := v asCharacter. > upper := char asUppercase. > upper isOctetCharacter > ifFalse: [ upper := char ]. > CaseInsensitiveOrder at: char asciiValue + 1 put: (CaseInsensitiveOrder at: upper asciiValue + 1) ]. > > (the check for #isOctectCharacter is needed because for some entries the correspondending > uppercase character is not within this character set). > > This would solve all three issues. > > > nicolai That looks like a beautiful fix that makes perfect sense. If all tests are green, I see no reason not to do it. Thanks and well done (again), Sven

Jan. 6, 2016

CasInsensitiveOrder map with upper/lower case characters for all latin1 entries

by Nicolai Hess

see issues 17302/17242/17227 String>>findString:startindAt:caseSensitive appears to be failing for extended charsets String>>compare:caseSensitive seems to be failing for extended charset comparisons String>>beginsWithEmpty:caseSensitive: has test failure for some cases the problem is, the standard character set used for building the CaseInsensitiveOrder map only maps characters from the set of ascii characters but it is used in the findString/compare/beginsWith-methods for all byte characters. Any objections if we fill this map like it is suggested in case 17242 ? CaseInsensitiveOrder := AsciiOrder copy. (0 to: 255) do:[ :v | | char upper | char := v asCharacter. upper := char asUppercase. upper isOctetCharacter ifFalse: [ upper := char ]. CaseInsensitiveOrder at: char asciiValue + 1 put: (CaseInsensitiveOrder at: upper asciiValue + 1) ]. (the check for #isOctectCharacter is needed because for some entries the correspondending uppercase character is not within this character set). This would solve all three issues. nicolai

Jan. 6, 2016

Re: [Pharo-dev] context mirror primitives

by Christophe Demarey

Le 6 janv. 2016 Ã 08:11, Marcus Denker a Ã©crit : > >> On 05 Jan 2016, at 21:04, stepharo <stepharo(a)free.fr> wrote: >> >> All the Inria integration got a problem and this is restarting to work. >> So we will get there. >> > > Something is still broken: > > https://ci.inria.fr/pharo/ > > all slaves are blocked with threads that are dead. It looks like Jenkins is mess up with a job number. I need to find the job causing that and I think I could fix that

Jan. 6, 2016

[ANN] The next Pharo Sprints (Lille)

by Marcus Denker

Hello, We looked at the calendar and fixed the dates for all public sprints that we will do this year here locally. These are all Fridays: 29 Januar 26 Feb 25 March 29 April 27 May They will be at the Inria Lille, Building B, third floor (RMoD offices). Remotely, you can join us on Slack or the IRC channel #pharo on irc.freenode.net server. During the sprint, we will try to synchronize local and remote Pharo sprinters. One nice idea is to organise local sprints yourself. E.g. over the last sprints we had one in Chile at the same time. Marcus

Jan. 6, 2016

Re: [Pharo-dev] context mirror primitives

by Marcus Denker

> On 05 Jan 2016, at 21:04, stepharo <stepharo(a)free.fr> wrote: > > All the Inria integration got a problem and this is restarting to work. > So we will get there. > Something is still broken: https://ci.inria.fr/pharo/ all slaves are blocked with threads that are dead. Marcus

Jan. 6, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Tudor Girba

Thanks! Doru > On Jan 6, 2016, at 12:56 AM, Ben Coman <btc(a)openInWorld.com> wrote: > > okay. I'll have a go. > cheers -ben > > On Wed, Jan 6, 2016 at 3:28 AM, stepharo <stepharo(a)free.fr> wrote: >> Ben >> >> would you not be interested to write a little chapter on concurrency because >> we would all benefit from it. >> I can help but I'm pretty bad with concurrency. >> I'm sure that doing that we will find a lot of things to improve in Pharo :) >> >> Stef >> >> Le 5/1/16 18:15, Ben Coman a Ã©crit : >> >>> On Tue, Jan 5, 2016 at 11:59 PM, Denis Kudriashov <dionisiydk(a)gmail.com> >>> wrote: >>>> >>>> 2016-01-05 16:06 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >>>>> >>>>> btw I have this growing suspicion that we should eliminate >>>>> Semaphore>>critical: and Semaphore>>forMutualExclusion. Semaphores >>>>> on their own should *not* provide a facility for to protect critical >>>>> regions since they suffer from accidental release [1] due to >>>>> *lack*of*ownership*. >>>> >>>> >>>> I have same feeling when analyse problem of critical: implementation. But >>>> I >>>> not think that Semaphore>>forMutualExclusion is bad. >>> >>> But Semaphore>>forMutualExclusion *encourages* people to believe >>> semaphores can be used *on*their*own* for mutual exclusion, when they >>> *shouldn't*. You *must* add ownership. If the mutual exclusion >>> object doesnât have ownership then, irrelevant of what it is called, >>> it is not a mutex!!! [1]. >>> >>> "Strictly speaking [2]... >>> -- A mutex is *locking* mechanism used to synchronize access to a >>> resource. Only one task (can be a thread or process based on OS >>> abstraction) can acquire the mutex. It means there is *ownership* >>> associated with mutex, and only the owner can release the lock >>> (mutex). >>> -- A semaphore is *signaling* mechanism (âI am done, you can carry >>> onâ kind of signal). For example, if you are listening songs (assume >>> it as one task) on your mobile and at the same time your friend calls >>> you, an interrupt is triggered upon which an interrupt service routine >>> (ISR) signals the call processing task to wakeup >>> >>> >>>> It is common case that semaphore "free" by default. >>> >>> With an implementation like.. >>> Semaphore>>forMutualExclusion >>> ^self new signal >>> >>> we don't gain a lot, and its a misleading convenience method since its >>> doesn't provide the proper facility for mutual exclusion (and I do >>> conflate mutual exclusion == mutex). Indeed, "Semaphore >>> forMutualExclusion + roll your ownership management + problems since >>> you weren't aware you needed to roll your own ownership management" is >>> not more convenient than "Mutex new" >>> >>> If you want to keep a convenience method for a pre signalled >>> Semaphore, then we could provide something like "Semaphore >>> newSignalled" >>> >>>> And this name is explicitly said about this. >>> >>> Actually no. It explicitly says it provides mutual exclusion - which >>> without ownership, it does not. It only implicitly provides a >>> pre-signalled Semaphore - you have to *know* of look at the source. >>> >>> [1] >>> https://blog.feabhas.com/2009/09/mutex-vs-semaphores-%E2%80%93-part-2-the-m… >>> [2] http://www.geeksforgeeks.org/mutex-vs-semaphore/ >>> >>> cheers -ben >>> >>> >> >> > -- www.tudorgirba.com www.feenk.com "Reasonable is what we are accustomed with."

Jan. 6, 2016

Re: [Pharo-dev] small refactor on files.pharo.org

by Dimitris Chloupis

thank you :) On Tue, Jan 5, 2016 at 9:57 PM Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > On 05 Jan 2016, at 20:06, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > but this still works as expected yes ? > > wget -O- get.pharo.org/alpha+vmLatest | bash > > > yes > > > > > On Tue, Jan 5, 2016 at 8:23 PM Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> On 05 Jan 2016, at 19:14, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: >> >> What's the recommended way of loading the VM through zeroconf scripts? >> >> Just http://get.pharo.org/vm loads the non-spur vm and >> http://get.pharo.org/vm50 loads the spur one. Will >> http://get.pharo.org/vm be updated to the spur one in the future? >> >> >> Hi, >> >> no it will not be updated. >> In fact if you see is not listed anymore (since almost one year now). It >> is just there for backward compatibility. >> >> you need to use the VM corresponding with your image version (in case of >> Pharo 50, vm50). >> >> Esteban >> >> ps: this was described when I made the change like one year agoâ¦ but now >> I do not find the mail :P >> >> >> Cheers, >> Andrei >> >> On Tue, Jan 5, 2016 at 11:47 AM, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> >>> I move old VMs from files.pharo.org/vm to files.pharo.org/vm/old >>> >>> because it was confusing and some students were lost (Stef too :P). >>> >>> cheers, >>> Esteban >>> >> >>

Jan. 5, 2016