On 10/14/2011 05:22 PM, Martin Schreiber wrote:
I understand that this is exactly what Delphi-type runtime packages are
invented for.
and Lazarus-type packages can't do.
Obviously, AFAIK, this never has been claimed, but that there have been
requests for "loadable binary plug-in" type runtime
On 13 Oct 2011, at 20:51, Craig Peterson wrote:
> BTW, I wanted to point out, to anyone arguing for full Delphi compatibility,
> that on OS X Delphi's DefaultSystemCodePage and AnsiString(0) are *not* the
> system encoding _or_ UTF-8. They're the Windows ANSI codepages that
> correspond to th
On Friday 14 October 2011 15.42:38 Michael Schnell wrote:
> On 10/14/2011 02:51 PM, Martin Schreiber wrote:
> > Ever tried to implement a form or any function which uses dynamic types
> > or common application elements in a dll/so?
>
> I understand that this is exactly what Delphi-type runtime pa
On 10/14/2011 02:51 PM, Martin Schreiber wrote:
Ever tried to implement a form or any function which uses dynamic types or
common application elements in a dll/so?
I understand that this is exactly what Delphi-type runtime packages are
invented for.
-Michael
_
Am 14.10.2011 14:07, schrieb Michael Schnell:
On 10/14/2011 10:30 AM, Hans-Peter Diettrich wrote:
- and start implementing a new FireMonkey component library,
independent from the LCL.
Is this really necessary ? FireMonkey is a rebranded open source
library, so it should be possible just to _us
On Friday 14 October 2011 14.19:35 Michael Schnell wrote:
> On 10/14/2011 10:30 AM, Hans-Peter Diettrich wrote:
> > BTW2, the Lazarus IDE has big problems with the lack of dynamically
> > loadable packages, which still are *not* supplied by FPC. This will
> > possibly make impossible above separati
On 10/14/2011 10:30 AM, Hans-Peter Diettrich wrote:
BTW2, the Lazarus IDE has big problems with the lack of dynamically
loadable packages, which still are *not* supplied by FPC. This will
possibly make impossible above separation between the IDE
implementation and FPC progress. Wouldn't it b
On 10/14/2011 10:30 AM, Hans-Peter Diettrich wrote:
- and start implementing a new FireMonkey component library,
independent from the LCL.
Is this really necessary ? FireMonkey is a rebranded open source
library, so it should be possible just to _use_ it.
OTOH, (I don't have XE2): does XE2 co
Craig Peterson schrieb:
In Delphi XE2 on OS X AnsiString does *not* map to UTF-8. On an English
system it maps to "Windows-1252". If you want to convert an "array of
AnsiChar" to a WideString you need to cast it as a UTF8String first. By
default DefaultSystemCodePage is 1252, not 65001.
W
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 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
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
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
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
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
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
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
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
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
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 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
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
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: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 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: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
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
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 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;
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
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
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
Am 13.10.2011 09:29, schrieb 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
1. Cu
59 matches
Mail list logo
