Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
On Wed, Jul 30, 2008 at 6:05 PM, Daniël Mantione [EMAIL PROTECTED] wrote: ...because all characters that need upper/lower casing are in the BMP. Likewise, all possible thousand separators are in the BMP, so you don't need to bother with that either. Ah, that's so true. :-) I'm starting to like the idea of UTF-16 more and more compared to UTF-8. UTF-8 is a lot more work. If so, it would same me a lot of time implementing them myself. What would Pos, Length, Copy etc return? This would be the same behaviour as with widestrings. RTL routines are dump, smarter ones should go in sysutils. OK thanks. I'll start creating unit tests for some of these basic functions so I can solidify my understanding and expected behaviour of widestrings and UTF-16. 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
Funny that you say that about the Oxygene language. To me the language concept and marketing screams .NET me too wannabe. Remobj is one of the few companies that bring the cross-platform features, and thus the promising future of CIL (aka .NET in Microsoft speak) up to front. They, too, do use the term .NET instead of CIL, because otherwise 90% of the readers would not know what they are talking about :( . But they do advertise that Oxygen can compile for multiple OSes (using Mono bindings) and multiple processors (e.g. using portable .NET bindings). If the user code is done in a way that all bindings are possible (this can be checked with the SDK), the resulting Assembly will run everywhere. (At least this is what I understood.) IMHO, CIL (.NET) is a really promising concept for the future of computing. I just read about an embedded CIL Framework, done for a deeply embedded CPU that is to be configured (programmed) into an FPGA (IMHO this is the future of deeply embedded Computing) and this Framework does not even need an OS to run (but can take advantage of any co-existing OS, says the article). Provided that it's a lot easier to create a compiler for CIL than creating it for multiple CPUs and OSes, IMHO, this is the way to go on the long run. (But of course native code will widely be in use for several years to come :) ). -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
Provided that it's a lot easier to create a compiler for CIL than creating it for multiple CPUs and OSes, IMHO, this is the way to go on the long run. (But of course native code will widely be in use for several years to come :) ). If this was true, Java would have taken that market already. There is nothing new to that aspect of CIL, and specially with only one minor vendor supporting 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
Well, then where are the major new features of Oxygene? Where, what? I already did rant about future and async. If there would be much more I would already have bought it :) . -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 5:50 PM, Daniël Mantione [EMAIL PROTECTED] wrote: 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? Like Bee said... The time frame has come and gone! If you read the delphi.non-technical newsgroup you would notice that quite a few Delphi developers use FPC for backend features. Linux services etc... They also talked about FPC having 64bit support. If FPC didn't worry to much about compatibility and instead implemented Unicode support long ago like it could have, it might just have boosted FPC usage, beating Borland to the punch by about 7 years. FPC could have attracted and converted more Delphi developers... Yes it's always easy to say that with the benefit of hindsight, but it's not far from the truth. Our company is a case in point. We saw features in FPC that we would like and Borland was going in the wrong direction for us. At that point in time (2-3 years ago) there was no mention of when Delphi would ever support those features. FPC seemed the obvious choice to us, so we moved - an still with no regrets. :-) Yes it costed use some time and effort to port our code and required tools, but it's still been worth it. We can now target different platforms, 32/64bit systems Our next evolution for our products are non-English speaking countries, hence the Unicode requirements. But the time frame to beat Delphi with Unicode support has passed... :-( 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
If this was true, Java would have taken that market already. There is nothing new to that aspect of CIL, and specially with only one minor vendor supporting it. Basically you are right, but - In fact Java is very widely in use (even though there are lots of shortcomings regarding Java e.g. performance ) - AFAIK, CIL seems to improve some of the Java shortcomings - CIL defines concepts for multi-treading and multi-processing - every year the processing performance and available memory resources improve and thus creating economical object code is less critical - While (AFAIK) there are no (or only very few and rarely used) languages besides Java that can create byte code for the just-in-time compiling Java Framework, There are a lot languages with compilers form different brands usable with CIL (several C# compilers, C++, Pascal, (Oxygen and Delphi), Visual Basic, Iron-Python, .., is there a Java-CIL compiler ? ) - 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 Wed, 30 Jul 2008, Graeme Geldenhuys wrote: On Tue, Jul 29, 2008 at 5:50 PM, Daniël Mantione [EMAIL PROTECTED] wrote: 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? Like Bee said... The time frame has come and gone! If you read the delphi.non-technical newsgroup you would notice that quite a few Delphi developers use FPC for backend features. Linux services etc... They also talked about FPC having 64bit support. If FPC didn't worry to much about compatibility and instead implemented Unicode support long ago like it could have, it might just have boosted FPC usage, beating Borland to the punch by about 7 years. FPC could have attracted and converted more Delphi developers... Yes it's always easy to say that with the benefit of hindsight, but it's not far from the truth. Our company is a case in point. We saw features in FPC that we would like and Borland was going in the wrong direction for us. At that point in time (2-3 years ago) there was no mention of when Delphi would ever support those features. FPC seemed the obvious choice to us, so we moved - an still with no regrets. :-) Yes it costed use some time and effort to port our code and required tools, but it's still been worth it. We can now target different platforms, 32/64bit systems Our next evolution for our products are non-English speaking countries, hence the Unicode requirements. But the time frame to beat Delphi with Unicode support has passed... :-( Well, if we could clone the FPC team a couple of times, we probably would have had it a long time ago. And a host of other things at well. But we are few, we have day jobs, and we're not being paid for any of this. Volunteers have also been very scarce. Talks of foundations and whatnot have popped up at various times, but always dwindled away, no-one doing anything was the result time and again. And that is the whole explanation for some features not being there: it's open source, and a hobby project for the core teams. If users badly need some features, it's time they organized themselves and get something going to support FPC development *actively*. If this doesn't happen, then I conclude that these features aren't really needed, but are in the domain of 'nice to have'. 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
Zitat von Michael Schnell [EMAIL PROTECTED]: If this was true, Java would have taken that market already. There is nothing new to that aspect of CIL, and specially with only one minor vendor supporting it. Basically you are right, but - In fact Java is very widely in use (even though there are lots of shortcomings regarding Java e.g. performance ) Which is mostly due to the garbage collector. There are already java coprocessors boosting java to native speed. - AFAIK, CIL seems to improve some of the Java shortcomings I'm curious. Has someone evidence for that? - CIL defines concepts for multi-treading and multi-processing - every year the processing performance and available memory resources improve and thus creating economical object code is less critical Same for java. I have some doubts about the increases of processing performance. The speed ups of the last years were mainly due to multiple cores. The increase of speed of a single core decreased. In fact many recent computers like the eeepc are pretty slow to get longer run times. And writing multithreaded code is economically more expensive than single threaded. So I see a strong need for native compilers like FPC. - While (AFAIK) there are no (or only very few and rarely used) languages besides Java that can create byte code for the just-in-time compiling Java Framework, There are a lot languages with compilers form different brands usable with CIL (several C# compilers, C++, Pascal, (Oxygen and Delphi), Visual Basic, Iron-Python, .., is there a Java-CIL compiler ? ) Yes, but I didn't test it. Mattias ___ 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 Wed, Jul 30, 2008 at 10:48 AM, Michael Van Canneyt [EMAIL PROTECTED] wrote: But we are few, we have day jobs, and we're not being paid for any of this. I'm in the same boat. And I did offer to extend or start writing tests cases to help implementation. I'm not a compiler developer (I don't understand any of it's internals), but I can help implement Unicode enabled string functions. We have a few implementations floating around already. And that is the whole explanation for some features not being there: it's open source, and a hobby project for the core teams. I did not demand the unicode features... I simply stated a shortcoming when I started this thread and asked how I could proceed with a work-around. Also, I did not see an issue in highlighting my thoughts on cloning other projects. I thought we are free to express our opinions, seeing that this is an open-source community project. I also do not consider myself one of those users that simply bitch from the sidelines and not really participate. I might not have been as active as other users in FPC or Lazarus development, but I have submitted patches for things I could fix or implement. Plus, if I feel strongly about (against) something (like my issues regarding LCL), I do something about it, like I'm doing with fpGUI. Anyway, I have received a answer to my original question and I thank those that participated in the conversation. Always a pleasure chatting to you guys. ;-) 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 Wed, Jul 30, 2008 at 11:04 AM, Florian Klaempfl [EMAIL PROTECTED] wrote: We spent this time frame with making FPC multiplatform. Knowing what's And I thank you again for it. :) delphi.non-technical is yellow press made by users for users. What better place to find out what users think of a product. After all, they are the people using it. I don't want to hear from the Borland/CodeGear/Embarcadero sales and marketing team, I want to hear from the actual people using the product! That newsgroup does just that. FPC has unicode support for years. Remember what a widestring is? So I'm just imagining the locale issue with U+00A0 character? Plus the knock-on affect to FormatFloat, FormatDateTime etc.. Does FPC have any any functions that work correctly with surrogate pair used by UTF-16? If so, it would same me a lot of time implementing them myself. What would Pos, Length, Copy etc return? BTW: If it comes down to it that I have implement UTF-16 string functions myself, you are more that welcome to use the code in FPC. :) long ago like it could have, it might just have boosted FPC usage, Unlikely. Anyways, who is interested in usage? The important part is contribution. With usage comes contributions! Nobody can deny that. The MSE is fully unicode. How much people use it and contribute? Without Martin, MSE would be dead. Nope, MSE only supports UCS2, not full UTF-16. And off the top of my head I know of myself, Felipe and Michael van C. that had a look at MSE. It's just to hard to read Martin's code and be able to contribute. He has a very different coding style. It works for him, but unfortunately not for others. 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
Marco van de Voort schrieb: Read this and the reactions, and weep: http://groups.google.com/group/borland.public.delphi.non-technical/browse_frm/thread/db61d19063a2f948/289008199451755a?lnk=gstq=voort+multicore#289008199451755a I don't agree on the point that good mt support is a matter of the framework. _Really_ good multithreading support is a matter and must be a matter of the language as well and in several years and must be as common as while or for loops. Currently, multithreaded programming is like programming spaghetti basic. A good framework is comparable to at least the try to program structured with line numbered basic but it is not forced by the language. The compiler must know about parallism. ___ 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 schrieb: Read this and the reactions, and weep: http://groups.google.com/group/borland.public.delphi.non-technical/browse_frm/thread/db61d19063a2f948/289008199451755a?lnk=gstq=voort+multicore#289008199451755a I don't agree on the point that good mt support is a matter of the framework. _Really_ good multithreading support is a matter and must be a matter of the language as well and in several years and must be as common as while or for loops. Note that I already hinted on the duality. Performance vs ease of use. You more or less specify the performance angle, for newly written code for people with heavy calculation that generally know what they are doing. I think that is the rarer case in practice. But the other side is not about perfecting lineair algorithm with a bit of multithreading. I'm talking about what to do from the perspective of the avg Delphi/FPC user. And most of them don't have really intensive calculating loops, outside maybe some minor encryption/compression code that they never wrote themselves in the first place. It is not a simple linear algorum that needs updating with a bit of manually instrucmented threading. The problem of ease is just that multithreading from scratch is too hard or too time consuming as a programming model for most. Specially with a single threading GUI (and maybe here and there GUI api), and the ad-hoc way they throw together programs. And they desperately turn to the tools makers (CG and us) to fix that, because Intel promised them heaps of extra performance due to the multicore revolution. So preferably they want us toe wave a magic wand and that their old crusty VCL code ridden with timers, COM objects, external libs and the like is suddenly fully multithreading and scales with number of cores. Without a totally new design paradigm that is harder, and without a careful tuning to avoid the threaded loop being slower than the single core one. And that is IMHO not realistic. So the cure you are suggesting is for a different problem, and for a happy few that also can handle manual threading fine. And then I think better frameworks is a better solution then optimizing loops OpenMP style, because you won't even notice the speed up of that in the avg app. Currently, multithreaded programming is like programming spaghetti basic. A good framework is comparable to at least the try to program structured with line numbered basic but it is not forced by the language. The compiler must know about parallism. Personally I hope we get it tomorrow. For me it would mostly work, since at work I really do dataprocessing in a fairly linear way. But that isn't the avg users case as far as I can see. ___ 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 don't agree on the point that good mt support is a matter of the framework. _Really_ good multithreading support is a matter and must be a matter of the language as well and in several years and must be as common as while or for loops. Currently, multithreaded programming is like programming spaghetti basic. A good framework is comparable to at least the try to program structured with line numbered basic but it is not forced by the language. The compiler must know about parallism. I fully support this. Regarding Object pascal I am dreaming about thread events since many years. (This would need no new keyword and only a very small addition to the compiler. You might find posts on this in the backlog of this forum.) I did provide a concept, but had not the spare time to try to implement it. The said future and asnc concept that Oxygen adopted from .NET seems very promising, and I'm sure that it can be implemented in the RTL in native code without thinking about a .NET framework. -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 Wed, 30 Jul 2008, Graeme Geldenhuys wrote: On Wed, Jul 30, 2008 at 10:48 AM, Michael Van Canneyt [EMAIL PROTECTED] wrote: But we are few, we have day jobs, and we're not being paid for any of this. I'm in the same boat. And I did offer to extend or start writing tests cases to help implementation. I'm not a compiler developer (I don't understand any of it's internals), but I can help implement Unicode enabled string functions. We have a few implementations floating around already. This is so, and is good, but compiler support for a new string type is of a different order... And that is the whole explanation for some features not being there: it's open source, and a hobby project for the core teams. I did not demand the unicode features... I simply stated a shortcoming when I started this thread and asked how I could proceed with a work-around. I am not targeting anyone in particular, definitely not you... But the huge discussion about features in FPC is a bit gratuitous, because as always, many people participate in the discussion, but there are too few that actually help out. Ideas and plans are not the problem. Manpower and time are usually the problem in FPC. Compared to the GCC team or Mono, we're seriously understaffed. 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 woensdag 30-07-2008 om 11:33 uur [tijdzone +0200], schreef Florian Klaempfl: Marco van de Voort schrieb: Read this and the reactions, and weep: http://groups.google.com/group/borland.public.delphi.non-technical/browse_frm/thread/db61d19063a2f948/289008199451755a?lnk=gstq=voort+multicore#289008199451755a I don't agree on the point that good mt support is a matter of the framework. _Really_ good multithreading support is a matter and must be a matter of the language as well and in several years and must be as common as while or for loops. Currently, multithreaded programming is like programming spaghetti basic. A good framework is comparable to at least the try to program structured with line numbered basic but it is not forced by the language. The compiler must know about parallism. I'm not really into paralel-computing. But it does interest me. Just to test some ideas/opinions. Could something like this be usefull? Function DoSomething(const astring : string) : boolean; parallel; begin .. end So that the 'parallel' keywords means that if you call this procedure, it's started in a separate thread. (maybe just a compiler hint, like in inline. So that the compiler can decide) If you actually use the result somewhat further in you program, the compiler detects this and waits for the other thread to finish, before it continous. Ofcourse, of someone uses some globa-vars in an 'parallel' procedure, he could be doomed, if he don't know what he does. But maybe the compiler can even forbid this. Would this be usefull at all? Doable? Joost ___ 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 Wed, 30 Jul 2008, schreef Graeme Geldenhuys: Does FPC have any any functions that work correctly with surrogate pair used by UTF-16? Likely, because I doubt FPC has routines, other than UTF-8 - UTF-16 conversion, that need to bother with surrogate pairs. I.e. the following code is fully correct in an UTF-16 environment: procedure upcase(var s:widestring); var i:longint; begin for i:=1 to length(s) do s[i]:=upcase(s[i]); end; ...because all characters that need upper/lower casing are in the BMP. Likewise, all possible thousand separators are in the BMP, so you don't need to bother with that either. If so, it would same me a lot of time implementing them myself. What would Pos, Length, Copy etc return? This would be the same behaviour as with widestrings. RTL routines are dump, smarter ones should go in sysutils. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[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
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
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
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] 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] 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 fpc-devel@lists.freepascal.org 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
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] 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
