[Pharo-project] Nicolas tests for MultiByteFileStreamTest
Nicolas: I was trying to integrate your changes from here: http://source.squeak.org/trunk/MultilingualTests-nice.4.mcz in the latest Pharo Core 11116 and I have 2 failures and 2 errors. I just load the MultiByteFileStreamTest from that version. The question is, should I integrate some changes from MultiByteFileStream that are in squeak trunk so that the tests are green ? Thanks Mariano
2009/12/26 Mariano Martinez Peck <marianopeck@gmail.com>:
Nicolas: I was trying to integrate your changes from here: http://source.squeak.org/trunk/MultilingualTests-nice.4.mcz
in the latest Pharo Core 11116Â and I have 2 failures and 2 errors. I just load the MultiByteFileStreamTest from that version.
The question is, should I integrate some changes from MultiByteFileStream that are in squeak trunk so that the tests are green ?
Thanks
Mariano
Hmm, don't remember... BackChunk problem seems related to Damien changes (oldBack vs back) ByteConverter problem seems connected to lazy initialization of latin1Map
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/12/26 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
2009/12/26 Mariano Martinez Peck <marianopeck@gmail.com>:
Nicolas: I was trying to integrate your changes from here: http://source.squeak.org/trunk/MultilingualTests-nice.4.mcz
in the latest Pharo Core 11116Â and I have 2 failures and 2 errors. I just load the MultiByteFileStreamTest from that version.
The question is, should I integrate some changes from MultiByteFileStream that are in squeak trunk so that the tests are green ?
Thanks
Mariano
Hmm, don't remember... BackChunk problem seems related to Damien changes (oldBack vs back) ByteConverter problem seems connected to lazy initialization of latin1Map
1) You must pick TextConverter>>initialize 2) one test uses #collect:as you must pick from trunk (a very nice message to have in Pharo too http://code.google.com/p/pharo/issues/detail?id=1698 ) 3) Pharo use Unicode for example for converting MacRoman, while Squeak use CP1252 (the windows extended latin1) Pharo changes are using more advanced Sophie refactorings, so don't touch without asking authority :) Is the test too simplistic ? Nonetheless, my expectations are broken... I expect that If I can decode a char, It will then be encoded the same. 4) for UTF16, I don't know what's going on... 5) lineEnding problem comes from wantsLineEndConversion inst var in MultiByteFileStream which is not initialized correctly In squeak it is initialized automatically when setting #lineEndConvention: in Pharo it requires an explicit #wantsLineEndConversion: send... either change the test or update Pharo (by the way, this was an enhancement from Keith findable in mantis) 6) for backChunk, ask Damien and Nile maintainers for advice. oldBack was replaced by back, and this is not clear to me if it should be so or not... I don't know if my TestCase is a valid specification for backCunk too. That's what I would expect... but anyway, backChunk sounds like shit-to-be-removed - it has no clear definition / TestCase - implementation is inefficient - it is clearly broken by MultiByteFileStream (the expected failure) unfortunately, it is used... Nicolas
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (2)
-
Mariano Martinez Peck -
Nicolas Cellier