February 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Streams. Status and where to go?

by Nicolas Cellier

2010/2/27 Levente Uzonyi <leves(a)elte.hu>: > On Sat, 27 Feb 2010, Richard Durr wrote: > >> So what speaks against using VisualWorks' Xtreams? >> >> http://www.cincomsmalltalk.com/blog/blogView?entry=3444278480&printTitle=Sm… > > 1. Someone has to port it. > 2. It's optimized for VW, so the ported code's performance will probably be > bad. > > > Levente > Licensing was not clear when I begun, so I just picked a few ideas and re-implement from scratch. Now it would be interesting to try porting VW Xtream (I should say the original XTream, I just hijacked the name...). Concerning performance, VW XTream use exeptions extensively, which I tried to avoid. Nicolas >> >> On Fri, Feb 26, 2010 at 11:01 PM, Igor Stasenko <siguctua(a)gmail.com> >> wrote: >>> >>> On 26 February 2010 21:30, Nicolas Cellier >>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>> >>>> 2010/2/26 Igor Stasenko <siguctua(a)gmail.com>: >>>>> >>>>> On 26 February 2010 18:59, Nicolas Cellier >>>>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>>>> >>>>>> 2010/2/26 Igor Stasenko <siguctua(a)gmail.com>: >>>>>>> >>>>>>> Hello, Nicolas. >>>>>> >>>>>> Hi igor. >>>>>> You should load it in trunk. >>>>>> >>>>> Ah, i think my image is a bit outdated then. >>>>> >>>>>>> I want to try it out. >>>>>>> I tried to load it (XTream-Core) into my image, and it bug me about >>>>>>> unresolved dependencies: >>>>>>> ---- >>>>>>> This package depends on the following classes: >>>>>>> Â ByteTextConverter >>>>>>> You must resolve these dependencies before you will be able to load >>>>>>> these definitions: >>>>>>> Â ByteTextConverter>>nextFromXtream: >>>>>>> Â ByteTextConverter>>nextPut:toXtream: >>>>>>> Â ByteTextConverter>>readInto:startingAt:count:fromXtream: >>>>>>> ---- >>>>>>> I ignored these warnings, pressing continue, and here what it warns >>>>>>> about in my trunk image: >>>>>>> >>>>>>> TextConverter>>next:putAll:startingAt:toXtream: (latin1Map is >>>>>>> Undeclared) >>>>>>> TextConverter>>next:putAll:startingAt:toXtream: (latin1Encodings is >>>>>>> Undeclared) >>>>>>> TextConverter>>readInto:startingAt:count:fromXtream: (latin1Map is >>>>>>> Undeclared) >>>>>>> >>>>>>> Is ByteTextConverter a Pharo-specific class? >>>>>>> >>>>>> >>>>>> This is a refactoring of TextConverter I made in trunk. >>>>>> Pharo did the same before me (it comes from Sophie), but I missed it >>>>>> unfortunately... >>>>>> >>>>>>> If you seen my previous message, i think you noticed that >>>>>>> XXXTextConverter is abdominations (IMO), and should be reimplemented >>>>>>> as a wrapping-streams instead. >>>>>>> Would you be willing to change that in XStreams? I mean implementing >>>>>>> a >>>>>>> conversion streams model, which can wrap around any other stream, >>>>>>> like: >>>>>>> >>>>>>> myStream := UTFReaderStream on: otherStream. >>>>>>> myString := myStream contents. >>>>>>> >>>>>>> or using other way: >>>>>>> >>>>>>> myString := (someBaseStream wrapWith: UTFReaderStream) contents. >>>>>>> >>>>>>> or.. >>>>>>> myDecodedString := (someBaseStream wrapWith: (DecodingStreams >>>>>>> decoderFor: myEncoding) contents. >>>>>>> >>>>>>> That's would be much nicer than using converters. >>>>>> >>>>>> Currently, I have a ConverterReadXtream and a ConverterWriteXtream >>>>>> which are stream wrappers. >>>>>> They use old TextConverter to do the real job, but I agree, a full >>>>>> rewrite of this one is needed. >>>>>> However, I would like to keep these two layers for Stream composition: >>>>>> - the generic converter stream >>>>>> - the conversion algorithm >>>>>> >>>>> >>>>> Why? >>>>> In your implementation you already added the >>>>> readInto: aCollection startingAt: startIndex count: anInteger >>>>> and >>>>> next: count into: aString startingAt: startIndex >>>>> into converters, which makes them even more like streams. >>>>> >>>> >>>> Yes, you may be right. >>>> Maybe my ratio innovating/reusing was a bit low :) >>>> >>>>> So, what stopping you from making an abstract, generic XtreamWrapper >>>>> class, >>>>> and then a number of subclasses Â (LatinConversionStream , >>>>> UnicodeConversionStream etc), >>>> >>>> Yes, that's possible. But it's already what ConverterReadXtream and >>>> ConverterWriteXtream are. >>>> >>> >>> I suggesting to use a following hierarchy >>> >>> Xtream -> XtreamWrapper -> ConverterXtream -> (bunch of subclasses) >>> >>> or just >>> >>> Xtream -> XtreamWrapper -> (bunch of subclasses) >>> >>> since i don't think there a lot of specific behavior in >>> ConverterXtream worth creating a separate class. >>> But maybe i'm wrong. >>> >>>>> as well as BufferedWrapper? >>>>> >>>> >>>> BufferedReadXtream and BufferedWriteXtream already are generic. It's >>>> just that I have separated read and write... >>>> So you will find ReadXtream>>buffered >>>> Â Â Â Â ^(BufferedReadXtream new) >>>> Â Â Â Â Â Â Â Â contentsSpecies: self contentsSpecies bufferSize: self >>>> preferredBufferSize; >>>> Â Â Â Â Â Â Â Â source: self >>>> >>>> Or do you mean a single Buffer for read/write ? >>>> That would look more like original VW I think. >>>> >>> >>> obviously, if you reading and writing to same stream , you should take >>> care of keeping any buffered i/o in sync. >>> The #buffered can decide what kind of stream to create >>> self isWritable ifTrue: [ create R/W wrapper ] ifFalse: [ create R/O >>> wrapper ] >>> >>> this is , of course if you promote #buffered to Xtream class. Which i >>> think worthful thing. >>> >>>>> So, it will cost us 1 less message dispatch in >>>>> a := stream next. >>>>> >>>>> In your model you having: >>>>> >>>>> (converter stream) -> (converter) -> basic stream >>>>> >>>>> while if using wrapper it will be just: >>>>> (converter wrapper) -> basic stream >>>>> >>>> >>>> I must re-think why I made this decision of additional indirection... >>>> Maybe it was just reusing... >>>> >>> >>> I think this is just about reuse. But as i shown in >>> UFT8TextConverter>>nextFromStream: >>> its in addition to extra dispatch, using a characters instead of >>> bytes, which can be avoided >>> if you wrap the stream to be converted and tell it to work in binary >>> mode, since your wrapper are in control. >>> >>>>> >>>>>> Though current XTream is a quick hack reusing Yoshiki TextConverter, >>>>>> it already demonstrates possible gains coming from buffering. >>>>>> The speed comes from,applying utf8ToSqueak, squeakToUtf8 trick: copy >>>>>> large ASCII encoded portions verbatim. >>>>>> This works very well with squeak source because 99,99% of characters >>>>>> are ASCII. >>>>>> >>>>>>> >>>>>>> Wrappers is more flexible comparing to TextConverters, since they are >>>>>>> not obliged to convert to/from text-based collections only. >>>>>>> For example, we can use same API for wrapping with ZIP stream: >>>>>>> >>>>>>> myUnpackedData := (someBaseStream wrapWith: ZIPReaderStream) >>>>>>> contents. >>>>>>> >>>>>>> and many other (ab)uses.. Like reading changeset chunks: >>>>>>> >>>>>>> nextChunk := (fileStream wrapWith: ChunkReaderStream) next. >>>>>>> >>>>>> >>>>>> Yes, that fits my intentions. >>>>>> What I want is to preserve buffered operations along the chain, and >>>>>> avoid byte-by-byte conversions when possible. >>>>>> >>>>> >>>>> Buffering is just a wrapper. Btw, again, why you don't providing a >>>>> generic wrapper class which everyone can subclass from? >>>>> >>>>> bufferedStream := anyStreamClass buffered >>>>> >>>>> (buffered wrapper) -> (anyStreamClass) >>>>> >>>> >>>> See above, it's just split in BufferedRead/WriteXtream >>>> >>>> Or see the example (a bit heavy) >>>> Â tmp := ((StandardFileStream readOnlyFileNamed: (SourceFiles at: 2) >>>> name) >>>> Â Â Â readXtream ascii buffered decodeWith: (UTF8TextConverter new >>>> installLineEndConvention: nil)) buffered. >>>> >>> >>> yes. its a bit heavy, but this is a way how one should build a chains >>> of streams. >>> Except that there should be only streams in chain, no non-stream >>> converters in between :) >>> >>>> >>>>> i don't see where else you should care of buffering explicitly in >>>>> anyStreamClass. >>>>> >>>>> And, how you can avoid byte-by-byte conversion in utf8? It should >>>>> iterate over bytes to determine the characters anyways. >>>> >>>> True, it is faster because you scan fast with a primitive, >>>> then copy a whole chunk with replaceFrom:to:with:startingAt: primitive >>>> >>>> Of course, if you handle some cyrillic files, then this strategy won't >>>> be efficient. It just work in ASCII dominated files. >>>> UTF8 itself would not be an optimal choice for cyrillic anyway... >>>> >>> I prefer to use UFT8 nowadays, instead of old rubbish encodings, which >>> is many :) >>> >>>>> But sure thing, nothing prevents you from buffering things in a way >>>>> like: >>>>> >>>>> reader := anyStream buffered wrapWith: UTF8Reader. >>>>> >>>> >>>> My above example is just equivalent to: >>>> >>>> reader := (anyStream buffered wrapWith: UTF8Reader) buffered. >>>> >>>> Then even if I use reader next, a whole buffer of UTF8 is converted >>>> (presumably by large chunks) >>>> >>> >>> Right, nobody says that its not possible to do double-buffering. >>> First, by wrapping an original stream (presumably file-based) >>> and second - an output of utf8 converter. >>> >>> [snip] >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 27, 2010

