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

Re: [Pharo-dev] [Pharo-users] gtdebugger in pharo 5.0

by Alexandre Bergel

This is an excellent news! I have been waiting for that for long! go go go! Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Jan 8, 2016, at 8:07 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > We are about to integrate in Pharo a new member of the Glamorous Toolkit: the GTDebugger. As this is a significant change that might affect your workflow, here is some background information to help you deal with the change. > > First, you should know that the change is not irreversible and it is easily possible to disabled the new debugger through a setting. However, please do take the time to provide us feedback if something does not work out for you. We want to know what can be improved and we try to react as fast as we can. > > A practical change comes from the fact that the variables are manipulated through a GTInspector, which makes it cheaper to maintain in the longer run. > > While the first thing that will capture the attention is the default generic interface, the real power comes from the moldable nature of the debugger. Like all other GT tools, GTDebugger is also moldable by design. This means that we can construct custom debuggers for specific libraries at small costs (often measured in a couple of hundred lines of code). > > For example, the core configuration includes also the SUnit and the bytecode debugger. These are around 150 lines of code. Here is how the bytecode debugger looks like: > > <bytecode.png> > > You can find more information in an introductory overview blog post that also includes some links for further reading: > http://www.humane-assessment.com/blog/gtdebugger-in-pharo/ <http://www.humane-assessment.com/blog/gtdebugger-in-pharo/> > > Please let us know what you think. > > Cheers, > Doru > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > www.feenk.com > > "What is more important: To be happy, or to make happy?" >

Jan. 8, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Ben Coman

Long standing Case 5959 "Process suspension and Semaphore clash" seems related... https://pharo.fogbugz.com/default.asp?5959 cheers -ben On Fri, Jan 8, 2016 at 10:45 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > I not understand. Is you code is working for you? > > This test return nil on my image: > > sema := Semaphore new. > p:= [ sema waitIfCurtailed: [ r := p suspendingList ] ] fork. > 1 seconds wait. > p terminate2. "your implementation" > r. > > > And what I try to said is as soon as suspend called on waiting process > semaphore is not anymore on it suspendingList. > > > > 2016-01-08 15:35 GMT+01:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: >> >> >> On 08 Jan 2016, at 3:24 , Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> >> >> 2016-01-08 15:17 GMT+01:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: >>> >>> Which is why in terminate I do >>> myList := self suspend. >>> >>> So the semaphore *should* still be the suspendingList, just without the >>> process actually on the list... >> >> >> I just test it in workspace. >> >> sema := Semaphore new. >> p := [sema wait] fork. >> p suspend. >> p suspendingList == nil >> >> sema asArray isEmpty >> >> >> >> Of course, that's something entirely different... >> if you do what I actually do in the modified terminate; >> sema := Semaphore new. >> p := [sema wait ] newProcess. >> p resume. >> 1 second wait. >> list := p suspend. >> "this list is (re)assigned to myList in terminate" >> list == nil >> list == sema >> >> You should get different answers. >> >> Cheers, >> Henry >> >> >

Jan. 8, 2016

Re: [Pharo-dev] Setup Locale for Italy country

by Sven Van Caekenberghe

But even so, there is totally no provision in the image to magically change for example date formatting or parsing based on (one global default) locale, let alone the decimal or thousands separators. One could even argue whether that would be a good idea or not. The alternative would be for you to use the appropriate formatters/parsers where you produce/consume user visible text. There are certainly provisions for doing that, as well as several external frameworks that can help. > On 08 Jan 2016, at 15:39, Max Leske <maxleske(a)gmail.com> wrote: > > Wow! Locale seems to be seriously broken: variables have not accessors, primitives have not senders... > > It seems that the primitives can be used without problems to access the locale properties of the host OS but it seems that itâs not possible to switch the locale. > > >> On 08 Jan 2016, at 12:17, Trussardi Dario Romano <dario.trussardi(a)tiscali.it> wrote: >> >> Ciao, >> >> i work with Pharo4.0 Latest update: #40625 >> >> Now i need to setup the system to manage the Italy country >> >> - decimalSymbol ( , ) >> - currencySymbol ( â¬ ) >> >> -dateFormat dd-MM-yyyy HH:mm >> >> How i can do it ? >> >> What is the Pharo system status about localization ? >> >> The: Locale current answer aLocale instance >> >> with id set to it-It >> >> but with all variables set to nil. >> >> >> Thanks for any considerations, >> >> Dario > >

