about Issue 860: Accelerate MulitByteFileStream

>
> nicolas
>
> do you have an idea how I could integrate these changes. I could not
> really understand what
> andreas meant when he pushed them into their trunk
>
> Stef
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> Hi Stephane,
>
> I just repeated the work in four steps, it worked OK in my Pharo  
> image.
> You just have to publish a package and a ScriptLoader script after
> each changeSet.
> Andreas managed to load in fewer steps, but he had modified Monticello
> load order previously.
> No need to be that adventurous.
>
> Nicolas
>
> 2009/11/1 Stéphane Ducasse <[hidden email]>:
>>
>> nicolas
>>
>> do you have an idea how I could integrate these changes. I could not
>> really understand what
>> andreas meant when he pushed them into their trunk
>>
>> Stef
>>
>>
>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Hi Stephane,
>
> I just repeated the work in four steps, it worked OK in my Pharo  
> image.
> You just have to publish a package and a ScriptLoader script after
> each changeSet.
> Andreas managed to load in fewer steps, but he had modified Monticello
> load order previously.
> No need to be that adventurous.
>
> Nicolas
>
> 2009/11/1 Stéphane Ducasse <[hidden email]>:
>>
>> nicolas
>>
>> do you have an idea how I could integrate these changes. I could not
>> really understand what
>> andreas meant when he pushed them into their trunk
>>
>> Stef
>>
>>
>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 2009/11/1 Stéphane Ducasse <[hidden email]>:
>> Nicolas
>>
>> I was wondering why TextConverter>> initialize
>> was calling nextPut: to Stream: which is abstract.
>>
>
> which initialize ?
> initializeLatin1MapAndEncodings ? yes, it is intended for concrete
> subclass only and triggered by lazy initialization.
>
>> So I imagine that only subclasses are invoking this behavior.
>>
>> So I was trying to understand the speed up idea but I failed (because
>> I did not know the speed up of andreas).
>>
>> Stef
>>
>>
>
> MultiByteFileStream iterate Character by Character which is sloooow...
> The idea is that most ASCII characters won't need a conversion.
> Andreas trick is to do a fast scan of the String for detecting chunks
> not requiring translation
> (there are fast primitives to do that on a ByteString).
> This enables putting these chunks of String without translations
> directly on the stream...
>
> I generalized this to any format (not only UTF8)
> I generalized this to lineEndConventions (for converting CR/LF,
> MultiByteFileStream iterates char by char too)
>
> That's for writting only. Maybe someday we should also speed reading  
> up.
>
> Nicolas
>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 2009/11/1 Stéphane Ducasse <[hidden email]>:
>> Nicolas
>>
>> I was wondering why TextConverter>> initialize
>> was calling nextPut: to Stream: which is abstract.
>>
>
> which initialize ?
> initializeLatin1MapAndEncodings ? yes, it is intended for concrete
> subclass only and triggered by lazy initialization.
>
>> So I imagine that only subclasses are invoking this behavior.
>>
>> So I was trying to understand the speed up idea but I failed (because
>> I did not know the speed up of andreas).
>>
>> Stef
>>
>>
>
> MultiByteFileStream iterate Character by Character which is sloooow...
> The idea is that most ASCII characters won't need a conversion.
> Andreas trick is to do a fast scan of the String for detecting chunks
> not requiring translation
> (there are fast primitives to do that on a ByteString).
> This enables putting these chunks of String without translations
> directly on the stream...
>
> I generalized this to any format (not only UTF8)
> I generalized this to lineEndConventions (for converting CR/LF,
> MultiByteFileStream iterates char by char too)
>
> That's for writting only. Maybe someday we should also speed reading  
> up.
>
> Nicolas
>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>