Re: [Pharo-project] Streams. Status and where to go?

by Nicolas Cellier

I pushed embryonary XTream-CharacterCode for TextConverter replacement in XTream. Nicolas 2010/2/26 Igor Stasenko <siguctua(a)gmail.com>: > On 26 February 2010 21:30, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> 2010/2/26 Igor Stasenko <siguctua(a)gmail.com>: >>> On 26 February 2010 18:59, Nicolas Cellier >>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>> 2010/2/26 Igor Stasenko <siguctua(a)gmail.com>: >>>>> Hello, Nicolas. >>>> >>>> Hi igor. >>>> You should load it in trunk. >>>> >>> Ah, i think my image is a bit outdated then. >>> >>>>> I want to try it out. >>>>> I tried to load it (XTream-Core) into my image, and it bug me about >>>>> unresolved dependencies: >>>>> ---- >>>>> This package depends on the following classes: >>>>> Â ByteTextConverter >>>>> You must resolve these dependencies before you will be able to load >>>>> these definitions: >>>>> Â ByteTextConverter>>nextFromXtream: >>>>> Â ByteTextConverter>>nextPut:toXtream: >>>>> Â ByteTextConverter>>readInto:startingAt:count:fromXtream: >>>>> ---- >>>>> I ignored these warnings, pressing continue, and here what it warns >>>>> about in my trunk image: >>>>> >>>>> TextConverter>>next:putAll:startingAt:toXtream: (latin1Map is Undeclared) >>>>> TextConverter>>next:putAll:startingAt:toXtream: (latin1Encodings is Undeclared) >>>>> TextConverter>>readInto:startingAt:count:fromXtream: (latin1Map is Undeclared) >>>>> >>>>> Is ByteTextConverter a Pharo-specific class? >>>>> >>>> >>>> This is a refactoring of TextConverter I made in trunk. >>>> Pharo did the same before me (it comes from Sophie), but I missed it >>>> unfortunately... >>>> >>>>> If you seen my previous message, i think you noticed that >>>>> XXXTextConverter is abdominations (IMO), and should be reimplemented >>>>> as a wrapping-streams instead. >>>>> Would you be willing to change that in XStreams? I mean implementing a >>>>> conversion streams model, which can wrap around any other stream, >>>>> like: >>>>> >>>>> myStream := UTFReaderStream on: otherStream. >>>>> myString := myStream contents. >>>>> >>>>> or using other way: >>>>> >>>>> myString := (someBaseStream wrapWith: UTFReaderStream) contents. >>>>> >>>>> or.. >>>>> myDecodedString := (someBaseStream wrapWith: (DecodingStreams >>>>> decoderFor: myEncoding) contents. >>>>> >>>>> That's would be much nicer than using converters. >>>> >>>> Currently, I have a ConverterReadXtream and a ConverterWriteXtream >>>> which are stream wrappers. >>>> They use old TextConverter to do the real job, but I agree, a full >>>> rewrite of this one is needed. >>>> However, I would like to keep these two layers for Stream composition: >>>> - the generic converter stream >>>> - the conversion algorithm >>>> >>> >>> Why? >>> In your implementation you already added the >>> readInto: aCollection startingAt: startIndex count: anInteger >>> and >>> next: count into: aString startingAt: startIndex >>> into converters, which makes them even more like streams. >>> >> >> Yes, you may be right. >> Maybe my ratio innovating/reusing was a bit low :) >> >>> So, what stopping you from making an abstract, generic XtreamWrapper class, >>> and then a number of subclasses Â (LatinConversionStream , >>> UnicodeConversionStream etc), >> >> Yes, that's possible. But it's already what ConverterReadXtream and >> ConverterWriteXtream are. >> > > I suggesting to use a following hierarchy > > Xtream -> XtreamWrapper -> ConverterXtream -> (bunch of subclasses) > > or just > > Xtream -> XtreamWrapper -> (bunch of subclasses) > > since i don't think there a lot of specific behavior in > ConverterXtream worth creating a separate class. > But maybe i'm wrong. > >>> as well as BufferedWrapper? >>> >> >> BufferedReadXtream and BufferedWriteXtream already are generic. It's >> just that I have separated read and write... >> So you will find ReadXtream>>buffered >> Â Â Â Â ^(BufferedReadXtream new) >> Â Â Â Â Â Â Â Â contentsSpecies: self contentsSpecies bufferSize: self preferredBufferSize; >> Â Â Â Â Â Â Â Â source: self >> >> Or do you mean a single Buffer for read/write ? >> That would look more like original VW I think. >> > > obviously, if you reading and writing to same stream , you should take > care of keeping any buffered i/o in sync. > The #buffered can decide what kind of stream to create > self isWritable ifTrue: [ create R/W wrapper ] ifFalse: [ create R/O wrapper ] > > this is , of course if you promote #buffered to Xtream class. Which i > think worthful thing. > >>> So, it will cost us 1 less message dispatch in >>> a := stream next. >>> >>> In your model you having: >>> >>> (converter stream) -> (converter) -> basic stream >>> >>> while if using wrapper it will be just: >>> (converter wrapper) -> basic stream >>> >> >> I must re-think why I made this decision of additional indirection... >> Maybe it was just reusing... >> > > I think this is just about reuse. But as i shown in > UFT8TextConverter>>nextFromStream: > its in addition to extra dispatch, using a characters instead of > bytes, which can be avoided > if you wrap the stream to be converted and tell it to work in binary > mode, since your wrapper are in control. > >>> >>>> Though current XTream is a quick hack reusing Yoshiki TextConverter, >>>> it already demonstrates possible gains coming from buffering. >>>> The speed comes from,applying utf8ToSqueak, squeakToUtf8 trick: copy >>>> large ASCII encoded portions verbatim. >>>> This works very well with squeak source because 99,99% of characters are ASCII. >>>> >>>>> >>>>> Wrappers is more flexible comparing to TextConverters, since they are >>>>> not obliged to convert to/from text-based collections only. >>>>> For example, we can use same API for wrapping with ZIP stream: >>>>> >>>>> myUnpackedData := (someBaseStream wrapWith: ZIPReaderStream) contents. >>>>> >>>>> and many other (ab)uses.. Like reading changeset chunks: >>>>> >>>>> nextChunk := (fileStream wrapWith: ChunkReaderStream) next. >>>>> >>>> >>>> Yes, that fits my intentions. >>>> What I want is to preserve buffered operations along the chain, and >>>> avoid byte-by-byte conversions when possible. >>>> >>> >>> Buffering is just a wrapper. Btw, again, why you don't providing a >>> generic wrapper class which everyone can subclass from? >>> >>> bufferedStream := anyStreamClass buffered >>> >>> (buffered wrapper) -> (anyStreamClass) >>> >> >> See above, it's just split in BufferedRead/WriteXtream >> >> Or see the example (a bit heavy) >> Â tmp := ((StandardFileStream readOnlyFileNamed: (SourceFiles at: 2) name) >> Â Â Â readXtream ascii buffered decodeWith: (UTF8TextConverter new >> installLineEndConvention: nil)) buffered. >> > > yes. its a bit heavy, but this is a way how one should build a chains > of streams. > Except that there should be only streams in chain, no non-stream > converters in between :) > >> >>> i don't see where else you should care of buffering explicitly in >>> anyStreamClass. >>> >>> And, how you can avoid byte-by-byte conversion in utf8? It should >>> iterate over bytes to determine the characters anyways. >> >> True, it is faster because you scan fast with a primitive, >> then copy a whole chunk with replaceFrom:to:with:startingAt: primitive >> >> Of course, if you handle some cyrillic files, then this strategy won't >> be efficient. It just work in ASCII dominated files. >> UTF8 itself would not be an optimal choice for cyrillic anyway... >> > I prefer to use UFT8 nowadays, instead of old rubbish encodings, which > is many :) > >>> But sure thing, nothing prevents you from buffering things in a way like: >>> >>> reader := anyStream buffered wrapWith: UTF8Reader. >>> >> >> My above example is just equivalent to: >> >> reader := (anyStream buffered wrapWith: UTF8Reader) buffered. >> >> Then even if I use reader next, a whole buffer of UTF8 is converted >> (presumably by large chunks) >> > > Right, nobody says that its not possible to do double-buffering. > First, by wrapping an original stream (presumably file-based) > and second - an output of utf8 converter. > > [snip] > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 27, 2010

[Pharo-project] [update 1.1] #11237

by StÃ©phane Ducasse

11237 ----- - Issue 2093: SUnitSpeedUp testSelectors - Issue 2092: Register file after setting name (from CUIS) and a couple of other little tweaks from squeak Stef

Feb. 27, 2010

Re: [Pharo-project] polymorph theme with new color for text

by Schwab,Wilhelm K

My interest is to change the background color of text editors. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Hilaire Fernandes [hilaire(a)ofset.org] Sent: Saturday, February 27, 2010 2:31 PM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] polymorph theme with new color for text Hello, In a custom Polymorph theme I want to use another color them for the menu font, button font,... Really I don't see from where it is themable. Any ideas? Hilaire _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 27, 2010

