[Glass] Encoding in Topaz files ...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[Glass] Encoding in Topaz files ...

GLASS mailing list

I import my source code via a topaz script and when executing the topaz
script it prints the following information:

...
successful login
fileformat is now utf8
sourcestringclass is now Unicode16
...


%
category: 'group - QDot'
set compile_env: 0
classmethod: WCATIRestCall
QDot_StudyQDotServer

  ^self
     summary: 'Setzt/Löscht den Server.'
%

You may see, that summary: is followed by a string containing German
umlaut.

This source code is generated under Windows and when viewing it with
notepad++ I can see, that the source code is indeed written in UTF8 and
not ANSI.

After transfering the stuff to Linux and viewing it with "less", "gedit"
it seems to be still UTF8. All umlauts are viewable.

In  Jade I can see the source code as above - in Latin-?. Jade can not
show UTF stuff or Unicode stuff therefore it seems to be ok to assume,
that the source code is indeed here in Latin-?.

Could it be, that Gemstone - while importing it, converts it to ANSI and
then compile it ...



--
Marten Feldtmann
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] Encoding in Topaz files ...

GLASS mailing list
I can now answer this question by myself - the source code is actually
stored as instances of Unicode16 class in the database - and I guess,
that jade is doing something like asString to convert it back to ANSI
code page.

Marten


--
Marten Feldtmann
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] Encoding in Topaz files ...

GLASS mailing list
Yes, Jade does some conversions in bringing strings from the server to the client. The best way to tell the internal GemStone representation is to keep as much of the evaluation on the server as possible. For example:
        myString class name
or:
        (MyClass compiledMethodAt: #’mySelector’) sourceString class name
If you evaluate these then you will get a better idea of what is stored internally.

If you want to see the characters themselves, then you could convert them (again, on the server):
        myString asArray collect: [:each | each codePoint]

My understanding is that Dolphin’s support for Unicode is minimal so I’m somewhat constrained on how to show things in a Win32 environment.

James

> On May 22, 2015, at 8:14 AM, [hidden email] via Glass <[hidden email]> wrote:
>
> I can now answer this question by myself - the source code is actually
> stored as instances of Unicode16 class in the database - and I guess,
> that jade is doing something like asString to convert it back to ANSI
> code page.
>
> Marten
>
>
> --
> Marten Feldtmann
> _______________________________________________
> Glass mailing list
> [hidden email]
> http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass