On Thu, November 12, 2009 14:19, Marco van de Voort wrote:
> In our previous episode, Tomas Hajny said:
>> > Incompatibility how exactly? Two different FPC versions are already
>> not
>> > compatible.
>>
>> If you need to change the used range between e.g. FPC 2.6.x and 2.8.x
>> (due
>> to MS exten
In our previous episode, Tomas Hajny said:
> > Incompatibility how exactly? Two different FPC versions are already not
> > compatible.
>
> If you need to change the used range between e.g. FPC 2.6.x and 2.8.x (due
> to MS extending their use of the codepage values into the range we decided
> to us
Micha Nelissen wrote:
Intel: system programming guide vol 3 section 8.1.1 says byte, word,
doubleword, quadword (since Pentium) are all atomic if they are
naturally aligned. (word = 16 bits) 8.1.2.2 notes that LOCK is also best
to be used on naturally aligned boundaries for 8/16/32/64 bit acces
On Thu, November 12, 2009 08:56, Marco van de Voort wrote:
> In our previous episode, Tomas Hajny said:
>> > > supported codepages in the next version of MS Windows (or that they
>> don't
>> > > support a different list in some special version, like a version for
>> the
>> > > Chinese market) break
Jonas Maebe wrote:
If you'd want to limit the length to 2GB on 64 bit systems. I also don't
know whether all 64 bit CPUs support atomic operations on 32 bit
entities (for the reference count).
Something might be said for "compatibility" towards 32 bit
implementations that the maximum length i
In our previous episode, Tomas Hajny said:
> > > supported codepages in the next version of MS Windows (or that they don't
> > > support a different list in some special version, like a version for the
> > > Chinese market) breaking your selection of "50 free values in Windows
> > > range"?
> >
>
On 12 Nov 09, at 0:01, Jonas Maebe wrote:
> On 11 Nov 2009, at 23:54, Tomas Hajny wrote:
>
> > Are character sets recognized by numeric values under Mac OS X?
>
> There are two ways to deal with them. One is libiconv, like on any
> *nix platform (which, afaik, only supports string identifiers).
On 11 Nov 2009, at 23:54, Tomas Hajny wrote:
Are character sets recognized by numeric values under Mac OS X?
There are two ways to deal with them. One is libiconv, like on any
*nix platform (which, afaik, only supports string identifiers). The
other is CFString, which uses numeric values:
On 11 Nov 09, at 23:50, Jonas Maebe wrote:
> On 11 Nov 2009, at 23:46, Tomas Hajny wrote:
>
> > That raises a question whether incompatibility between two FPC
> > versions is better than incompatibility between FPC and Delphi
> > (caused by tight connection between Delphi and one particular
> > pl
On 11 Nov 2009, at 23:46, Tomas Hajny wrote:
That raises a question whether incompatibility between two FPC
versions is better than incompatibility between FPC and Delphi
(caused by tight connection between Delphi and one particular
platform)...
Since they're working on a Mac OS X cross compi
On 11 Nov 09, at 20:53, Marco van de Voort wrote:
> In our previous episode, Tomas Hajny said:
> > >begin
> > > encoding:=windowsencoding2nativeencoding[encoding];
> > >end;
> > >
> > > Delphi users would only have to define the fpc constants of (2) to their
> > > respective windows co
In our previous episode, Tomas Hajny said:
> >begin
> > encoding:=windowsencoding2nativeencoding[encoding];
> >end;
> >
> > Delphi users would only have to define the fpc constants of (2) to their
> > respective windows codepages to keep the code working.
>
> Well... How do you make s
On Wed, November 11, 2009 16:31, Marco van de Voort wrote:
> In our previous episode, Tomas Hajny said:
>> >
>> > We might implement 1 or 2 of those. Most of them will however be
>> > handled by libiconv, the Windows code page conversion APIs, or some
>> > other external library (just like with the
On Wednesday 11 November 2009 15:57:28 Paul Ishenin wrote:
> Martin Schreiber wrote:
> > On Wednesday 11 November 2009 15:11:07 Florian Klaempfl wrote:
> >> What rtl did you use? You need one from the branch.
> >
> > Compiling the cpstrnew rtl with fixes_2_4 does not work:
>
> 1. Build compiler exe
In our previous episode, Tomas Hajny said:
> >
> > We might implement 1 or 2 of those. Most of them will however be
> > handled by libiconv, the Windows code page conversion APIs, or some
> > other external library (just like with the current widestring manager).
>
> Nevertheless: is e.g. ISO 8859
Vincent Snijders wrote:
This fails here with the error Martin got too:
Compiling ../unix/cwstring.pp
Not Florian nor me touched linux yet.
Best regards,
Paul Ishenin.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.o
Paul Ishenin schreef:
Martin Schreiber wrote:
On Wednesday 11 November 2009 15:11:07 Florian Klaempfl wrote:
What rtl did you use? You need one from the branch.
Compiling the cpstrnew rtl with fixes_2_4 does not work:
1. Build compiler executable with 2.2.4 / 2.4.0
2. Build RTL wit
On Wed, November 11, 2009 14:10, Jonas Maebe wrote:
> On 11 Nov 2009, at 13:49, Graeme Geldenhuys wrote:
>
>> Is FPC realistically going to implement all 2059 of those?
>
> We might implement 1 or 2 of those. Most of them will however be
> handled by libiconv, the Windows code page conversion APIs,
Vincent Snijders schreef:
Paul Ishenin schreef:
Martin Schreiber wrote:
On Wednesday 11 November 2009 15:11:07 Florian Klaempfl wrote:
What rtl did you use? You need one from the branch.
Compiling the cpstrnew rtl with fixes_2_4 does not work:
1. Build compiler executable with 2.2
Paul Ishenin schreef:
Martin Schreiber wrote:
On Wednesday 11 November 2009 15:11:07 Florian Klaempfl wrote:
What rtl did you use? You need one from the branch.
Compiling the cpstrnew rtl with fixes_2_4 does not work:
1. Build compiler executable with 2.2.4 / 2.4.0
2. Build RTL wit
Martin Schreiber wrote:
On Wednesday 11 November 2009 15:11:07 Florian Klaempfl wrote:
What rtl did you use? You need one from the branch.
Compiling the cpstrnew rtl with fixes_2_4 does not work:
1. Build compiler executable with 2.2.4 / 2.4.0
2. Build RTL with the new executable
3
On Wednesday 11 November 2009 15:11:07 Florian Klaempfl wrote:
>
> What rtl did you use? You need one from the branch.
Compiling the cpstrnew rtl with fixes_2_4 does not work:
"
Free Pascal Compiler version 2.3.1 [2009/11/01] for i386
Copyright (c) 1993-2009 by Florian Klaempfl
Target OS: Linux fo
Martin Schreiber schrieb:
> On Wednesday 11 November 2009 13:47:43 Florian Klaempfl wrote:
>>> I try to prove the exciting statement. How can I build a startup compiler
>>> for the cpstrnew branch or
>> I use the 2.2.4/2.4.0 ide to build the compiler, so make in the cpstrnew
>> branch compiler dir
On Wed, November 11, 2009 13:56, Graeme Geldenhuys wrote:
> Tomas Hajny wrote:
>>
>> I'm afraid that your assumption about the number of codepages is
>> incorrect. The MIBENUM value defined in list at
>> http://www.iana.org/assignments/character-sets goes up to 2059 at the
>> moment.
>
> I just dou
On Wed, November 11, 2009 13:56, Graeme Geldenhuys wrote:
> Tomas Hajny wrote:
>>
>> I'm afraid that your assumption about the number of codepages is
>> incorrect. The MIBENUM value defined in list at
>> http://www.iana.org/assignments/character-sets goes up to 2059 at the
>> moment.
>
> I just dou
On Wednesday 11 November 2009 13:47:43 Florian Klaempfl wrote:
> > I try to prove the exciting statement. How can I build a startup compiler
> > for the cpstrnew branch or
>
> I use the 2.2.4/2.4.0 ide to build the compiler, so make in the cpstrnew
> branch compiler dir should work using 2.2.4/2.4.
Tomas Hajny wrote:
>
> I'm afraid that your assumption about the number of codepages is
> incorrect. The MIBENUM value defined in list at
> http://www.iana.org/assignments/character-sets goes up to 2059 at the
> moment.
I just double checked. That number is "in theory" only. There are not
nearly
On 11 Nov 2009, at 13:49, Graeme Geldenhuys wrote:
Is FPC realistically going to implement all 2059 of those?
We might implement 1 or 2 of those. Most of them will however be
handled by libiconv, the Windows code page conversion APIs, or some
other external library (just like with the cur
Tomas Hajny wrote:
>
> I'm afraid that your assumption about the number of codepages is
> incorrect. The MIBENUM value defined in list at
> http://www.iana.org/assignments/character-sets goes up to 2059 at the
> moment.
Is FPC realistically going to implement all 2059 of those? I still think
eve
Martin Schreiber wrote:
I try to prove the exciting statement. How can I build a startup compiler for
the cpstrnew branch or how to compile the cpstrnew branch?
I use the next bat file in the compiler dir:
[copy of my bat]
@echo off
c:\programming\cpstrnew\bin\i386-win32\make.exe clean all O
On Wed, November 11, 2009 13:42, Tomas Hajny wrote:
> On Wed, November 11, 2009 09:58, Graeme Geldenhuys wrote:
>> Florian Klaempfl wrote:
>>>
>>> The constant encoding the code page requires 2 bytes,
>>
>> Could those become enum values instead, which means you can store up to
>> 255 different cod
On 11 Nov 2009, at 13:47, Micha Nelissen wrote:
Jonas Maebe wrote:
No, 25 bytes. The plain ansistring 'a' is already 17 bytes on
x86_64 platforms today.
Is that because of sizeint?
Yes.
Wouldn't longint be long enough?
If you'd want to limit the length to 2GB on 64 bit systems. I also
Martin Schreiber schrieb:
> On Tuesday 10 November 2009 19:08:45 Florian Klaempfl wrote:
>> Martin Schreiber schrieb:
>>> On Tuesday 10 November 2009 18:33:54 Florian Klaempfl wrote:
> Did you look into the code in cpstrnew branch? I did.
And which changes are exactly the reason for your c
Jonas Maebe wrote:
Does that mean in the cpstrnew branch and on x86_64 systems, the UTF-8
string 'a' will be 9 bytes long?
No, 25 bytes. The plain ansistring 'a' is already 17 bytes on x86_64
platforms today.
Is that because of sizeint? Wouldn't longint be long enough?
Micha
___
On Wed, November 11, 2009 09:58, Graeme Geldenhuys wrote:
> Florian Klaempfl wrote:
>>
>> The constant encoding the code page requires 2 bytes,
>
> Could those become enum values instead, which means you can store up to
> 255 different code-page types in 1 byte. 255 should be sufficient to
> cover
On Tuesday 10 November 2009 19:08:45 Florian Klaempfl wrote:
> Martin Schreiber schrieb:
> > On Tuesday 10 November 2009 18:33:54 Florian Klaempfl wrote:
> >>> Did you look into the code in cpstrnew branch? I did.
> >>
> >> And which changes are exactly the reason for your concerns?
> >
> > More ch
On 11 Nov 2009, at 11:04, Michael Schnell wrote:
What about case sensitivity with "if str1=str2 then ..." ?
The "=" operator for strings has always performed a simply byte-wise
comparison until now, and presumably keeps acting the same in Delphi
2009 with the new UnicodeStrings. Custom st
In our previous episode, Martin Schreiber said:
[ Charset ISO-8859-1 unsupported, converting... ]
> On Tuesday 10 November 2009 21:38:33 Marco van de Voort wrote:
> >
> > The only problem is the db-aware part and the few other widgets that can
> > have 10 elements and more, like treeview. There
Jonas Maebe wrote:
> RawWordString and RawDWordString don't make any sense. All Strings with
> 32 bit elements are UTF-32.
What about case sensitivity with "if str1=str2 then ..." ?
> Those with 16 bit elements can't be UTF-16
> big or little endian, or UCS-2, but I can't see why any programmer
Michael Schnell wrote:
>
> - RawDWordString
> - RawWordString
> - RawByteString
Edit:
add RawQWordString.
OTHO I just learned that all of them are called "RawByteString" (Thus
IMHO just "RawString" is the more appropriate name) and the character
size (= 1, 2, 4, or 8) is handled separately.
On 11 Nov 2009, at 10:52, Jonas Maebe wrote:
Those with 16 bit elements can't be UTF-16 big or little endian, or
UCS-2,
*can* be, of course
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listin
On 11 Nov 2009, at 10:37, Michael Schnell wrote:
Of course that is true. So IMHO (at least) theses encoding types
should
be supported:
Please read this document first: http://edn.embarcadero.com/article/38980
- RawDWordString
- RawWordString (handled like good old WideStrings ?(*) )
- Raw
Florian Klaempfl wrote:
>
> No. RawByteString means simply: encoding unknown, the string is just a
> couple of bytes (which could also form words or dwords) described by the
> the encoding and char size fields.
I see. Bit this is exactly what I meant:
RawByteString, RawWordString and RawDWordSt
On 11 Nov 2009, at 10:07, Graeme Geldenhuys wrote:
Sergei Gorelkin wrote:
It won't. 4 bytes will be used anyway because of alignment.
On x86_64, it is even 8 bytes.
Does that mean in the cpstrnew branch and on x86_64 systems, the UTF-8
string 'a' will be 9 bytes long?
No, 25 bytes. The pl
Sergei Gorelkin wrote:
>
> It won't. 4 bytes will be used anyway because of alignment.
> On x86_64, it is even 8 bytes.
Does that mean in the cpstrnew branch and on x86_64 systems, the UTF-8
string 'a' will be 9 bytes long?
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit
Florian Klaempfl wrote:
>
> The constant encoding the code page requires 2 bytes,
Could those become enum values instead, which means you can store up to
255 different code-page types in 1 byte. 255 should be sufficient to
cover all available code-page constants (I think).
Or couldn't that maybe
Marco van de Voort wrote:
> While I think it would be best to use native encoding on all platforms as
> much as possible, that is an opinion. However not using native encoding for
> general processing is nuts. So we need the UTF8 type anyway.
>
Of course that is true. So IMHO (at least) theses en
Marco van de Voort wrote:
> That is probably solvable (... only translating at the moment of
> viewing ...).
I feel that this is exactly what D2009 Strings are a perfect tool for:
conversions are automatically done when necessary and not "just in
case". I suppose that there are means provided to t
Michael Schnell schrieb:
> Florian Klaempfl wrote:
>> No other string types being involved especially things like RawByteString.
>
> If you additionally implement the encoding Type RawWordString, Martin
> should be happy.
No. RawByteString means simply: encoding unknown, the string is just a
coup
Michael Schnell schrieb:
> Martin Schreiber wrote:
>> OK, so you say that the processing of the new and the current UnicodeString
>> and therefore the RTL and compiler procedures are identical with exception
>> of
>> the initialization of 4 bytes with a constant? Now that is exciting.
>
> Of co
Florian Klaempfl wrote:
> No other string types being involved especially things like RawByteString.
If you additionally implement the encoding Type RawWordString, Martin
should be happy.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.or
Martin Schreiber wrote:
> OK, so you say that the processing of the new and the current UnicodeString
> and therefore the RTL and compiler procedures are identical with exception of
> the initialization of 4 bytes with a constant? Now that is exciting.
Of course with any operation that uses two
Martin Schreiber wrote:
> Did you look into the code in cpstrnew branch?
Not yet (sitting behind a firewall I had major problems with using the
revision control system. I do use GIT for other projects so I'll recheck
some day soon.)
> I did.
So you do suggest that this code is not optimized on
Graeme Geldenhuys wrote:
I have not looked at the cpstrnew branch, but what is the 4 bytes used
for in each string? Couldn't the individual bits in 1 byte value be
used? That will reduce the extra memory overhead by 75%?
It won't. 4 bytes will be used anyway because of alignment.
On x86_64, it
Graeme Geldenhuys schrieb:
> Florian Klaempfl wrote:
>>> and therefore the RTL and compiler procedures are identical with exception
>>> of
>>> the initialization of 4 bytes with a constant?
>> Well, two times two byte ;)
>
> I have not looked at the cpstrnew branch, but what is the 4 bytes used
Florian Klaempfl wrote:
>> and therefore the RTL and compiler procedures are identical with exception
>> of
>> the initialization of 4 bytes with a constant?
>
> Well, two times two byte ;)
I have not looked at the cpstrnew branch, but what is the 4 bytes used
for in each string? Couldn't the i
thaddy wrote:
> Just to make a small point: the choice for UTF16 was made because of
> market reasons, not technical ones. Chinese Korean, Japanese markets are
> important for Delphi. Try to figure out how to fit that in UTF8. Just a
> thought.
I have to agree with Marco there. Delphi simply fo
Martin Schreiber wrote:
> It supports now Linux x86-64. I used about 110 hours for the adaption.
> Problem
> is gdb and dwarf on x86-64 (display of var parameters) and freezing of the
> application if compiled with -gl in case of an exception. I can't understand
> that Lazarus lives with this s
On Tuesday 10 November 2009 21:38:33 Marco van de Voort wrote:
>
> The only problem is the db-aware part and the few other widgets that can
> have 10 elements and more, like treeview. There mass conversion can
> hurt, e.g. when loading the data into the widget.
>
That's the reason why MSEgui st
Marco van de Voort schrieb:
> In our previous episode, thaddy said:
>> Marco van de Voort wrote:
>>> While I think it would be best to use native encoding on all platforms as
>>> much as possible, that is an opinion. However not using native encoding for
>>> general processing is nuts. So we need t
In our previous episode, thaddy said:
> Marco van de Voort wrote:
> > While I think it would be best to use native encoding on all platforms as
> > much as possible, that is an opinion. However not using native encoding for
> > general processing is nuts. So we need the UTF8 type anyway.
> >
> Just
Marco van de Voort wrote:
Neither do I.
While I think it would be best to use native encoding on all platforms as
much as possible, that is an opinion. However not using native encoding for
general processing is nuts. So we need the UTF8 type anyway.
Just to make a small point: the choice
In our previous episode, Michael Schnell said:
> > multi-encoding/multi-charsize. At the moment msestring=UnicodeString for
> > FPC
> > 2.4 which is perfect. I fear FPC will drop this simple solution where it
> > was
> > ahead of Delphi.
>
> Hmmm. I suppose with Linux (using utf-8 for the GUI
On Tuesday 10 November 2009 20:20:06 Florian Klaempfl wrote:
> > OK, so you say that the processing of the new and the current
> > UnicodeString and therefore the RTL and compiler procedures are identical
> > with exception of the initialization of 4 bytes with a constant?
>
> Well, two times two b
Martin Schreiber schrieb:
> On Tuesday 10 November 2009 19:08:45 Florian Klaempfl wrote:
>> Where? A pure unicodestring routine won't get additional checks.
>>
> What is a "pure unicodestring routine"?
No other string types being involved especially things like RawByteString.
>
>>> and more comp
On Tuesday 10 November 2009 19:24:38 Michael Van Canneyt wrote:
>
> MSE boasts some 'great features'. Well, last time I checked
> (admittedly some time ago), MSE didn't even support 64-bits,
> while Lazarus does since many years.
>
It supports now Linux x86-64. I used about 110 hours for the adapti
On Tuesday 10 November 2009 19:08:45 Florian Klaempfl wrote:
>
> Where? A pure unicodestring routine won't get additional checks.
>
What is a "pure unicodestring routine"?
> > and more complicated address calculation.
>
> Where? Adding 16 instead of 12 makes no difference.
>
> The "major" differen
On Tuesday 10 November 2009 19:01:51 Luiz Americo Pereira Camara wrote:
> Martin Schreiber escreveu:
> > On Tuesday 10 November 2009 18:33:54 Florian Klaempfl wrote:
> >>> Did you look into the code in cpstrnew branch? I did.
> >>
> >> And which changes are exactly the reason for your concerns?
> >
On Tue, 10 Nov 2009, Florian Klaempfl wrote:
Martin Schreiber schrieb:
On Tuesday 10 November 2009 18:33:54 Florian Klaempfl wrote:
Did you look into the code in cpstrnew branch? I did.
And which changes are exactly the reason for your concerns?
More checks
Where? A pure unicodestring
Martin Schreiber schrieb:
> On Tuesday 10 November 2009 18:33:54 Florian Klaempfl wrote:
>
>>> Did you look into the code in cpstrnew branch? I did.
>> And which changes are exactly the reason for your concerns?
>
> More checks
Where? A pure unicodestring routine won't get additional checks.
>
Martin Schreiber escreveu:
On Tuesday 10 November 2009 18:33:54 Florian Klaempfl wrote:
Did you look into the code in cpstrnew branch? I did.
And which changes are exactly the reason for your concerns?
More checks and more complicated address calculation. OK, you can say "you
On Tuesday 10 November 2009 18:33:54 Florian Klaempfl wrote:
> > Did you look into the code in cpstrnew branch? I did.
>
> And which changes are exactly the reason for your concerns?
More checks and more complicated address calculation. OK, you can say "you
will not notice the small difference".
Martin Schreiber schrieb:
> On Tuesday 10 November 2009 12:45:26 Michael Schnell wrote:
>> Martin Schreiber wrote:
>>> Performance and simplicity. MSEgui does not need the overhead of
>>> multi-encoding/multi-charsize. At the moment msestring=UnicodeString for
>>> FPC 2.4 which is perfect. I fear F
On Tuesday 10 November 2009 12:45:26 Michael Schnell wrote:
> Martin Schreiber wrote:
> > Performance and simplicity. MSEgui does not need the overhead of
> > multi-encoding/multi-charsize. At the moment msestring=UnicodeString for
> > FPC 2.4 which is perfect. I fear FPC will drop this simple solu
Michael Schnell wrote:
Paul Ishenin wrote:
4. Most of codepage convertion methods and string type convertion
methods (ansistring <=> unicodestring <=> widestring)
Does this mean that the compiler already automatically calls the
appropriate conversion, but the code that actually perform
Martin Schreiber wrote:
> Performance and simplicity. MSEgui does not need the overhead of
> multi-encoding/multi-charsize. At the moment msestring=UnicodeString for FPC
> 2.4 which is perfect. I fear FPC will drop this simple solution where it was
> ahead of Delphi.
Hmmm. I suppose with Linux
Paul Ishenin wrote:
> 4. Most of codepage convertion methods and string type convertion
> methods (ansistring <=> unicodestring <=> widestring)
>
Does this mean that the compiler already automatically calls the
appropriate conversion, but the code that actually performs it is not
yet implemented i
Paul Ishenin wrote:
> 3. RawByteString type (an ansi string type which does not perform any
> codepage conversions) with compiler support.
A great idea ! I would have requested this if it would not be already
planned :).
-Michael
___
fpc-devel maillist
In our previous episode, Martin Schreiber said:
> > This would break a lot of Delphi and COM code, and is IMHO not smart. If
> > for some reason the old widestring implemention needs to continue (it is
> > redundant if unicodestring is there?), it should get a different
> > identifier.
> >
> No pr
On Monday 09 November 2009 16:34:52 Marco van de Voort wrote:
> In our previous episode, Martin Schreiber said:
> > Will there be a simple reference counted WideString on all platforms as
> > the current FPC UnicodeString is?
>
> Why does there need to be a widestring type if there is unicodestrin
On Mon, Nov 9, 2009 at 6:30 PM, Martin Schreiber wrote:
> WideString could be reference counted on all platforms and the current not
> reference counted Windows WideString could be renamed to OLEString in order
> applications which don't need different encodings in strings don't suffer
> from the
In our previous episode, Martin Schreiber said:
> > > http://wiki.freepascal.org/FPC_Unicode_support
> > >
> > > (saying "Upcoming Delphi release codenamed Tiburon will natively support
> > > Unicode")
> > >
> > > still valid ?
> > >
> > At least the branch link is valid :)
> >
> [...]
>
> Wil
On Monday 09 November 2009 15:36:06 Paul Ishenin wrote:
> Michael Schnell wrote:
> > Is this page
> >
> > http://wiki.freepascal.org/FPC_Unicode_support
> >
> > (saying "Upcoming Delphi release codenamed Tiburon will natively support
> > Unicode")
> >
> > still valid ?
> >
> At least the branch
Michael Schnell wrote:
Is this page
http://wiki.freepascal.org/FPC_Unicode_support
(saying "Upcoming Delphi release codenamed Tiburon will natively support
Unicode")
still valid ?
At least the branch link is valid :)
Yesterday I asked Florian to permit me to help him with the development.
84 matches
Mail list logo
