On 10/13/2011 08:51 PM, Craig Peterson wrote:
http://community.devexpress.com/blogs/ctodx/archive/2011/09/19/delphi-vcl-is-dead-long-live-firemonkey.aspx
One thing that needs to be considered about FireMonkey and similar
"application internal Widget Sets" is that they don't integrate well
On Thu, Oct 13, 2011 at 7:13 PM, Paul Ishenin wrote:
> 13.10.2011 21:21, Jonas Maebe wrote:
>>
>> This I don't really understand.
>
> This is how delphi works according to my tests. I will retest to be 100%
> sure.
>
>> Shouldn't the constant be converted at run time from UTF-8 to the
>> DefaultSy
13.10.2011 21:21, Jonas Maebe wrote:
This I don't really understand.
This is how delphi works according to my tests. I will retest to be 100%
sure.
Shouldn't the constant be converted at run time from UTF-8 to the
DefaultSystemCodePage to make sure that an ansistring(0) variable
always conta
On 10/13/2011 2:03 PM, Marco van de Voort wrote:
No backwards compatibility, no native ties to tie it down. Clearly it is
meant to be fast moving by skipping details. And that doesn't appeal to the
bulk of the Delphi crowd
They're so far behind they pretty much have to run fast and loose.
I'm
In our previous episode, Craig Peterson said:
> >> Plus, isn't Embarcadero pushing FireMonkey anyway?
> >
> > I don't see it that way. I see FM as a Delphi PHP/3rd Rail/Prism like
> > product, not as serious VCL contender. If I understood it correctly, it is
> > mostly a sideproduct of internal eff
On 10/13/2011 4:36 AM, Marco van de Voort wrote:
Plus, isn't Embarcadero pushing FireMonkey anyway?
I don't see it that way. I see FM as a Delphi PHP/3rd Rail/Prism like
product, not as serious VCL contender. If I understood it correctly, it is
mostly a sideproduct of internal efforts to port E
Jonas Maebe schrieb:
On 13 Oct 2011, at 15:02, Paul Ishenin wrote:
Then use {$codepage UTF8} only. This directive treats all ansistring
constants in UTF8 codepage. So the next code:
{$codepage UTF8}
var
s: ansistring;
begin
s := 'utf8 string';
WriteLn(StringCodePage(s));
end.
will output
Sven Barth schrieb:
Am 13.10.2011 14:35, schrieb Michael Schnell:
On 10/13/2011 02:08 PM, Hans-Peter Diettrich wrote:
but you cannot derive further types with different encoding from it,
as you can do from AnsiString.
I see. So these variables don't have a TAnsiRec handling record.
No, they
> ... the constant be converted at run
> time from UTF-8 to the DefaultSystemCodePage to make sure that an
> ansistring(0) variable always contains strings encoded in the
> DefaultSystemCodePage? If you assign e.g. a string(866) variable to a plain
> ansistring variable, then such a conversion is a
On 13 Oct 2011, at 15:02, Paul Ishenin wrote:
Then use {$codepage UTF8} only. This directive treats all ansistring
constants in UTF8 codepage. So the next code:
{$codepage UTF8}
var
s: ansistring;
begin
s := 'utf8 string';
WriteLn(StringCodePage(s));
end.
will output CP_UTF8 constant.
T
13.10.2011 16:30, Felipe Monteiro de Carvalho wrote:
On Thu, Oct 13, 2011 at 10:26 AM, Paul Ishenin wrote:
It will affect as well as compiler directive you suggested to add.
No, the directive is per source code file. 3rd party libraries do not
need to use it.
Then use {$codepage UTF8} only. Th
On 10/13/2011 02:36 PM, Marco van de Voort wrote:
Afaik tansirec (d2009 style)=tunicoderec (d2009) style.
The rawbytestring type afaik depends on that,
According to Embarcadero: "RawByteString type is type ANSIString($)"
So the implemented structure of RawByteString and ANSIString obvious
13.10.2011 16:31, Sven Barth пишет:
Am 13.10.2011 14:35, schrieb Michael Schnell:
On 10/13/2011 02:08 PM, Hans-Peter Diettrich wrote:
but you cannot derive further types with different encoding from it,
as you can do from AnsiString.
I see. So these variables don't have a TAnsiRec handling rec
In our previous episode, Michael Schnell said:
> >
> > No, they have something else like TUnicodeRec or so.
> >
> Which does not provide a CodePage element ???
Afaik tansirec (d2009 style)=tunicoderec (d2009) style.
The rawbytestring type afaik depends on that, that any string can be passed
to it
On 10/13/2011 02:31 PM, Sven Barth wrote:
No, they have something else like TUnicodeRec or so.
Which does not provide a CodePage element ???
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listi
In our previous episode, Martin Schreiber said:
> > And while that is an option for you, it doesn't satisfy anybody else. Not
> > even the ones that want as close to D2009 compatibility as possible, since
> > they also need the new ansistring type here and there.
> >
> Hm, even Embarcadero can liv
Am 13.10.2011 14:35, schrieb Michael Schnell:
On 10/13/2011 02:08 PM, Hans-Peter Diettrich wrote:
but you cannot derive further types with different encoding from it,
as you can do from AnsiString.
I see. So these variables don't have a TAnsiRec handling record.
No, they have something else l
On 10/13/2011 02:08 PM, Hans-Peter Diettrich wrote:
but you cannot derive further types with different encoding from it,
as you can do from AnsiString.
I see. So these variables don't have a TAnsiRec handling record.
Thanks,
-Michael
___
fpc-devel ma
Michael Schnell schrieb:
On 10/13/2011 10:52 AM, Sven Barth wrote:
So you suggest that in Delphi XE, UnicodeString is _not_ a "new String"
Type ?
I don't know what you describe as "new string", but "UnicodeString"
was introduced as a new type in Delphi 2009 and "String" was made an
alias
After the test program, sent by Paul, I was playing more with
AnsiStrings in Delphi XE, with catastrophic results :-(
At least when MBCS enter the scene, and UTF-8 is widely used in FPC and
Lazarus and is the preferred string type on Linux, incredible bugs show
up. With
var
a: AnsiString;
On Thursday 13 October 2011 13.56:50 Marco van de Voort wrote:
> In our previous episode, Martin Schreiber said:
> > Suggestion: Let it be as it is in fixes_2_6, add support for Unicode
> > resource strings and invest power into development of Delphi like
> > packages for example.
>
Or improved op
On 10/13/2011 01:45 PM, Luiz Americo Pereira Camara wrote:
This means that StringCodePage is only meaningful when calling it on a
string variable that actually holds a string.
How can a string variable not hold a string ? It might hold an empty
string, but what is a "no-string" ?
Of course
Ok, so after summing in all of this problems which we are facing, I
will withdraw all of my previous ideas and agree with you Marco. If
FPC can produce a RTL mode where string=utf8string then I agree
Lazarus should try to use this UTF-8 RTL.
--
Felipe Monteiro de Carvalho
On 10/13/2011 02:16 AM, Hans-Peter Diettrich wrote:
Almost every required conversion can be determined at compile time.
The only uncertain case is a result (or other source) of type
RawByteString.
What should be the point in doing a library supporting Strings with
dynamically (at run-time)
In our previous episode, Martin Schreiber said:
> Suggestion: Let it be as it is in fixes_2_6, add support for Unicode
> resource strings and invest power into development of Delphi like packages
> for example.
That is already not an option anymore, with the newstr branch merged in.
And while th
On Thursday 13 October 2011 13.41:24 Marco van de Voort wrote:
> > It's time to cut the gordian knot and take a decision.
> > All pros and contras have been discussed at great length meanwhile.
>
> Exactly. That's why a decision that is futureproof should be made, and not
> just start hacking, an
On 13/10/2011 04:55, Michael Schnell wrote:
On 10/13/2011 02:05 AM, Hans-Peter Diettrich wrote:
There is no "Raw" source ID.
The Delphi doc says "the RawByteString Type is type ANSIString($)".
So the RawByte encoding ID in fact is $ (if FPC wants to be Delphi
compatible in that behal
In our previous episode, michael.vancann...@wisa.be said:
> > The more procedural packages yes. The OOP ones not, since their stringtype
> > must match classes for overrides.
>
> Yes, but
> 1. this is the smallest group, so I don't consider that a problem.
Only in number of packages.
> 2. I dou
On Thu, 13 Oct 2011, Marco van de Voort wrote:
In our previous episode, michael.vancann...@wisa.be said:
2. Try a blanket {$H} to make the default stringtype what you want, and fix
problems (e.g. overrides of methods, passing to var params).
The blanket {$H} seems like the way to go for m
In our previous episode, Felipe Monteiro de Carvalho said:
> > Out of curiosity: how did you come to that conclusion? According to what I
> > read in rtl/inc/systemh.inc "PChar" is still defined as an "^Char" and
> > further down is also an alias "AnsiChar = Char", so "PChar" should still be
> > an
On Thu, Oct 13, 2011 at 11:54 AM, Sven Barth
wrote:
> Out of curiosity: how did you come to that conclusion? According to what I
> read in rtl/inc/systemh.inc "PChar" is still defined as an "^Char" and
> further down is also an alias "AnsiChar = Char", so "PChar" should still be
> and behave the s
In our previous episode, Sven Barth said:
> > The difference is more that I don't think it will solve as much as people
> > think, and using this to stitch together code from different origins will
> > fail miserably or be unworkable.
>
> For non-inheritance-related code that is encoding-agnostic
In our previous episode, michael.vancann...@wisa.be said:
> > 2. Try a blanket {$H} to make the default stringtype what you want, and fix
> > problems (e.g. overrides of methods, passing to var params).
>
> The blanket {$H} seems like the way to go for most packages.
> If we insert {$H ANSISTRIN
On 13 Oct 2011, at 12:06, Marco van de Voort wrote:
In our previous episode, Martin said:
But maybe a switch could be added, where an fpc exe gives feedback,
what
it currently defaults to?
in the case of the multiple RTL situation, the target designation gets
enhanced with the encoding (or
Marco van de Voort schrieb:
In our previous episode, Michael Schnell said:
deal seems to be an attempt to avoid an own development, what already
failed with both Kylix and Delphi.NET.
instead of Kylix they now with XE2 provide FPC and instead of Delphi.NET
they sell Prism. Both are 3rd party pr
Paul Ishenin schrieb:
What's CP_NONE? Value and purpose?
RawByteString codepage. Value $ and purpose - inform that string has
no codepage assigned. I think at the moment compiler does not produce
strings of codepage $ anymore but before it did. So now we can
probably clear the RTL f
Am 13.10.2011 12:13, schrieb Marco van de Voort:
In our previous episode, Sven Barth said:
the utf* designates the type of the default string type. And the same for
unix. Maybe win32-ansi too.
Ok... that you want multiple distributions per platform is clear now.
But you would not oppose (in t
In our previous episode, Sven Barth said:
> > the utf* designates the type of the default string type. And the same for
> > unix. Maybe win32-ansi too.
>
> Ok... that you want multiple distributions per platform is clear now.
> But you would not oppose (in the case of having multiple distributio
On 10/13/2011 11:45 AM, michael.vancann...@wisa.be wrote:
Lazarus happens to be UTF-8 centric
I understand, this is because it had been impossible for them to support
as well UTF-8 for Linux as UTF-16 for Windows,
With the new code page aware Strings it should be possible to compile
the sa
On Thu, 13 Oct 2011, Sven Barth wrote:
Am 13.10.2011 11:57, schrieb Marco van de Voort:
In our previous episode, Sven Barth said:
I think he ment that if such a feature is introduced it would be a
natural conclusion to define "string = unicodestring" on Windows and
"string = utf8string" for
On Thu, 13 Oct 2011, Marco van de Voort wrote:
In our previous episode, Sven Barth said:
I think he ment that if such a feature is introduced it would be a
natural conclusion to define "string = unicodestring" on Windows and
"string = utf8string" for Unix in the RTL and the FCL (and maybe "st
Am 13.10.2011 11:57, schrieb Marco van de Voort:
In our previous episode, Sven Barth said:
I think he ment that if such a feature is introduced it would be a
natural conclusion to define "string = unicodestring" on Windows and
"string = utf8string" for Unix in the RTL and the FCL (and maybe "str
In our previous episode, Martin said:
> > it. Anything else will break as soon as the default is changed from
> > one compiler version to another.
> >
> But maybe a switch could be added, where an fpc exe gives feedback, what
> it currently defaults to?
in the case of the multiple RTL situation,
On 13 Oct 2011, at 12:00, Martin wrote:
On 13/10/2011 09:37, Jonas Maebe wrote:
No, and such table will not be made because it's an implementation
detail. If you require a particular debug information format,
specify it. Anything else will break as soon as the default is
changed from on
On Thu, 13 Oct 2011, Alex Shishkin wrote:
13.10.2011 13:34, michael.vancann...@wisa.be пишет:
On Thu, 13 Oct 2011, Felipe Monteiro de Carvalho wrote:
On Thu, Oct 13, 2011 at 11:24 AM, Sven Barth
wrote:
I think he ment that if such a feature is introduced it would be a
natural
conclusion
On 13/10/2011 09:37, Jonas Maebe wrote:
Is there a table somewhere about which debug info types are default in
each operating system?
No, and such table will not be made because it's an implementation
detail. If you require a particular debug information format, specify
it. Anything else wi
Am 13.10.2011 11:53, schrieb Alex Shishkin:
another alternative. in {$H-} no changes string=shortstring, in {$h+}
string = ansistring or unocodestring in delphiunicode mode) by default
but can be redefined directly in code (or this definition is set in
ObjPas unit) "type string = MyNiceStringType
In our previous episode, Sven Barth said:
> I think he ment that if such a feature is introduced it would be a
> natural conclusion to define "string = unicodestring" on Windows and
> "string = utf8string" for Unix in the RTL and the FCL (and maybe "string
> = ansistring" for DOS and OS/2). Thus
Am 13.10.2011 11:49, schrieb Felipe Monteiro de Carvalho:
On Thu, Oct 13, 2011 at 11:45 AM, wrote:
Well, if we add such a beast, it won't be just for UTF-8.
Lazarus happens to be UTF-8 centric, but that doesn't mean we should limit
the use of such a feature to UTF-8...
An addendum to that: W
13.10.2011 13:34, michael.vancann...@wisa.be пишет:
On Thu, 13 Oct 2011, Felipe Monteiro de Carvalho wrote:
On Thu, Oct 13, 2011 at 11:24 AM, Sven Barth
wrote:
I think he ment that if such a feature is introduced it would be a
natural
conclusion to define "string = unicodestring" on Windows
On Thu, Oct 13, 2011 at 11:51 AM, Sven Barth
wrote:
> In one of your mails you had the example of the units "system" and "classes"
> which define "string" as aliased to the string type "banana"
Ah, that was not ment to be interpreted like that ... I just wanted to
say that in this RTL mode or wha
Am 13.10.2011 11:28, schrieb Felipe Monteiro de Carvalho:
On Thu, Oct 13, 2011 at 11:24 AM, Sven Barth
wrote:
I think he ment that if such a feature is introduced it would be a natural
conclusion to define "string = unicodestring" on Windows and "string =
utf8string" for Unix in the RTL and th
On Thu, Oct 13, 2011 at 11:45 AM, wrote:
> Well, if we add such a beast, it won't be just for UTF-8.
>
> Lazarus happens to be UTF-8 centric, but that doesn't mean we should limit
> the use of such a feature to UTF-8...
An addendum to that: We also need the normal PChar. Changing PChar was
*very
On 13 Oct 2011, at 11:37, Felipe Monteiro de Carvalho wrote:
Carbon and Cocoa are rather encoding agnostic, but from what I
understand they use UTF-8 internally.
It's not documented what they use internally, but since all CFString
(= NSString) "character" accessors are UTF-16 based, I think
On Thu, 13 Oct 2011, Felipe Monteiro de Carvalho wrote:
On Thu, Oct 13, 2011 at 11:38 AM, Felipe Monteiro de Carvalho
wrote:
On Thu, Oct 13, 2011 at 11:34 AM, wrote:
In short, you want a directive to say
"In this unit, 'string' means MyNiceStringType"
Which is in fact an extension of the
12.10.2011 15:29, Alex Shishkin пишет:
My proposed changes to spstring.
1) if string is defined w/o explicit encoding (f.e. just "string", in
H+ modeswitch or "ansistring") it treated as RawByteString.
2) In unicode Delphi mode encoding of all string constant values is
forced to UTF16, source en
On Thu, Oct 13, 2011 at 11:38 AM, Felipe Monteiro de Carvalho
wrote:
> On Thu, Oct 13, 2011 at 11:34 AM, wrote:
>> In short, you want a directive to say
>> "In this unit, 'string' means MyNiceStringType"
>> Which is in fact an extension of the current {$H} to a more general case ?
>
> yes
Actu
On Thu, Oct 13, 2011 at 11:34 AM, wrote:
> In short, you want a directive to say
> "In this unit, 'string' means MyNiceStringType"
> Which is in fact an extension of the current {$H} to a more general case ?
yes
--
Felipe Monteiro de Carvalho
___
fp
On Thu, Oct 13, 2011 at 11:26 AM, Sven Barth
wrote:
> AFAIK it was remarked that Qt and Carbon (or only Cocoa?) use UTF-16 as
> well.
Carbon and Cocoa are rather encoding agnostic, but from what I
understand they use UTF-8 internally.
Qt is also rather agnostic, but internally I think it uses UT
In our previous episode, Felipe Monteiro de Carvalho said:
[ Charset ISO-8859-1 unsupported, converting... ]
> On Thu, Oct 13, 2011 at 10:47 AM, Marco van de Voort wrote:
> > But I don't consider this as solution. You have to put each string type in
> > the entire libraries on trial, and keep it u
On Thu, 13 Oct 2011, Felipe Monteiro de Carvalho wrote:
On Thu, Oct 13, 2011 at 11:24 AM, Sven Barth
wrote:
I think he ment that if such a feature is introduced it would be a natural
conclusion to define "string = unicodestring" on Windows and "string =
utf8string" for Unix in the RTL and th
On Thu, Oct 13, 2011 at 11:24 AM, Sven Barth
wrote:
> I think he ment that if such a feature is introduced it would be a natural
> conclusion to define "string = unicodestring" on Windows and "string =
> utf8string" for Unix in the RTL and the FCL
? I am totally lost as to what this has to do wit
Am 13.10.2011 11:29, schrieb Michael Schnell:
On 10/13/2011 11:19 AM, Sven Barth wrote:
No, UnicodeString is not codepage aware.
I was asking about the implementation in XE.
If you mean this: Thanks for the clarification.
Yes, I meant this. Only AnsiString is code page aware in Delphi 2009+
Am 13.10.2011 11:27, schrieb Michael Schnell:
On 10/13/2011 11:05 AM, Mattias Gaertner wrote:
LCL backends work in UTF-16.
Of course the LCL backends close to the OS-API on Windows use UTF-16, as
this is what the API provides. (Or did I misunderstand your wording ?)
AFAIK it was remarked th
Am 13.10.2011 11:02, schrieb Felipe Monteiro de Carvalho:
On Thu, Oct 13, 2011 at 10:47 AM, Marco van de Voort wrote:
But I don't consider this as solution. You have to put each string type in
the entire libraries on trial, and keep it up.
Could you explain more? Which libraries are you talki
On 10/13/2011 11:19 AM, Sven Barth wrote:
No, UnicodeString is not codepage aware.
I was asking about the implementation in XE.
If you mean this: Thanks for the clarification.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://
On 10/13/2011 11:05 AM, Mattias Gaertner wrote:
LCL backends work in UTF-16.
Of course the LCL backends close to the OS-API on Windows use UTF-16, as
this is what the API provides. (Or did I misunderstand your wording ?)
-Michael
___
fpc-devel mail
Am 13.10.2011 11:04, schrieb Michael Schnell:
On 10/13/2011 10:52 AM, Sven Barth wrote:
So you suggest that in Delphi XE, UnicodeString is _not_ a "new String"
Type ?
I don't know what you describe as "new string", but "UnicodeString"
was introduced as a new type in Delphi 2009 and "String"
Michael Schnell hat am 13. Oktober 2011 um 10:18
geschrieben:
> On 10/13/2011 04:27 AM, Hans-Peter Diettrich wrote:
> >
> > I don't see a speed penalty in using UTF-16. In contrast to UTF-8 it
> > simplifies (and consequently speeds up) all string handling.
>
> If doing code heavily doing G
On Thu, Oct 13, 2011 at 10:47 AM, Marco van de Voort wrote:
> But I don't consider this as solution. You have to put each string type in
> the entire libraries on trial, and keep it up.
Could you explain more? Which libraries are you talking about? As I
showed, nothing would need to change in the
On 10/13/2011 10:52 AM, Sven Barth wrote:
So you suggest that in Delphi XE, UnicodeString is _not_ a "new String"
Type ?
I don't know what you describe as "new string", but "UnicodeString"
was introduced as a new type in Delphi 2009 and "String" was made an
alias to "UnicodeString". If you
Am 13.10.2011 10:46, schrieb Michael Schnell:
On 10/13/2011 09:47 AM, Sven Barth wrote:
Since FPC 2.4 there also is a UnicodeString in FPC which is compatible
to the one in Delphi: a reference counted 2-byte-per-character string
type.
So you suggest that in Delphi XE, UnicodeString is _not_ a
On 10/13/2011 10:39 AM, Sven Barth wrote:
When installing you can always select a custom directory though you
can not change the version-id. E.g. you could install to
"/lib/fpc-cpstring/2.7.1".
Of course I do know how to install FPC in another directory or how to
preserve the current installa
Am 13.10.2011 10:34, schrieb Alex Shishkin:
13.10.2011 11:30, Sven Barth пишет:
Am 13.10.2011 04:30, schrieb Hans-Peter Diettrich:
Martin Schreiber schrieb:
Well, with Delphi 2009's Unicode support, the Delphi language now
supports Unicode too. Thus unit names, class names, property names,
va
In our previous episode, Felipe Monteiro de Carvalho said:
> I dont fully understand your question, but lets suppose this RTL file:
>
> unit system;
> {$mode string = banana}
> type RTLString = string;
>
> unit classes;
> {$mode string = banana}
> type
> TWhaeverClass = class
> procedure Do(P
On 10/13/2011 09:47 AM, Sven Barth wrote:
Since FPC 2.4 there also is a UnicodeString in FPC which is compatible
to the one in Delphi: a reference counted 2-byte-per-character string
type.
So you suggest that in Delphi XE, UnicodeString is _not_ a "new String"
Type ?
-Michael
__
On 13 Oct 2011, at 10:37, Jonas Maebe wrote:
On 13 Oct 2011, at 10:17, Felipe Monteiro de Carvalho wrote:
Then maybe the default debug info created by -g on Mac should be
dwarf2? dwarf2 works correctly in my tests.
Yes, I agree it's about time to change that (along with making -
godwarfset
Am 13.10.2011 10:39, schrieb Michael Schnell:
The last FPC version I installed was "Free Pascal Compiler version 2.7.1
[2011/08/26] for i386". "/usr/bin/ppc383" points to
"../lib/fpc/2.7.1/ppc386".
So, when installing a Unicode enabled it might be a good idea to do this
to a separate subdirector
On 13 Oct 2011, at 10:17, Felipe Monteiro de Carvalho wrote:
Then maybe the default debug info created by -g on Mac should be
dwarf2? dwarf2 works correctly in my tests.
Yes, I agree it's about time to change that (along with making -
godwarfsets the default). It requires at least the latest
13.10.2011 11:30, Sven Barth пишет:
Am 13.10.2011 04:30, schrieb Hans-Peter Diettrich:
Martin Schreiber schrieb:
Well, with Delphi 2009's Unicode support, the Delphi language now
supports Unicode too. Thus unit names, class names, property names,
variable names etc can all contain Unicode text
On 10/13/2011 09:43 AM, Sven Barth wrote:
1. Currently there is this huge work going on to get trunk to a
reasonable and usable shape again and until that is done (and maybe
RTL changes as well) it is (in my opinion (!) ) not reasonable to
think about changing the meaning of "string" at all.
On Thu, Oct 13, 2011 at 10:26 AM, Paul Ishenin wrote:
> It will affect as well as compiler directive you suggested to add.
No, the directive is per source code file. 3rd party libraries do not
need to use it.
--
Felipe Monteiro de Carvalho
___
fpc-dev
13.10.2011 16:14, Felipe Monteiro de Carvalho wrote:
On Thu, Oct 13, 2011 at 9:44 AM, Paul Ishenin wrote:
The later can be made by call SetMultiByteConversionCodePage(CP_UTF8) at the
program start.
From my comment on the bug report:
Won't SetMultyByteConversionCodePage inadvertedly affect
On Thu, Oct 13, 2011 at 10:17 AM, Marco van de Voort wrote:
> How do you override classes that are declared in RTLString which might not
> be equal to utf8string?
I dont fully understand your question, but lets suppose this RTL file:
unit system;
{$mode string = banana}
type RTLString = string;
On 10/13/2011 08:20 AM, Paul Ishenin wrote:
RawByteString codepage. Value $ and purpose - inform that string
has no codepage assigned. I think at the moment compiler does not
produce strings of codepage $ anymore but before it did. So now we
can probably clear the RTL from this codepa
On 10/13/2011 03:13 AM, Hans-Peter Diettrich wrote:
..., or try to implement something incompatible with Delphi :-(
I would not generally depreciate this.
I heard a lot comments on problems introduced by the Delphi Unicode
String implementation. So maybe in fact there is room for (incompatibl
In our previous episode, Felipe Monteiro de Carvalho said:
> RTLString = string;
>
> It would not need to be used anywhere in the RTL, but files which use
> the utf8string directive can use this string type to reffer to the RTL
> string type.
How do you override classes that are declared in RTLSt
Hello,
Then maybe the default debug info created by -g on Mac should be
dwarf2? dwarf2 works correctly in my tests.
Is there a table somewhere about which debug info types are default in
each operating system?
--
Felipe Monteiro de Carvalho
___
fpc-de
On Thu, Oct 13, 2011 at 9:44 AM, Paul Ishenin wrote:
> The later can be made by call SetMultiByteConversionCodePage(CP_UTF8) at the
> program start.
>From my comment on the bug report:
Won't SetMultyByteConversionCodePage inadvertedly affect 3rd party
libraries used by the program which, for exa
On Thu, Oct 13, 2011 at 9:43 AM, Sven Barth wrote:
> 1. Currently there is this huge work going on to get trunk to a reasonable
> and usable shape again and until that is done (and maybe RTL changes as
> well) it is (in my opinion (!) ) not reasonable to think about changing the
> meaning of "stri
On 10/13/2011 10:11 AM, Marco van de Voort wrote:
No, they stated the FPC usage was only temporary because their own ARM
compiler was delayed.
but AFAIK not notion on until when
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
ht
On 10/13/2011 04:27 AM, Hans-Peter Diettrich wrote:
I don't see a speed penalty in using UTF-16. In contrast to UTF-8 it
simplifies (and consequently speeds up) all string handling.
If doing code heavily doing GUI handling (such as the LCL in Lazarus)
and the GUI's API is not UTF-16, all str
In our previous episode, Michael Schnell said:
> > deal seems to be an attempt to avoid an own development, what already
> > failed with both Kylix and Delphi.NET.
> instead of Kylix they now with XE2 provide FPC and instead of Delphi.NET
> they sell Prism. Both are 3rd party products, too.
No, t
On 10/13/2011 04:27 AM, Hans-Peter Diettrich wrote:
FireMonkey is a third-party product, now bought by Embarcadero. That
deal seems to be an attempt to avoid an own development, what already
failed with both Kylix and Delphi.NET.
instead of Kylix they now with XE2 provide FPC and instead of Delp
Am 13.10.2011 09:56, schrieb Jonas Maebe:
On 13 Oct 2011, at 09:30, Sven Barth wrote:
Am 13.10.2011 04:30, schrieb Hans-Peter Diettrich:
Perhaps it's an attempt to better interface with .NET, Java or
ObjectiveC?
I don't think so as AFAIK all three don't support unicode characters
in identif
On 13 Oct 2011, at 09:28, Martin wrote:
same address when trying to insert a breakpoint
-break-insert -f testunicode.pas:182
^done,bkpt={number="11",type="breakpoint",disp="keep",enabled="y",addr="0x0edb",file="testunicode.pas",line="182",shlib="/Users/felipe/Programas/lazarus/test/lazutil
On 13 Oct 2011, at 09:30, Sven Barth wrote:
Am 13.10.2011 04:30, schrieb Hans-Peter Diettrich:
Perhaps it's an attempt to better interface with .NET, Java or
ObjectiveC?
I don't think so as AFAIK all three don't support unicode characters
in identifiers.
Java does, but the JDK doesn't c
On 10/13/2011 02:05 AM, Hans-Peter Diettrich wrote:
- assignment will do a conversion (at least if the target encoding
ID is not zero.)
... conversion unless the target type is RawByteString, or has the
same encoding.
Paul did inform us that encoding ID = 0 in the target means no
conversion
Am 13.10.2011 09:49, schrieb Michael Schnell:
Moreover seemingly there is (or will be, or in Delphi XE is) a type
called UnicodeString. In the Delphi docs UnicodeString is said to be
supposed to hold UTF-16 encoded data. But this of course is due to the
string Windows-Binding of Delphi. On Linux
13.10.2011 15:29, Felipe Monteiro de Carvalho пишет:
Hello,
Posting here as this was requested in the bug report:
http://bugs.freepascal.org/view.php?id=20473
I think it is very simple: Having such a directive would save a lot of
work when porting Lazarus-based projects to FPC 2.7
Wrote to t
1 - 100 of 105 matches
Mail list logo
