[fpc-devel] Russian locale information not compatible with FPC locale variables
Hi, A Russian user raised the issue in the fpGUI newsgroups... fpGUI uses UTF-8 as the internal string encoding. He noticed that the File Dialog which displays the file sizes with thousand separators were totally blank. On further investigation he noticed that it was FormatFloat() that caused the issue. FormatFloat uses the ThousandSeparator locale variable. In FPC the ThousandSeparator is of type Char which can only hold one byte. Yet the Russian locale uses the non-breaking space character as expressed in UTF-8 as 'C2 A0' (bytes) and takes up 2 bytes. So how do we assign the Russian ThousandSeparator (U+00A0) in FPC to the ThousandSeparator variable? Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: Russian locale information not compatible with FPC locale variables
On Tue, Jul 29, 2008 at 9:54 AM, Graeme Geldenhuys <[EMAIL PROTECTED]> wrote: > Hi, > > A Russian user raised the issue in the fpGUI newsgroups... fpGUI uses > UTF-8 as the internal string encoding. He noticed that the File Dialog > which displays the file sizes with thousand separators were totally > blank. On further investigation he noticed that it was FormatFloat() > that caused the issue. FormatFloat uses the ThousandSeparator locale > variable. > > In FPC the ThousandSeparator is of type Char which can only hold one > byte. Yet the Russian locale uses the non-breaking space character as > expressed in UTF-8 as 'C2 A0' (bytes) and takes up 2 bytes. So how do > we assign the Russian ThousandSeparator (U+00A0) in FPC to the > ThousandSeparator variable? In fpGUI the rsThousandSeparator contains the locale specific character in UTF-8 encoding. Also ThousandSeparator := Utf8toAnsi(rsThousandSeparator) is not compilable because Utf8ToAnsi() returns a string, not a Char. And simply casting the result to a Char might not be a good idea in all cases. This issue obviously affects more that just the FormatFloat() function. It affects any functions using FPC locale variables defined as Char and the UTF8toAnsi() result is more that one byte. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
Op Tue, 29 Jul 2008, schreef Graeme Geldenhuys: Hi, A Russian user raised the issue in the fpGUI newsgroups... fpGUI uses UTF-8 as the internal string encoding. He noticed that the File Dialog which displays the file sizes with thousand separators were totally blank. On further investigation he noticed that it was FormatFloat() that caused the issue. FormatFloat uses the ThousandSeparator locale variable. In FPC the ThousandSeparator is of type Char which can only hold one byte. Yet the Russian locale uses the non-breaking space character as expressed in UTF-8 as 'C2 A0' (bytes) and takes up 2 bytes. So how do we assign the Russian ThousandSeparator (U+00A0) in FPC to the ThousandSeparator variable? As a workaround, it can be converted into a normal breaking space. There is no proper solution, MBCS requires it to be a string rather than a char, but compatibility requires it to be a char. Which means you are limited to SBCS compatible thousand separators. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
Daniël Mantione wrote: is no proper solution, MBCS requires it to be a string rather than a char, but compatibility requires it to be a char. Which means you are Isn't a string backward compatible with a Char? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
On Tue, Jul 29, 2008 at 10:16 AM, Daniël Mantione <[EMAIL PROTECTED]> wrote: > As a workaround, it can be converted into a normal breaking space. There is > no proper solution, MBCS requires it to be a string rather than a char, but > compatibility requires it to be a char. Which means you are limited to SBCS > compatible thousand separators. This is what the Russian user had to revert to, using a normal $20 (space) character. But seeing that Delphi is now going to be fully Unicode compliant, surely we need to attend to these issues as well in FPC - being fully Unicode compliant. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
Op Tue, 29 Jul 2008, schreef Micha Nelissen: Daniël Mantione wrote: is no proper solution, MBCS requires it to be a string rather than a char, but compatibility requires it to be a char. Which means you are Isn't a string backward compatible with a Char? No. A char can be automatically typeconverted to a string, but they are not compatible types. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
> Dani?l Mantione wrote: > > is no proper solution, MBCS requires it to be a string rather than a > > char, but compatibility requires it to be a char. Which means you are > > Isn't a string backward compatible with a Char? No. You can't typecast or ORD() it anymore, or subtract other chars from it. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
On Tue, Jul 29, 2008 at 10:25 AM, Micha Nelissen <[EMAIL PROTECTED]> wrote: > > Isn't a string backward compatible with a Char? I don't understand your question? Ansi Char is always 1 bytes. A UTF-8 character can be anything from 1-4 bytes. The non-breaking spaces is such a case, being 2 bytes and the ThousandSeparator variable only accepting 1 byte. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
> <[EMAIL PROTECTED]> wrote: > > As a workaround, it can be converted into a normal breaking space. There is > > no proper solution, MBCS requires it to be a string rather than a char, but > > compatibility requires it to be a char. Which means you are limited to SBCS > > compatible thousand separators. > > This is what the Russian user had to revert to, using a normal $20 > (space) character. But seeing that Delphi is now going to be fully > Unicode compliant, surely we need to attend to these issues as well in > FPC - being fully Unicode compliant. And just like Delphi, I think it is better to wait to a major version with proper unicode string support, and do it (mostly) right in one go, instead of little ad-hoc changes to support workarounds. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
Op Tue, 29 Jul 2008, schreef Graeme Geldenhuys: On Tue, Jul 29, 2008 at 10:16 AM, Daniël Mantione <[EMAIL PROTECTED]> wrote: As a workaround, it can be converted into a normal breaking space. There is no proper solution, MBCS requires it to be a string rather than a char, but compatibility requires it to be a char. Which means you are limited to SBCS compatible thousand separators. This is what the Russian user had to revert to, using a normal $20 (space) character. But seeing that Delphi is now going to be fully Unicode compliant, surely we need to attend to these issues as well in FPC - being fully Unicode compliant. Delphi will do char=widechar, which will solve this. It is likely FPC will follow, but that doesn't change anything for the situation which is that we have a sysutils unit that has not been designed for UTF-8 usage. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
On Tue, Jul 29, 2008 at 10:30 AM, Marco van de Voort <[EMAIL PROTECTED]> wrote: >> >> This is what the Russian user had to revert to, using a normal $20 >> (space) character. But seeing that Delphi is now going to be fully >> Unicode compliant, surely we need to attend to these issues as well in >> FPC - being fully Unicode compliant. > > And just like Delphi, I think it is better to wait to a major version with > proper unicode string support, and do it (mostly) right in one go, instead > of little ad-hoc changes to support workarounds. I did not suggest ad-hoc changes, I meant FPC should fully support unicode strings as Delphi is doing in the next release. Unicode is not something new, it's just Delphi that is way behind with their implementation compared to the demand, and FPC now seems to be in the same boat. I don't see any point in waiting for Delphi, after all, we may NOT look at their implementation anyway! Is there any FPC discussions as to how this is going to be tackled and what implications there are etc..? Anything I can join? Any timeline for developers to expect unicode support? Anything we can help test or write unit tests for? Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
> On Tue, Jul 29, 2008 at 10:30 AM, Marco van de Voort <[EMAIL PROTECTED]> > wrote: > > of little ad-hoc changes to support workarounds. > > I did not suggest ad-hoc changes, I meant FPC should fully support > unicode strings as Delphi is doing in the next release. Unicode is > not something new, it's just Delphi that is way behind with their > implementation compared to the demand, and FPC now seems to be in the > same boat. I don't see any point in waiting for Delphi, after all, we > may NOT look at their implementation anyway! No, but we can try to keep compability. > Is there any FPC discussions as to how this is going to be tackled and > what implications there are etc..? There have been, but they are now postponed till we have real Tiburon usage data. > Anything I can join? Any timeline for developers to expect unicode > support? When it is ready (tm). Probably it will also depend on the plans for the 2.3.x branch, and how intrusive the new string type will be. If it is very intrusive it might be post 2.4. I don't think it is realistic to expect anything releaseworthy in the next year. > Anything we can help test or write unit tests for? Yes. You can make tests using widestrings. When it is working, translate all literals to utf-8. Do so for preferably all sysutils,dateutils and strutils string routines, but start with the more important ones. Probably you can see if there are already routines testing this for ansistring in the testsuite and build on that. It will help me/us to start making UTF-8,16 versions of the RTL routines. That work is parallelizable with the compiler work, and these will have to be done anyway sooner or later, and fairly independant of the exact outcome of the string types. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
On Tue, Jul 29, 2008 at 10:34 AM, Daniël Mantione <[EMAIL PROTECTED]> wrote: > > Delphi will do char=widechar, which will solve this. It is likely FPC will > follow, but that doesn't change anything for the situation which is that we > have a sysutils unit that has not been designed for UTF-8 usage. So is anybody working on unicode support in the RTL or sysutils unit? I don't see why we need to be waiting for Delphi, we may not look at their implementation anyway. And in the mean time FPC developers like myself need to keep hacking their code to be unicode compatible, when unicode support should be in FPC directly. fpGUI, Lazarus, MSEGUI etc all have their own unicode helper functions for string manipulation, file access handling etc All this should actually be in FPC itself, not duplicated over and over in user applications and frameworks. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
Op Tue, 29 Jul 2008, schreef Graeme Geldenhuys: On Tue, Jul 29, 2008 at 10:30 AM, Marco van de Voort <[EMAIL PROTECTED]> wrote: This is what the Russian user had to revert to, using a normal $20 (space) character. But seeing that Delphi is now going to be fully Unicode compliant, surely we need to attend to these issues as well in FPC - being fully Unicode compliant. And just like Delphi, I think it is better to wait to a major version with proper unicode string support, and do it (mostly) right in one go, instead of little ad-hoc changes to support workarounds. I did not suggest ad-hoc changes, I meant FPC should fully support unicode strings as Delphi is doing in the next release. Unicode is not something new, it's just Delphi that is way behind with their implementation compared to the demand, and FPC now seems to be in the same boat. I don't see any point in waiting for Delphi, after all, we may NOT look at their implementation anyway! Is there any FPC discussions as to how this is going to be tackled and what implications there are etc..? Anything I can join? Any timeline for developers to expect unicode support? Anything we can help test or write unit tests for? It depends on implementation of new widechar based string types, which will be supported. The developers haven't talked about it yet, but I can imagine we will have some target platforms where sizeof(char)=1, which would provide for 100% compatibility with old code and some platforms where sizeof(char)=2, which will provide the unicode support for the future. For the time being you can prepare your own code by adding: type char=widechar; string=widestring; ... at the top of your files By the way, I do believe we need to be Delphi compatible here and thus know their implementation. Code exchange between Delphi & FPC otherwise becomes too hard for people. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
On Tuesday 29 July 2008 09.54:54 Graeme Geldenhuys wrote: > > A Russian user raised the issue in the fpGUI newsgroups... fpGUI uses > UTF-8 as the internal string encoding. He noticed that the File Dialog > which displays the file sizes with thousand separators were totally > blank. On further investigation he noticed that it was FormatFloat() > that caused the issue. FormatFloat uses the ThousandSeparator locale > variable. > > In FPC the ThousandSeparator is of type Char which can only hold one > byte. Yet the Russian locale uses the non-breaking space character as > expressed in UTF-8 as 'C2 A0' (bytes) and takes up 2 bytes. So how do > we assign the Russian ThousandSeparator (U+00A0) in FPC to the > ThousandSeparator variable? > MSEgui has a widestring version of the FormatFloat function (lib/common/kernel/mseformatstr.pas formatfloatmse). There were no bug reports from Russian users, so it seems to work, although I did not test the U+00A0 ThousandSeparator... Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
On Tue, Jul 29, 2008 at 10:45 AM, Marco van de Voort <[EMAIL PROTECTED]> wrote: >> same boat. I don't see any point in waiting for Delphi, after all, we >> may NOT look at their implementation anyway! > > No, but we can try to keep compability. > >> Is there any FPC discussions as to how this is going to be tackled and >> what implications there are etc..? > > There have been, but they are now postponed till we have real Tiburon usage > data. So FPC plans to always be worse off than Delphi. :-( I really think playing 'catchup' with somebody like Delphi is not a good thing. They have different goals as far as I can see, plus their future doesn't look bright (for a very long time now). Delphi tries to compete with Microsoft using Microsoft's own tool (.NET). We all know how that turns out when anybody tries to compete with Microsoft. Because of that, Delphi language features are very behind compared to the developer demand. So now FPC wants to be even more behind, because we need to wait for Delphi to one day get there act together. :-( As far as I heard we are already incompatible with Delphi regarding Generics (I don't know generics, I just heard of them). So even though FPC has Generics for some time, nobody can use it, because it's incompatible with Delphi. Unicode is another issue. Delphi dictates there design decisions based on Windows only. FPC targets multiple platforms, so we should target our implementations based on OUR requirements. An open source project trying to be compatible with a commercial product is simply a pipe dream. That's my thought on the subject, but that irrelevant I guess because I have no say in the FPC core team and there direction. I'm also getting a bit off topic here.. > Yes. You can make tests using widestrings. When it is working, translate all > literals to utf-8. Do so for preferably all sysutils,dateutils and strutils > string routines, but start with the more important ones. Probably you can > see if there are already routines testing this for ansistring in the > testsuite and build on that. I'll have a look at the current testsuite to see what's there... > It will help me/us to start making UTF-8,16 versions of the RTL routines. > That work is parallelizable with the compiler work, and these will have to > be done anyway sooner or later, and fairly independant of the exact outcome > of the string types. Exactly my point! And if you want some code to look at (which you may legally do, not like Delphi code), have a look at MSEIDE, Lazarus and fpGUI for implementation examples of some functions. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] GetAppConfigDir confusion
It seems that currently, GetAppConfigDir performs rather incosistently. On Unix, it returns path with trailing pathdelim, on windows it returns path with random trailing path delim (depends on which branch, see code). What should it be then? Considering the importance of this function to programs, it's changes along versions (e.g: 2.2.0 vs 2.2.2 vs soon-to-be-trunk) I think we need to document the behaviors per-version so people can decide if it's even viable to use atm. (I got burned). So.. questions are: 1. trailing pathdelims, yes or no? (of course only if there's something to return) 2. can I update the doc with per-version peculiarities info? Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
Op Tue, 29 Jul 2008, schreef Graeme Geldenhuys: On Tue, Jul 29, 2008 at 10:45 AM, Marco van de Voort <[EMAIL PROTECTED]> wrote: same boat. I don't see any point in waiting for Delphi, after all, we may NOT look at their implementation anyway! No, but we can try to keep compability. Is there any FPC discussions as to how this is going to be tackled and what implications there are etc..? There have been, but they are now postponed till we have real Tiburon usage data. So FPC plans to always be worse off than Delphi. :-( I really think playing 'catchup' with somebody like Delphi is not a good thing. They have different goals as far as I can see, plus their future doesn't look bright (for a very long time now). Delphi tries to compete with Microsoft using Microsoft's own tool (.NET). We all know how that turns out when anybody tries to compete with Microsoft. Because of that, Delphi language features are very behind compared to the developer demand. So now FPC wants to be even more behind, because we need to wait for Delphi to one day get there act together. :-( FPC behind? What are you talking of man? :) Waiting until we know more about the Delphi implementation is in the interrest of everyone here. Borland, oops, Codegear, whoops, Embarcadero, might have strange plans, but Delphi users remain important for FPC. Not everyone has completely switches to FPC like you and even you benefit from being able to use more external code. Code exchange is extremely important. Note we need a major revision anyway to introduce these changes. As far as I heard we are already incompatible with Delphi regarding Generics (I don't know generics, I just heard of them). So even though FPC has Generics for some time, nobody can use it, because it's incompatible with Delphi. People who need their code compilable with Delphi cannot use generics indeed. So what, they can use both Delphi and FPC if they keep their code clean of compiler specific features. But, doing strings incompatible with Delphi means Delphi users cannot use FPC. Because any program uses strings. Unicode is another issue. Delphi dictates there design decisions based on Windows only. FPC targets multiple platforms, so we should target our implementations based on OUR requirements. Agree, but note that one of our requirements is code exchange with Delphi. An open source project trying to be compatible with a commercial product is simply a pipe dream. That's my thought on the subject, but that irrelevant I guess because I have no say in the FPC core team and there direction. I'm also getting a bit off topic here.. Yes. You can make tests using widestrings. When it is working, translate all literals to utf-8. Do so for preferably all sysutils,dateutils and strutils string routines, but start with the more important ones. Probably you can see if there are already routines testing this for ansistring in the testsuite and build on that. I'll have a look at the current testsuite to see what's there... It will help me/us to start making UTF-8,16 versions of the RTL routines. That work is parallelizable with the compiler work, and these will have to be done anyway sooner or later, and fairly independant of the exact outcome of the string types. Exactly my point! And if you want some code to look at (which you may legally do, not like Delphi code), have a look at MSEIDE, Lazarus and fpGUI for implementation examples of some functions. Good. MSEIDE is quiet a bit ahead because it made the switch to widechar/strings from the start. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
On Tue, Jul 29, 2008 at 10:45 AM, Daniël Mantione <[EMAIL PROTECTED]> wrote: > The developers haven't talked about it yet, but I can imagine we will have > some target platforms where sizeof(char)=1, which would provide for 100% > compatibility with old code and some platforms where sizeof(char)=2, which > will provide the unicode support for the future. Sorry, but a unicode character can be anything from 1-4 bytes. 2 bytes will hardly cover the full unicode character range. > For the time being you can prepare your own code by adding: > > type char=widechar; > string=widestring; I already use something similar to fpGUI... TfpgString = type string; TfpgChar= type string[4]; TfpgChar being 4 bytes to cover the whole Unicode range. And some UTF-8 compliant string functions which are used often... function UTF8Copy(const s: string; StartCharIndex, CharCount: integer): string; function UTF8Length(const s: string): integer; function UTF8Pos(const SearchForText, SearchInText: string): integer; procedure UTF8Delete(var S: string; Index, Size: integer); procedure UTF8Insert(const Source: string; var S: string; Index: integer); // short form (alias or convenience) functions for the UTF8 ones above function Copy8(const s: string; StartCharIndex, CharCount: integer): string; function Length8(const s: string): integer; function Pos8(const SearchForText, SearchInText: string): integer; procedure Delete8(var S: string; Index, Size: integer); procedure Insert8(const Source: string; var S: string; Index: integer); And some UTF-8 file access functions // RTL wrapper filesystem functions with platform independant encoding // These functions are common for all platforms and rely on fpgXXXPlatformEncoding function fpgFindFirst(const Path: TfpgString; Attr: Longint; out Rslt: TSearchRec): Longint; function fpgFindNext(var Rslt: TSearchRec): Longint; function fpgGetCurrentDir: TfpgString; function fpgSetCurrentDir(const NewDir: TfpgString): Boolean; function fpgExpandFileName(const FileName: TfpgString): TfpgString; function fpgFileExists(const FileName: TfpgString): Boolean; And this is my point. Many developers have such implementations in there own code for some time now. All these string encoding functions should actually be in FPC (a long time ago). > By the way, I do believe we need to be Delphi compatible here and thus know > their implementation. Code exchange between Delphi & FPC otherwise becomes > too hard for people. A pipe dream, like I said before... :-)I don't see the point why developers want to switch between compilers, using the same code base. Simply pick a compiler that can do it all, FPC!! ;-) That's what our company did. FPC fills our needs perfectly - cross platform, 32 bit and 64 bit support, an awesome FCL, loads of header translations etc... We don't need Delphi! Now the next item I would like to add to that awesome feature list of FPC, is full Unicode support. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
On Tue, Jul 29, 2008 at 11:07 AM, Martin Schreiber <[EMAIL PROTECTED]> wrote: > > MSEgui has a widestring version of the FormatFloat function > (lib/common/kernel/mseformatstr.pas formatfloatmse). There were no bug > reports from Russian users, so it seems to work, although I did not test the > U+00A0 ThousandSeparator... My case in point. We keep rewriting the sysutils unit functions, when all these things should be in FPC itself! Could you do a test with the U+00A0 ThousandSeparator character? If it works, I guess I'll be using another custom written sysutils function in fpGUI. :-( Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
Op Tue, 29 Jul 2008, schreef Graeme Geldenhuys: On Tue, Jul 29, 2008 at 10:45 AM, Daniël Mantione <[EMAIL PROTECTED]> wrote: The developers haven't talked about it yet, but I can imagine we will have some target platforms where sizeof(char)=1, which would provide for 100% compatibility with old code and some platforms where sizeof(char)=2, which will provide the unicode support for the future. Sorry, but a unicode character can be anything from 1-4 bytes. 2 bytes will hardly cover the full unicode character range. Please read http://unicode.org/notes/tn12/ why using 2 byte strings internally is the best choice. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
Marco van de Voort wrote: Dani?l Mantione wrote: is no proper solution, MBCS requires it to be a string rather than a char, but compatibility requires it to be a char. Which means you are Isn't a string backward compatible with a Char? No. You can't typecast or ORD() it anymore, or subtract other chars from it. I'm not sure how many people are trying to do that on the ThousandSeparator variable, but in theory you are right. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
> On Tue, Jul 29, 2008 at 10:45 AM, Marco van de Voort <[EMAIL PROTECTED]> > wrote: > > There have been, but they are now postponed till we have real Tiburon usage > > data. > > So FPC plans to always be worse off than Delphi. :-( Well, of course. We have more requirements!? Multi-platform and compability to self and Delphi. But that we pull that off is also one of our main (if not THE) strengths. And in the past it has proven that it pays to be compatible, and to be not rash in major course decisions because of pressure to "immediately" do something. > I really think playing 'catchup' with somebody like Delphi is not a good > thing. They have different goals as far as I can see, plus their future > doesn't look bright (for a very long time now). We have Delphi compatibility as a major point, and it pays off. We are the only smaller development project that is not stewarded by some firm that has commercial components written for it. Also, the clear direction of compability limits the "design by committee" problem a bit, where you get a feature laden, but unusuable product. > Delphi tries to compete with Microsoft using Microsoft's own tool (.NET). Tiburon comes without .NET. > We all know how that turns out when anybody tries to compete with > Microsoft. We also have a Windows compiler. > Because of that, Delphi language features are very behind compared to the > developer demand. So now FPC wants to be even more behind, because we > need to wait for Delphi to one day get there act together. :-( We are not a commercial company, and even a commercial company doesn't automatically only cater to the herd. There are specialized commercial companies too. You say it yourself, you can't compete with Microsoft, and we need an edge over the zillion of useless Open Source development projects somehow. A clear direction, our relative independance and the fact that we dare to take impopular choices is our main edge there. That, and the influx from a major external commercial codebase. Let's not ruin that. > As far as I heard we are already incompatible with Delphi regarding > Generics (I don't know generics, I just heard of them). So even though > FPC has Generics for some time, nobody can use it, because it's > incompatible with Delphi. We will see how that pans out in time. Maybe we'll support Delphi's syntax too in time. Wouldn't be the first time. > Unicode is another issue. Delphi dictates there design decisions based > on Windows only. FPC targets multiple platforms, so we should target > our implementations based on OUR requirements. Yes. But while we don't have the exact requirements that Delphi does, we do have Delphi compability as major feature. Period. All the major open source codebases (Jedi, Indy, VST, the remobjects stuff, whatever is still active of the TurboPower stuff etc) will go Tiburon sooner or later. If you want to be the messenger that tells them that they have to manually insert a conversion in each procedure, or fork the codebase for FPC, I can give them your email address. The same ackward position is created for more FPC oriented packages that also support Delphi (like e.g. TDBF). A lot of former deviations from Delphi compatability have been changed back to compatible in time (e.g. the procvar stuff, the required @ which is still in objfpc) except for some of the most lowlevel details, for exactly such reasons. > An open source project trying to be compatible with a commercial > product is simply a pipe dream. Well first, I don't think so, but also what are you suggesting? Becoming the a small "last stand" for Pascal ? > > It will help me/us to start making UTF-8,16 versions of the RTL routines. > > That work is parallelizable with the compiler work, and these will have to > > be done anyway sooner or later, and fairly independant of the exact outcome > > of the string types. > > Exactly my point! And if you want some code to look at (which you may > legally do, not like Delphi code), have a look at MSEIDE, Lazarus and > fpGUI for implementation examples of some functions. Yes, we can stuff the rough routines in a few temporary utitlity routines even (sysutilsunicode and strutilsunicode or so), till the rest is ready to go native. Or postfix them with encoding for time being and stuff them in sysutils/strutils. But first we need a set of tests, then make the routines, and then we'll see where to stuff them. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
> On Tue, Jul 29, 2008 at 10:45 AM, Dani?l Mantione > <[EMAIL PROTECTED]> wrote: > > The developers haven't talked about it yet, but I can imagine we will have > > some target platforms where sizeof(char)=1, which would provide for 100% > > compatibility with old code and some platforms where sizeof(char)=2, which > > will provide the unicode support for the future. > > Sorry, but a unicode character can be anything from 1-4 bytes. 2 > bytes will hardly cover the full unicode character range. (it can be larger, since a printable char might be more than one codepoints. (Thai iirc uses up to 4). This is due to the fact that interpunction in a lot of languages is more or less combined into the last char. > A pipe dream, like I said before... :-)I don't see the point why > developers want to switch between compilers, using the same code base. > Simply pick a compiler that can do it all, FPC!! (It happens. However sharing libraries are more important for sharing then actual end-developer projects. Specially the open source ones. And why not? A few defines extra and your audience is larger) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
> Op Tue, 29 Jul 2008, schreef Graeme Geldenhuys: > >> will provide the unicode support for the future. > > > > Sorry, but a unicode character can be anything from 1-4 bytes. 2 > > bytes will hardly cover the full unicode character range. > > Please read http://unicode.org/notes/tn12/ why using 2 byte strings > internally is the best choice. (while true, IMHO that changes nothing for us, since the OS developers mostly made that choice for us) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
Op Tue, 29 Jul 2008, schreef Micha Nelissen: Marco van de Voort wrote: Dani?l Mantione wrote: is no proper solution, MBCS requires it to be a string rather than a char, but compatibility requires it to be a char. Which means you are Isn't a string backward compatible with a Char? No. You can't typecast or ORD() it anymore, or subtract other chars from it. I'm not sure how many people are trying to do that on the ThousandSeparator variable, but in theory you are right. charvar:=ThousandSeparator; ... would fail as fail. Basically anything fails except where the char is converted to string. I don't the compat issues are theoretic. There for sure exists code that assigns thousandseparator to a char or passes it to a var parameter. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
On Tue, Jul 29, 2008 at 11:18 AM, Daniël Mantione <[EMAIL PROTECTED]> wrote: >> developer demand. So now FPC wants to be even more behind, because we >> need to wait for Delphi to one day get there act together. :-( > > FPC behind? What are you talking of man? :) I knew that statement would get some attention. :) > Waiting until we know more about the Delphi implementation is in the > interrest of everyone here. Borland, oops, Codegear, whoops, Embarcadero, Ya, my point. And nobody knows what Embarcadero is going to be like. > might have strange plans, but Delphi users remain important for FPC. Not > everyone has completely switches to FPC like you and even you benefit from > being able to use more external code. Code exchange is extremely important. Code exchange - the pipe dream (tm). :) I have done quite a bit of code porting. Trust me, FPC and Delphi is not as compatible as everybody would hope. The reason is not because FPC is inferior, it's because FPC targets more platforms, so some things need to be different. I'm pretty sure there are NO reasonably sized projects that are code compatible without a need of some changes. Plus if FPC frees itself from that requirement, it has free reins to implement things perfectly based on OUR requirements. Look at Chrome (or whatever they are called now). Some awesome language features have been knocked out in a relatively short period, because they don't bother with Delphi compatibility. Instead they concentrate on improving the language. Delphi on the other hand are more interested in building a Visual Studio clone and .NET support. When last did Borland, CodeGear, Emb add language features that was not specifically due to .NET requirements D6 or D7 maybe? That's like a lifetime ago. > People who need their code compilable with Delphi cannot use generics > indeed. So what, they can use both Delphi and FPC if they keep their code > clean of compiler specific features. And loose all the benefits Generics can give them! > Good. MSEIDE is quiet a bit ahead because it made the switch to > widechar/strings from the start. Pity FPC could do such a bold move. ;-) Imagine how much less work Martin would have had to do. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
> Op Tue, 29 Jul 2008, schreef Graeme Geldenhuys: > interrest of everyone here. Borland, oops, Codegear, whoops, Embarcadero, You forgot Inprise and Devco :-) And codegear is still good, since the Delphi oriented division retains that name. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
Op Tue, 29 Jul 2008, schreef Graeme Geldenhuys: Good. MSEIDE is quiet a bit ahead because it made the switch to widechar/strings from the start. Pity FPC could do such a bold move. ;-) Imagine how much less work Martin would have had to do. True. Because of the influence of Lazarus, the FPC team has spent much more time satisying the needs of ansistring based LCL than satisfying the needs of widestring based MSEGUI. But Martin also choose consiously to do work outside the FPC team rather than work with it to integrate his needs into FPC. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
Because of that, Delphi language features are very behind compared to the developer demand. In my personal view, there are very few points that are shared by Delphi and FP and that are "very behind compared to the developer demand". The main of these is multi-threading support. While both Delphi and FP do have the very workable TThread, same was planned with an application in mind that runs on a single processor engine and is mainly intended to free up the GUI thread when long winded calculations are to be done, so that the GUI does not freeze. .NET introduced some very interesting new concepts on parallel programming that are easy to use and are planned with the application running on SMP machines in mind. RemObject's "Oxygen" implemented these concepts in Object Pascal "Delphi Language". As theses concepts, while being "invented" by .NET, can decently be implemented in the RTL without using (or even thinking of) a .NET runtime, IMHO it would take FP a great step ahead (of Delphi :) ) if it would provide these concepts. The language constructs "*future *variables" and "*async* expressions" allow to easily "spinning off" an instruction sequence from the running code into the background (and thus allow it to be calculated by another processor). See: http://wiki.remobjects.com/wiki/Future_%28keyword%29 I feel that this can be (quite easily :) ) be converted to using (a special kind of) TThreads by the RTL. Maybe there are some more .NET goodies that can be implemented without actually using .NET. http://wiki.remobjects.com/wiki/Oxygene_Glossary might provide some hints on how these can be translated into Object Pascal enhancements. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
On Tue, Jul 29, 2008 at 10:27 AM, Graeme Geldenhuys <[EMAIL PROTECTED]> wrote: > On Tue, Jul 29, 2008 at 10:16 AM, Daniël Mantione > <[EMAIL PROTECTED]> wrote: >> As a workaround, it can be converted into a normal breaking space. There is >> no proper solution, MBCS requires it to be a string rather than a char, but >> compatibility requires it to be a char. Which means you are limited to SBCS >> compatible thousand separators. > > This is what the Russian user had to revert to, using a normal $20 > (space) character. So back to my original question :) Due to ThousandSeparator being a Char type, is using a normal space ($20) the only available option for Russian users, using the current RTL implementation? Though this might cause issues in text wrapping routines which can now not distinguish between breaking spaces and non-breaking spaces. The only other alternative is writing my own string format functions like fpgFormatFloat() and hope the users of fpGUI use the custom written functions instead of the RTL ones. This also means I need to implement my own locale variables to be Unicode compatible. What a job, for something that seemed so small an issue in the beginning. :) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] GetAppConfigDir confusion
Michael Van Canneyt wrote / napísal(a): On Tue, 29 Jul 2008, Ales Katona wrote: It seems that currently, GetAppConfigDir performs rather incosistently. On Unix, it returns path with trailing pathdelim, on windows it returns path with random trailing path delim (depends on which branch, see code). What should it be then? Considering the importance of this function to programs, it's changes along versions (e.g: 2.2.0 vs 2.2.2 vs soon-to-be-trunk) I think we need to document the behaviors per-version so people can decide if it's even viable to use atm. (I got burned). So.. questions are: 1. trailing pathdelims, yes or no? (of course only if there's something to return) What is the most logical according to you ? I think the pathdelim should be there so people can simply add name of their file to it. That's how it currently works in unix, and I think it's the most logical solution. Loesje said he'll look into it but I can help, after someone confirms which way to go :) 2. can I update the doc with per-version peculiarities info? I'll take care of this. Thanks Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] GetAppConfigDir confusion
On Tue, 29 Jul 2008, Ales Katona wrote: > It seems that currently, GetAppConfigDir performs rather incosistently. > > On Unix, it returns path with trailing pathdelim, on windows it returns path > with random trailing path delim (depends on which branch, see code). > > What should it be then? > > Considering the importance of this function to programs, it's changes along > versions (e.g: 2.2.0 vs 2.2.2 vs soon-to-be-trunk) I think we need to document > the behaviors per-version so people can decide if it's even viable to use atm. > (I got burned). > > So.. questions are: > 1. trailing pathdelims, yes or no? (of course only if there's something to > return) What is the most logical according to you ? > 2. can I update the doc with per-version peculiarities info? I'll take care of this. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
Op Tue, 29 Jul 2008, schreef Graeme Geldenhuys: So back to my original question :) Due to ThousandSeparator being a Char type, is using a normal space ($20) the only available option for Russian users, using the current RTL implementation? Though this might cause issues in text wrapping routines which can now not distinguish between breaking spaces and non-breaking spaces. A possible hack could be to abuse an ASCII control character for the non breaking space, for example ThousandSeparator=#0 means a non breaking space, so it is later converted back to the right utf-8 representation. The only other alternative is writing my own string format functions like fpgFormatFloat() and hope the users of fpGUI use the custom written functions instead of the RTL ones. This also means I need to implement my own locale variables to be Unicode compatible. What a job, for something that seemed so small an issue in the beginning. :) Well, this seems exactly what Martin has done, so perhaps you can reuse some of his work. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] GetAppConfigDir confusion
On Tue, 29 Jul 2008, Ales Katona wrote: > Michael Van Canneyt wrote / napísal(a): > > On Tue, 29 Jul 2008, Ales Katona wrote: > > > > > > > It seems that currently, GetAppConfigDir performs rather incosistently. > > > > > > On Unix, it returns path with trailing pathdelim, on windows it returns > > > path > > > with random trailing path delim (depends on which branch, see code). > > > > > > What should it be then? > > > > > > Considering the importance of this function to programs, it's changes > > > along > > > versions (e.g: 2.2.0 vs 2.2.2 vs soon-to-be-trunk) I think we need to > > > document > > > the behaviors per-version so people can decide if it's even viable to use > > > atm. > > > (I got burned). > > > > > > So.. questions are: > > > 1. trailing pathdelims, yes or no? (of course only if there's something to > > > return) > > > > > > > What is the most logical according to you ? > > > > I think the pathdelim should be there so people can simply add name of their > file to it. That's how it currently works in unix, and I think it's the most > logical solution. Loesje said he'll look into it but I can help, after someone > confirms which way to go :) Well, I think adding it is indeed the most logical. Probably the confusing windows situation is the result of some bug fix not being merged correctly. I'll add a warning that prior to 2.2.2, the behaviour may be inconsistent. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
> > > On Tue, 29 Jul 2008, Graeme Geldenhuys wrote: > > > On Tue, Jul 29, 2008 at 10:27 AM, Graeme Geldenhuys > <[EMAIL PROTECTED]> wrote: > > On Tue, Jul 29, 2008 at 10:16 AM, Daniël Mantione > > <[EMAIL PROTECTED]> wrote: > >> As a workaround, it can be converted into a normal breaking space. There is > >> no proper solution, MBCS requires it to be a string rather than a char, but > >> compatibility requires it to be a char. Which means you are limited to SBCS > >> compatible thousand separators. > > > > This is what the Russian user had to revert to, using a normal $20 > > (space) character. > > > So back to my original question :) > > Due to ThousandSeparator being a Char type, is using a normal space > ($20) the only available option for Russian users, using the current > RTL implementation? Though this might cause issues in text wrapping > routines which can now not distinguish between breaking spaces and > non-breaking spaces. Yes, this is your only option. > > The only other alternative is writing my own string format functions > like fpgFormatFloat() and hope the users of fpGUI use the custom > written functions instead of the RTL ones. This also means I need to > implement my own locale variables to be Unicode compatible. What a > job, for something that seemed so small an issue in the beginning. :) Let's not jump to conclusions too quickly. Obviously, the FPC team will have to do something for Unicode support; Tiburon compatibility plays a big role in that. Once this is done, there should be no problem. For the time being, replacing the non- breaking space with a breaking space is the best you can do. The chances that you really need a non-breaking space somewhere in an amount are infinitesimally small. So, no need to make the issue bigger than it is, and start coding duplicates of existing routines because of such a small issue. We'll fix it eventually, this is the main message. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
>> As far as I heard we are already incompatible with Delphi regarding >> Generics (I don't know generics, I just heard of them). So even though >> FPC has Generics for some time, nobody can use it, because it's >> incompatible with Delphi. > > We will see how that pans out in time. Maybe we'll support Delphi's syntax > too in time. Wouldn't be the first time. That will be realy great! -- Inoussa O. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
So FPC plans to always be worse off than Delphi. :-( I really think playing 'catchup' with somebody like Delphi is not a good thing. They have different goals as far as I can see, plus their future doesn't look bright (for a very long time now). Delphi tries to compete with Microsoft using Microsoft's own tool (.NET). We all know how that turns out when anybody tries to compete with Microsoft. Because of that, Delphi language features are very behind compared to the developer demand. So now FPC wants to be even more behind, because we need to wait for Delphi to one day get there act together. :-( Yup. If it's really the case then I'm sorry to say that FPC has such a "loser mentality". FPC has chances to become the leader of object pascal native compiler since Delphi was starting to die after Delphi 7. But, instead of taking the lead, FPC let itself and the users down in the name of "compatibility". What a shame! :-P Then why FPC implemented generics before Delphi in the first place? I never heard compatibility issue when we discussed about this feature. Delphi didn't have this feature when FPC implemented its own syntax on generics. I was proud to know that FPC really implemented generics before Delphi did. It made me confident to completely using FPC and forget Delphi. I saw bright future with FPC. But now... :( Unicode is another issue. Delphi dictates there design decisions based on Windows only. FPC targets multiple platforms, so we should target our implementations based on OUR requirements. +1 Compatibility is good, no doubt about it. But if it obstacles FPC to have feature(s) that most users need, FPC should put compatibility issue aside and get users need on higher priority. Be the first, be the leader, be a winner. If Delphi then implements it (if ever) in different way, then we can start to discuss about compatibility. It's absurd talking compatibility to something that even doesn't exist! An open source project trying to be compatible with a commercial product is simply a pipe dream. That's my thought on the subject, but that irrelevant I guess because I have no say in the FPC core team and there direction. I'm also getting a bit off topic here.. FPC could lead the object pascal "standard" and make Borland /CodeGear /Embarcadero /whatever follows what FPC had done. Not the other way around. How can FPC become a better compiler than Delphi if FPC doesn't have the gut to be the best?! :( Please look at other open source projects that have dignity to win the competition e.g. Linux, Apache, Firefox, etc. They dare to be different on the beginning but people begin to follow them in the end. They never want to be a "clone" or "copycat" or "shadow" or "tail" to other successful (commercial) products. They have winner mentality, that's why they succeed. Sorry to be a little bit out of topic here. I just couldn't hold myself to express my opinion on this. -Bee- ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
The main of these is multi-threading support. I also demand this support. :) I believe FPC team could provide this feature. They are genius. But, I'm afraid, they don't want to provide it simply because Delphi doesn't have it (yet). They don't want FPC being incompatible with Delphi. :-P I don't understand why FPC has DELPHI MODE directive in the first place if FPC don't want to be different with Delphi. Maybe FPC should eliminate this directive and make it as the default mode. :-P -Bee- ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
Op Tue, 29 Jul 2008, schreef Bee: So FPC plans to always be worse off than Delphi. :-( I really think playing 'catchup' with somebody like Delphi is not a good thing. They have different goals as far as I can see, plus their future doesn't look bright (for a very long time now). Delphi tries to compete with Microsoft using Microsoft's own tool (.NET). We all know how that turns out when anybody tries to compete with Microsoft. Because of that, Delphi language features are very behind compared to the developer demand. So now FPC wants to be even more behind, because we need to wait for Delphi to one day get there act together. :-( Yup. If it's really the case then I'm sorry to say that FPC has such a "loser mentality". FPC has chances to become the leader of object pascal native compiler since Delphi was starting to die after Delphi 7. But, instead of taking the lead, FPC let itself and the users down in the name of "compatibility". What a shame! :-P Could you show me the advantage of having an incompatible string implementation in FPC 2.4, which will be out after highlander? What is the point to "leading" here? Just to be clear once and forever: We don't want a Netscape vs. Internet Explorer HTML extensions like war. It is our aim to unite rather than to divide the Pascal world more. Sorry to be a little bit out of topic here. I just couldn't hold myself to express my opinion on this. Good. Now it's time show practical proposals or stop the discussion. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
I believe FPC team could provide this feature. They are genius. But, I'm afraid, they don't want to provide it simply because Delphi doesn't have it (yet). They don't want FPC being incompatible with Delphi. :-P Adding some keywords would it not make incompatible. To stay compatible you just don't use them :). I don't understand why FPC has DELPHI MODE directive in the first place if FPC don't want to be different with Delphi. Maybe FPC should eliminate this directive and make it as the default mode. :-P Maybe a compiler switch can be added that disallows the new keywords and that is set by default in Delphi mode (but can be switched off by the user if he wants to take advantage of the new features. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
Bee wrote:
I don't understand why FPC has DELPHI MODE directive in the first place
if FPC don't want to be different with Delphi. Maybe FPC should
eliminate this directive and make it as the default mode. :-P
This is exactly the reason. Strings and API touches everything, while
generics are a language feature and thus under control of {$mode X}
Micha
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
Original-Nachricht > Datum: Tue, 29 Jul 2008 19:48:46 +0700 > Von: Bee <[EMAIL PROTECTED]> > An: FPC developers\' list > Betreff: Re: [fpc-devel] Russian locale information not compatible with FPC > locale variables > > > Unicode is another issue. Delphi dictates there design decisions based > > on Windows only. FPC targets multiple platforms, so we should target > > our implementations based on OUR requirements. > > +1 > > Compatibility is good, no doubt about it. But if it obstacles FPC to > have feature(s) that most users need, FPC should put compatibility issue > aside and get users need on higher priority. Be the first, be the > leader, be a winner. If Delphi then implements it (if ever) in different > way, then we can start to discuss about compatibility. It's absurd > talking compatibility to something that even doesn't exist! Well, I second that. Especially because the "Delphi" implementation seems to be so Win32-centric, that copying it would be close to useless on platforms other than Windows. As far as I understand there is no such thing as a "codepage number" on Unices. I doubt that the FPC team would want such a specific implementation, so despite all arguments, FPC would have to find its own way in either case. Vinzent. -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
FPC has chances to become the leader of object pascal native compiler since Delphi was starting to die after Delphi 7. But, instead of taking the lead, FPC let itself and the users down in the name of "compatibility". What a shame! :-P ... FPC could lead the object pascal "standard" and make Borland /CodeGear /Embarcadero /whatever follows what FPC had done. Not the other way around. How can FPC become a better compiler than Delphi if FPC doesn't have the gut to be the best?! :( IMHO, Oxygen is the "leader of object pascal compiler" right now, but they don't provide support for native code, so you are right. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
> > FPC could lead the object pascal "standard" and make Borland /CodeGear > > /Embarcadero /whatever follows what FPC had done. Not the other way > > around. How can FPC become a better compiler than Delphi if FPC > > doesn't have the gut to be the best?! :( > IMHO, Oxygen is the "leader of object pascal compiler" right now, but > they don't provide support for native code, so you are right. Why, according to you, is Oxygen Object Pascal at all? Aside from their advertizements? Just if you compare the base subset ? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
Op Tue, 29 Jul 2008, schreef "Vinzent Höfler": Original-Nachricht Datum: Tue, 29 Jul 2008 19:48:46 +0700 Von: Bee <[EMAIL PROTECTED]> An: FPC developers\' list Betreff: Re: [fpc-devel] Russian locale information not compatible with FPC locale variables Unicode is another issue. Delphi dictates there design decisions based on Windows only. FPC targets multiple platforms, so we should target our implementations based on OUR requirements. +1 Compatibility is good, no doubt about it. But if it obstacles FPC to have feature(s) that most users need, FPC should put compatibility issue aside and get users need on higher priority. Be the first, be the leader, be a winner. If Delphi then implements it (if ever) in different way, then we can start to discuss about compatibility. It's absurd talking compatibility to something that even doesn't exist! Well, I second that. Especially because the "Delphi" implementation seems to be so Win32-centric, that copying it would be close to useless on platforms other than Windows. As far as I understand there is no such thing as a "codepage number" on Unices. Disagree. Nobody maintains codepage registries except two companies: Microsoft and IBM. While I have my doubts about Windows API constants, there are only a few identifications that make sense: * Microsoft code page number * IBM code page number * IANA mib-enum * IANA encoding name It doesn't matter which one you choose, you should choose one and use that over all platforms. I doubt that the FPC team would want such a specific implementation, so despite all arguments, FPC would have to find its own way in either case. I can live with using numbers from the Microsoft code page registry. Numbers are far more comfortable to use in portable code than using strings, which is the common practise on Unix. So, while there is some bad Windows taste involved, it's not that bad from a portability point of view. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
Why, according to you, is Oxygen Object Pascal at all? Aside from their advertizements? Just if you compare the base subset ? Is there some independent definition of the term "Object Pascal" ? I don't suppose so. So they are right to claim that they are compatible to Object pascal :) . But If you call their Oxygen code "Delphi Language" they in fact will get angry :) :) :) . Of course Oxygen is a lot less compatible to Delphi than FP is. They are greatly CIL centric - though happily not really .NET centric as they explicitly do support Mono and Linux. That is why the strict create...free mechanism is not used there (as the CIL framework performs the garbage control for the application) and thus the code can be a lot different. OTOH they claim that "Delphi for .NET" is not a decent way to write CIL code at all. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
> > Why, according to you, is Oxygen Object Pascal at all? Aside from their > > advertizements? Just if you compare the base subset ? > > > Is there some independent definition of the term "Object Pascal" ? I > don't suppose so. Well, there is the actual Object Pascal standard draft. Delphi deviates quite some from that though. > So they are right to claim that they are compatible to > Object pascal :) . "compatible" is nonsense, since they are not compatible to any of the roughly three preexisting ones. Descendant could be said, but I don't even see much evidence for that. There is a superficial resemblance in the parser model and that is about it. They are about as Pascal as Perl is C because they both have curly braces and some similar operator names. > Of course Oxygen is a lot less compatible to Delphi than FP is. They are > greatly CIL centric "less compatible"?!?!? Can Oxygen actually compile and execute any preexisting code in any Pascal dialect ? > OTOH they claim that "Delphi for .NET" is not a decent way to > write CIL code at all. Probably. But that doesn't make them "Object Pascal". I do recognize that Rem Objects needs some language to package and promote their frameworks (the thing they are IMHO good in), but the featurelist is a bunch of C# me too's. Of course they will greatly stress the improved readability and the like, but I would too if I had to sell it :-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
On Tue, Jul 29, 2008 at 3:08 PM, "Vinzent Höfler" <[EMAIL PROTECTED]> wrote: > > Well, I second that. Especially because the "Delphi" implementation seems to > be so Win32-centric, that copying it would be close to useless on platforms > other than Windows. As far as I understand there is no such thing as a > "codepage number" on Unices. > > I doubt that the FPC team would want such a specific implementation, so > despite all arguments, FPC would have to find its own way in either case. > For more information on what Vinzent is talking about, please see the following website. http://blogs.codegear.com/abauer/2008/07/16/38864/ examples: type MyString = type AnsiString(<1..65534>); were 1..65534 is the Windows codepage number. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
> http://blogs.codegear.com/abauer/2008/07/16/38864/ This is all known and processed on July 17th. > type > MyString = type AnsiString(<1..65534>); > > were 1..65534 is the Windows codepage number. Elegant is different, but a reason incompatability? Also note Daniel's remark about codepage classification. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] GetAppConfigDir confusion
Ales Katona wrote: It seems that currently, GetAppConfigDir performs rather incosistently. On Unix, it returns path with trailing pathdelim, on windows it returns path with random trailing path delim (depends on which branch, see code). What should it be then? :) This is exactly the reason why I at work created the utility function: function ConcatinatePath(const Elements: array of string): String so it will take cate if a delim exist or not for the individual parts. (especially when users may define a dir) Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
Could you show me the advantage of having an incompatible string implementation in FPC 2.4, which will be out after highlander? Boost the usage of Unicode in FPC that would boost the usage of FPC itself. Unicode is one of the most demanded features (beside cross platform, 64bit support, etc) in Delphi since Delphi 7 (2001?). Yet, CodeGear never fulfill it until Tiburon. What is the point to "leading" here? Be the first object pascal compiler that provide newest technologies needed by users. Object pascal users are not as much as Java or C/C++ users. But, they are not in very small numbers either. In capitalism term, they're asset. By providing pascal compiler that always capable to provide new technologies would prevent pascal from its death. That would also save millions lines of pascal code being trashed. Just to be clear once and forever: We don't want a Netscape vs. Internet Explorer HTML extensions like war. It is our aim to unite rather than to divide the Pascal world more. You may say that. But look at the reality. You want it or not, users would create competition atmosphere by themselves by comparing features. There are many faith Delphi developers who still think that FPC is just a Delphi follower and Lazarus just another Delphi-like wannabe project because FPC/Laz doesn't really provide something that they really need. No wonder if those Delphi developers move to other languages (Java, Ruby, Python, etc) instead of using FPC. The biggest advantage of FPC/Laz over Delphi, IMO, is only the cross platform ability which is also available on other languages. Unite doesn't mean to be a follower. Being different also doesn't mean against union. Look at the big picture. There are many pascal developers out there that need new technologies being implemented in pascal. No matter how much they love the language, if the language doesn't provide what they need, sooner or later they would leave pascal for other languages. By providing DELPHI MODE (and other pascal dialects directive), IMO, FPC is already in the correct way of being different but still united with other pascal compilers. Good. Now it's time show practical proposals or stop the discussion. Well, I'm not a compiler expert. Is it possible to keep the "old" string in Delphi mode and implement "new" string in FPC mode? This way, FPC could keep (backward) compatibility in Delphi mode and provide the new (Unicode) implementation in FPC mode. FPC can modify Delphi mode string later after Delphi shows its mechanism and follow it to get Delphi compatibility. However, I think it's too late to use this scenario since Unicode support in Tiburon is just a few months away. I think FPC should have done it since v.2.0. :( Perhaps FPC could think about multiprocessor support using this scenario. ;) -Bee- ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
"compatible" is nonsense, since they are not compatible to any of the roughly three preexisting ones. Descendant could be said, but I don't even see much evidence for that. There is a superficial resemblance in the parser model and that is about it. At least, they're trying to answer what the users need in .Net world which CodeGear couldn't do. They have guts to be different instead of being follower. They are about as Pascal as Perl is C because they both have curly braces and some similar operator names. But, users have an option to convert their old Delphi codes and get the new technology as the pay-off. "less compatible"?!?!? Can Oxygen actually compile and execute any preexisting code in any Pascal dialect ? Neither FPC. My old TP codes is hardly can be compiled using FPC due the old DOS nature. In the sake of being cross platform, incompatibility is inevitable. Converting to less compatible but similar syntax is easier than rewriting the whole codes in totally different syntax. I do recognize that Rem Objects needs some language to package and promote their frameworks (the thing they are IMHO good in), but the featurelist is a bunch of C# me too's. It's acceptable as they provide Oxygene only for .Net platform. Nothing wrong of being "me too" if it offers benefits of new technologies. It's wrong, IMO, of being stagnant and not creative in the name of "compatibility". Technologies are always improving and changing. We can't force ourselves to stick with old technologies just for compatibility sake. Compatibility is preserved only if it's possible to be done. -Bee- ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
Op Tue, 29 Jul 2008, schreef Bee: Could you show me the advantage of having an incompatible string implementation in FPC 2.4, which will be out after highlander? Boost the usage of Unicode in FPC that would boost the usage of FPC itself. Unicode is one of the most demanded features (beside cross platform, 64bit support, etc) in Delphi since Delphi 7 (2001?). Yet, CodeGear never fulfill it until Tiburon. Why would it boost FPC usage? Okay, here is the deal: From now I'm going to stick my fingers in my ears until someone says "You should be incompatible because". Until now I have heard these valid arguments: - Delphi's implementation is ugly/non portable. By providing DELPHI MODE (and other pascal dialects directive), IMO, FPC is already in the correct way of being different but still united with other pascal compilers. The intention of the FPC mode is threefold: - Allow FPC to be compatible by itself - Fix the worst quirks in the Delphi dialect - Disable some FPC features that interfere with compatibility The FPC modes were never intended to design our own dialect from scratch, or give the finger to existing code. Any code should compile in FPC mode with just a few fixes, at least that is how it is intended. Further, you lack complete understanding of the impact of incompatible strings. Delphi mode is feasible because in one mode, you can call code in compiled in other modes. Good. Now it's time show practical proposals or stop the discussion. Well, I'm not a compiler expert. Is it possible to keep the "old" string in Delphi mode and implement "new" string in FPC mode? This way, FPC could keep (backward) compatibility in Delphi mode and provide the new (Unicode) implementation in FPC mode. FPC can modify Delphi mode string later after Delphi shows its mechanism and follow it to get Delphi compatibility. I don't consider this a practical solution for Graeme's issue with the numeric separators, he would still have to wait for 2.4, and we could implement it compatible anyway in 2.4. However, I think it's too late to use this scenario since Unicode support in Tiburon is just a few months away. I think FPC should have done it since v.2.0. :( Perhaps FPC could think about multiprocessor support using this scenario. ;) Agree for the part that an proprietary unicode string would have made sense then and not now. I would not have done things differently in hindsight. Postponing it for even more features would have given extra stress supporting 1.0 and made users impatient waiting for 2.0. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
> > "compatible" is nonsense, since they are not compatible to any of the > > roughly three preexisting ones. Descendant could be said, but I don't even > > see much evidence for that. There is a superficial resemblance in the parser > > model and that is about it. > > At least, they're trying to answer what the users need in .Net world > which CodeGear couldn't do. Wouldn't do, since it is a totally different market. A new language, incompatible with everything. While Codegear caters to the needs in its own usergroup, not in (a very vaguely defined) .NET world. > They have guts to be different instead of being follower. Funny that you say that about the Oxygene language. To me the language concept and marketing screams ".NET me too wannabe". > > They are about as Pascal as Perl is C because they both have curly braces > > and some similar operator names. > > But, users have an option to convert their old Delphi codes Where? There is no migration path. It is scratch from new for all non-trivial code. > and get the new technology as the pay-off. Which "new" technology? > > "less compatible"?!?!? Can Oxygen actually compile and execute any > > preexisting > > code in any Pascal dialect ? > > Neither FPC. Note that I say _any_ not _all_. > > I do recognize that Rem Objects needs some language to package and promote > > their frameworks (the thing they are IMHO good in), but the featurelist is a > > bunch of C# me too's. > > It's acceptable as they provide Oxygene only for .Net platform. Nothing > wrong of being "me too" if it offers benefits of new technologies. There is nothing new there. It is all C# and Java rehash. > It's wrong, IMO, of being stagnant and not creative in the name of > "compatibility". Well, then where are the major new features of Oxygene? Where, what? > Technologies are always improving and changing. We can't > force ourselves to stick with old technologies just for compatibility > sake. Programmers are not exempt from normal business practices. And that means constant revenue, dealing with installed base and long term investment plans. > Compatibility is preserved only if it's possible to be done. And all this from a codepage number in one line of source. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
