May 2014 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Slots

by Johan Fabry

On May 19, 2014, at 8:06 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> This so that I can transparently redirect them to a dictionary lookup. > > there will be Dictionay based slots coming with Pharo4, no need to roll your own for that. > > In addition, I want to add support for Reflectivity meta links on slots. This means that instead of changing the class definition, > you will be able to put a MetaLink on the slot definition (before, after, around/instead). This is for the more âreflectiveâ use cases. > > Now this is all in an early state.. the idea is to finish all this over the summer :-) OK I declare that Iâm a customer for dictionary-based slots. Please keep me up to date on progress :-) ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

May 19, 2014

Re: [Pharo-users] Class definition changes in change log

by Sean P. DeNigris

Arturo Zambrano wrote > When trying to recover the changes, class name changes are not there Yes, I've been bitten by this as well. It becomes a major PITA to manually search through the changes and find the places to manually define classes. Also, I've wondered why it's not an error to attempt to apply a change that creates a method on a non-existent class... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Class-definition-changes-in-change-log-tp4759413p4759… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

May 19, 2014

Re: [Pharo-users] compiling Pillar files locally (for LaserGame book)

by Damien Cassou

On Sun, May 11, 2014 at 3:20 PM, Ben Coman <btc(a)openinworld.com> wrote: > > I noticed that many of the figures are pdf, so I am really curious why this > was done and not left as a JPG or PNG? It may not matter for a book but it > seems awkward if a html version is needed at some point. Also I added a > .gitignore since `git status` showed way too much irrelevant info to be > useful - and the PDF-figures prevent *.pdf being a filter (but *.pier.pdf is > an effective alternative for our purpose). - PDF is a vector graphics format. - JPG and PNG are not. http://en.wikipedia.org/wiki/Vector_graphics -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

May 19, 2014

Re: [Pharo-users] Slots

by Camille Teruel

On 19 mai 2014, at 14:11, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 19 May 2014, at 07:24, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > >> >> >> >> 2014-05-18 21:42 GMT+02:00 Johan Fabry <jfabry(a)dcc.uchile.cl>: >> >> I understand, thanks for the info. >> >> Let me simplify my question: Using slots is there a reasonably straightforward way for me to intercept variable accesses in all methods within a class? >> >> Yes. This is easy to do with slots. >> >> >> However we were discussing about that recently with some VM guys, and this may be quite slow on our VM. One language that runs on our VM, NewSpeak, have similar features (indirection for all instance variable access) and it is difficult for them to have good performance. This dictionary lookup case is optimized in prototype-based language VMs (Self, Javascript). Usually for users it appears that there is an indirection with a dictionary, but the implementation does not rely on dictionary for performance. > The nice thing with the Slot idea is that by default, everyone will just use InstanceVariableSlots which are as fast as now. (the current image, all slots are ivars, or all ivars are Slots instances). > You will only use Dictionary Slots when you *really* need them (e.g. Morph could merge most of MorphExtension into Dictioarny and BooleanSlotsâ¦ it would even be more memory efficient > and faster than now... > > >> >> Or am I going to have to override instVarNamed: and hope that works always? >> >> I guess you will also have to override instVarNamed: and/or instVarAt: if you want to catch reflexive instVar access. >> >> But that will never always work this method is only for reflective access. >> > > instVarAt:, as it reasons about offsets, is very low levelâ¦. for slots, it makes not much sense (as they do not have offsets). > > But the idea is to provide a reasonable reflective APIâ¦. e.g. slotNamed: (and maybe instVarNamed: is just an alias of that) > will of course delegate to the slot for reading, taking your semantic change into account. Rather, I think that instVarXXX methods (or equivalent) should be exposed in a low-level API as it deals with an object actual representation in memory whereas slotXXX methods should be exposed in a high level API as it's closer to the application domain and to the programmer's intent. This is an example of the problems we get when we want to add new concepts and features to Pharo. The problem lies in the interaction between two interweaved languages: - the high-level language we use to develop - the low-level language that the runtime (VM) executes. Currently, both languages are merged (especially in the light of reflection) as their concepts are supposed to map. But when we introduce something like slots, we mess with this fragile ecosystem since the concepts of both languages doesn't map anymore (field ~= slots). There is basically two solutions, either we adapt the runtime to close the semantic gap introduced by the new language feature to reunify the LL and HL languages or we explicitly keep both languages. The first solution requires manpower and the work has to be done each time a new feature is introduced. If on the contrary we expect our language to evolve, the second solution is better: just another level of indirection. We have an evolvable language of smalltalkish code, slots and theNewCoolConcept that compiles to an almost fixed language of bytecodes and field offsets. I think we need this distinction and I'm working on it. > > Marcus >

May 19, 2014

Re: [Pharo-users] Slots

by Marcus Denker

On 19 May 2014, at 14:38, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > One more question. Can all this provide a possibility (in the future) to add inst vars to classes of the foreign packages? > it definitly would be easier to do as ivars (like all slots) are objectsâ¦ that could be âpartâ of a package, like methods are now allready. Marcus

May 19, 2014

Re: [Pharo-users] Slots

by Marcus Denker

On 19 May 2014, at 14:33, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 19 mai 2014, at 14:06, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On 18 May 2014, at 21:42, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: >> >>> >>> I understand, thanks for the info. >>> >>> Let me simplify my question: Using slots is there a reasonably straightforward way for me to intercept variable accesses in all methods within a class? >> >> Yes, you can make a special slot subclass and this defines than the semantics of the slot. You have full control of what code to emit. >> >>> This so that I can transparently redirect them to a dictionary lookup. >> >> there will be Dictionay based slots coming with Pharo4, no need to roll your own for that. >> >> In addition, I want to add support for Reflectivity meta links on slots. This means that instead of changing the class definition, >> you will be able to put a MetaLink on the slot definition (before, after, around/instead). This is for the more âreflectiveâ use cases. >> >> Now this is all in an early state.. the idea is to finish all this over the summer :-) >> >> With Camille we did a quick 20 minute prototype of the whole thing: Subclass of Slot. > > Yes it was fun :) > To experiment, we did a really simple kind of slot we called ClassSlot that is equivalent to our current class variables. > AbstractSlot subclass: #TestSlot instanceVariableNames: 'value' classVariableNames: '' category: 'Slot-Scopeâ we just implement the reflective read and write (not bothering to emit optimised bytecode): read: anObject ^ value write: aValue to: anObject value := aValue a method iv ^ iv of a class here iv is such a special class slot is compiled to 21 <20> pushConstant: a TestSlot 22 <70> self 23 <E1> send: read: 24 <7C> returnTop

