Re: [fpc-devel] Encoded AnsiString
30.12.2013 20:59, Michael Van Canneyt wrote: That was my idea. If it turns out to be really impossible, we can still do as Paul suggests, but if it works, I would attempt to release 2.8 with dotted units. In each case, the ground work will be done in a branch, so as not to irreversibly damage trunk and destroy Paul's dreams :) I have nothing against if you think there are no risks to delay the release for more than a year. Let's see how well I fare; 2.8.0 is not for next month anyway. First get 2.6.4 out of the door. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Encoded AnsiString
On Mon, 30 Dec 2013, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: But the "experiments for ansi/unicode RTL" are already in trunk. Do you plan to take them out ? and: What good is having the unicode string support if none of the classes or units make use of it ? Limited. But 2.8.x is not all about unicode. Still, if you have planned time, it might be worth to try it IMHO. That was my idea. If it turns out to be really impossible, we can still do as Paul suggests, but if it works, I would attempt to release 2.8 with dotted units. In each case, the ground work will be done in a branch, so as not to irreversibly damage trunk and destroy Paul's dreams :) Let's see how well I fare; 2.8.0 is not for next month anyway. First get 2.6.4 out of the door. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Encoded AnsiString
In our previous episode, Michael Van Canneyt said: > But the "experiments for ansi/unicode RTL" are already in trunk. > Do you plan to take them out ? > > and: > What good is having the unicode string support if none of the classes or > units make use of it ? Limited. But 2.8.x is not all about unicode. Still, if you have planned time, it might be worth to try it IMHO. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Encoded AnsiString
In our previous episode, Paul Ishenin said: > > I don't think that this is a good idea, it means that e.g. > > TStrings.SaveToFile() or TFileStream.Create() is still crippled. > > Better bite the bullet. This is what I wanted to test in feb/march. > > This will also mean that we will release 2.8 much later (looking at > cpstr development speed probably few years later) because together with > this implementation we need to solve ansi/unicode RTL problem (dotted > unit names in RTL and packages). > > Imo it is better to release all that huge changes we have in trunk as is > (maybe together with resourcestring solution). Then with the following > minor releases we improve dotted unit names support (like default > namespaces) together with experiments for ansi/unicode RTL. Having a base classes implementation that is unicode capable, can help with e.g. fixing up TProcess to unicode over the 2.8 lifecycle and other simple but crucial packages, and maybe even pioneer with fcl-db. Doing this after the 2.8 branch makes trunk and fixes immediately incompatible, which would make 2.8 quite an orphan. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Encoded AnsiString
30.12.2013 20:25, Michael Van Canneyt wrote: But the "experiments for ansi/unicode RTL" are already in trunk. Do you plan to take them out ? By "experiments" I ment having 2 (or 1.5) RTL with unicode + ansi classes which we planned to solve using namespaces. What good is having the unicode string support if none of the classes or units make use of it ? No-one will test it or even be able to test it because none of the base classes/routines are adapted to it. We have string, file and console routings for use and testing. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Encoded AnsiString
On Mon, 30 Dec 2013, Paul Ishenin wrote: 30.12.2013 18:33, Michael Van Canneyt пишет: So how one can help at this stage: 1. Check related FPC tests and write new for the missing cases. 2. Compare FPC and Delphi RTL classes which had beed adjusted in Delphi during the unicodestring move and check whether something minor can be added to FPC. All major changes like the new TStringList class based on UnicodeString should wait for 2.8 release. I don't think that this is a good idea, it means that e.g. TStrings.SaveToFile() or TFileStream.Create() is still crippled. Better bite the bullet. This is what I wanted to test in feb/march. This will also mean that we will release 2.8 much later (looking at cpstr development speed probably few years later) because together with this implementation we need to solve ansi/unicode RTL problem (dotted unit names in RTL and packages). Imo it is better to release all that huge changes we have in trunk as is (maybe together with resourcestring solution). Then with the following minor releases we improve dotted unit names support (like default namespaces) together with experiments for ansi/unicode RTL. I think I understand what you want to say: Release the codepage strings support with the RTL as-is. But the "experiments for ansi/unicode RTL" are already in trunk. Do you plan to take them out ? and: What good is having the unicode string support if none of the classes or units make use of it ? No-one will test it or even be able to test it because none of the base classes/routines are adapted to it. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Encoded AnsiString
30.12.2013 18:33, Michael Van Canneyt пишет: So how one can help at this stage: 1. Check related FPC tests and write new for the missing cases. 2. Compare FPC and Delphi RTL classes which had beed adjusted in Delphi during the unicodestring move and check whether something minor can be added to FPC. All major changes like the new TStringList class based on UnicodeString should wait for 2.8 release. I don't think that this is a good idea, it means that e.g. TStrings.SaveToFile() or TFileStream.Create() is still crippled. Better bite the bullet. This is what I wanted to test in feb/march. This will also mean that we will release 2.8 much later (looking at cpstr development speed probably few years later) because together with this implementation we need to solve ansi/unicode RTL problem (dotted unit names in RTL and packages). Imo it is better to release all that huge changes we have in trunk as is (maybe together with resourcestring solution). Then with the following minor releases we improve dotted unit names support (like default namespaces) together with experiments for ansi/unicode RTL. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Encoded AnsiString
On Sun, Dec 29, 2013 at 7:26 PM, Hans-Peter Diettrich wrote: > > var a: AnsiString; u: UTF8String; > function cpy(s: RawByteString):RawByteString; > begin Result := s; end; > a := cpy(u); //now a has encoding UTF-8! > > Here the XE compiler omits the conversion of the RawByteString result to > the declared encoding of the target. Dunno about newer versions. > A quick note: the new LLVM Delphi compiler forbid the use of AnsiString and AnsiChar, (declared in the unit AnsiString.pas, you cannot use this unit anyway), you will probably choose to hack using MarshaledAString. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Encoded AnsiString
On Mon, 30 Dec 2013, Paul Ishenin wrote: 30.12.2013 9:07, Hans-Peter Diettrich пишет: Do you think that FPC should really reproduce all this inconsistent behaviour? Who would test or even specify the compatible behaviour, when every new variation will result in more unexpected results? IMO it's much easier to do it right, and fix the Delphi flaws in FPC. The work is already done by FPC team. AnsiString(codepage) works and works compatible with Delphi (whether someone like this or not) and the behavior is covered by tests. Trunk version is very close to 2.8 release. The only related thing which we thought to touch before the release was resourcestring handling. If I have some free time during the new year holidays I will look at it. So how one can help at this stage: 1. Check related FPC tests and write new for the missing cases. 2. Compare FPC and Delphi RTL classes which had beed adjusted in Delphi during the unicodestring move and check whether something minor can be added to FPC. All major changes like the new TStringList class based on UnicodeString should wait for 2.8 release. I don't think that this is a good idea, it means that e.g. TStrings.SaveToFile() or TFileStream.Create() is still crippled. Better bite the bullet. This is what I wanted to test in feb/march. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Encoded AnsiString
Paul Ishenin schrieb: 30.12.2013 9:07, Hans-Peter Diettrich пишет: Do you think that FPC should really reproduce all this inconsistent behaviour? Who would test or even specify the compatible behaviour, when every new variation will result in more unexpected results? IMO it's much easier to do it right, and fix the Delphi flaws in FPC. The work is already done by FPC team. AnsiString(codepage) works and works compatible with Delphi (whether someone like this or not) and the behavior is covered by tests. Trunk version is very close to 2.8 release. This means that UTF-8 won't work properly when it's not CP_ACP :-( DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