Jan. 8, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Denis Kudriashov

I not understand. Is you code is working for you? This test return nil on my image: sema := Semaphore new. p:= [ sema waitIfCurtailed: [ r := p suspendingList ] ] fork. 1 seconds wait. p terminate2. "your implementation" r. And what I try to said is as soon as suspend called on waiting process semaphore is not anymore on it suspendingList. 2016-01-08 15:35 GMT+01:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > On 08 Jan 2016, at 3:24 , Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-01-08 15:17 GMT+01:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > >> Which is why in terminate I do >> myList := self suspend. >> >> So the semaphore *should* still be the suspendingList, just without the >> process actually on the list... >> > > I just test it in workspace. > > sema := Semaphore new. > p := [sema wait] fork. > p suspend. > p suspendingList == nil > > sema asArray isEmpty > > > > Of course, that's something entirely different... > if you do what I actually do in the modified terminate; > sema := Semaphore new. > p := [sema wait ] newProcess. > p resume. > 1 second wait. > list := p suspend. > "this list is (re)assigned to myList in terminate" > list == nil > list == sema > > You should get different answers. > > Cheers, > Henry > > >

Jan. 8, 2016

Re: [Pharo-dev] Setup Locale for Italy country

by Max Leske

Wow! Locale seems to be seriously broken: variables have not accessors, primitives have not senders... It seems that the primitives can be used without problems to access the locale properties of the host OS but it seems that itâs not possible to switch the locale. > On 08 Jan 2016, at 12:17, Trussardi Dario Romano <dario.trussardi(a)tiscali.it> wrote: > > Ciao, > > i work with Pharo4.0 Latest update: #40625 > > Now i need to setup the system to manage the Italy country > > - decimalSymbol ( , ) > - currencySymbol ( â¬ ) > > -dateFormat dd-MM-yyyy HH:mm > > How i can do it ? > > What is the Pharo system status about localization ? > > The: Locale current answer aLocale instance > > with id set to it-It > > but with all variables set to nil. > > > Thanks for any considerations, > > Dario

Jan. 8, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Henrik Johansen

> On 08 Jan 2016, at 3:24 , Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-01-08 15:17 GMT+01:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>>: > Which is why in terminate I do > myList := self suspend. > > So the semaphore *should* still be the suspendingList, just without the process actually on the list... > > I just test it in workspace. > sema := Semaphore new. > p := [sema wait] fork. > p suspend. > p suspendingList == nil > sema asArray isEmpty > Of course, that's something entirely different... if you do what I actually do in the modified terminate; sema := Semaphore new. p := [sema wait ] newProcess. p resume. 1 second wait. list := p suspend. "this list is (re)assigned to myList in terminate" list == nil list == sema You should get different answers. Cheers, Henry

Jan. 8, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Denis Kudriashov

2016-01-08 15:17 GMT+01:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > Which is why in terminate I do > myList := self suspend. > > So the semaphore *should* still be the suspendingList, just without the > process actually on the list... > I just test it in workspace. sema := Semaphore new. p := [sema wait] fork. p suspend. p suspendingList == nil sema asArray isEmpty

Jan. 8, 2016

Re: [Pharo-dev] Changing performance balance between CPU & non-volatile storage

by Ben Coman

