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

Re: [Pharo-dev] context mirror primitives

by ClÃ©ment Bera

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. > > 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." > > >

Jan. 4, 2016

[Ann] ReadWriteLock

by Denis Kudriashov

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

Jan. 4, 2016

Re: [Pharo-dev] context mirror primitives

by Eliot Miranda

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 > 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)

Jan. 4, 2016

Re: [Pharo-dev] context mirror primitives

by Eliot Miranda

Hi Doru, > On Jan 4, 2016, at 7:42 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > 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. Note that a more powerful mirror implementation is still built upon these same primitives. Newspeak has a rich mirror implementation, but underneath it still uses these primitives to reach u side of objects without sending them messages. > 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? I can see no reason for delay. Remember that they should be used not only in low level inspectors but in Context's execution simulation machinery. Squeak can be used as a model, although in squeak there is still the ContextPart/MethodContext split. > Cheers, > Doru Happy new year! > www.tudorgirba.com > www.feenk.com > > "Problem solving efficiency grows with the abstractness level of problem understanding." _,,,^..^,,,_ (phone)

Jan. 4, 2016

Re: [Pharo-dev] Kafka protocol

by Chris Cunningham

I wrote a low-level interface for this a while back: http://www.smalltalkhub.com/#!/~cbc/KAFKAClient (it does skip zookeeper, though). And I've used it for reading from Kafka, but have not verified writing to it - and didn't finish that part (didn't need it). I did need additional ByteArray at:put: and at: methods - for 32 and 64 bit access (and 8 bit signed access as well) - which where mostly added to Squeak (where I used this from). Enjoy, -cbc On Mon, Dec 28, 2015 at 9:19 AM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 27 December 2015 at 16:11, Robert Withers <robert.w.withers(a)gmail.com> > wrote: > > This would be awesome in Pharo: > > > https://cwiki.apache.org/confluence/display/KAFKA/A+Guide+To+The+Kafka+Prot… > . > > Since we cannot yet call JARs, implementing the wire protocol and API > > proxies would really be huge from an enterprise pharo standpoint. If > other > > folks are interested in working on this, I could help out. > > Having a Kafka client in Pharo would indeed be awesome. But who cares > about calling JARs? It's a wire protocol; write a client against that > and you're done. > > frank > >

Jan. 4, 2016

Re: [Pharo-dev] context mirror primitives

by Esteban A. Maringolo

Thank you Doru! When do you guess it is going to be integrated in the main codebase? Esteban A. Maringolo 2016-01-04 12:42 GMT-03: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." > > > > >

Jan. 4, 2016

Re: [Pharo-dev] context mirror primitives

by Tudor Girba

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? 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."

Jan. 4, 2016

Re: [Pharo-dev] context mirror primitives

by ClÃ©ment Bera

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. 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." > > > > > >

Jan. 4, 2016

context mirror primitives

by Tudor Girba

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."

Jan. 4, 2016

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Tudor Girba

Thank you, Sven! I like this very much. This would also mean that we could deprecate Collection>>#sum altogether :)) Cheers, Doru > On Dec 30, 2015, at 12:53 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi Henrik, > >> On 25 Dec 2015, at 14:08, Henrik Nergaard <henrin10(a)student.uia.no> wrote: >> >> Like this? >> http://smalltalkhub.com/#!/~Latsabben/NumIt > > That is a cool take on a possible approach. Thanks for doing it, it makes it much easier to think about and discuss alternatives. > > This inspired me to do something similar, but not quite. I am just thinking out loud by implementation. Here is my result: > > <Collections-Operations-SvenVanCaekenberghe.1.mcz> > > There are some examples in the class comments. > > Sven > >> Best regards, >> Henrik >> >> -----Original Message----- >> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of stepharo >> Sent: Thursday, December 24, 2015 9:58 AM >> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >> Subject: Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers: >> >> Just a remark. >> I think that we discarded the proposition of having >> >> aCol arithmetic sum >> >> but I found it nice because there if was clear that you want to get back >> 0 for #(). >> >> Stef >> > -- www.tudorgirba.com www.feenk.com "Innovation comes in the least expected form. That is, if it is expected, it already happened."

Jan. 4, 2016