Questionn

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Questionn

Santiago Bragagnolo
Hi all! I was chating with Guille, who's blaming me for make a refactor in sunit for pharo 1.4 instead of 2.0 and told me 'pharo 2.0 probably adds class layouts and slots'. Well, i'm with a concrete type inference project, i want to know what is made and who is in that part of the project to annoy and bore him with questions, 'cause probably i'll want to type the slots, but i need to understand the metaphor of the slots implementation. I want to understand too whats implication has the class layout over the types.

Santiago.



Reply | Threaded
Open this post in threaded view
|

Re: Questionn

Mariano Martinez Peck
All I can do is to recommend you to read this paper: http://rmod.lille.inria.fr/archives/papers/Verw11a-OOSPLA11-FlexibleObjectLayouts.pdf


On Mon, Apr 30, 2012 at 8:36 PM, Santiago Bragagnolo <[hidden email]> wrote:
Hi all! I was chating with Guille, who's blaming me for make a refactor in sunit for pharo 1.4 instead of 2.0 and told me 'pharo 2.0 probably adds class layouts and slots'. Well, i'm with a concrete type inference project, i want to know what is made and who is in that part of the project to annoy and bore him with questions, 'cause probably i'll want to type the slots, but i need to understand the metaphor of the slots implementation. I want to understand too whats implication has the class layout over the types.

Santiago.






--
Mariano
http://marianopeck.wordpress.com

Reply | Threaded
Open this post in threaded view
|

Re: Questionn

Camillo Bruni-3
and the working protoype (in 1.3 + Helvetia) is avail here:

http://dl.dropbox.com/u/18184943/SlotImage.zip

make sure to run the image in an older vm (squeak 5.XX)

best
cami
       
On 2012-04-30, at 22:59, Mariano Martinez Peck wrote:

> All I can do is to recommend you to read this paper: http://rmod.lille.inria.fr/archives/papers/Verw11a-OOSPLA11-FlexibleObjectLayouts.pdf
>
>
> On Mon, Apr 30, 2012 at 8:36 PM, Santiago Bragagnolo <[hidden email]> wrote:
> Hi all! I was chating with Guille, who's blaming me for make a refactor in sunit for pharo 1.4 instead of 2.0 and told me 'pharo 2.0 probably adds class layouts and slots'. Well, i'm with a concrete type inference project, i want to know what is made and who is in that part of the project to annoy and bore him with questions, 'cause probably i'll want to type the slots, but i need to understand the metaphor of the slots implementation. I want to understand too whats implication has the class layout over the types.
>
> Santiago.
>
>
>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>


Reply | Threaded
Open this post in threaded view
|

Re: Questionn

Francisco Garau-2
Thanks Camilo - I've tried your image with the latest CogVM for Mac and it's usable. 

I understand this is work in progress, are you planning to change Object>>instVarAt: with a new primitive? or will that be handled on the image side?

Apart from the change in the class declaration, do you think that any of the existing code will have to be changed?

What's the biggest advantage of having slots? (and will we also have slots for temp vars?)

Object subclass: #Rectangle
layout: PointerLayout
slots: {
#origin => Slot.
#corner => Slot.
}
classSlots: {}
globals: ''
category: #'Graphics-Primitives'
Display boundingBox instVarAt: #origin


On 1 May 2012 09:51, Camillo Bruni <[hidden email]> wrote:
and the working protoype (in 1.3 + Helvetia) is avail here:

http://dl.dropbox.com/u/18184943/SlotImage.zip

make sure to run the image in an older vm (squeak 5.XX)

best
cami

On 2012-04-30, at 22:59, Mariano Martinez Peck wrote:

> All I can do is to recommend you to read this paper: http://rmod.lille.inria.fr/archives/papers/Verw11a-OOSPLA11-FlexibleObjectLayouts.pdf
>
>
> On Mon, Apr 30, 2012 at 8:36 PM, Santiago Bragagnolo <[hidden email]> wrote:
> Hi all! I was chating with Guille, who's blaming me for make a refactor in sunit for pharo 1.4 instead of 2.0 and told me 'pharo 2.0 probably adds class layouts and slots'. Well, i'm with a concrete type inference project, i want to know what is made and who is in that part of the project to annoy and bore him with questions, 'cause probably i'll want to type the slots, but i need to understand the metaphor of the slots implementation. I want to understand too whats implication has the class layout over the types.
>
> Santiago.
>
>
>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>



