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

Re: [Pharo-dev] Repeatable VM crash

by Mariano Martinez Peck

On Sun, Dec 7, 2014 at 3:27 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Mariano, > > On Dec 7, 2014, at 10:21 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > > On Sun, Dec 7, 2014 at 3:09 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> Hi Hilaire, >> >> >> On Dec 7, 2014, at 12:35 AM, Hilaire <hilaire(a)drgeo.eu> wrote: >> >> > I download this one >> > >> http://www.mirandabanda.org/files/Cog/VM/VM.r3164/coglinux-14.48.3164.tgz >> > >> > and the crash is still there. Attached crash dump. >> >> different bugs. The 3164 VMs fix a 32-bit Spur bug. Your image is >> showing a bug in Cog that looks to be to do with the decompression >> primitive. I haven't had time to look at it deeply yet but can see it and >> should be able to fix it soon. >> > > You mean GZip stuff? Because I have found a similar issue years ago: > http://forum.world.st/Re-Pharo-project-GZipWriteStream-crashing-my-VM-when-… > > > No. That bug got fixed recently. This is a bug in the custom > huffman-ciding bitmap decompression routine (selector begins with > "decompress") that's compiled to a primitive. > > Hi, It seems Stephan is seeing this bug again. Eliot, is there a chance that the fix was not finally integrated or something? > > >> >> > >> > Thanks >> > >> > Hilaire >> > >> > Le 06/12/2014 22:57, Eliot Miranda a Ã©crit : >> >> Hi Esteban, >> >> >> >> plausibly the fix to the latest VM might fix your crash. You might >> >> test? Fingers crossed. >> >> >> >> On Fri, Dec 5, 2014 at 11:26 PM, Esteban Lorenzano < >> estebanlm(a)gmail.com >> >> <mailto:estebanlm@gmail.com>> wrote: >> >> >> >> yes, but the first step is to be sure you have the latest vm >> version :) >> >> >> >> Esteban >> > >> > >> > -- >> > Dr. Geo - http://drgeo.eu >> > iStoa - http://istoa.drgeo.eu >> > <crash.dmp> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

Jan. 4, 2016

Re: [Pharo-dev] do you know we have an issue tracker? (rant)

by Torsten Bergmann

You wanted to rebuild the Windows Spur VM due to some missing changes: https://pharo.fogbugz.com/f/cases/17289/Spur-VM-breaks-CTRL-keys-on-Windows The one you provided on 14.12.2015 is without correct CTRL key handling and therefore not very usable. Nicolai provided also some info's in the issue. While compiling you can review https://pharo.fogbugz.com/f/cases/17253 ;) Thanks T. > Gesendet: Montag, 04. Januar 2016 um 19:13 Uhr > Von: "Johan Fabry" <jfabry(a)dcc.uchile.cl> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] do you know we have an issue tracker? (rant) > > > Just to be sure, did you get notified for this one? https://pharo.fogbugz.com/f/cases/17309/Roassal2-in-Pharo-5-produces-a-segf… > > > On Jan 4, 2016, at 11:34, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > > Hi guys, > > > > Soâ¦ last two weeks I was first in Togo with Stef and after taking holidays for the end of the year. > > During that time some bugs on new FFI emerged and were talked in this listâ¦ > > > > Today I came back to work and I wanted to walk through the issues to priorize and start work on fixing themâ¦ and no reports on the issue tracker :( > > > > So Iâm forced to do email-archeology to dig up the problemsâ¦ or just ignore them until a report arrives. > > > > What is not in the issue tracker does not exist: PLEASE REPORT YOUR ISSUES. > > > > thanks, > > Esteban > > > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > > >

Jan. 4, 2016

Re: [Pharo-dev] do you know we have an issue tracker? (rant)

by Dimitris Chloupis