May 19, 2014

Re: [Pharo-users] Slots

by Yuriy Tymchuk

One more question. Can all this provide a possibility (in the future) to add inst vars to classes of the foreign packages? Uko On 19 May 2014, at 14:33, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 19 mai 2014, at 14:06, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On 18 May 2014, at 21:42, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: >> >>> >>> I understand, thanks for the info. >>> >>> Let me simplify my question: Using slots is there a reasonably straightforward way for me to intercept variable accesses in all methods within a class? >> >> Yes, you can make a special slot subclass and this defines than the semantics of the slot. You have full control of what code to emit. >> >>> This so that I can transparently redirect them to a dictionary lookup. >> >> there will be Dictionay based slots coming with Pharo4, no need to roll your own for that. >> >> In addition, I want to add support for Reflectivity meta links on slots. This means that instead of changing the class definition, >> you will be able to put a MetaLink on the slot definition (before, after, around/instead). This is for the more âreflectiveâ use cases. >> >> Now this is all in an early state.. the idea is to finish all this over the summer :-) >> >> With Camille we did a quick 20 minute prototype of the whole thing: Subclass of Slot. > > Yes it was fun :) > To experiment, we did a really simple kind of slot we called ClassSlot that is equivalent to our current class variables. > >> Opal calles #emitStore: and #emitRead: >> on slots. the abstract slot has a fall-back that just uses reflection: >> >> emitValue: aMethodBuilder >> aMethodBuilder >> pushLiteral: self; >> pushReceiver; >> send: #read: >> >> while you can implement it yourself and emit the bytecode that >> you need. e.g. for the ivarSlot subclass it is >> >> emitValue: methodBuilder >> >> methodBuilder pushInstVar: index. >> >> making Ivar Slots be as efficient as instance variables now. >> >> Marcus

May 19, 2014

Re: [Pharo-users] Slots

by Camille Teruel

