On Tue, 25 Nov 2014, Gennady Agranov wrote:
Hi,
When can regular FPC user expect 2.7.1 to graduate and be marked as stable
release?
Somewhere in Spring - like 2.6.4?
Forking off 2.8 is going to happen reasonably soon (some people on core prefer sooner,
others a little later).
After
2014-11-26 1:54 GMT+01:00 Mark Morgan Lloyd
markmll.fpc-de...@telemetry.co.uk:
Marco van de Voort wrote:
In our previous episode, Pierre Free Pascal said:
I am surprised,
for me, as French, I always believed that
the French thousand separator is simply a space,
what else should it be?
On Tue, 25 Nov 2014, luiz americo pereira camara wrote:
Hi,
Until now, when i make changes to RTL units in trunk, i take two pathes to test
and compile:
1) If the unit is self contained, i go to source directory and compile directly
2) If the unit is a dependency of other RTL parts, i
On 11/26/2014 01:54 AM, Mark Morgan Lloyd wrote:
How does that look when hand-written on a cheque?
Supposedly this is a non-breaking space, that does not allow to be
replaced by a line-break (nbsp; in HTML)
-Michael
___
fpc-devel maillist -
2014-11-26 9:47 GMT+01:00 Michael Schnell mschn...@lumino.de:
On 11/26/2014 01:54 AM, Mark Morgan Lloyd wrote:
How does that look when hand-written on a cheque?
Supposedly this is a non-breaking space, that does not allow to be
replaced by a line-break (nbsp; in HTML)
Precisely.
--
On 11/24/2014 10:45 AM, Michael Schnell wrote:
. I'll post the wiki paper on this tomorrow.
Please see a preliminary version of the text -
http://wiki.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support#Three_more_RAW_types
.
(Please use a new thread for any discussion on
I fail to understand some of the text.
It seems to be unavoidable to use the name ANSIString even though I
always though up when seeing a thing called ANSI containing Unicode
(e. g. UTF8String = type AnsiString(CP_UTF8) ).
Seemingly here the bytes per character setting implicitly is
On Wed, 26 Nov 2014 11:23:17 +0100
Michael Schnell mschn...@lumino.de wrote:
[...]
It seems to be unavoidable to use the name ANSIString even though I
always though up when seeing a thing called ANSI containing Unicode
(e. g. UTF8String = type AnsiString(CP_UTF8) ).
Is there a question?
In our previous episode, Mark Morgan Lloyd said:
what else should it be?
A shift space. In utf8 that takes two bytes.
How does that look when hand-written on a cheque?
I haven't seen a cheque in a decade, but I assume that depends on the hand
having an utf8 encoding or not.
On 11/26/2014 11:40 AM, Mattias Gaertner wrote:
Ansistring supports only one byte per character code pages.
Even more confused. Am I wrong thinking that with code aware Strings,
for Delphi XE compatibility, in Windows CP_ACP needs to be UTF16 (if not
right, than due later) ?
What is a
Am 26.11.2014 11:53 schrieb Michael Schnell mschn...@lumino.de:
On 11/26/2014 11:40 AM, Mattias Gaertner wrote:
Ansistring supports only one byte per character code pages.
Even more confused. Am I wrong thinking that with code aware Strings,
for Delphi XE compatibility, in Windows CP_ACP
On Wed, 26 Nov 2014 11:23:17 +0100
Michael Schnell mschn...@lumino.de wrote:
[...]
2) I fail to understand how with this explanation that seems to force
auto conversion for assignments between types with different code page
settings (also for CP_ACP) the static code page can differ from the
On Wed, 26 Nov 2014 11:52:50 +0100
Michael Schnell mschn...@lumino.de wrote:
On 11/26/2014 11:40 AM, Mattias Gaertner wrote:
Ansistring supports only one byte per character code pages.
Even more confused. Am I wrong thinking that with code aware Strings,
for Delphi XE compatibility, in
On 11/26/2014 12:09 PM, Sven Barth wrote:
In Delphi (and FPC) CP_ACP corresponds by default with the current
system codepage (e.g. CP1252 on a German Windows).
OK. So in Delphi XE (in Germany) String(CP_ACP) is the same as
String(CP1252) but different from String without brackets which in
On 11/26/2014 12:13 PM, Mattias Gaertner wrote:
In mode delphiunicode String=UnicodeString.
I see.
So even in Delphi XE where UnicodeString is denoted by CP_UTF16, the
value of the constant CP_UTF16 is not the same as the value of the
(constant or) variable CP_ACP, (while OTOH using the
On 11/26/2014 12:10 PM, Mattias Gaertner wrote:
the results of conversions from/to the CP_NONE code page are undefined.
... because CP_NONE is not a real code page.
So you understand result as what you would get when printing.
In the context of this wiki page I would understand result as the
After re-reading yet another question:
In section String concatenations there is no mentioning about
auto-conversion. For statically typed Strings it's rather obvious that
they will be auto-converted if appropriate. Technically - if differently
encode - they seem to be converted to Unicode
Am 26.11.2014 12:37 schrieb Michael Schnell mschn...@lumino.de:
On 11/26/2014 12:09 PM, Sven Barth wrote:
In Delphi (and FPC) CP_ACP corresponds by default with the current
system codepage (e.g. CP1252 on a German Windows).
OK. So in Delphi XE (in Germany) String(CP_ACP) is the same as
On 26/11/14 12:53, Michael Schnell wrote:
[CP_NONE]
Is this undefined in the meaning of not predictable by the user in
the current version of fpc, or in the meaning of due to change when
updating fpc.
This undefined literally means undefined. It does not mean
undefined in a meaning that is
On 11/26/2014 03:05 PM, Sven Barth wrote:
OK. So in Delphi XE (in Germany) String(CP_ACP) is the same as
String(CP1252) but different from String without brackets which in
turn is the same as String(CP_UTF16) ? Correct ?
There is no String with brackets. You can only use AnsiString
On 26/11/14 13:11, Michael Schnell wrote:
In section String concatenations there is no mentioning about
auto-conversion.
There is.
For statically typed Strings it's rather obvious that
they will be auto-converted if appropriate.
It's probably rather obvious because it is literally mentioned
Am 26.11.2014 15:30 schrieb Mattias Gaertner nc-gaert...@netcologne.de:
On Wed, 26 Nov 2014 15:05:16 +0100
Sven Barth pascaldra...@googlemail.com wrote:
[...]
While both AnsiString and UnicodeString have the current codepage and
the
character size in their header record
AFAIK
On 26/11/14 17:21, Sven Barth wrote:
Yes, nevertheless the header record is the same for UnicodeString and
AnsiString and thus it also has a codepage field which is always
initialized to CP_UTF16 however.
It can also be CP_UTF16BE (which it is on big endian FPC targets right now).
Jonas
On 26/11/14 16:19, Michael Schnell wrote:
So seemingly you could do MyStringType = type
AnsiString(CP_UTF16), and seemingly the size information is set
according to this.
As several people have told you several times, that is invalid (in the
meaning of undefined) in both FPC and Delphi.
On 26 Nov 14, at 17:23, Jonas Maebe wrote:
On 26/11/14 17:21, Sven Barth wrote:
Yes, nevertheless the header record is the same for UnicodeString and
AnsiString and thus it also has a codepage field which is always
initialized to CP_UTF16 however.
It can also be CP_UTF16BE (which it is
On Wed, 26 Nov 2014 17:23:48 +0100
Jonas Maebe jonas.ma...@elis.ugent.be wrote:
On 26/11/14 17:21, Sven Barth wrote:
Yes, nevertheless the header record is the same for UnicodeString and
AnsiString and thus it also has a codepage field which is always
initialized to CP_UTF16 however.
It
On 26/11/14 17:41, Tomas Hajny wrote:
BTW, in this context - can users choose UTF16BE on little endian
platforms (and vice versa)?
No, because we do not have any routines that allow a user to set/change
the codepage of a unicodestring (either at run time or at compile time).
Jonas
On Wed, 26 Nov 2014 17:50:31 +0100
Mattias Gaertner nc-gaert...@netcologne.de wrote:
On Wed, 26 Nov 2014 17:23:48 +0100
Jonas Maebe jonas.ma...@elis.ugent.be wrote:
On 26/11/14 17:21, Sven Barth wrote:
Yes, nevertheless the header record is the same for UnicodeString and
AnsiString
Mattias Gaertner schrieb:
On Wed, 26 Nov 2014 11:23:17 +0100
Michael Schnell mschn...@lumino.de wrote:
Seemingly here the bytes per character setting implicitly is thought
of as a port of the code-page definition. correct ?
Code page define bytes per character.
Huh?
Not all codepages
Michael Schnell schrieb:
On 11/26/2014 11:40 AM, Mattias Gaertner wrote:
Ansistring supports only one byte per character code pages.
Even more confused. Am I wrong thinking that with code aware Strings,
for Delphi XE compatibility, in Windows CP_ACP needs to be UTF16 (if not
right, than
Michael Schnell schrieb:
On 11/26/2014 12:09 PM, Sven Barth wrote:
In Delphi (and FPC) CP_ACP corresponds by default with the current
system codepage (e.g. CP1252 on a German Windows).
OK. So in Delphi XE (in Germany) String(CP_ACP) is the same as
String(CP1252) but different from String
Mattias Gaertner schrieb:
Hi,
The page about FPC Unicode support mentions what has already been
updated to preserve character data.
http://wiki.freepascal.org/FPC_Unicode_support#RTL_changes
Is there already a page about what has not (yet) been updated aka does
not work with all code pages?
Michael Schnell schrieb:
I fail to understand some of the text.
It seems to be unavoidable to use the name ANSIString even though I
always though up when seeing a thing called ANSI containing Unicode
(e. g. UTF8String = type AnsiString(CP_UTF8) ).
Seemingly here the bytes per character
Ewald schrieb:
Of the OS/window manager actually. You are of course right in that there
are a certain set of separators that can be used, but the exact
separator to use is dependent on the system.
Sounds easy, but just yesterday I ran into a bunch of related problems.
Even if the following
Mattias Gaertner schrieb:
For example:
CP_ACP=0, DefaultSystemCodePage=1252
That means static code page is always 0, while dynamic code page can be
0 or 1252. Both describe the same encoding.
A *dynamic* encoding *never* can be CP_ACP nor CP_NONE (in Delphi).
These values are allowed only
On Wed, 26 Nov 2014 15:34:19 +0100
Hans-Peter Diettrich drdiettri...@aol.com wrote:
Mattias Gaertner schrieb:
Hi,
The page about FPC Unicode support mentions what has already been
updated to preserve character data.
http://wiki.freepascal.org/FPC_Unicode_support#RTL_changes
Is
Michael Schnell schrieb:
So seemingly you could do MyStringType = type
AnsiString(CP_UTF16), and seemingly the size information is set
according to this.
Not in Delphi XE.
DoDi
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Jonas Maebe schrieb:
On 26/11/14 17:41, Tomas Hajny wrote:
BTW, in this context - can users choose UTF16BE on little endian
platforms (and vice versa)?
No, because we do not have any routines that allow a user to set/change
the codepage of a unicodestring (either at run time or at compile
Jonas Maebe schrieb:
Technically, that section literally states that they will be
concatenated without data loss and that the result is then converted to
the target string's encoding (except in case the target is
RawByteString). How that is implemented exactly is undefined; again in
the meaning
On 26 November 2014 at 23:54, Hans-Peter Diettrich drdiettri...@aol.com
wrote:
Conclusion:
Proper handling of separators in formatted numbers is essential, or else
users may run into so big trouble, that they will drop your program as
unusable.
DoDi
(renamed subject due to change in
On 26.11.2014 16:54, Hans-Peter Diettrich wrote:
When the system does not notify all other (running) programs of such an
global change, or when some other stupid program doesn't know how to
deal with changed settings, the user better shuts down and restarts his
system, before and after using
On 26.11.2014 19:54, Hans-Peter Diettrich wrote:
UTF-16 is not a valid value for CP_ACP in Delphi, because it's a 2-byte
encoding. Even if the Delphi architects may have thought about an common
string type, with a variable element size (1,2,4), this certainly turned
out soon as a stupid idea, so
Sven Barth wrote:
On 26.11.2014 16:54, Hans-Peter Diettrich wrote:
When the system does not notify all other (running) programs of such an
global change, or when some other stupid program doesn't know how to
deal with changed settings, the user better shuts down and restarts his
system, before
43 matches
Mail list logo
