[Pharo-project] custom code on squeaksource
We are currently working on first-class slots and layouts in pharo. This required some changes in how the class definitions are printed: ============================================= Object subclass: #Layout layout: ObjectLayout slots: { #host => Slot. #compactClassIndex => Slot. } classSlots: {} globals: '' category: #'Slot-Layout' ============================================= I adapted the MCClassDefinition >> definitionString to output our new class definitions. However squeaksource is not too happy with this and rewrites it completely using the default definition. Local mcz files contain the new definition, mcz files loaded form squeaksources still the old definition. Is there a way to still use squeaksources with our custom classes? thanks v(^_^)v camillo
On Thu, Mar 24, 2011 at 11:43 AM, Camillo Bruni <camillo.bruni@inria.fr>wrote:
We are currently working on first-class slots and layouts in pharo. This required some changes in how the class definitions are printed:
============================================= Object subclass: #Layout layout: ObjectLayout slots: { #host => Slot. #compactClassIndex => Slot. } classSlots: {} globals: '' category: #'Slot-Layout'
I like it! A great use for tuples. Not sure I like sots vs instanceVarables, but then I'm an old man ;) Have you thought about automatically creating accessors for byte data? I'm imagining HeapField subclass: #ObjectHeaderLittleEndian type: #Bits fields: { #classTag => 20. #isPointers => 1 => #Boolean. #isIndexable => 1 => #Boolean. #slotSize => 8 => #Align => 8. #identityHash => 20 => #Align => 32. #isMarked => 1 => #Boolean. #isForwarded => 1 => #Boolean. #isWeak => 1 => #Boolean. #isEphemeron => 1 => #Boolean. } classSlots: {} globals: '' category: #'VMMaker-MemoryManager'
=============================================
I adapted the MCClassDefinition >> definitionString to output our new class definitions.
However squeaksource is not too happy with this and rewrites it completely using the default definition.
Local mcz files contain the new definition, mcz files loaded form squeaksources still the old definition.
Is there a way to still use squeaksources with our custom classes?
thanks
v(^_^)v camillo
I like it! A great use for tuples. Not sure I like sots vs instanceVarables, but then I'm an old man ;) Have you thought about automatically creating accessors for byte data? I'm imagining
HeapField subclass: #ObjectHeaderLittleEndian type: #Bits fields: { #classTag => 20. #isPointers => 1 => #Boolean. #isIndexable => 1 => #Boolean. #slotSize => 8 => #Align => 8. #identityHash => 20 => #Align => 32. #isMarked => 1 => #Boolean. #isForwarded => 1 => #Boolean. #isWeak => 1 => #Boolean. #isEphemeron => 1 => #Boolean. } classSlots: {} globals: '' category: #'VMMaker-MemoryManager'
yes now we should probably avoid to have syntax in the class definition but in a description of the slots. What means exactly: #identityHash => 20 => #Align => 32. For slots we did a first experience with marcus in 2008/9 where we show that we could get first class instanceVariable without speed penalties. We postpone our experience because it required a working new compiler and a complete rewrite of classBuilder. We want to be able to define active value hashTable relationship magritte like description and a lot more So if you have ideas or wishes let us know. Stef
On Thu, Mar 24, 2011 at 1:45 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
I like it! A great use for tuples. Not sure I like sots vs
instanceVarables, but then I'm an old man ;)
Have you thought about automatically creating accessors for byte data? I'm imagining
HeapField subclass: #ObjectHeaderLittleEndian type: #Bits fields: { #classTag => 20. #isPointers => 1 => #Boolean. #isIndexable => 1 => #Boolean. #slotSize => 8 => #Align => 8. #identityHash => 20 => #Align => 32. #isMarked => 1 => #Boolean. #isForwarded => 1 => #Boolean. #isWeak => 1 => #Boolean. #isEphemeron => 1 => #Boolean. } classSlots: {} globals: '' category: #'VMMaker-MemoryManager'
yes now we should probably avoid to have syntax in the class definition but in a description of the slots.
What means exactly: #identityHash => 20 => #Align => 32.
This is just an example but it means a 20-bit unsigned integer field aligned on a 32-bit boundary. In the above #isPointers => 1 => #Boolean would mean a 1 bit-field accessed as a boolean (a flag). The above is close to the object header in the new GC I want to build.
For slots we did a first experience with marcus in 2008/9 where we show that we could get first class instanceVariable without speed penalties. We postpone our experience because it required a working new compiler and a complete rewrite of classBuilder. We want to be able to define active value hashTable relationship magritte like description and a lot more
So if you have ideas or wishes let us know.
Stef
On 24 March 2011 21:52, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Thu, Mar 24, 2011 at 1:45 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I like it! Â A great use for tuples. Â Not sure I like sots vs instanceVarables, but then I'm an old man ;) Have you thought about automatically creating accessors for byte data? Â I'm imagining
HeapField subclass: #ObjectHeaderLittleEndian   type: #Bits   fields: {     #classTag => 20.     #isPointers => 1 => #Boolean.     #isIndexable => 1 => #Boolean.     #slotSize => 8 => #Align => 8.     #identityHash => 20 => #Align => 32.     #isMarked => 1 => #Boolean.     #isForwarded => 1 => #Boolean.     #isWeak => 1 => #Boolean.     #isEphemeron => 1 => #Boolean. }     classSlots: {}    globals: ''    category: #'VMMaker-MemoryManager'
yes now we should probably avoid to have syntax in the class definition but in a description of the slots.
What means exactly: Â Â #identityHash => 20 => #Align => 32.
This is just an example but it means a 20-bit unsigned integer field aligned on a 32-bit boundary.  In the above  #isPointers => 1 => #Boolean would mean a 1 bit-field accessed as a boolean (a flag).  The above is close to the object header in the new GC I want to build.
kekeke... i like it when people see a direct benefits for themselves :)
For slots we did a first experience with marcus in 2008/9 where we show that we could get first class instanceVariable without speed penalties. We postpone our experience because it required a working new compiler and a complete rewrite of classBuilder. We want to be able to define     active value     hashTable     relationship     magritte like description     and a lot more
So if you have ideas or wishes let us know.
Stef
-- Best regards, Igor Stasenko AKA sig.
yes now we should probably avoid to have syntax in the class definition but in a description of the slots.
What means exactly: #identityHash => 20 => #Align => 32.
This is just an example
Yes I see that but I value real examples I cannot imagine :) So we could have a nice BitFieldSlot class with nice message and creation interface (no magic intepretation needed and we would write something like HeapField subclass: #ObjectHeaderLittleEndian instanceVar: 'identityHash <BitFieldSlot length: 20 aligned: 32> ' or something like that and it will be quite cool.
but it means a 20-bit unsigned integer field aligned on a 32-bit boundary. In the above #isPointers => 1 => #Boolean would mean a 1 bit-field accessed as a boolean (a flag). The above is close to the object header in the new GC I want to build.
For slots we did a first experience with marcus in 2008/9 where we show that we could get first class instanceVariable without speed penalties. We postpone our experience because it required a working new compiler and a complete rewrite of classBuilder. We want to be able to define active value hashTable relationship magritte like description and a lot more
So if you have ideas or wishes let us know.
Stef
well the bitfield stuff would already work, thats fairly easy to implement. The only issue right now is that we rely on helvetia for the source code transformation. And I urge not to introduce custom syntax for slot creation, that doesn't make sense. Right now the class definition has always been hardcoded, which IMO is quite wrong. But by relying on first-class layouts in slots we can simply ask these objects what properties a class has. Just as a hint, first-class layouts render the format integer on classes basically useless. Since you can always query the layout and ask it for these properties. Thus the format should be used only at VM level to speed things up (the same for compact classes ;)). On 2011-03-24, at 22:04, Stéphane Ducasse wrote:
yes now we should probably avoid to have syntax in the class definition but in a description of the slots.
What means exactly: #identityHash => 20 => #Align => 32.
This is just an example
Yes I see that but I value real examples I cannot imagine :)
So we could have a nice BitFieldSlot class with nice message and creation interface (no magic intepretation needed and we would write something like
HeapField subclass: #ObjectHeaderLittleEndian instanceVar: 'identityHash <BitFieldSlot length: 20 aligned: 32> '
or something like that and it will be quite cool.
but it means a 20-bit unsigned integer field aligned on a 32-bit boundary. In the above #isPointers => 1 => #Boolean would mean a 1 bit-field accessed as a boolean (a flag). The above is close to the object header in the new GC I want to build.
For slots we did a first experience with marcus in 2008/9 where we show that we could get first class instanceVariable without speed penalties. We postpone our experience because it required a working new compiler and a complete rewrite of classBuilder. We want to be able to define active value hashTable relationship magritte like description and a lot more
So if you have ideas or wishes let us know.
Stef
participants (4)
-
Camillo Bruni -
Eliot Miranda -
Igor Stasenko -
Stéphane Ducasse