Reply | Threaded
Open this post in threaded view
|

Re: Questionn

Marcus Denker-4
In reply to this post by Camillo Bruni-3

On May 1, 2012, at 11:27 AM, Francisco Garau wrote:

> Thanks Camilo - I've tried your image with the latest CogVM for Mac and it's usable.
>
> I understand this is work in progress, are you planning to change Object>>instVarAt: with a new primitive? or will that be handled on the image side?
>

Objects continue to have offset ivars... everything is mapped on those. So #instVarAt: just stays as it is.


> Apart from the change in the class declaration, do you think that any of the existing code will have to be changed?
>
> What's the biggest advantage of having slots?

-> Objects describing the layout of a class, simplifying a lot of thing
-> Objects describing instance variables, available for reasoning about and e.g annotating.

And of course, you can subclass Slot and do special ones... there are examples in the paper.
Virtual slots, type check slots, Bit Slot, Property Slot....

http://hal.inria.fr/docs/00/64/17/16/PDF/Verw11b-OOSPLA11-FlexibleObjectLayouts.pdf


> (and will we also have slots for temp vars?)
>
> Object subclass: #Rectangle
> layout: PointerLayout
> slots: {
> #origin => Slot.
> #corner => Slot.
> }
> classSlots: {}
> globals: ''
> category: #'Graphics-Primitives'
>
> Display boundingBox instVarAt: #origin
>

instVarAt: can not take a symbol, just an integer. And it will return what it finds at the position.
In the case of simple slots, there is a 1:1 mapping to iVars and therefore no change.

See section 4.1 Primitive Slots

"Primitive slots are metaobjects that simply bind an instance variable to a field index."

        Marcus

--
Marcus Denker -- http://marcusdenker.de


Reply | Threaded
Open this post in threaded view
|

Re: Questionn

Stéphane Ducasse
In reply to this post by Francisco Garau-2
First class instance variables will bring a lot to the system:
        foundation for a lot of innovation
                - relationships support
                - meta description.
                - bitfields description
                ...
       
Now we should really work to get from the prototype to a fully robust and tested version.

Stef



> Thanks Camilo - I've tried your image with the latest CogVM for Mac and it's usable.
>
> I understand this is work in progress, are you planning to change Object>>instVarAt: with a new primitive? or will that be handled on the image side?
>
> Apart from the change in the class declaration, do you think that any of the existing code will have to be changed?
>
> What's the biggest advantage of having slots? (and will we also have slots for temp vars?)
>
> Object subclass: #Rectangle
> layout: PointerLayout
> slots: {
> #origin => Slot.
> #corner => Slot.
> }
> classSlots: {}
> globals: ''
> category: #'Graphics-Primitives'
>
> Display boundingBox instVarAt: #origin
>
>
> On 1 May 2012 09:51, Camillo Bruni <[hidden email]> wrote:
> and the working protoype (in 1.3 + Helvetia) is avail here:
>
> http://dl.dropbox.com/u/18184943/SlotImage.zip
>
> make sure to run the image in an older vm (squeak 5.XX)
>
> best
> cami
>
> On 2012-04-30, at 22:59, Mariano Martinez Peck wrote:
>
> > All I can do is to recommend you to read this paper: http://rmod.lille.inria.fr/archives/papers/Verw11a-OOSPLA11-FlexibleObjectLayouts.pdf
> >
> >
> > On Mon, Apr 30, 2012 at 8:36 PM, Santiago Bragagnolo <[hidden email]> wrote:
> > Hi all! I was chating with Guille, who's blaming me for make a refactor in sunit for pharo 1.4 instead of 2.0 and told me 'pharo 2.0 probably adds class layouts and slots'. Well, i'm with a concrete type inference project, i want to know what is made and who is in that part of the project to annoy and bore him with questions, 'cause probably i'll want to type the slots, but i need to understand the metaphor of the slots implementation. I want to understand too whats implication has the class layout over the types.
> >
> > Santiago.
> >
> >
> >
> >
> >
> >
> > --
> > Mariano
> > http://marianopeck.wordpress.com
> >
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Questionn

Ben Coman
I am really looking forward to the relationship support.
I will be trying out the download this weekend.