[Pharo-project] polymorph theme with new color for text

by Hilaire Fernandes

Hello, In a custom Polymorph theme I want to use another color them for the menu font, button font,... Really I don't see from where it is themable. Any ideas? Hilaire

Feb. 27, 2010

Re: [Pharo-project] Quasi-stateful traits?

by Igor Stasenko

On 27 February 2010 19:21, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> My point is still valid >>> >>>>> Igor now one of the problem is see with the possible to add and access slot everywhere is illustrated by morphic code >>>>> when a method add a property extension to a morph, another tests for its value and the third one remove it. >>>>> You get code that is really difficult to understand. >>> >> You mean that morphs could add arbitrary slots to its instances? > > yes look at addProperty and friends > >> Why difficult? > > Apparently you never tried to understand morphic code. > Try in Squeak 3.9 not pharo because we removed a lot of problem already > I took a look. And addProperty & morphic-extensions is obviously not best pieces of code. The things is, that most of these properties usually set up only once on widget init and never touched during lifetime of morph. The possibility to remove the property from morph is cool, but used seldom. So, actually this means, that morphs could be built using a composition of dynamic and static properties - styles, and all you need is to pick a morph and apply style to it. And no need to support dozens of properties as an additional state on a per-morph basis. >> This extension is to match the object format of Self and JavaScript. > > Why do we need that? > When do you need that? > Why an instance should have a dictionary based access? > How this is integrate with our tools? > > Why a good mop does not let you do that :) Maybe because its not good enough? > We will be working on that > > I asked but this is several years that I think that under specific circumstances it would make sense > to have > > Object dictionaryVariableSubclass: > > > but not just to look like self or javascript. > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Feb. 27, 2010

