Accelerating MultiByteFileStream

What about integrating changes from
http://code.google.com/p/pharo/issues/detail?id=860 ?

It will only accelerate nextPutAll: in case of latin1, but that
already covers lot of code.
And it generalizes Andreas trick squeakToUtf8 to any other encoding...
And it handles lineEndConvention with the same trick...

Nicolas

Nicolas Cellier wrote:
> What about integrating changes from
> http://code.google.com/p/pharo/issues/detail?id=860 ?
>
> It will only accelerate nextPutAll: in case of latin1, but that
> already covers lot of code.
> And it generalizes Andreas trick squeakToUtf8 to any other encoding...
> And it handles lineEndConvention with the same trick...

Looks like a great improvement! Do you any help with integrating it?

Cheers,
   - Andreas

On 23.10.2009, at 00:40, Nicolas Cellier wrote:

> What about integrating changes from
> http://code.google.com/p/pharo/issues/detail?id=860 ?
>
> It will only accelerate nextPutAll: in case of latin1, but that
> already covers lot of code.


> And it generalizes Andreas trick squeakToUtf8 to any other encoding...

Sounds good, and this direction should be safe I hope.

We just had a bug in Etoys that required replacing "squeakToUtf8" with  
"convertFromEncoding: #utf8". While the both are supposed to be  
equivalent, the former does not set the leadingChar, which is required  
for some locales:

http://lists.squeakland.org/pipermail/etoys-dev/2009-October/004045.html

- Bert -

Bert Freudenberg wrote:
> Sounds good, and this direction should be safe I hope.
>
> We just had a bug in Etoys that required replacing "squeakToUtf8" with
> "convertFromEncoding: #utf8". While the both are supposed to be
> equivalent, the former does not set the leadingChar, which is required
> for some locales:
>
> http://lists.squeakland.org/pipermail/etoys-dev/2009-October/004045.html

This is fixed now. I think it was more of a typo, it said Character
value: foo where it should have said Unicode value: foo.

Cheers,
   - Andreas

2009/10/23 Andreas Raab <[hidden email]>:
Hi Andreas,
There should not be much conflict with trunk.
The files load and the image still works :) (File tests pass at least).
But I don't know if I'll have much time this week end.
And there is a tricky Postscript, I don't know how to handle via MC:

SourceFiles do: [:e | (e isKindOf: MultiByteFileStream) ifTrue: [
                e installLineEndConventionInConverter]]!

Maybe the trick should better be applied to each and every file found
in some registry...
So yes, I think I need a bit help, at least for initialization.

Nicolas

Nicolas Cellier wrote:
All taken care of. It was actually interesting to see that because the
MC loader now has a well-defined load order there was no need to break
out the changes. They could go into a single commit. For the SourceFiles
I decided not to do an explicit doIt but rather put in a lazy install,
issue a config map, and remove the lazy install again. That works fine.
Oh, and I chose to ignore any other open files (I don't believe that it
matters).

Cheers,
   - Andreas