Re: [fpc-devel] libtinfo issue
On Mon, Nov 8, 2010 at 10:32 PM, Joost van der Sluis jo...@cnoc.nl wrote: Hmm... r15671 which fixes this issue, is not merged to the release. So to fix this, you have to apply r15671 from trunk to fpcsrc, before you build the rpm. (I did so for the Fedora rpm's) Just to be sure, the command will be: cd fpcbuild/fpcsrc svn merge -r 15670:15671 http://svn.freepascal.org/svn/fpc/trunk/ Is this correct? thanks, -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Boehm garbage collector for freepascal
But it might be an advantage for some projects as the discussions over the years implied. What about using GC for fpc itself? If it is usable for fpc, then the problem of fpc leaking memory when compilation fails with errors can be solved using GC. As a result fpc can be integrated to some IDEs without a fear or memleaks. Just a thought. Regards Zilvinas Ledas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Boehm garbage collector for freepascal
On 11/18/2010 08:05 AM, Thaddy wrote: To summarize: what you write/propose is already in there :) OK, great, its there, but how to get it _here_ ? To make it useful FPC would need some the appropriate keywords (such as GarbageControlled) for creating this type of variables, and it would need to use them in a double-indirect way (or use a function call into the garbage-control-RTL when creating and dumping these variables to make them known) to allow for the Garbage Collector to do it's work while the program is temporarily stalled. I have rather good initial results with it, even compiling medium/large Freepascal projects with it, f.e. fpGUI and fpGUI designer ;-) :-) Sounds good so far. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: enumerators
On 11/18/2010 12:33 AM, Hans-Peter Diettrich wrote: Separator characters can be assumed as ASCII, so that they can be found by a dumb byte/char scan; only few encodings have to be recognized and handled, based on the char size: MBCS (UTF-8...), WideChars (UTF-16/UCS2) and UTF-32. In fact I suppose that for UTF-8 (pure UTF-8 without surrogates) pos() works for all strings and an UTF-8 character is a string. It's just not allowed to use the result of pos() other than in the position argument of copy() or delete() and to calculate the length argument for copy() or delete() as a difference between pos() results or Length(String)-values. this makes it hard to extract a single Unicode character from an UTF-8 string, but of course it's easy to create a library function that gets a pos() result and - decoding the UTF-8 code - creates an UTF-8 string containing the next Unicode character. (UTF-8 coded surrogate pairs may need additional attention) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: enumerators
In our previous episode, Michael Schnell said: found by a dumb byte/char scan; only few encodings have to be recognized and handled, based on the char size: MBCS (UTF-8...), WideChars (UTF-16/UCS2) and UTF-32. In fact I suppose that for UTF-8 (pure UTF-8 without surrogates) pos() works for all strings and an UTF-8 character is a string. Either you have UTF-8 with surrogates, or you have ASCII (since UTF-8 without surrogates means that only char 0..127 are valid, which is ASCII) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: enumerators
On 11/18/2010 02:31 PM, Marco van de Voort wrote: Either you have UTF-8 with surrogates, or you have ASCII (since UTF-8 without surrogates means that only char 0..127 are valid, which is ASCII) In another post surrogate pairs have been denoted as a specialty of a 16 Bit coding (UCS-2), and I did not understand why this was introduced in a discussion about UTF-8. I just accepted that this somehow would leak into UTF-8 as a special (alternate) way to code certain Unicode characters. I did not think about calling the up to four bytes of a normal UTF-8 character surrogates (to me these are codes or something like this). Sorry if I introduced any confusion. :( -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: enumerators
In our previous episode, Michael Schnell said: Either you have UTF-8 with surrogates, or you have ASCII (since UTF-8 without surrogates means that only char 0..127 are valid, which is ASCII) In another post surrogate pairs have been denoted as a specialty of a 16 Bit coding (UCS-2), and I did not understand why this was introduced in a discussion about UTF-8. I just accepted that this somehow would leak into UTF-8 as a special (alternate) way to code certain Unicode characters. Surrogates are characters that can't be encoded in one encoding space. About 4 chars can be encoded in a 16-bit value in UTF16, and 127 in 8-bit UTF8. The rest must be encoded in multiple encoding spaces, and these are called surrogates. I did not think about calling the up to four bytes of a normal UTF-8 character surrogates (to me these are codes or something like this). Anything larger than 1 is surrogate in UTF-8. And since UTF-8 uses a bit to signal a larger character, you end up with low ASCII 0..127 values. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Use widesting as default?
Hi all, I'm converting a Delphi 2009 project to FPC. In this project all strings are widestrings, which is default for Delphi 2009. However, in FPC all strings are still 'normal' strings. Is there a way (compiler switch?) to use widestring as default for all strings in FPC? Kind regards, Birger Jansen (I'm not sure if this message should go here or to Lazarus list since it is not entirely clear to me if strings belong to FPC or Lazarus. Forgive me if this is the wrong list!) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Use widesting as default?
18.11.2010 21:12, Birger Jansen wrote: Hi all, I'm converting a Delphi 2009 project to FPC. In this project all strings are widestrings, which is default for Delphi 2009. However, in FPC all strings are still 'normal' strings. Is there a way (compiler switch?) to use widestring as default for all strings in FPC? Yes. Checkout cpstrnew branch and complete missing things. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Use widesting as default?
On 18 Nov 2010, at 15:12, Birger Jansen wrote: I'm converting a Delphi 2009 project to FPC. In this project all strings are widestrings, which is default for Delphi 2009. However, in FPC all strings are still 'normal' strings. Is there a way (compiler switch?) to use widestring as default for all strings in FPC? Strings belong to FPC, so this is the right list (fpc-pascal would be slightly more appropriate, but that doesn't matter). That said, FPC does not have such an option at this time. Keep in mind that Delphi 2009's default string type is much more than a regular widestring. Using unicodestring instead in FPC would be more correct, but even then you won't have the same support yet (that first requires the completion of the cpstrnew branch, as Paul indicated). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Boehm garbage collector for freepascal
On 18-11-2010 13:21, Z(ilvinas Ledas wrote: But it might be an advantage for some projects as the discussions over the years implied. What about using GC for fpc itself? If it is usable for fpc, then the problem of fpc leaking memory when compilation fails with errors can be solved using GC. As a result fpc can be integrated to some IDEs without a fear or memleaks. Just a thought. Regards Zilvinas Ledas It is not a very good idea to use a GC as a means to catch mistakes made by a programmer. These kind of mistakes can still cause memory resource related problems or violations. That's not why I (re)wrote my GC interface unit (again) anyway. But, there is no reason why it shouldn't work. The Lazarus IDE for example is a different proposal and more difficult to implement: You have to get rid of the suballocator mm to have it working properly and efficently (The Lazarus IDE uses a memory manager on top, not in place, of the default memory manager.) At least the Boehm GC would have a performance penalty in this case (large blocks) - being the lower level one -, but the reason it - the sub allocator - is there is because of performance in the first place and I would not be surprised at all if the Boehm GC would perform equal or better after the removal of this sub allocator. Regards, Thaddy ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Native Datatypes
Hi, There could be native Datatypes, that means data types that are compiled into fastest code by compiler (without size casting). An example is the PtrInt, but there should a more intuirive naming: - BestInt (integer in system size) - BestFloat (float that is calculated fastest) - BestString (String performed fastest on this architecture) That would allow programmers to write efficient code without breaking old pascals datatype bandwith. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Use widesting as default?
Keep in mind that Delphi 2009's default string type is much more than a regular widestring. Using unicodestring instead in FPC would be more correct, but even then you won't have the same support yet (that first requires the completion of the cpstrnew branch, as Paul indicated). Thanks for the answer, Paul and Jonas. I'll check how cpstrnew works for me. Although I'm not sure if I have enough knowledge to actually contribute something in these deeper parts of the FPC-dungeon, I will report my findings. Kind regards, Birger Jansen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
