12.10.2011 4:11, Hans-Peter Diettrich wrote:
When I have a variable of type AnsiString, and assign an string to it,
then its encoding is reported as 1252 (my system codepage). On Paul's
machine it will have a different encoding, I assume?
Yes, 1251 here.
Best regards,
Paul Ishenin.
___
Sven Barth schrieb:
Am 11.10.2011 11:35, schrieb Hans-Peter Diettrich:
Sven Barth schrieb:
Nevertheless Jonas' statement is correct, because (currently) String =
AnsiString and thus they are the same (and both can currently use code
pages).
Really? This were absolutely incompatible with Delp
Marco van de Voort schrieb:
Note that many places that are runtime typed (like tstringlist.loadfromfile)
get a encoding parameter, so that the loading code can convert the encoding
of the file (in encoding parameter) to whatever stringtype tstringlist uses
(typically utf8 or utf16 or "default")
Marco van de Voort schrieb:
In our previous episode, Hans-Peter Diettrich said:
components under Lazarus/LCL ecosystem that would need such change. Also
porting Delphi VCL components would be a lot harder.
IMO Lazarus (and FPC) should follow the Delphi way, with strictly
separate Unicode and pr
Michael Schnell schrieb:
On 10/11/2011 11:30 AM, Paul Ishenin wrote:
11.10.2011 16:52, Michael Schnell wrote:
In fact I still don't understand the difference between a type called
"RawByteString"and a basic new String that happens to be set to the
encoding "RawByte".
Encoding RawByte as well
Michael Schnell schrieb:
On 10/11/2011 11:20 AM, Hans-Peter Diettrich wrote:
Michael Schnell schrieb:
Why should a function Utf8ToLower be used (or even be defined for
normal use) ?
Because it expects and UTF8 argument, and provides an UTF8 result, so
that no further conversions are require
On 11 Oct 2011, at 04:00, Marco van de Voort wrote:
> I know that Florian and you wanted to see the default string as something of a
> dialect mode, but I never saw a way to do that practically.
How about this: a new language feature is added to the compiler that enables
defining a type alias t
Building a snapshot now works fine, shared linking and IDE inclusive. The IDE
isn't
built standardly yet though, so not in the snapshot
I uploaded an initial snapshot to
ftp://ftp.freepascal.org/pub/fpc/snapshot/v27/i386-openbsd/
___
fpc-devel maill
On Tue, Oct 11, 2011 at 13:36, Jonas Maebe wrote:
>
> On 11 Oct 2011, at 13:29, ik wrote:
>
> I'm having a problem compiling FPC 2.7.1 under linux 64 bit:
>>
>> sysconst.pp(243,7) Error: Wrong number of parameters specified for call to
>> "$fpc_ansistr_sint"
>> sysconst.pp(249) Fatal: There were
Am 11.10.2011 11:21, schrieb Marco van de Voort:
In our previous episode, Sven Barth said:
is that a new mode DelphiUnicode and a new modeswitch Unicodestrings
will be introduced which do exactly what Delphi 2009 has done: change
the default string to UnicodeString. But unlike Delphi this will b
On 11 Oct 2011, at 13:29, ik wrote:
I'm having a problem compiling FPC 2.7.1 under linux 64 bit:
sysconst.pp(243,7) Error: Wrong number of parameters specified for
call to
"$fpc_ansistr_sint"
sysconst.pp(249) Fatal: There were 1 errors compiling module, stopping
[snip]
FPC:
Free Pascal C
11.10.2011 19:29, ik wrote:
I'm having a problem compiling FPC 2.7.1 under linux 64 bit:
sysconst.pp(243,7) Error: Wrong number of parameters specified for
call to "$fpc_ansistr_sint"
sysconst.pp(249) Fatal: There were 1 errors compiling module, stopping
Please check that you are building fp
2011/10/11 ik :
> Hello,
>
> I'm having a problem compiling FPC 2.7.1 under linux 64 bit:
>
> sysconst.pp(243,7) Error: Wrong number of parameters specified for call to
> "$fpc_ansistr_sint"
> sysconst.pp(249) Fatal: There were 1 errors compiling module, stopping
>
> uname identify my system like s
Hello,
I'm having a problem compiling FPC 2.7.1 under linux 64 bit:
sysconst.pp(243,7) Error: Wrong number of parameters specified for call to
"$fpc_ansistr_sint"
sysconst.pp(249) Fatal: There were 1 errors compiling module, stopping
uname identify my system like so:
Linux ik-laptop2 3.0-ARCH #1
On 10/11/2011 08:52 AM, Hans-Peter Diettrich wrote:
It does *not* help, because SetCodePage does a string *conversion*,
Nope.
procedure SetCodePage(var s : RawByteString; CodePage : TSystemCodePage;
Convert : Boolean = True);
So it can be set to do a conversion or not to do it.
-Michael
__
On 10/11/2011 11:30 AM, Paul Ishenin wrote:
11.10.2011 16:52, Michael Schnell wrote:
In fact I still don't understand the difference between a type called
"RawByteString"and a basic new String that happens to be set to the
encoding "RawByte".
Encoding RawByte as well as encoding 0 (CP_ACP) are
On 10/11/2011 11:05 AM, Marco van de Voort wrote:
IRC there is also a codepage that
just means "system default" and assumes the system knows how to convert that
from/to utf16 (or utf8 on *nix)
Why should it do a _conversion_ and not just use the appropriate coding
(e.g. utf-16 on Windows and ut
11.10.2011 16:52, Michael Schnell wrote:
In fact I still don't understand the difference between a type called
"RawByteString"and a basic new String that happens to be set to the
encoding "RawByte".
Encoding RawByte as well as encoding 0 (CP_ACP) are both treated as
DefaultSystemCodePage at pl
On 10/11/2011 11:05 AM, Marco van de Voort wrote:
In our previous episode, Michael Schnell said:
I suppose there is a way to just set the encoding of a new string. This
should not affect the stored bytes (or words or DWords).
Afaik it does, but only for ansistring.
What exactly is "ansistring"
In our previous episode, Sven Barth said:
> is that a new mode DelphiUnicode and a new modeswitch Unicodestrings
> will be introduced which do exactly what Delphi 2009 has done: change
> the default string to UnicodeString. But unlike Delphi this will be
> possible on a per unit base. (That the
In our previous episode, Hans-Peter Diettrich said:
> > components under Lazarus/LCL ecosystem that would need such change. Also
> > porting Delphi VCL components would be a lot harder.
>
> IMO Lazarus (and FPC) should follow the Delphi way, with strictly
> separate Unicode and pre-Unicode versi
In our previous episode, Michael Schnell said:
> I suppose there is a way to just set the encoding of a new string. This
> should not affect the stored bytes (or words or DWords).
Afaik it does, but only for ansistring. IIRC there is also a codepage that
just means "system default" and assumes th
In our previous episode, Pierre Free Pascal said:
> You were right, it didn't help much:
> http://www.freepascal.org/testsuite/cgi-bin/testsuite.cgi?os=7&cpu=8&version
> =0&date=&submitter=&machine=&comment=&cond=
>
> > 2) Did you test with elf binwriter ?
> It took me a long time to understand
In our previous episode, Hans-Peter Diettrich said:
> > And what happens if an app did read data from some external source
> > (serial port) and then wants to declare what encoding it is?
>
> That's not different from the current situation. Network communication
> must agree about the encoding t
On 10/11/2011 11:28 AM, Hans-Peter Diettrich wrote:
Excessive use of RawByteString is at least as inefficient as using
Variant for everything :-(
While I still doubt that (only) RawByteString is a type that is to be
used for dynamical encoding
That is correct, depending on what exces
On 10/11/2011 11:20 AM, Hans-Peter Diettrich wrote:
Michael Schnell schrieb:
Why should a function Utf8ToLower be used (or even be defined for
normal use) ?
Because it expects and UTF8 argument, and provides an UTF8 result, so
that no further conversions are required when used with strings o
Am 11.10.2011 11:35, schrieb Hans-Peter Diettrich:
Sven Barth schrieb:
Nevertheless Jonas' statement is correct, because (currently) String =
AnsiString and thus they are the same (and both can currently use code
pages).
Really? This were absolutely incompatible with Delphi!
This is because
Sven Barth schrieb:
Nevertheless Jonas' statement is correct, because (currently) String =
AnsiString and thus they are the same (and both can currently use code
pages).
Really? This were absolutely incompatible with Delphi!
And it would be as inefficient as using Variant for everything :-(
On 10/11/2011 07:33 AM, Hans-Peter Diettrich wrote:
Concrete types are required when strings are manipulated (parsed...),
and the implementation assumes a certain encoding.
Why do you think so. when parsing, a 32 bit Unicode character can be
extracted from a new string with any (not raw) encod
Michael Schnell schrieb:
On 10/10/2011 11:11 PM, Martin wrote:
But that will always just push the issue to another location.
Somewhere the change from string to utf8string must be made.
??? The "new string" paradigm is all about changing from utf8string (and
other such types) to string. Isn't
Michael Schnell schrieb:
On 10/11/2011 12:23 AM, Martin wrote:
Utf8ToLower is, (and should) be declared expecting a Utf8String.
Why should a function Utf8ToLower be used (or even be defined for
normal use) ?
Because it expects and UTF8 argument, and provides an UTF8 result, so
that no fur
On 10/11/2011 07:33 AM, Hans-Peter Diettrich wrote:
I'd use another type, e.g. LCLstring, which can be set independently
from any other automatisms.
While using a "private" string type "just in case" or for flexibility in
a work in progress, might be a good idea, the goal should be to
every
Am 11.10.2011 09:44, schrieb Hans-Peter Diettrich:
what happens (or is intended to happen), if I cast a string to pchar,
before handing it over as param?
procedure foo(a: Utf8String);
.
var s: string;
foo(pchar(s));
This will work only when "string" is UTF-16, since PChar is a pointer to
Am 11.10.2011 08:11, schrieb Hans-Peter Diettrich:
Jonas Maebe schrieb:
On 10 Oct 2011, at 22:11, Luiz Americo Pereira Camara wrote:
1- Most of LCL must be code page agnostic, so not use
UTF8String/AnsiString directly (keep String)
There is no difference between ansistring and string in {$mo
Am 11.10.2011 09:17, schrieb Tomas Hajny:
On 11 Oct 11, at 9:01, Hans-Peter Diettrich wrote:
Jonas Maebe schrieb:
On 11 Oct 2011, at 00:06, Luiz Americo Pereira Camara wrote:
On 10/10/2011 17:56, Jonas Maebe wrote:
On 10 Oct 2011, at 22:11, Luiz Americo Pereira Camara wrote:
1- Most of LCL
On 10/11/2011 09:17 AM, Hans-Peter Diettrich wrote:
IMO Lazarus (and FPC) should follow the Delphi way, with strictly
separate Unicode and pre-Unicode versions. Nobody can expect that new
VCL (Unicode) components can be back-ported to Ansi versions.
As right now the current (Unicode aware) L
On 10/11/2011 08:52 AM, Hans-Peter Diettrich wrote:
It does *not* help, because SetCodePage does a string *conversion*,
when it really changes the encoding.
That of course does make sense. OTOH, there should (must) be a function
that forces the encoding to some setting without looking at the
On 10/11/2011 12:23 AM, Martin wrote:
Utf8ToLower is, (and should) be declared expecting a Utf8String.
Why should a function Utf8ToLower be used (or even be defined for
normal use) ?
With dynamically encoded Strings "ToLower" should work for any encoding.
-Michael
_
On 10/10/2011 11:11 PM, Martin wrote:
But that will always just push the issue to another location.
Somewhere the change from string to utf8string must be made.
??? The "new string" paradigm is all about changing from utf8string (and
other such types) to string. Isn't it ?
The big decision wa
11.10.2011 15:25, Michael Schnell wrote:
I suppose there is a way to just set the encoding of a new string. This
should not affect the stored bytes (or words or DWords).
Yes, there is SetCodePage() both for AnsiString types and UnicodeString
type.
Also RTL has SetMultiByteConversionCodePage
On 10/10/2011 10:11 PM, Luiz Americo Pereira Camara wrote:
2- It should have (dont know if currently has) a compiler switch to
change the default code page to UTF8 or whatever, so all variables
with type String will map to UTF8String.
Why ?
I feel, the LCL code should only be codepage aware
I suppose there is a way to just set the encoding of a new string. This
should not affect the stored bytes (or words or DWords).
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 11 Oct 11, at 9:01, Hans-Peter Diettrich wrote:
> Jonas Maebe schrieb:
> > On 11 Oct 2011, at 00:06, Luiz Americo Pereira Camara wrote:
> >
> >> On 10/10/2011 17:56, Jonas Maebe wrote:
> >>> On 10 Oct 2011, at 22:11, Luiz Americo Pereira Camara wrote:
> >>>
> 1- Most of LCL must be code p
43 matches
Mail list logo