Re: [Pharo-project] Quasi-stateful traits?

by StÃ©phane Ducasse

>> My point is still valid >> >>>> Igor now one of the problem is see with the possible to add and access slot everywhere is illustrated by morphic code >>>> when a method add a property extension to a morph, another tests for its value and the third one remove it. >>>> You get code that is really difficult to understand. >> > You mean that morphs could add arbitrary slots to its instances? yes look at addProperty and friends > Why difficult? Apparently you never tried to understand morphic code. Try in Squeak 3.9 not pharo because we removed a lot of problem already > This extension is to match the object format of Self and JavaScript. Why do we need that? When do you need that? Why an instance should have a dictionary based access? How this is integrate with our tools? Why a good mop does not let you do that :) We will be working on that I asked but this is several years that I think that under specific circumstances it would make sense to have Object dictionaryVariableSubclass: but not just to look like self or javascript. Stef

Feb. 27, 2010

Re: [Pharo-project] Quasi-stateful traits?

by Igor Stasenko

On 27 February 2010 18:44, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Feb 27, 2010, at 5:12 PM, Igor Stasenko wrote: > >> On 27 February 2010 10:11, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> orthogonally to traits I sometimes would like python like hash based (but class and not object) semantics >>> ie >>> >>> Object dictionaryVariable: #MyClass >>> >>> >>> Igor now one of the problem is see with the possible to add and access slot everywhere is illustrated by morphic code >>> when a method add a property extension to a morph, another tests for its value and the third one remove it. >>> You get code that is really difficult to understand. >>>> <key1><value1> >>>> <key2><value2> >>> >> This is an object memmory layout - >> a pair of two oops(object pointers) one following other - Â key and value. > > yes I got it. > > > My point is still valid > >>> Igor now one of the problem is see with the possible to add and access slot everywhere is illustrated by morphic code >>> when a method add a property extension to a morph, another tests for its value and the third one remove it. >>> You get code that is really difficult to understand. > You mean that morphs could add arbitrary slots to its instances? Why difficult? This extension is to match the object format of Self and JavaScript. > > > >> >>> >>> >>> On Feb 27, 2010, at 12:39 AM, Igor Stasenko wrote: >>> >>>> One of the ways of introducing a stateful traits is changing the VM >>>> object format. >>>> There is a bits in object's header reserved for identity hash. >>>> Instead of putting the identify hash value there, we could use it to >>>> indicate if given object has additional arbitrary slots following the >>>> object contents: >>>> >>>> <header> >>>> <ivar1> >>>> ... >>>> <ivarN> >>>> <variableVar1> >>>> ... >>>> <variableVarM> >>>> <key1><value1> >>>> <key2><value2> >>>> ... >>>> <keyK><valueK> >>>> >>>> so, these keyN->valueN forming a dictionary of key/value pairs, which >>>> can be accessed using new primitives #slotAt: and #sloatAt:put: >>>> >>>> slot allocaiton can be expressed as: >>>> >>>> newObject := object copyWithSlot: key value: value. >>>> object becomeForward: newObject. >>>> >>>> (except that this is done by VM primitively). >>>> >>>> Once slots is allocated, object size is not grows anymore (so there >>>> are no overhead) and as bonus, you getting a way to attach any >>>> additional state to virtually any objects (except smallints) , for any >>>> purposes. >>>> Identity hash is become slower, but only at first hashing attempt. >>>> (slotAt: #identityHash put: value) >>>> But as benefit, we could use any object (or just 31 bit small integer) >>>> for hash values, which will increase the hashing quality considerably. >>>> So, it is a question, what will be faster, especially for large >>>> dictionaries. >>>> >>>> Obviously, then traits free to use this to keep own state, without any >>>> extra demands from classes where it installed: >>>> >>>> foo >>>> Â ^ self slotAt: #foo >>>> foo: value >>>> Â self slotAt: #foo put: value >>>> >>>> Also, I think that with such extension, we might expect a considerable >>>> speed boost for Magma OODB, which can use additional slot for marking >>>> objects by own ids, as well as for marking object dirty, instead of >>>> maintaining a huge and ineffective IdentityDictionaries to track the >>>> objects state. >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Feb. 27, 2010