ninja coders beg for less bug reports , technomages beg for more :D On Mon, Jan 4, 2016 at 4:35 PM Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi guys, > > Soâ¦ last two weeks I was first in Togo with Stef and after taking holidays > for the end of the year. > During that time some bugs on new FFI emerged and were talked in this listâ¦ > > Today I came back to work and I wanted to walk through the issues to > priorize and start work on fixing themâ¦ and no reports on the issue tracker > :( > > So Iâm forced to do email-archeology to dig up the problemsâ¦ or just > ignore them until a report arrives. > > What is not in the issue tracker does not exist: PLEASE REPORT YOUR ISSUES. > > thanks, > Esteban >

Jan. 4, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Igor Stasenko

It heavily depends on data structure you using what kind of synchronization mechanism is more efficient than another. For instance AtomicQueue implementation is one that falls in such category 'many readers, but only single writer'. But it's not using semaphores to synchronise access to it. On 4 January 2016 at 20:06, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > If I understand correctly: > - the Monitor only offer one kind of critical section that typically > affects everyone equally, > - while with the new ReadWriteLock, the readers will be blocked only if a > writer will acquire the writer critical section. > > Cheers, > Doru > > > > On Jan 4, 2016, at 7:55 PM, Max Leske <maxleske(a)gmail.com> wrote: > > > > Hi Denis, > > > > How does your ReadWriteLock compare to Monitor? I was under the > impression that what you describe could be done with a Monitor. > > > > Cheers, > > Max > > > > > >> On 04 Jan 2016, at 18:39, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> > >> Hi. > >> > >> I implemented small package ReadWriteLock > http://smalltalkhub.com/mc/Pharo/ReadWriteLock/main. > >> > >> Gofer it > >> smalltalkhubUser: 'Pharo' project: 'ReadWriteLock'; > >> configurationOf: 'ReadWriteLock'; > >> loadStable > >> > >> It is reentral read write lock which described in > >> https://en.wikipedia.org/wiki/Readersâwriter_lock. From the article: > >> > >> An ReadWriteLock allows concurrent access for read-only operations, > while write operations require exclusive access. This means that multiple > threads can read the data in parallel but an exclusive lock is needed for > writing or modifying data. When a writer is writing the data, all other > writers or readers will be blocked until the writer is finished writing. > >> > >> Public API and Key Messages > >> > >> - lock := ReadWriteLock new > >> - lock criticalRead: aBlock > >> - lock criticalWrite: aBlock > >> > >> Implementation based on two semaphores and readers counter. > >> > >> Main difficulty is carefully handle process termination during > execution of critical sections. This problem described in > Semaphore>>critical: comment. Same approach is used here. But > synchronisation logic around two semaphores for reading and writing > complicates things very much. No simple way to decompose logic on multiple > methods because information about process interruption become hidden. > >> From the Semaphore comment: > >> The main trick is assignment right before we go into the wait primitive > (which is not a real send and therefore not interruptable either). So after > we can check that waiting is happen or not. > >> > >> Tests are implemented only for lock scenarios. No tests for described > termination process cases. It is not really clear how to write it. > >> I will be appreciate if people review code. Maybe you will suggest > simplifications. It is always difficult to implement concurrent code. > >> > >> Best regards, > >> Denis > > > > -- > www.tudorgirba.com > www.feenk.com > > âLive like you mean it." > > > -- Best regards, Igor Stasenko.

Jan. 4, 2016

Re: [Pharo-dev] do you know we have an issue tracker? (rant)

by Johan Fabry

Just to be sure, did you get notified for this one? https://pharo.fogbugz.com/f/cases/17309/Roassal2-in-Pharo-5-produces-a-segf… > On Jan 4, 2016, at 11:34, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi guys, > > Soâ¦ last two weeks I was first in Togo with Stef and after taking holidays for the end of the year. > During that time some bugs on new FFI emerged and were talked in this listâ¦ > > Today I came back to work and I wanted to walk through the issues to priorize and start work on fixing themâ¦ and no reports on the issue tracker :( > > So Iâm forced to do email-archeology to dig up the problemsâ¦ or just ignore them until a report arrives. > > What is not in the issue tracker does not exist: PLEASE REPORT YOUR ISSUES. > > thanks, > Esteban > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

Jan. 4, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Tudor Girba

Hi, If I understand correctly: - the Monitor only offer one kind of critical section that typically affects everyone equally, - while with the new ReadWriteLock, the readers will be blocked only if a writer will acquire the writer critical section. Cheers, Doru > On Jan 4, 2016, at 7:55 PM, Max Leske <maxleske(a)gmail.com> wrote: > > Hi Denis, > > How does your ReadWriteLock compare to Monitor? I was under the impression that what you describe could be done with a Monitor. > > Cheers, > Max > > >> On 04 Jan 2016, at 18:39, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> >> Hi. >> >> I implemented small package ReadWriteLock http://smalltalkhub.com/mc/Pharo/ReadWriteLock/main. >> >> Gofer it >> smalltalkhubUser: 'Pharo' project: 'ReadWriteLock'; >> configurationOf: 'ReadWriteLock'; >> loadStable >> >> It is reentral read write lock which described in >> https://en.wikipedia.org/wiki/Readersâwriter_lock. From the article: >> >> An ReadWriteLock allows concurrent access for read-only operations, while write operations require exclusive access. This means that multiple threads can read the data in parallel but an exclusive lock is needed for writing or modifying data. When a writer is writing the data, all other writers or readers will be blocked until the writer is finished writing. >> >> Public API and Key Messages >> >> - lock := ReadWriteLock new >> - lock criticalRead: aBlock >> - lock criticalWrite: aBlock >> >> Implementation based on two semaphores and readers counter. >> >> Main difficulty is carefully handle process termination during execution of critical sections. This problem described in Semaphore>>critical: comment. Same approach is used here. But synchronisation logic around two semaphores for reading and writing complicates things very much. No simple way to decompose logic on multiple methods because information about process interruption become hidden. >> From the Semaphore comment: >> The main trick is assignment right before we go into the wait primitive (which is not a real send and therefore not interruptable either). So after we can check that waiting is happen or not. >> >> Tests are implemented only for lock scenarios. No tests for described termination process cases. It is not really clear how to write it. >> I will be appreciate if people review code. Maybe you will suggest simplifications. It is always difficult to implement concurrent code. >> >> Best regards, >> Denis > -- www.tudorgirba.com www.feenk.com âLive like you mean it."

Jan. 4, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Max Leske

Hi Denis, How does your ReadWriteLock compare to Monitor? I was under the impression that what you describe could be done with a Monitor. Cheers, Max > On 04 Jan 2016, at 18:39, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi. > > I implemented small package ReadWriteLock http://smalltalkhub.com/mc/Pharo/ReadWriteLock/main <http://smalltalkhub.com/mc/Pharo/ReadWriteLock/main>. > > Gofer it > smalltalkhubUser: 'Pharo' project: 'ReadWriteLock'; > configurationOf: 'ReadWriteLock'; > loadStable > > It is reentral read write lock which described in > https://en.wikipedia.org/wiki/Readersâwriter_lock <https://en.wikipedia.org/wiki/Readers%E2%80%93writer_lock>. From the article: > > An ReadWriteLock allows concurrent access for read-only operations, while write operations require exclusive access. This means that multiple threads can read the data in parallel but an exclusive lock is needed for writing or modifying data. When a writer is writing the data, all other writers or readers will be blocked until the writer is finished writing. > > Public API and Key Messages > > - lock := ReadWriteLock new > - lock criticalRead: aBlock > - lock criticalWrite: aBlock > > Implementation based on two semaphores and readers counter. > > Main difficulty is carefully handle process termination during execution of critical sections. This problem described in Semaphore>>critical: comment. Same approach is used here. But synchronisation logic around two semaphores for reading and writing complicates things very much. No simple way to decompose logic on multiple methods because information about process interruption become hidden. > From the Semaphore comment: > The main trick is assignment right before we go into the wait primitive (which is not a real send and therefore not interruptable either). So after we can check that waiting is happen or not. > > Tests are implemented only for lock scenarios. No tests for described termination process cases. It is not really clear how to write it. > I will be appreciate if people review code. Maybe you will suggest simplifications. It is always difficult to implement concurrent code. > > Best regards, > Denis

Jan. 4, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Tudor Girba

Quite elegant! :) Is this meant to be part of the main distribution? Doru > On Jan 4, 2016, at 7:39 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi. > > I implemented small package ReadWriteLock http://smalltalkhub.com/mc/Pharo/ReadWriteLock/main. > > Gofer it > smalltalkhubUser: 'Pharo' project: 'ReadWriteLock'; > configurationOf: 'ReadWriteLock'; > loadStable > > It is reentral read write lock which described in > https://en.wikipedia.org/wiki/Readersâwriter_lock. From the article: > > An ReadWriteLock allows concurrent access for read-only operations, while write operations require exclusive access. This means that multiple threads can read the data in parallel but an exclusive lock is needed for writing or modifying data. When a writer is writing the data, all other writers or readers will be blocked until the writer is finished writing. > > Public API and Key Messages > > - lock := ReadWriteLock new > - lock criticalRead: aBlock > - lock criticalWrite: aBlock > > Implementation based on two semaphores and readers counter. > > Main difficulty is carefully handle process termination during execution of critical sections. This problem described in Semaphore>>critical: comment. Same approach is used here. But synchronisation logic around two semaphores for reading and writing complicates things very much. No simple way to decompose logic on multiple methods because information about process interruption become hidden. > From the Semaphore comment: > The main trick is assignment right before we go into the wait primitive (which is not a real send and therefore not interruptable either). So after we can check that waiting is happen or not. > > Tests are implemented only for lock scenarios. No tests for described termination process cases. It is not really clear how to write it. > I will be appreciate if people review code. Maybe you will suggest simplifications. It is always difficult to implement concurrent code. > > Best regards, > Denis -- www.tudorgirba.com www.feenk.com "What is more important: To be happy, or to make happy?"

