xmlvm-users

[xmlvm-users] support of unicode String

[Panayotis K. <pan...@pa...>]

It seems that unicode Strings are still not quite supported by XMLVM.

A simple command like this one:
String a = "Δοκιμή";
in the source (under constant pool)  becomes something like

// ID=1455: \1624\1677\1672\1671\1674\1656
(JAVA_ARRAY_CHAR[]) {916, 959, 954, 953, 956, 942},

which looks wrong, if indeed JAVA_ARRAY_CHAR is a char table.


Similarly in the OBjC backend, the octal representation is shown.

How can this issue be solved?
For starters, is it possible instead of exporting the octal value, to
present the actual unicode (UTF-8?) value?

Thanks in advance

-- 
Panayotis Katsaloulis

Re: [xmlvm-users] support of unicode String

[Arno P. <ar...@pu...>]

The String encoding happens on the input side in 
DEXmlvmOutputProcess.encodeString() (for both the C and the ObjC 
backend). The C backend then generates the string constant pool via 
COutputProcess.genConstantPool(). The actual code is emitted by the 
xmlvm2c.xsl stylesheet.

Arno


On 2/28/13 6:10 PM, Panayotis Katsaloulis wrote:
> It seems that unicode Strings are still not quite supported by XMLVM.
>
> A simple command like this one:
> String a = "Δοκιμή";
> in the source (under constant pool)  becomes something like
>
> // ID=1455: \1624\1677\1672\1671\1674\1656
> (JAVA_ARRAY_CHAR[]) {916, 959, 954, 953, 956, 942},
>
> which looks wrong, if indeed JAVA_ARRAY_CHAR is a char table.
>
>
> Similarly in the OBjC backend, the octal representation is shown.
>
> How can this issue be solved?
> For starters, is it possible instead of exporting the octal value, to
> present the actual unicode (UTF-8?) value?
>
> Thanks in advance
>
> --
> Panayotis Katsaloulis
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
>
>
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] support of unicode String

[Panayotis K. <pan...@pa...>]

After some thoughts I believe there is a more appropriate solution.
Java's "char" is actually a "unichar" and I think it should be handled like
this most of the time.
Which actually is a synonym for "unsigned short".
Thus the produced table is not "wrong", it's just the wrong type.


Under ObjC is more like a chaos, I tried to correct some parts (and I am
surprised that it didn't break many things, but now I understand why quite
often the unicode characters were not properly supported. I tried to
correct some.

PS, I have written some code to deal with varargs, which is really a pain.
The code is under xmlvm.m in ObjC. Just in case you need it, it is there.


On Sun, Mar 3, 2013 at 10:46 PM, Arno Puder <ar...@pu...> wrote:

>
> The String encoding happens on the input side in
> DEXmlvmOutputProcess.encodeString() (for both the C and the ObjC
> backend). The C backend then generates the string constant pool via
> COutputProcess.genConstantPool(). The actual code is emitted by the
> xmlvm2c.xsl stylesheet.
>
> Arno
>
>
> On 2/28/13 6:10 PM, Panayotis Katsaloulis wrote:
> > It seems that unicode Strings are still not quite supported by XMLVM.
> >
> > A simple command like this one:
> > String a = "Δοκιμή";
> > in the source (under constant pool)  becomes something like
> >
> > // ID=1455: \1624\1677\1672\1671\1674\1656
> > (JAVA_ARRAY_CHAR[]) {916, 959, 954, 953, 956, 942},
> >
> > which looks wrong, if indeed JAVA_ARRAY_CHAR is a char table.
> >
> >
> > Similarly in the OBjC backend, the octal representation is shown.
> >
> > How can this issue be solved?
> > For starters, is it possible instead of exporting the octal value, to
> > present the actual unicode (UTF-8?) value?
> >
> > Thanks in advance
> >
> > --
> > Panayotis Katsaloulis
> >
> >
> >
> ------------------------------------------------------------------------------
> > Everyone hates slow websites. So do we.
> > Make your web apps faster with AppDynamics
> > Download AppDynamics Lite for free today:
> > http://p.sf.net/sfu/appdyn_d2d_feb
> >
> >
> >
> > _______________________________________________
> > xmlvm-users mailing list
> > xml...@li...
> > https://lists.sourceforge.net/lists/listinfo/xmlvm-users
> >
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>



-- 
Panayotis Katsaloulis

Re: [xmlvm-users] support of unicode String

[Panayotis K. <pan...@pa...>]

On Fri, Mar 1, 2013 at 4:10 AM, Panayotis Katsaloulis
<pan...@pa...> wrote:
>
> It seems that unicode Strings are still not quite supported by XMLVM.
>
> A simple command like this one:
> String a = "Δοκιμή";
> in the source (under constant pool)  becomes something like
>
> // ID=1455: \1624\1677\1672\1671\1674\1656
> (JAVA_ARRAY_CHAR[]) {916, 959, 954, 953, 956, 942},
>
> which looks wrong, if indeed JAVA_ARRAY_CHAR is a char table.


On Sat, Mar 16, 2013 at 2:49 AM, Panayotis Katsaloulis
<pan...@pa...> wrote:
>
> After some thoughts I believe there is a more appropriate solution.
> Java's "char" is actually a "unichar" and I think it should be handled like this most of the time.
> Which actually is a synonym for "unsigned short".
> Thus the produced table is not "wrong", it's just the wrong type.




After some tests, indeed character arrays are handled as arrays of
"unsigned sort" (as I was suggesting). Sorry for not recognise it
earlier.

>From the sources, it seems that indeed the type is "unsigned short"

typedef unsigned short    JAVA_ARRAY_CHAR;

Also from Apple's source code, we can find that

typedef UInt16                          UniChar;

Which is the same, so everything should (and is) fine.

The only missing part is the escaped sequences of Strings in the comments.

I am not proficient with XSLT, but I can improve the updater ant task,
to take care of such strings and re-construct the original String, if
desired.


--
Panayotis Katsaloulis