Norbert,
The reason that things are working correct is due to the use of the UTF8
stream ... without that, I think that things will go badly (sooner or
later) if QueadByte or DoubleByte strings are embedded ...
Have you checked what happens if a null codec stream is used when
QuadByte strings are used? If an error occurs when writing the stream
then that would be good enough:)
Dale
Norbert Hartl wrote:
> A short notice about my new changes to Sixx.
>
> Today I recognized that there is missing handling for DoubleByteString/-Symbol and QuadByteString/-Symbol in Sixx. I added the handling in a way that it only uses the String and Symbol class to be more cross-platform
>
> - DoubleByteString and QuadByteString are exported as type String
> - DoubleByteSymbol and QuadByteSymbol are exported as type Symbol
>
> This way they can be read back in from a platform that is not gemstone.
>
> If the content is read back in into gemstone the following happens:
>
> - gemstone only produces String and QuadByteString when read in
> - in case it was a QuadByteString everything is fine
> - in case of a DoubleByteString I added an additional asString to the mix that converts a double byte string that was read in as QuadByteString back to DoubleByteString
> - this way the classes are equally recreated
> - the same goes for the symbol classes
>
> I hope I'm not mistaken that this can lead to errors. I added tests for this to Sixx.
>
> With the changes to Sixx the last days (grease stream integration) I can now export a pier kernel reliably by invoking
>
> (PRKernel instanceNamed: 'pier') sixxOn: (GRUtf8CodecStream on: (GsFile openWriteOnServer: '/tmp/pier-kernel.xml'))
>
> Norbert
>
Locked
