On 07.08.2010, at 13:19, Stéphane Ducasse wrote:
Has this been reported before? If not why? This is really important. I don't think we can wait until Monticello is replaced by something different that will fix this :)
the anwser is: - check bug entries - add new one if necessary - propose a fix if possible - else wait.
I replied to Henriks mail. It was meant as a question to him because he knows about the topic. I see I need to be more clear next time. And btw. this was _not_ an answer to my question.
There are a few things here that work together in 98% of all cases. I didn't get it fully what is going on but
ZipArchiveMember>>contentStream does ... s := MultiByteBinaryOrTextStream on: (String new: self uncompressedSize). s converter: Latin1TextConverter new. ...
and
MultiByteBinaryOrTextStream>>defaultConverter ^ Latin1TextConverter new.
These two are being used when a monticello package is being read. So we have an assumption about an encoding here. On the other hand something in the system does something similar. I don't know InputEvents and how to debug them but if I create a method
EncTest>>encTest ^ 'ö'
I can see that
((EncTest>>#encTest literalAt: 1) at: 1) asciiValue
is 246 which is something that matches latin1 to some extent.
This way there is a conversion (I think at the time I press on my keyboard) to latin1. While writing a monticello package I didn't find any conversion so this might be the reason that the files become latin1 on disk and can be read back using an explicit conversion from latin1.
But this does not explain how it does work with WideString. I would need to dig deeper but maybe someone of you have an idea.
To estimate the possibility to change this I think we should fix this. I scanned all of my cached monticello packages. Most of them are 7bit clean.
how do you do that?
for i in `find . -name "*.mcz"`; do echo $i; unzip -qc $i snapshot/source.st | enca -L none; done
No problem for them if we change encoding. Besides XML Parser I didn't find any that contain WideString so no problem here. Some of them are latin1 encoded (like Seaside 2.8 or Seaside-InternetExplorer from 3.0). That is the biggest problem because there is no fallback and monticello does not have a version number on file format, right? I think it is still feasible to change this in monticello as the fix for users of older images will be probably only a few lines that you can apply to any version of monticello if I'm not wrong. But the change is not that easy.
This is not clear to me what is the problem and potential solution. I was not concentrated enough on pharo :(
It is not clear to me, either. That's why I am asking. I'm willing to track this down any further. At least i want to open a substantial ticket. But a little bit more information would be helpful. Norbert