On Thu, Sep 25, 2008 at 10:33 PM, Florian Klaempfl
<[EMAIL PROTECTED]> wrote:
>
> Who says that? UTF-16 is simply chosen because it has features (supporting
> all characters basically) ANSI doesn't?
Sorry, my message was unclear and I got somewhat mixed up between ANSI
and UTF-8. I meant the encod
Op Fri, 26 Sep 2008, schreef Graeme Geldenhuys:
On Thu, Sep 25, 2008 at 10:33 PM, Florian Klaempfl
<[EMAIL PROTECTED]> wrote:
Who says that? UTF-16 is simply chosen because it has features (supporting
all characters basically) ANSI doesn't?
Sorry, my message was unclear and I got somewhat
Graeme Geldenhuys schreef:
On Thu, Sep 25, 2008 at 10:33 PM, Florian Klaempfl
I suppose it would be viable doing timing results for saving text
files as well. After all, 99% of the time, text files are stored in
UTF-8.
Where did you get that number (99%) from? I don't think that is true,
exce
On Fri, Sep 26, 2008 at 9:04 AM, Graeme Geldenhuys
<[EMAIL PROTECTED]> wrote:
>
> So has anybody actually done a timing comparision? Do you have your
> test code available? Do you have your results published? I'm
> interested to see the timing results using different hardware.
What I'm getting at
Graeme Geldenhuys schrieb:
> On Thu, Sep 25, 2008 at 10:33 PM, Florian Klaempfl
> <[EMAIL PROTECTED]> wrote:
>> Who says that? UTF-16 is simply chosen because it has features (supporting
>> all characters basically) ANSI doesn't?
>
> Sorry, my message was unclear and I got somewhat mixed up betwee
On Fri, Sep 26, 2008 at 09:04, Graeme Geldenhuys
<[EMAIL PROTECTED]> wrote:
> On Thu, Sep 25, 2008 at 10:33 PM, Florian Klaempfl
> <[EMAIL PROTECTED]> wrote:
>>
> I suppose it would be viable doing timing results for saving text
> files as well. After all, 99% of the time, text files are stored in
On Fri, Sep 26, 2008 at 9:12 AM, Daniël Mantione
<[EMAIL PROTECTED]> wrote:
>
> For me the speed of input/output is less relevant, this is limited by disk
> speed anyway. It's the speed of processing that should be decisive.
That's highly dependant on what you application does! If your
applicatio
Graeme Geldenhuys schrieb:
> On Fri, Sep 26, 2008 at 9:04 AM, Graeme Geldenhuys
> <[EMAIL PROTECTED]> wrote:
>> So has anybody actually done a timing comparision? Do you have your
>> test code available? Do you have your results published? I'm
>> interested to see the timing results using different
On Fri, Sep 26, 2008 at 9:19 AM, Aleksa Todorovic <[EMAIL PROTECTED]> wrote:
> I support decision of using UTF-16 over UTF-8. String processing is
> far more simpler, it's actually as simple as it should be.
And that's guarenteed to work with surrogate pairs as well? The
problem is, most people as
On Fri, Sep 26, 2008 at 9:27 AM, Florian Klaempfl
<[EMAIL PROTECTED]> wrote:
>
> Being honest, imo UTF-8 is only a hack to get unicode on platforms like
> unix.
I don't know where you get that information, but it's surely not what
I read from the unicode.org website.
UTF-8, UTF-16 and UTF-32 were
Graeme Geldenhuys schrieb:
> On Fri, Sep 26, 2008 at 9:27 AM, Florian Klaempfl
> <[EMAIL PROTECTED]> wrote:
>> Being honest, imo UTF-8 is only a hack to get unicode on platforms like
>> unix.
>
> I don't know where you get that information,
Rather simple: initially in unicode 1.0 there was only
In our previous episode, Graeme Geldenhuys said:
> Yes I know we have had lengthy discussions about this before.
> Everybody (whoever they might be) keeps saying that UTF-16 was chosen
> for Tiburon's UnicodeString because it makes "significant speed gains"
> when calling the Windows API based on U
In our previous episode, Aleksa Todorovic said:
> > I suppose it would be viable doing timing results for saving text
> > files as well. After all, 99% of the time, text files are stored in
> > UTF-8. So in D2009 you would first have to convert UTF-16 to UTF-8 and
> > then save. And the opposite wh
In our previous episode, Florian Klaempfl said:
> > On Fri, Sep 26, 2008 at 9:27 AM, Florian Klaempfl
> > <[EMAIL PROTECTED]> wrote:
> >> Being honest, imo UTF-8 is only a hack to get unicode on platforms like
> >> unix.
> >
> > I don't know where you get that information,
>
> Rather simple: ini
Well if you have Utf-8 versions of all basic string processing
functions like Pos, Length, Copy, Insert etc
s[i] := 'x'; will be especially funny :).
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mail
It's no different then UTF-16 if you want to do it properly. In both you
have to look out for surrogates.
Is UTF-16 Widestring in FPC (and Delphi 200x ? ) not done just ignoring
the surrogates ? (AFAI understand, a Widechar is just 16 bit, it would
need to be 32 bit if surrogates were allow
On Fri, Sep 26, 2008 at 10:43 AM, Michael Schnell <[EMAIL PROTECTED]> wrote:
>
>> It's no different then UTF-16 if you want to do it properly. In both you
>> have to look out for surrogates.
>>
>
> Is UTF-16 Widestring in FPC (and Delphi 200x ? ) not done just ignoring the
> surrogates ?
Lets hope
Op Fri, 26 Sep 2008, schreef Graeme Geldenhuys:
On Fri, Sep 26, 2008 at 9:12 AM, Daniël Mantione
<[EMAIL PROTECTED]> wrote:
For me the speed of input/output is less relevant, this is limited by disk
speed anyway. It's the speed of processing that should be decisive.
That's highly dependant
In our previous episode, Michael Schnell said:
> > It's no different then UTF-16 if you want to do it properly. In both you
> > have to look out for surrogates.
> >
> Is UTF-16 Widestring in FPC (and Delphi 200x ? ) not done just ignoring
> the surrogates ?
No different as UTF-8 in principle.
Graeme Geldenhuys schrieb:
> On Thu, Sep 25, 2008 at 10:33 PM, Florian Klaempfl
> <[EMAIL PROTECTED]> wrote:
>
>> Who says that? UTF-16 is simply chosen because it has features (supporting
>> all characters basically) ANSI doesn't?
>>
>
> Sorry, my message was unclear and I got somewhat mix
In our previous episode, Dani?l Mantione said:
> > That's highly dependant on what you application does! If your
> > application primarily parses text files, it's relevant. :-)
>
> Shortstrings & ansistrings won't go away. You'll still be able to code
> fast text file parsers. Note that in such
Op Fri, 26 Sep 2008, schreef Graeme Geldenhuys:
On Fri, Sep 26, 2008 at 10:43 AM, Michael Schnell <[EMAIL PROTECTED]> wrote:
It's no different then UTF-16 if you want to do it properly. In both you
have to look out for surrogates.
Is UTF-16 Widestring in FPC (and Delphi 200x ? ) not done
Ivo Steinmann schrieb:
>
> In the core of all windows nt systems, there's the NT API. The normal
> WinAPI is on the top of the NTAPI. the NT API itself uses UTF-16 as
> stringtype!
>
> type
> UNICODE_STRING = record
> Length: USHORT;
> MaximumLength: USHORT;
> Buffer: PWSTR;
> end;
On Fri, Sep 26, 2008 at 11:11 AM, Ivo Steinmann <[EMAIL PROTECTED]> wrote:
>
> So in core, winnt is working with UTF16. All ANSI Winapi functions map
> to these winnt calls.
So then there is already a "conversion" going on. From ANSI api to
UTF16 api. I still think (and will try and put together
In our previous episode, Dani?l Mantione said:
> > as I know D2009 (I think) handles this correctly, but I have no idea
> > how.
>
> Let me put it like this: Someone writing a Russian/Arabic/Japanese spell
> checker does not have to handle surrogates with UTF-16, but he does with
> UTF-8, i.e. U
On Fri, Sep 26, 2008 at 11:17 AM, Daniël Mantione
<[EMAIL PROTECTED]> wrote:
>
> Russian, Arabic, Japanese are languages in daily use on computers, countless
> electronic documents in these languages exist.
And most documents that exist in the world are in UTF-8 format: Save
to file, HTML document
On 26 Sep 2008, at 10:43, Michael Schnell wrote:
Is UTF-16 Widestring in FPC (and Delphi 200x ? ) not done just
ignoring the surrogates ?
At least the Unix widestring manager fully supports surrogates (except
if you use the MSIDE-patched version, where it has been removed
because it is c
Op Fri, 26 Sep 2008, schreef Marco van de Voort:
In our previous episode, Dani?l Mantione said:
That's highly dependant on what you application does! If your
application primarily parses text files, it's relevant. :-)
Shortstrings & ansistrings won't go away. You'll still be able to code
f
On Fri, Sep 26, 2008 at 11:31 AM, Marco van de Voort <[EMAIL PROTECTED]> wrote:
>> Someone writing a spell checker for old-Egyptian Hieroglyphs will have to
>> deal with surrogates. For those people UTF-16 has few advantages over
>> UTF-8, (allthough in practice it's still a bit easier to handle th
Op Fri, 26 Sep 2008, schreef Marco van de Voort:
In our previous episode, Dani?l Mantione said:
as I know D2009 (I think) handles this correctly, but I have no idea
how.
Let me put it like this: Someone writing a Russian/Arabic/Japanese spell
checker does not have to handle surrogates with
In our previous episode, Dani?l Mantione said:
> >
> > Accepting both Arabic and Westernized Arabic numerals would possibly break a
> > lot of code anyway, since to string and back wouldn't be reversible.
>
> It has never been reversible. Think about val('$100',v);
See one line further down.
>
On Friday 26 September 2008 09.34:44 Graeme Geldenhuys wrote:
>
> Well if you have Utf-8 versions of all basic string processing
> functions like Pos, Length, Copy, Insert etc you don't have to think
> of encoding or anything. fpGUI uses UTF-8 internally, and I never have
> to think about what enco
In our previous episode, Martin Schreiber said:
> > Well if you have Utf-8 versions of all basic string processing
> > functions like Pos, Length, Copy, Insert etc you don't have to think
> > of encoding or anything. fpGUI uses UTF-8 internally, and I never have
> > to think about what encoding I'm
On Fri, Sep 26, 2008 at 11:46 AM, Martin Schreiber <[EMAIL PROTECTED]> wrote:
> It seems you prefer utf-8 over utf-16 for internal string encoding in a GUI
> framework. Why?
> I prefer utf-16 over utf-8 for MSEide+MSEgui because *all* current users
> (including the Chinese) can use simple string in
On Friday 26 September 2008 11.51:14 Graeme Geldenhuys wrote:
> On Fri, Sep 26, 2008 at 11:46 AM, Martin Schreiber <[EMAIL PROTECTED]> wrote:
> > It seems you prefer utf-8 over utf-16 for internal string encoding in a
> > GUI framework. Why?
> > I prefer utf-16 over utf-8 for MSEide+MSEgui because
Marco van de Voort schrieb:
>
>
>> For many people Unicode is just "let's go UTF-8". It's far more than that
>> and 100% supporting Unicode is even next to impossible.
>>
>
> Correct, but that is what I'm suggesting. UTF-16 is not a cure all either,
> only at a first superficial glance.
In our previous episode, Martin Schreiber said:
> >
> Hmm, you should ask the Russian users for example if they prefer MSEgui
> utf-16
> internal encoding or Lazarus utf-8.
Users always look short term, and want to change as little as possible.
This goes both for UTF-16 (with the "is UCS2" app
Hello Graeme,
Friday, September 26, 2008, 10:50:43 AM, you wrote:
GG> Good question and I have been wondering about this myself. In D2009
GG> SizeOf(Char) = 2, so I have no idea how that works with surrogate
GG> pairs. Can anybody explain this please?
I don't know how D2009 and others do it, bu
In our previous episode, Ivo Steinmann said:
> > in the native encoding per platform.
> >
> >
> I guess that would be one of the best solutions. Having a system unicode
> string type and then some specialized string types.
>
> SysString
> UTF8String
> UTF16String
> UTF32String
> Anyway, I still
Martin Schreiber wrote:
Hmm, you should ask the Russian users for example if they prefer MSEgui utf-16
internal encoding or Lazarus utf-8.
You are mixing things a bit. People from russian forum prefere less
bugs. And utf8 implementation of lazarus brought them alot. This is the
difference.
On Fri, Sep 26, 2008 at 12:34 PM, Marco van de Voort <[EMAIL PROTECTED]> wrote:
>> I guess that would be one of the best solutions. Having a system unicode
>> string type and then some specialized string types.
>>
>> SysString
>> UTF8String
>> UTF16String
>> UTF32String
>> Anyway, I still think som
Is UTF-16 Widestring in FPC (and Delphi 200x ? ) not done just ignoring the
surrogates ?
Lets hope not,
I don't think, full UTF-16 really would be desirable desirable over UC-2.
Imagine you have a string of some million characters (e.g. a Book). All
functions that need to find the n-
need to be 32 bit if surrogates were allowed in Widestrings).
How to squeeze a value > $ in a 16 Bit value ?
Can you magically store two bits in a single hardware cell ?
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Op Fri, 26 Sep 2008, schreef Graeme Geldenhuys:
Taking a step back from Free Pascal and Tiburon How do other
frameworks handle string encodings etc... Frameworks like Java, Qt
etc... Can't we learn something from them as well? Both Java and Qt
run on multiple platforms, read/write to fil
On Friday 26 September 2008 12.30:27 Marco van de Voort wrote:
> In our previous episode, Martin Schreiber said:
> > Hmm, you should ask the Russian users for example if they prefer MSEgui
> > utf-16 internal encoding or Lazarus utf-8.
>
> Users always look short term, and want to change as little
How do other
frameworks handle string encodings etc
With .NET/Mono I suppose you don't need to bother. But I suppose this is
one of the reasons that strings are constants once they are assigned
some value; and you can't so things like s[n] := 'x'.
-Michael
___
In our previous episode, Michael Schnell said:
> >> need to be 32 bit if surrogates were allowed in Widestrings).
> >>
> How to squeeze a value > $ in a 16 Bit value ?
>
> Can you magically store two bits in a single hardware cell ?
As said before, unicode is more than just expanding the
In our previous episode, Dani?l Mantione said:
> > Taking a step back from Free Pascal and Tiburon How do other
> > frameworks handle string encodings etc... Frameworks like Java, Qt
> > etc... Can't we learn something from them as well? Both Java and Qt
> > run on multiple platforms, read/wri
At the moment, I'm developing on a i386 Linux machine. For some servers
I need x86_64 binaries, so I have a second machine with x86_64 linux I
use just for compiling.
It would be great to compile everything on one machine, so I tried to
build a crosscompiler for x86_64 on my i386 machine. The
Nonetheless a type to hold a single character needs to exist. And same
needs to be a 32 bit type if you want to store more than 2^16 different
values (as possible with UTF-8 and UTF-16 but not with UCS-2.
-Michael
___
fpc-devel maillist - fpc-devel@
In our previous episode, Lukas Gradl said:
> At the moment, I'm developing on a i386 Linux machine. For some servers
> I need x86_64 binaries, so I have a second machine with x86_64 linux I
> use just for compiling.
>
> It would be great to compile everything on one machine, so I tried to
> bui
Graeme Geldenhuys wrote:
Has anybody else got sample test code that clearly shows the claimed
"significant speed gain" in using UTF-16 for Windows API's? If so,
could you please post the code and your comparative results (timing
values). I think most people perception was that ANSI API's will
In our previous episode, Michael Schnell said:
> >> Is UTF-16 Widestring in FPC (and Delphi 200x ? ) not done just ignoring the
> >> surrogates ?
> >
> > Lets hope not,
> I don't think, full UTF-16 really would be desirable desirable over UC-2.
>
> Imagine you have a string of some million chara
On Fri, 26 Sep 2008 13:20:57 +0200
Michael Schnell <[EMAIL PROTECTED]> wrote:
> Nonetheless a type to hold a single character needs to exist. And
> same needs to be a 32 bit type if you want to store more than 2^16
> different values (as possible with UTF-8 and UTF-16 but not with
> UCS-2.
Some c
Dear Marco van de Voort ,
Your paper
Development Tutorial (a.k.a Build FAQ)
by Marco van de Voort
May 17 2008
in
http://www.stack.nl/~marcov/buildfaq.pdf
is seen here in
Windows XP
Adobe Reader 8.0
Version 8.0.0
with a very low contrast with letter color ( black )
and background c
Marco van de Voort schrieb:
In our previous episode, Lukas Gradl said:
At the moment, I'm developing on a i386 Linux machine. For some servers
I need x86_64 binaries, so I have a second machine with x86_64 linux I
use just for compiling.
It would be great to compile everything on one machine,
On Fri, 2008-09-26 at 19:09 +0200, Lukas Gradl wrote:
> Marco van de Voort schrieb:
> > In our previous episode, Lukas Gradl said:
> >> At the moment, I'm developing on a i386 Linux machine. For some servers
> >> I need x86_64 binaries, so I have a second machine with x86_64 linux I
> >> use just
I have the same proble, ubuntu 64 and need to compiler for i386 and
x86_64. Theres some tutorial or somebody doing that to give us a litle
help?
Thanks
Donald shimoda
http://donaldshimoda.blogspot.com
2008/9/26 Lukas Gradl <[EMAIL PROTECTED]>:
> Marco van de Voort schrieb:
>>
>> In our previous
Dear Sirs ,
In my previous message
http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg12236.html
I mentioned required DLL files .
(A)
The following sample ReadMe.TXT file
may be inserted into the following directory :
http://svn.freepascal.org/svn/fpc/trunk/packages/gtk1/ex
59 matches
Mail list logo