On 19 mai 2014, at 14:06, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 18 May 2014, at 21:42, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > >> >> I understand, thanks for the info. >> >> Let me simplify my question: Using slots is there a reasonably straightforward way for me to intercept variable accesses in all methods within a class? > > Yes, you can make a special slot subclass and this defines than the semantics of the slot. You have full control of what code to emit. > >> This so that I can transparently redirect them to a dictionary lookup. > > there will be Dictionay based slots coming with Pharo4, no need to roll your own for that. > > In addition, I want to add support for Reflectivity meta links on slots. This means that instead of changing the class definition, > you will be able to put a MetaLink on the slot definition (before, after, around/instead). This is for the more âreflectiveâ use cases. > > Now this is all in an early state.. the idea is to finish all this over the summer :-) > > With Camille we did a quick 20 minute prototype of the whole thing: Subclass of Slot. Yes it was fun :) To experiment, we did a really simple kind of slot we called ClassSlot that is equivalent to our current class variables. > Opal calles #emitStore: and #emitRead: > on slots. the abstract slot has a fall-back that just uses reflection: > > emitValue: aMethodBuilder > aMethodBuilder > pushLiteral: self; > pushReceiver; > send: #read: > > while you can implement it yourself and emit the bytecode that > you need. e.g. for the ivarSlot subclass it is > > emitValue: methodBuilder > > methodBuilder pushInstVar: index. > > making Ivar Slots be as efficient as instance variables now. > > Marcus >

May 19, 2014

Re: [Pharo-users] Slots

by Marcus Denker

On 19 May 2014, at 07:24, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > > 2014-05-18 21:42 GMT+02:00 Johan Fabry <jfabry(a)dcc.uchile.cl>: > > I understand, thanks for the info. > > Let me simplify my question: Using slots is there a reasonably straightforward way for me to intercept variable accesses in all methods within a class? > > Yes. This is easy to do with slots. > > > However we were discussing about that recently with some VM guys, and this may be quite slow on our VM. One language that runs on our VM, NewSpeak, have similar features (indirection for all instance variable access) and it is difficult for them to have good performance. This dictionary lookup case is optimized in prototype-based language VMs (Self, Javascript). Usually for users it appears that there is an indirection with a dictionary, but the implementation does not rely on dictionary for performance. The nice thing with the Slot idea is that by default, everyone will just use InstanceVariableSlots which are as fast as now. (the current image, all slots are ivars, or all ivars are Slots instances). You will only use Dictionary Slots when you *really* need them (e.g. Morph could merge most of MorphExtension into Dictioarny and BooleanSlotsâ¦ it would even be more memory efficient and faster than now... > > Or am I going to have to override instVarNamed: and hope that works always? > > I guess you will also have to override instVarNamed: and/or instVarAt: if you want to catch reflexive instVar access. > > But that will never always work this method is only for reflective access. > instVarAt:, as it reasons about offsets, is very low levelâ¦. for slots, it makes not much sense (as they do not have offsets). But the idea is to provide a reasonable reflective APIâ¦. e.g. slotNamed: (and maybe instVarNamed: is just an alias of that) will of course delegate to the slot for reading, taking your semantic change into account. Marcus

May 19, 2014

Re: [Pharo-users] Slots

by Marcus Denker

On 18 May 2014, at 21:42, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > > I understand, thanks for the info. > > Let me simplify my question: Using slots is there a reasonably straightforward way for me to intercept variable accesses in all methods within a class? Yes, you can make a special slot subclass and this defines than the semantics of the slot. You have full control of what code to emit. > This so that I can transparently redirect them to a dictionary lookup. there will be Dictionay based slots coming with Pharo4, no need to roll your own for that. In addition, I want to add support for Reflectivity meta links on slots. This means that instead of changing the class definition, you will be able to put a MetaLink on the slot definition (before, after, around/instead). This is for the more âreflectiveâ use cases. Now this is all in an early state.. the idea is to finish all this over the summer :-) With Camille we did a quick 20 minute prototype of the whole thing: Subclass of Slot. Opal calles #emitStore: and #emitRead: on slots. the abstract slot has a fall-back that just uses reflection: emitValue: aMethodBuilder aMethodBuilder pushLiteral: self; pushReceiver; send: #read: while you can implement it yourself and emit the bytecode that you need. e.g. for the ivarSlot subclass it is emitValue: methodBuilder methodBuilder pushInstVar: index. making Ivar Slots be as efficient as instance variables now. Marcus

May 19, 2014