Re: [Pharo-project] Quasi-stateful traits?

by StÃ©phane Ducasse

On Feb 27, 2010, at 5:12 PM, Igor Stasenko wrote: > On 27 February 2010 10:11, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> orthogonally to traits I sometimes would like python like hash based (but class and not object) semantics >> ie >> >> Object dictionaryVariable: #MyClass >> >> >> Igor now one of the problem is see with the possible to add and access slot everywhere is illustrated by morphic code >> when a method add a property extension to a morph, another tests for its value and the third one remove it. >> You get code that is really difficult to understand. >>> <key1><value1> >>> <key2><value2> >> > This is an object memmory layout - > a pair of two oops(object pointers) one following other - key and value. yes I got it. My point is still valid >> Igor now one of the problem is see with the possible to add and access slot everywhere is illustrated by morphic code >> when a method add a property extension to a morph, another tests for its value and the third one remove it. >> You get code that is really difficult to understand. > >> >> >> On Feb 27, 2010, at 12:39 AM, Igor Stasenko wrote: >> >>> One of the ways of introducing a stateful traits is changing the VM >>> object format. >>> There is a bits in object's header reserved for identity hash. >>> Instead of putting the identify hash value there, we could use it to >>> indicate if given object has additional arbitrary slots following the >>> object contents: >>> >>> <header> >>> <ivar1> >>> ... >>> <ivarN> >>> <variableVar1> >>> ... >>> <variableVarM> >>> <key1><value1> >>> <key2><value2> >>> ... >>> <keyK><valueK> >>> >>> so, these keyN->valueN forming a dictionary of key/value pairs, which >>> can be accessed using new primitives #slotAt: and #sloatAt:put: >>> >>> slot allocaiton can be expressed as: >>> >>> newObject := object copyWithSlot: key value: value. >>> object becomeForward: newObject. >>> >>> (except that this is done by VM primitively). >>> >>> Once slots is allocated, object size is not grows anymore (so there >>> are no overhead) and as bonus, you getting a way to attach any >>> additional state to virtually any objects (except smallints) , for any >>> purposes. >>> Identity hash is become slower, but only at first hashing attempt. >>> (slotAt: #identityHash put: value) >>> But as benefit, we could use any object (or just 31 bit small integer) >>> for hash values, which will increase the hashing quality considerably. >>> So, it is a question, what will be faster, especially for large >>> dictionaries. >>> >>> Obviously, then traits free to use this to keep own state, without any >>> extra demands from classes where it installed: >>> >>> foo >>> ^ self slotAt: #foo >>> foo: value >>> self slotAt: #foo put: value >>> >>> Also, I think that with such extension, we might expect a considerable >>> speed boost for Magma OODB, which can use additional slot for marking >>> objects by own ids, as well as for marking object dirty, instead of >>> maintaining a huge and ineffective IdentityDictionaries to track the >>> objects state. >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 27, 2010

[Pharo-project] [ANN] Printed version of "Dynamic Web Development with Seaside"

by Lukas Renggli

A print-on-demand, softcover copy of the book "Dynamic Web Development with Seaside" is available from Lulu. The printed book is identical with the online and the PDF version of the book. http://book.seaside.st/book/introduction/print-book We wish to thank the European Smalltalk User Group (ESUG), inceptive.be, Cincom Smalltalk, GemStone Smalltalk and Instantiations for generously sponsoring this book. Please distribute this message widely. Cheers, Stef & Lukas

Feb. 27, 2010