Stéphane Ducasse wrote:

> First class instance variables will bring a lot to the system:
> foundation for a lot of innovation
> - relationships support
> - meta description.
> - bitfields description
> ...
>
> Now we should really work to get from the prototype to a fully robust and tested version.
>
> Stef
>
>
>
>  
>> Thanks Camilo - I've tried your image with the latest CogVM for Mac and it's usable.
>>
>> I understand this is work in progress, are you planning to change Object>>instVarAt: with a new primitive? or will that be handled on the image side?
>>
>> Apart from the change in the class declaration, do you think that any of the existing code will have to be changed?
>>
>> What's the biggest advantage of having slots? (and will we also have slots for temp vars?)
>>
>> Object subclass: #Rectangle
>> layout: PointerLayout
>> slots: {
>> #origin => Slot.
>> #corner => Slot.
>> }
>> classSlots: {}
>> globals: ''
>> category: #'Graphics-Primitives'
>>
>> Display boundingBox instVarAt: #origin
>>
>>
>> On 1 May 2012 09:51, Camillo Bruni <[hidden email]> wrote:
>> and the working protoype (in 1.3 + Helvetia) is avail here:
>>
>> http://dl.dropbox.com/u/18184943/SlotImage.zip
>>
>> make sure to run the image in an older vm (squeak 5.XX)
>>
>> best
>> cami
>>
>> On 2012-04-30, at 22:59, Mariano Martinez Peck wrote:
>>
>>    
>>> All I can do is to recommend you to read this paper: http://rmod.lille.inria.fr/archives/papers/Verw11a-OOSPLA11-FlexibleObjectLayouts.pdf
>>>
>>>
>>> On Mon, Apr 30, 2012 at 8:36 PM, Santiago Bragagnolo <[hidden email]> wrote:
>>> Hi all! I was chating with Guille, who's blaming me for make a refactor in sunit for pharo 1.4 instead of 2.0 and told me 'pharo 2.0 probably adds class layouts and slots'. Well, i'm with a concrete type inference project, i want to know what is made and who is in that part of the project to annoy and bore him with questions, 'cause probably i'll want to type the slots, but i need to understand the metaphor of the slots implementation. I want to understand too whats implication has the class layout over the types.
>>>
>>> Santiago.
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Mariano
>>> http://marianopeck.wordpress.com
>>>
>>>      
>>
>>    
>
>
>
>  


Reply | Threaded
Open this post in threaded view
|

Re: Questionn

Igor Stasenko
In reply to this post by Stéphane Ducasse
On 2 May 2012 19:47, Stéphane Ducasse <[hidden email]> wrote:
> First class instance variables will bring a lot to the system:
>        foundation for a lot of innovation
>                - relationships support
>                - meta description.



>                - bitfields description

this one was always overrated, IMO.
unless you wanna parse the IP packet headers, where else you want to
play with bit fields,
and care how they fit in memory? :)

>                ...
>
> Now we should really work to get from the prototype to a fully robust and tested version.
>
> Stef
>
>
>
>> Thanks Camilo - I've tried your image with the latest CogVM for Mac and it's usable.
>>
>> I understand this is work in progress, are you planning to change Object>>instVarAt: with a new primitive? or will that be handled on the image side?
>>
>> Apart from the change in the class declaration, do you think that any of the existing code will have to be changed?
>>
>> What's the biggest advantage of having slots? (and will we also have slots for temp vars?)
>>
>> Object subclass: #Rectangle
>>       layout: PointerLayout
>>       slots: {
>>               #origin => Slot.
>>               #corner => Slot.
>>       }
>>       classSlots: {}
>>       globals: ''
>>       category: #'Graphics-Primitives'
>>
>> Display boundingBox instVarAt: #origin
>>
>>
>> On 1 May 2012 09:51, Camillo Bruni <[hidden email]> wrote:
>> and the working protoype (in 1.3 + Helvetia) is avail here:
>>
>> http://dl.dropbox.com/u/18184943/SlotImage.zip
>>
>> make sure to run the image in an older vm (squeak 5.XX)
>>
>> best
>> cami
>>
>> On 2012-04-30, at 22:59, Mariano Martinez Peck wrote:
>>
>> > All I can do is to recommend you to read this paper: http://rmod.lille.inria.fr/archives/papers/Verw11a-OOSPLA11-FlexibleObjectLayouts.pdf
>> >
>> >
>> > On Mon, Apr 30, 2012 at 8:36 PM, Santiago Bragagnolo <[hidden email]> wrote:
>> > Hi all! I was chating with Guille, who's blaming me for make a refactor in sunit for pharo 1.4 instead of 2.0 and told me 'pharo 2.0 probably adds class layouts and slots'. Well, i'm with a concrete type inference project, i want to know what is made and who is in that part of the project to annoy and bore him with questions, 'cause probably i'll want to type the slots, but i need to understand the metaphor of the slots implementation. I want to understand too whats implication has the class layout over the types.
>> >
>> > Santiago.
>> >
>> >
>> >
>> >
>> >
>> >
>> > --
>> > Mariano
>> > http://marianopeck.wordpress.com
>> >
>>
>>
>>
>
>