On Fri, Jan 8, 2016 at 9:17 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > On 07-01-16 20:07, Ben Coman wrote: >> >> An enlightening article (if a bit long). I wonder how non-volatile >> storage being faster than a CPU might affect Pharo systems. Perhaps >> the importance of migrating between live and backup Images gains in >> importance to backups via files. > > > I'm not sure what to think about it. I find it an rather vague and badly > written article. 100K iops is not close to saturating what a CPU core can > process. The problem is the communication and the article does a really good > job at confusing me about that. Further, commercial pricing is value based, > not cost. > > Stephan Yeah, I think I'll have to retract that about being enlightening, rather just a faÃ§ade of enlightenment. Many of the follow up comments on slashdot hit criticised it along the same lines and that its point of view is that of vendors selling fast-nvram. I probably shouldn't have posted it. Sorry for the noise. cheers -ben

Jan. 8, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Henrik Johansen

> On 08 Jan 2016, at 3:07 , Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Yes. When process suspend called during termination process has no more semaphore as suspendingList Which is why in terminate I do myList := self suspend. So the semaphore *should* still be the suspendingList, just without the process actually on the list... Seems to me something strange happens between setting activeProcess using execute:onBehalfOf: and when it reaches the ifCurtailed block, at that point the terminating thread is no longer the "active" process. Cheers, Henry > > 2016-01-08 14:56 GMT+01:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>>: > Ugh, there's a bug with the Processor activeProcess suspendingList, I only checked in the case where it *should* signal. > Take it as an inspiration :) > > Cheers, > Henry > >> On 08 Jan 2016, at 2:40 , Henrik Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>> wrote: >> >> Here's an alternative implementation, which, instead of checking for the new method name, hooks into the existing unwind machinery to execute the waitIfCurtailed: argument. >> Which removes the special case from Process >> #terminate, but at the added cost that in-progress unwinds are executed as if the (suspended) terminating thread they started executing on, is still the active process. (Which, arguably, should be done anyways) >> >> Cheers, >> Henry >> >> <SignalUsingUnwindMachinery.cs> >> >> >> "This runs on UI thread, pri 40" >> waiter := Semaphore new. >> waiter2 := Semaphore new. >> lock := Semaphore forMutualExclusion. >> >> proc := [lock critical2: [ Transcript crShow: '1 start'. >> waiter wait. >> Transcript crShow: '1 done'.]] newProcess. >> proc priority: 70. >> proc resume. >> >> proc2 := [lock critical2: [ Transcript crShow: '2 start'. >> waiter2 wait. >> Transcript crShow: '2 done'. ]] newProcess. >> proc2 priority: 15. >> proc2 resume. >> >> "Yield for proc2 so it gets to waiting on lock" >> 1 second wait. >> "Signal waiter and yield, causing proc1 to run, and release the lock. lock will then remove proc2 from waiting list" >> waiter signal. >> Processor yield. >> "We have a higher pri than proc2, and will resume execution here before proc2 has chance to run" >> proc2 terminate. >> "proc2 has been curtailed before running, thus ifCurtailed: guard is still on stack and will be run as part of termination." >> (lock instVarNamed: 'excessSignals') 1 >>> On 07 Jan 2016, at 11:09 , Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >>> >>> Ok. slice 17340 <https://pharo.fogbugz.com/f/cases/17340/Semaphore-critical-should-handle-in…> in inbox. It is only touches current #critical: implementation. It is not about deprecation wrong semaphore usage >>> >>> 2016-01-07 9:55 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: >>> >>> 2016-01-07 0:15 GMT+01:00 Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>>: >>> >>> I'm not qualified to judge, but is sounds okay. I have an alternative >>> proposal to consider that hopefully might remove Semaphore handling >>> completely from Process>>terminate. >>> >>> What if we have a wait primitive that instead of returning itself >>> (i.e. a Semaphore), it always returns true. Then if the process is >>> terminated while the primitive is waiting, before it consumes a >>> signal, the assignment to signalConsumed never occurs. Then we >>> have... >>> >>> critical: mutuallyExcludedBlock >>> signalConsumed := false. >>> [ >>> signalConsumed := self primWaitSucceeded. >>> blockValue := mutuallyExcludedBlock value >>> ] ensure: [ signalConsumed ifTrue: [self signal] ]. >>> ^blockValue >>> >>> It *feels* more atomic. Someone knowledgeable with the vm would need >>> to advise whether after the primitive wakes up and consumes a signal, >>> the assignment into signalConsumed can be guaranteed to occur before >>> the process gets a chance to terminate, even if the primitive needs to >>> directly poke the value into signalConsumed. >>> >>> To me it is better too. But it requires changes in VM primitive which I'm can't provide. >>> So I will implement my idea. Do you ok with the name #waitIfInterrupted? >>> >> > >

