On 07.08.2010, at 20:58, Philippe Marschall wrote: > On 07.08.2010 13:08, Norbert Hartl wrote: >> .... >> 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. >> 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. > > We try to be 7bit clean in Seaside. Can you report the methods you have > trouble with to either the seaside mailing list or the issue tracker [1]? > I don't have troubles with any of the seaside methods. It just seems impossible for me to state things clear enough :) There was a real problem. There was WideStrings creeping into the monticello package of XML Parser. There is no way monticello can handle multi byte strings as it uses latin1 for encoding. The latin1 encoded WideStrings cannot be read by gemstone. But the troublesome piece of code has already been removed from the XML Parser package.
Seaside is not completely 7bit clean. As an example take Seaside-InternetExplorer-lr.6.mcz. There is a sentence "...we have introduced a mechanism to help prevent the untrusted content from compromising your site<92>s security...". The <92> is a RIGHT SINGLE QUOTATION MARK that Microsoft put into the latin1 gap. So I guess this is CP1252 which means it has been copied from a windows system into the squeak image. Norbert _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
