Has someone seen something happening with Monticello Mcz handling extended characters ? If I add a non-ascii character to MCMockClassA comment, such as ø, then MCMczInstallerTest>>testInstallFromFile fails. If I add an ascii character instead to MCMockClassA comment, then this test pass. (On 2.0 / 20610) It's recent and has appeared between mid-june and now. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
On Jul 4, 2013, at 2:22 , Goubier Thierry wrote:
Has someone seen something happening with Monticello Mcz handling extended characters ?
If I add a non-ascii character to MCMockClassA comment, such as ø, then MCMczInstallerTest>>testInstallFromFile fails. If I add an ascii character instead to MCMockClassA comment, then this test pass.
(On 2.0 / 20610)
It's recent and has appeared between mid-june and now.
Thierry -- Not sure you can call it recent, the same bug exists and is reproduceable by adding an ø to MCMockClassA back to at least Pharo 1.0 :)
It happens due to: MCZInstaller >> #installMember: member self useNewChangeSetDuring: [ | str |str := member contentStream text. str setConverterForCode. CodeImporter evaluateReadStream: str readStream. ] setConverterForCode has never been the right thing to do for reading non-ascii .st files written by Monticello, since it's tended to write the raw strings to disk without any regard to encoding. For the comment you modified, that means it would have been written as latin1, and attempted to be read as MacRoman, where the code point of ø is different. In recent 3.0 versions, it's been fixed by Nicolas Cellier's changes to actually store/read .st files created by Monticello in utf8. Cheers, Henry
Hi Henrik, Thanks for the info; I effectively ended in setConverterForCode... One more reason to use github over Smalltalkhub: correct handling of accentuated text :( I'll do some testing to make sure I know how to safely copy github hosted packages to smalltalkhub, and avoid polluting my git repository. Thierry Le 04/07/2013 15:03, Henrik Johansen a écrit :
On Jul 4, 2013, at 2:22 , Goubier Thierry wrote:
Has someone seen something happening with Monticello Mcz handling extended characters ?
If I add a non-ascii character to MCMockClassA comment, such as ø, then MCMczInstallerTest>>testInstallFromFile fails. If I add an ascii character instead to MCMockClassA comment, then this test pass.
(On 2.0 / 20610)
It's recent and has appeared between mid-june and now.
Thierry -- Not sure you can call it recent, the same bug exists and is reproduceable by adding an ø to MCMockClassA back to at least Pharo 1.0 :)
It happens due to: MCZInstaller >> #installMember: member self useNewChangeSetDuring: [ | str |str := member contentStream text. *str setConverterForCode*. CodeImporter evaluateReadStream: str readStream. ]
setConverterForCode has never been the right thing to do for reading non-ascii .st files written by Monticello, since it's tended to write the raw strings to disk without any regard to encoding. For the comment you modified, that means it would have been written as latin1, and attempted to be read as MacRoman, where the code point of ø is different.
In recent 3.0 versions, it's been fixed by Nicolas Cellier's changes to actually store/read .st files created by Monticello in utf8.
Cheers, Henry
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
participants (2)
-
Goubier Thierry -
Henrik Johansen