Jan. 8, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Denis Kudriashov

Yes. When process suspend called during termination process has no more semaphore as suspendingList 2016-01-08 14:56 GMT+01:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > Ugh, there's a bug with the Processor activeProcess suspendingList, I only > checked in the case where it *should* signal. > Take it as an inspiration :) > > Cheers, > Henry > > On 08 Jan 2016, at 2:40 , Henrik Johansen <henrik.s.johansen(a)veloxit.no> > wrote: > > Here's an alternative implementation, which, instead of checking for the > new method name, hooks into the existing unwind machinery to execute the > waitIfCurtailed: argument. > Which removes the special case from Process >> #terminate, but at the > added cost that in-progress unwinds are executed as if the (suspended) > terminating thread they started executing on, is still the active process. > (Which, arguably, should be done anyways) > > Cheers, > Henry > > <SignalUsingUnwindMachinery.cs> > > > "This runs on UI thread, pri 40" > waiter := Semaphore new. > waiter2 := Semaphore new. > lock := Semaphore forMutualExclusion. > > proc := [lock critical2: [ Transcript crShow: '1 start'. > waiter wait. > Transcript crShow: '1 done'.]] newProcess. > proc priority: 70. > proc resume. > > proc2 := [lock critical2: [ Transcript crShow: '2 start'. > waiter2 wait. > Transcript crShow: '2 done'. ]] newProcess. > proc2 priority: 15. > proc2 resume. > > "Yield for proc2 so it gets to waiting on lock" > 1 second wait. > "Signal waiter and yield, causing proc1 to run, and release the lock. lock > will then remove proc2 from waiting list" > waiter signal. > Processor yield. > "We have a higher pri than proc2, and will resume execution here before > proc2 has chance to run" > proc2 terminate. > "proc2 has been curtailed before running, thus ifCurtailed: guard is still > on stack and will be run as part of termination." > (lock instVarNamed: 'excessSignals') 1 > > On 07 Jan 2016, at 11:09 , Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Ok. slice 17340 > <https://pharo.fogbugz.com/f/cases/17340/Semaphore-critical-should-handle-in…> > in inbox. It is only touches current #critical: implementation. It is not > about deprecation wrong semaphore usage > > 2016-01-07 9:55 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> >> 2016-01-07 0:15 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >> >>> >>> I'm not qualified to judge, but is sounds okay. I have an alternative >>> proposal to consider that hopefully might remove Semaphore handling >>> completely from Process>>terminate. >>> >>> What if we have a wait primitive that instead of returning itself >>> (i.e. a Semaphore), it always returns true. Then if the process is >>> terminated while the primitive is waiting, before it consumes a >>> signal, the assignment to signalConsumed never occurs. Then we >>> have... >>> >>> critical: mutuallyExcludedBlock >>> signalConsumed := false. >>> [ >>> signalConsumed := self primWaitSucceeded. >>> blockValue := mutuallyExcludedBlock value >>> ] ensure: [ signalConsumed ifTrue: [self signal] ]. >>> ^blockValue >>> >>> It *feels* more atomic. Someone knowledgeable with the vm would need >>> to advise whether after the primitive wakes up and consumes a signal, >>> the assignment into signalConsumed can be guaranteed to occur before >>> the process gets a chance to terminate, even if the primitive needs to >>> directly poke the value into signalConsumed. >> >> >> To me it is better too. But it requires changes in VM primitive which I'm >> can't provide. >> So I will implement my idea. Do you ok with the name #waitIfInterrupted? >> > > > >

Jan. 8, 2016