Jan. 4, 2016

Re: [Pharo-dev] context mirror primitives

by Tudor Girba

Hi, > On Jan 4, 2016, at 7:42 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > > 2016-01-04 17:35 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > > On Jan 4, 2016, at 6:30 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > > Hello, > > > > This is unrelated to Spur / SqueakV3 memory manager. The VM support has been there and stable for a long time now. > > > > I tried to add those primitives in Pharo but the problem is that the debugger in Pharo uses EyeInspector whereas the inspectors are done with Glamour. > > > > Hence, to add support for ProtoObject debugging you need: > > - to make interpretation implemented in Context compliant > > - to make EyeInspector compliant (for the inspector in the debugger) > > - to make GTInspector compliant. > > I am not sure I understand what you mean by " interpretation implemented in Context compliantâ. Could you explain? > > The generic idea is that in the debugger part of the execution is done using an in-image interpreter instead of the VM. The in-image interpreter should use the mirror primitives to be able to interpret correctly the code. > > For example: > > Context>>pushReceiverVariable: offset > self push: (self receiver instVarAt: offset + 1) > > should be rewritten: > > Context>>pushReceiverVariable: offset > self push: (self object: self receiver instVarAt: offset + 1) > > Else operations such as "over" or "into" in the debugger would crash if the receiver is a protoobject as they would use this code which sends a message to a protoobject instead of using the mirror primitives. Yep, I got this one. I was just not sure if there is maybe something else involved. I even did an analysis of what needs to be rewritten in this sense :) http://www.humane-assessment.com/blog/evaluating-the-reimplementation-of-ke… Cheers, Doru > > > I already made GTInspector and GTDebugger work with ProtoObject once. I lost the changes in the meantime :), but I will redo them. The only thing I needed were these primitives. But, maybe I missed something. > > > This is good news. I believe such inspectors are really important if one want to experiment with the kernel. The next steps would be to see if one can inspect an object which class directly inherit from nil and an object which has itself as a class (a prototype). > > > Cheers, > Doru > > > > Cheers ! > > > > Clement > > > > > > 2016-01-04 16:42 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > > Hi, > > > > The VM (both Cog and Spur) supports basic manipulation of objects without relying on sending messages to those objects. These primitives are meant to be handled by methods in Context. Eliot provided a changeset with these methods, and they are not yet in Pharo: > > > > object: anObject basicAt: index > > object: anObject basicAt: index put: value > > object: anObject eqeq: anOtherObject > > object: anObject instVarAt: anIndex > > object: anObject instVarAt: anIndex put: aValue > > object: anObject perform: selector withArguments: argArray inClass: lookupClass > > objectClass: anObject > > objectSize: anObject > > > > I added an issue and the slice: > > https://pharo.fogbugz.com/f/cases/17313/Missing-primitive-methods-in-Context > > > > As I note in the issue, I think it is certainly interesting to have a more powerful mirrors mechanism, but until then we should still be able to use what the VM already provides. > > > > I would like to use these primitives now to make the GT Inspector and Debugger be able to work with ProtoObject. I thought these methods were supposed to be in the Spur version of Pharo, but it seems they are not. So, I am wondering if maybe I am not missing something. Am I missing something or should we integrate these methods? > > > > Cheers, > > Doru > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "Problem solving efficiency grows with the abstractness level of problem understanding." > > > > > > > > > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "Things happen when they happen, > not when you talk about them happening." -- www.tudorgirba.com www.feenk.com "To lead is not to demand things, it is to make them happen."

