Re: [Pharo-project] [Help-smalltalk] Fun with Pharo generated source.st
Il 04/05/2013 18:51, Holger Hans Peter Freyther ha scritto:
Hi,
I am trying to convert/import all of Iliad (since the development had moved to Pharo) and I stumble up-on an issue I already had when I tried to convert Aida.
This[1] monticello file in line 6417 starts to use UCS-4 for a string and then stops at some characters later. Importing the file using FileStream is failing in Pharo as well.
And how does monticello file it in then?!? I'm adding the Pharo list. Paolo
There doesn't appear to be a BOM before the UCS-4 so I wonder if we can detect it or not. Maybe it is time to use more of MontiCello to read these files directly.
ideas?
holger
[1]http://www.squeaksource.com/IliadDev/Iliad-Core0.9.1-SebastienAudier.5.mcz
_______________________________________________ help-smalltalk mailing list help-smalltalk@gnu.org https://lists.gnu.org/mailman/listinfo/help-smalltalk
On 5 May 2013 09:54, Paolo Bonzini <bonzini@gnu.org> wrote:
Il 04/05/2013 18:51, Holger Hans Peter Freyther ha scritto:
Hi,
I am trying to convert/import all of Iliad (since the development had moved to Pharo) and I stumble up-on an issue I already had when I tried to convert Aida.
This[1] monticello file in line 6417 starts to use UCS-4 for a string and then stops at some characters later. Importing the file using FileStream is failing in Pharo as well.
And how does monticello file it in then?!? I'm adding the Pharo list.
Monticello doesn't use the snapshot. The snapshot's stored in addition to the "real" MC stuff, containing the changes that the mcz defines. It's sorta-kinda like the difference between your working copy and git diff HEAD HEAD^. MC uses the latter, the snapshot is the former. frank
Paolo
There doesn't appear to be a BOM before the UCS-4 so I wonder if we can detect it or not. Maybe it is time to use more of MontiCello to read these files directly.
ideas?
holger
[1]http://www.squeaksource.com/IliadDev/Iliad-Core0.9.1-SebastienAudier.5.mcz
_______________________________________________ help-smalltalk mailing list help-smalltalk@gnu.org https://lists.gnu.org/mailman/listinfo/help-smalltalk
Il 05/05/2013 12:06, Frank Shearar ha scritto:
On 5 May 2013 09:54, Paolo Bonzini <bonzini@gnu.org> wrote:
Il 04/05/2013 18:51, Holger Hans Peter Freyther ha scritto:
Hi,
I am trying to convert/import all of Iliad (since the development had moved to Pharo) and I stumble up-on an issue I already had when I tried to convert Aida.
This[1] monticello file in line 6417 starts to use UCS-4 for a string and then stops at some characters later. Importing the file using FileStream is failing in Pharo as well.
And how does monticello file it in then?!? I'm adding the Pharo list.
Monticello doesn't use the snapshot. The snapshot's stored in addition to the "real" MC stuff, containing the changes that the mcz defines.
It's sorta-kinda like the difference between your working copy and git diff HEAD HEAD^. MC uses the latter, the snapshot is the former.
But it's still a Pharo bug that the snapshot makes no sense, right? For GNU Smalltalk we can simply interpret a NUL as the first byte of an UTF-32BE character, and convert it to UTF-8. It's really ugly, but with a suitable comment it can work. Paolo
On May 5, 2013, at 10:54 AM, Paolo Bonzini wrote:
Il 04/05/2013 18:51, Holger Hans Peter Freyther ha scritto:
Hi,
I am trying to convert/import all of Iliad (since the development had moved to Pharo) and I stumble up-on an issue I already had when I tried to convert Aida.
This[1] monticello file in line 6417 starts to use UCS-4 for a string and then stops at some characters later. Importing the file using FileStream is failing in Pharo as well.
And how does monticello file it in then?!? I'm adding the Pharo list.
Paolo
It's a dirty little secret⦠The .st files stored in MC packages (at least written from Pharo/Squeak) are not Unicode-safe. The way it's concealed is that, by default, the binary format file in the MC package is used, from which WideStrings are read correctly. The way to "fix" it when porting to other dialects, is either a) Remove any non-latin1 from the source code b) Write a reader for the binary format (which isn't all that hard, there are a limited set of classes involved that needs to be converted to whatever the dialect-equivalent is) Cheers, Henry
participants (3)
-
Frank Shearar -
Henrik Johansen -
Paolo Bonzini