--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|

Re: Questionn

Francisco Garau-2
In reply to this post by Stéphane Ducasse
On 2 May 2012 18:47, Stéphane Ducasse <[hidden email]> wrote:
First class instance variables will bring a lot to the system:
       foundation for a lot of innovation
               - relationships support
               - meta description.
               - bitfields description
               ...


I like the idea -- you could even have a BroadcasterSlot that whenever it's changed send notifications (although this might not be necessary with the Announcement framework, I haven't looked into that). 

But there are a couple of points that I don't understand:

1) Slots and Layouts are descriptions of Objects and Classes and, as such, they are reflection facilities. Will this go into the "minimal" kernel image that you are trying to bootstrap? (I think they should go to a "reflection" module on top of the kernel)

2) Let's say you have a subclass of point with typed slots called FloatPoint with a couple of getter/setters. Would the generated bytecodes of the setter by the same as for the same method in the superclass? 

- Francisco 


 
Reply | Threaded
Open this post in threaded view
|

Re: Questionn

Marcus Denker-4
In reply to this post by Stéphane Ducasse

On May 4, 2012, at 9:44 AM, Francisco Garau wrote:

> On 2 May 2012 18:47, Stéphane Ducasse <[hidden email]> wrote:
> First class instance variables will bring a lot to the system:
>        foundation for a lot of innovation
>                - relationships support
>                - meta description.
>                - bitfields description
>                ...
>
>
> I like the idea -- you could even have a BroadcasterSlot that whenever it's changed send notifications (although this might not be necessary with the Announcement framework, I haven't looked into that).
>
> But there are a couple of points that I don't understand:
>
> 1) Slots and Layouts are descriptions of Objects and Classes and, as such, they are reflection facilities. Will this go into the "minimal" kernel image that you are trying to bootstrap?
yes, because the ClassBuilder will use the layout descriptions. And because the system itself might use them.

> (I think they should go to a "reflection" module on top of the kernel)
>
In the futuer, yes. But that is hard. In theory, you can think about a reflection-less system where reflection can be added later by loading something.
But this is a hard problem in itself. Nik did some research experiments in that direction:

        http://rmod.lille.inria.fr/web/pier/publications/bib?&query=Papo11a

In the end we want to go there, but for the bootstrap this is not the first goal. (ie, we will do a boostrap that has reflection first).

> 2) Let's say you have a subclass of point with typed slots called FloatPoint with a couple of getter/setters. Would the generated bytecodes of the setter by the same as for the same method in the superclass?
>
yes. (if I understand you question correctly)

        Marcus

--
Marcus Denker -- http://marcusdenker.de


Reply | Threaded
Open this post in threaded view
|

Re: Questionn

Ben Coman
In reply to this post by Igor Stasenko
Igor Stasenko wrote:

> On 2 May 2012 19:47, Stéphane Ducasse <[hidden email]> wrote:
>  
>> First class instance variables will bring a lot to the system:
>>        foundation for a lot of innovation
>>                - relationships support
>>                - meta description.
>>    
>
>
>
>  
>>                - bitfields description
>>    
>
> this one was always overrated, IMO.
> unless you wanna parse the IP packet headers, where else you want to
> play with bit fields,
> and care how they fit in memory? :)
>  

Industrial process control - where you have hundreds of physical digital
inputs and outputs providing feedback from limit switches and driving
control relays.