Jan. 4, 2016

Re: [Pharo-dev] context mirror primitives

by Tudor Girba

Hi, > On Jan 4, 2016, at 7:26 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Doru, > > On Jan 4, 2016, at 8:35 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi, >> >>> On Jan 4, 2016, at 6:30 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >>> >>> Hello, >>> >>> This is unrelated to Spur / SqueakV3 memory manager. The VM support has been there and stable for a long time now. >>> >>> I tried to add those primitives in Pharo but the problem is that the debugger in Pharo uses EyeInspector whereas the inspectors are done with Glamour. >>> >>> Hence, to add support for ProtoObject debugging you need: >>> - to make interpretation implemented in Context compliant >>> - to make EyeInspector compliant (for the inspector in the debugger) >>> - to make GTInspector compliant. >> >> I am not sure I understand what you mean by " interpretation implemented in Context compliantâ. Could you explain? > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-May/164282.html Thanks! Doru > > >> I already made GTInspector and GTDebugger work with ProtoObject once. I lost the changes in the meantime :), but I will redo them. The only thing I needed were these primitives. But, maybe I missed something. >> >> Cheers, >> Doru >> >> >>> Cheers ! >>> >>> Clement >>> >>> >>> 2016-01-04 16:42 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: >>> Hi, >>> >>> The VM (both Cog and Spur) supports basic manipulation of objects without relying on sending messages to those objects. These primitives are meant to be handled by methods in Context. Eliot provided a changeset with these methods, and they are not yet in Pharo: >>> >>> object: anObject basicAt: index >>> object: anObject basicAt: index put: value >>> object: anObject eqeq: anOtherObject >>> object: anObject instVarAt: anIndex >>> object: anObject instVarAt: anIndex put: aValue >>> object: anObject perform: selector withArguments: argArray inClass: lookupClass >>> objectClass: anObject >>> objectSize: anObject >>> >>> I added an issue and the slice: >>> https://pharo.fogbugz.com/f/cases/17313/Missing-primitive-methods-in-Context >>> >>> As I note in the issue, I think it is certainly interesting to have a more powerful mirrors mechanism, but until then we should still be able to use what the VM already provides. >>> >>> I would like to use these primitives now to make the GT Inspector and Debugger be able to work with ProtoObject. I thought these methods were supposed to be in the Spur version of Pharo, but it seems they are not. So, I am wondering if maybe I am not missing something. Am I missing something or should we integrate these methods? >>> >>> Cheers, >>> Doru >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "Problem solving efficiency grows with the abstractness level of problem understanding." >>> >>> >>> >>> >>> >>> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Things happen when they happen, >> not when you talk about them happening." > > _,,,^..^,,,_ (phone) -- www.tudorgirba.com www.feenk.com "Every successful trip needs a suitable vehicle."

Jan. 4, 2016