Re: [fpc-devel] (no subject)
Interesting switch in FPC 2.1.1: -Skload fpcylix unit what is it for? Afaik it implicitely USES the fpcylix unit that contains some identifiers for Kylix compat that we _really_ didn't want in the normal system/sysutils unit. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] (no subject)
Marco van de Voort wrote: Interesting switch in FPC 2.1.1: -Skload fpcylix unit what is it for? Afaik it implicitely USES the fpcylix unit that contains some identifiers for Kylix compat that we _really_ didn't want in the normal system/sysutils unit. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel where can i find it ? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] (no subject)
Interesting switch in FPC 2.1.1: -Skload fpcylix unit what is it for? Afaik it implicitely USES the fpcylix unit that contains some identifiers for Kylix compat that we _really_ didn't want in the normal system/sysutils unit. where can i find it ? ~/fpc find . -name 'fpcylix.pp' ./rtl/linux/fpcylix.pp ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] (no subject)
[EMAIL PROTECTED] wrote: Marco van de Voort wrote: Interesting switch in FPC 2.1.1: -Skload fpcylix unit what is it for? Afaik it implicitely USES the fpcylix unit that contains some identifiers for Kylix compat that we _really_ didn't want in the normal system/sysutils unit. where can i find it ? http://svn.freepascal.org/svn/fpc/trunk/rtl/linux/fpcylix.pp Vincent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] (no subject)
Marco van de Voort wrote: Interesting switch in FPC 2.1.1: -Skload fpcylix unit what is it for? Afaik it implicitely USES the fpcylix unit that contains some identifiers for Kylix compat that we _really_ didn't want in the normal system/sysutils unit. BTW, looking at the current implementation - shouldn't GetModuleName be changed to return name part of ParamStr (0) (without path and extension), and GetModuleFileName the complete ParamStr (0)? Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] (no subject)
Tomas Hajny wrote: Marco van de Voort wrote: Interesting switch in FPC 2.1.1: -Skload fpcylix unit what is it for? Afaik it implicitely USES the fpcylix unit that contains some identifiers for Kylix compat that we _really_ didn't want in the normal system/sysutils unit. BTW, looking at the current implementation - shouldn't GetModuleName be changed to return name part of ParamStr (0) (without path and extension), and GetModuleFileName the complete ParamStr (0)? No, the situation is more complex, that's not implemented yet. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
Hi! I've been following the generic discussion with great interest. Here are some of my thoughts. Florian Klaempfl wrote: - we'll use a syntax as close as possible to Chrome, e.g. type TListT = class ... end; I greatly favor this syntaxis above the generic-modifier. It will look at a lot more familiar to most programmers (due to e.g. C++ and Java), is more compact and moreover likely to be compatible with other implementations (Chrome, rumors about Delphi 11). I assume this also means that the generic type identifier has to be included in the method implementation, e.g. TListT.Add(AValue: T); begin ... end; This would also allow overloading of generics, i.e. having (generic) classes with different numbers of type parameters, but the same name. E.g. having both a TList and a TListT. (though a declaration like TList = TListpointer could easily solve this in this case) How will we deal with restrictions on the type of a generic parameter? Chrome does this with for example DictionaryKey, Value = public class where Key is IComparable, Key has constructor, Value is Component; And will it be possible to have type dependent specializations? E.g. TListT.Add(AValue: T); ... TListT: TObject.Add(AValue: T); ... This can allow for efficient implementations for certain specific types while using the same name. Though it more or less violates the write-once advantage of generics, efficiency and type name uniformity is still available I think. - instantiation will be only possible in declaration blocks, not in code blocks: possible: var mylist : TListinteger; const mylist : TListinteger = nil; type mylist = TListinteger; forbidden: procedure p(mylist : TListinteger); begin ... mylist:=TListinteger.create; ... end; This seems like a smart and sufficient solution to avoid the problem of parsing tokens in code blocks. On the other hand, programmers will like it (a lot) more if they don't need to separately define a type for every generic instantiation. Is the token-lookahead approach proposed elsewhere in this thread not a sufficient solution? If it is not very easy, or if we are quite unsure about this for now, perhaps we can postpone the implementation of in-code(block) generic instantiation to a later time and first implement generics as above. Maybe we need an exception to this when supporting sub routine templates: procedureT p(mylist : TListT); begin ... end; but this doesn't lead to an ambigious syntax. Because you can easily decide that a T following a in the code is a generic parameter? (I assume you also allow TListT.Create in the code block ... above?) - instantiation steps which require code generation are done after main program compilation based on information saved in the unit files, this has some advantages: - several equal instantiations require only one specialisation So TListTSomeNiceObkect and TListTSomeOtherNiceObject share the same code if nothing particular of the types TSomeNiceObject and TSomeOtherNiceObject is used in the generic? That is indeed quite important I think. Container classes often do not assume anything about the class they store, and otherwise we would get a lot of duplicate code in the resulting executables (for all different classes, which in fact all are 4 (or 8) byte pointers). - it's possible to setup an symbol environment as it has been used in the template definition, so the cyclic unit use problem is void it requires though that a lot symbols of the implementation part of a unit must be written to the unit file if the unit contains a template definition Will a generic implementation have access to procedures visible at the location where the generic is instantiated? It might seem at first to be a useful restriction to disallow this, because otherwise a TListTMyType in unit1 could need another specialisation than TListMyType in unit2. But on the other hand, we might just want to allow it! Example: In the (imaginary) unit containers there might be a TSortedListT class, which uses the operator on T. In yourunit you define a type TYourType and an operator operating on TYourType. If you now want use TSortedListTYourType in yourunit, it will need to pick up the operator defined in yourunit, which is not visible in the unit containers. Similar questions might arise with respect to code for Hashing a specific type for e.g. THashMapKey, Value. Possible solutions appearing in my mind are that (1) a user has to write a function Hash(O: TYourType):integer; for every TYourType, or (2) adding Hash to TObject (like in Java) or to some class of interface (e.g. IHashable), where we need to be able to impose certain conditions on the generic parameters's types as in Chrome (see above). Note: Java has the Comparable interface and does not allow overloading of operators like iirc (but C++ does of course). Regards, Bram ___ fpc-devel maillist -
Re: [fpc-devel] Templates / Generics
- instantiation will be only possible in declaration blocks, not in code blocks: possible: var mylist : TListinteger; const mylist : TListinteger = nil; type mylist = TListinteger; forbidden: procedure p(mylist : TListinteger); begin ... mylist:=TListinteger.create; ... end; This seems like a smart and sufficient solution to avoid the problem of parsing tokens in code blocks. On the other hand, programmers will like it (a lot) more if they don't need to separately define a type for every generic instantiation. Is the token-lookahead approach proposed elsewhere in this thread not a sufficient solution? If it is not very easy, or if we are quite unsure about this for now, perhaps we can postpone the implementation of in-code(block) generic instantiation to a later time and first implement generics as above. The token-lookahead is a hack and will create more problems and performance loss in a critical part of the compiler. The restriction of type blocks only is not strange at all, Delphi allows 'class of' is also only in type blocks ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: Thread REVERT (Ales Katona)
From: Ales Katona [EMAIL PROTECTED] What about simply disabling such -Ct compiler switch (with nice error message) under Windows ? Or maybe it should do nothing under Windows ? I have no idea how -Ct works. It seems there are also report(by Pavel to be more precise) that -Ct causes problems with threads in Linux too(Pavel uses his own thread manager so who knows..). Unless someone can explain to me how the stack checker knows the right size of stack it should be a rule to turn it off with threads. I'm actualy not sure wether -Ct works ok as-is. Ales Unfortunately the stack checker doesn't know the right size of the stack (yet; due to similar problems I am working on that at atm). It assumes that the stack is of fixed size, stored in the global stacklen (or so) variable. When stack checking is enabled, the compiler generates some extra code in the function prolog which checks whether the current stack pointer, decreased by the amount of stack space this method requires and some safety margin, is below the bottom of the stack (a value calculated at program start from the initial stack pointer, and the stacklen contents). If this is the case, it gives a RTE 202. Problems with that: * the __stacklen variable is a predetermined (at compile time) fixed value * the safety margin is quite high, e.g. 16k, which immediately RTEs in threads, because their default stack size is quite low (= 16k...). I hope this answers your question. Regards, Thomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
Peter Vreman wrote: The token-lookahead is a hack and will create more problems and performance loss in a critical part of the compiler. The restriction of type blocks only is not strange at all, Delphi allows 'class of' is also only in type blocks Ok, I didn't know it would be a real ugly hack. And you are right about the 'class of'. It is in fact very similar, as we can extend the conventions regarding naming as follows: type TMyObject = class ... end; TMyObjectClass = class of TMyObject; TMyObjectList = TListTMyObject; TMyObjectSet = TSetTMyObject; TStringMyObjectMap = TMapstring, TMyObject; etc. One more question: If I understand it correctly, the parser uses a recursive top-down recursive descent approach and not a bottom-up approach like the LALR parsers generated by the pyacc tool? Bram ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
Micha Nelissen wrote: Bram Kuijvenhoven wrote: Florian Klaempfl wrote: - we'll use a syntax as close as possible to Chrome, e.g. type TListT = class ... end; I greatly favor this syntaxis above the generic-modifier. It will look at a lot more familiar to most programmers (due to e.g. C++ and Java), Must look familiar programmers should be fired. Of course, the implementation of generics in Pascal should not depend solely on how it is implemented in other languages. I should in the first place fit into Pascal. Does for generics fit into Pascal? Well, we use [] for array indexing, and () for parameter passing to procedures/functions/methods. So why not use for passing parameters to generic types? And, similar to the case of function calls and array indexing, these could follow the type identifier directly. The only objection might be the ambiguity with the operator. From that perspective, a solution like generic(T) might seem nice. But a solution for that was already proposed: only allow the use of in declaration blocks, not in code. Also, I wouldn't particularly consider genericness a modifier (but like parameters). Of course it is hard to discuss about matters of taste. Perhaps a poll might help us out here. Anyway, I think that seeking some syntactical familiarity (when other considerations more or less tie) isn't neccesarily bad. Consider for example the following: Is Java bad because it looks like C++? Or is PHP bad because is looks like C++? I think it is even advantageous for programmers these languages have a similar syntaxis. Just as + means addition in most programming languages, is used for generics as far as I know in most languages supporting generics. I think if other considerations tie, we should therefore choose for as well. I think this will at least add to popularity and also reduce RSI ;) Regards, Bram ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Thread REVERT (Ales Katona)
Thomas Schatzl wrote: From: Ales Katona [EMAIL PROTECTED] What about simply disabling such -Ct compiler switch (with nice error message) under Windows ? Or maybe it should do nothing under Windows ? I have no idea how -Ct works. It seems there are also report(by Pavel to be more precise) that -Ct causes problems with threads in Linux too(Pavel uses his own thread manager so who knows..). Unless someone can explain to me how the stack checker knows the right size of stack it should be a rule to turn it off with threads. I'm actualy not sure wether -Ct works ok as-is. Ales Unfortunately the stack checker doesn't know the right size of the stack (yet; due to similar problems I am working on that at atm). It assumes that the stack is of fixed size, stored in the global stacklen (or so) variable. When stack checking is enabled, the compiler generates some extra code in the function prolog which checks whether the current stack pointer, decreased by the amount of stack space this method requires and some safety margin, is below the bottom of the stack (a value calculated at program start from the initial stack pointer, and the stacklen contents). If this is the case, it gives a RTE 202. Problems with that: * the __stacklen variable is a predetermined (at compile time) fixed value * the safety margin is quite high, e.g. 16k, which immediately RTEs in threads, because their default stack size is quite low (= 16k...). I hope this answers your question. Regards, Thomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Thanks, yes it does and it also is a valid point to turn it off with threads. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
On Mon, 07 Nov 2005 14:45:19 +0100 Bram Kuijvenhoven [EMAIL PROTECTED] wrote: Does for generics fit into Pascal? Well, we use [] for array indexing, and () for parameter passing to procedures/functions/methods. So why not use for passing parameters to generic types? And, similar to the case of function calls and array indexing, these could follow the type identifier directly. You got a point here, but the where T is Foo stuff is crap then, don't you agree? TGTypeT: TBaseType = class(...) ... end; is better then, when compared to your parameter example. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] (no subject)
Marco van de Voort wrote: Afaik it implicitely USES the fpcylix unit that contains some identifiers for Kylix compat that we _really_ didn't want in the normal system/sysutils unit. Is FPC able to compile Kylix forms (*.xfm) now? Forms are something of a higher level than FPC. They are compiled by an (external) resourcecompiler and then stored as a resource in a file. However for CrossFPC's sake, resourcehandling has been made more compatible, but I assume one still needs a resourcecompiler for this. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
Micha Nelissen wrote: On Mon, 07 Nov 2005 14:45:19 +0100 Bram Kuijvenhoven [EMAIL PROTECTED] wrote: Does for generics fit into Pascal? Well, we use [] for array indexing, and () for parameter passing to procedures/functions/methods. So why not use for passing parameters to generic types? And, similar to the case of function calls and array indexing, these could follow the type identifier directly. You got a point here, but the where T is Foo stuff is crap then, don't you agree? TGTypeT: TBaseType = class(...) ... end; is better then, when compared to your parameter example. I indeed don't like the where T is foo of Chrome :) So you are totally right, TGTypeT : TBaseType is a lot better and a lot more consistent (with e.g. function parameter syntaxis). Bram ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
On Mon, 07 Nov 2005 19:29:51 +0100 Bram Kuijvenhoven [EMAIL PROTECTED] wrote: Micha Nelissen wrote: On Mon, 07 Nov 2005 14:45:19 +0100 Bram Kuijvenhoven [EMAIL PROTECTED] wrote: Does for generics fit into Pascal? Well, we use [] for array indexing, and () for parameter passing to procedures/functions/methods. So why not use for passing parameters to generic types? And, similar to the case of function calls and array indexing, these could follow the type identifier directly. You got a point here, but the where T is Foo stuff is crap then, don't you agree? TGTypeT: TBaseType = class(...) ... end; is better then, when compared to your parameter example. I indeed don't like the where T is foo of Chrome :) So you are totally right, TGTypeT : TBaseType is a lot better and a lot more consistent (with e.g. function parameter syntaxis). Let's sum up the different points for the syntax so far: - will probably be used by Delphi - bites the operator - makes the parser more difficult and slow - makes pascal more ambigious - alternatives: modifiers or not yet used brackets like (! !) or (# #) It seems to me, it's a question of: Follow Delphi generics or not. And we don't know, where Delphi will go. They will not have generics in the next one and a half year and as always: They will do a few things completely different than expected. If we follow, then we will do, as Florian et al said. If not, then the is not the best solution. Is this correct so far? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] (no subject)
On Mon, 7 Nov 2005 [EMAIL PROTECTED] wrote: Marco van de Voort wrote: Interesting switch in FPC 2.1.1: -Skload fpcylix unit what is it for? Afaik it implicitely USES the fpcylix unit that contains some identifiers for Kylix compat that we _really_ didn't want in the normal system/sysutils unit. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Is FPC able to compile Kylix forms (*.xfm) now? Yes, using an external resource compiler. It will embed .xfm, .dfm and .res files. But you'll still need an .rc - .res compiler for icons, bitmaps etc. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] (no subject)
Michael Van Canneyt wrote: On Mon, 7 Nov 2005 [EMAIL PROTECTED] wrote: Marco van de Voort wrote: Interesting switch in FPC 2.1.1: -Skload fpcylix unit what is it for? Afaik it implicitely USES the fpcylix unit that contains some identifiers for Kylix compat that we _really_ didn't want in the normal system/sysutils unit. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Is FPC able to compile Kylix forms (*.xfm) now? Yes, using an external resource compiler. It will embed .xfm, .dfm and .res files. But you'll still need an .rc - .res compiler for icons, bitmaps etc. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Is it automated in CrossFCP? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
Marc Weustink wrote: Bram Kuijvenhoven wrote: Micha Nelissen wrote: Bram Kuijvenhoven wrote: Florian Klaempfl wrote: - we'll use a syntax as close as possible to Chrome, e.g. type TListT = class ... end; I greatly favor this syntaxis above the generic-modifier. It will look at a lot more familiar to most programmers (due to e.g. C++ and Java), Must look familiar programmers should be fired. Of course, the implementation of generics in Pascal should not depend solely on how it is implemented in other languages. I should in the first place fit into Pascal. Since it is already decided that it would be I didn't mix into the discussion anymore. However, I'll make a comment on this. Does for generics fit into Pascal? Well, we use [] for array indexing, and () for parameter passing to procedures/functions/methods. So why not use for passing parameters to generic types? And, similar to the case of function calls and array indexing, these could follow the type identifier directly. Params are passed to a procedure define like procedure MyProc(param, param, ..) Arrays are declared like A: array[0..9] of ... And generics they are soly defined by the fact that a type has in it. That is imo inconsequent. Marc I aggree. Why not use new keywords 'template', 'generic', like the current 'array' or record'? That would make the code more readable, and remove ambiguity problems. It won't cost much, compared to the total size of a template. It's also more pascal-like, as opposed to C, where e. g. a pointer is denoted with '*' and, at the same time, identifies an array etc. (sorry if this is out of time or had already been discussed - I just entered this thread here). Anton ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
On Mon, 07 Nov 2005 22:41:06 +0100 Florian Klaempfl [EMAIL PROTECTED] wrote: Mattias Gaertner wrote: On Mon, 07 Nov 2005 19:29:51 +0100 Bram Kuijvenhoven [EMAIL PROTECTED] wrote: Micha Nelissen wrote: On Mon, 07 Nov 2005 14:45:19 +0100 Bram Kuijvenhoven [EMAIL PROTECTED] wrote: Does for generics fit into Pascal? Well, we use [] for array indexing, and () for parameter passing to procedures/functions/methods. So why not use for passing parameters to generic types? And, similar to the case of function calls and array indexing, these could follow the type identifier directly. You got a point here, but the where T is Foo stuff is crap then, don't you agree? TGTypeT: TBaseType = class(...) ... end; is better then, when compared to your parameter example. I indeed don't like the where T is foo of Chrome :) So you are totally right, TGTypeT : TBaseType is a lot better and a lot more consistent (with e.g. function parameter syntaxis). Let's sum up the different points for the syntax so far: - will probably be used by Delphi - bites the operator No, as I said, we should allow template instantiation only in type blocks. type TMyType = boolean(ab)..(ab); :) - makes the parser more difficult and slow See above. - makes pascal more ambigious See above. - alternatives: modifiers or not yet used brackets like (! !) or (# #) Ugly :) Sure. But some people like emoticons. !) It seems to me, it's a question of: Follow Delphi generics or not. And we don't know, where Delphi will go. They will not have generics in the next one and a half year and as always: They will do a few things completely different than expected. If we follow, then we will do, as Florian et al said. If not, then the is not the best solution. Is this correct so far? Ok. So, FPC will follow chrome/Delphi? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
Mattias Gaertner wrote: On Mon, 07 Nov 2005 23:06:37 +0100 Florian Klaempfl [EMAIL PROTECTED] wrote: Ok. So, FPC will follow chrome/Delphi? I would do so, see my mail from the weekend :) I see, but also I see all the other posts still discussing the syntax. I wondered, if it was definitive. I didn't know there was already decided on the syntaxis. So that's why I wrote about it in my mail. And from there the discussion started again (I think). So I will stop discussing it and wait for the first generic-capable compiler version :) (it is definitely true that the syntax isn't the hardest part of the implementation!) Bram ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
Peter Vreman wrote: The token-lookahead is a hack and will create more problems and performance loss in a critical part of the compiler. The restriction of type blocks only is not strange at all, Delphi allows 'class of' is also only in type blocks Ok, I didn't know it would be a real ugly hack. And you are right about the 'class of'. It is in fact very similar, as we can extend the conventions regarding naming as follows: type TMyObject = class ... end; TMyObjectClass = class of TMyObject; TMyObjectList = TListTMyObject; TMyObjectSet = TSetTMyObject; TStringMyObjectMap = TMapstring, TMyObject; etc. One more question: If I understand it correctly, the parser uses a recursive top-down recursive descent approach and not a bottom-up approach like the LALR parsers generated by the pyacc tool? Bram ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
Florian Klaempfl [EMAIL PROTECTED] wrote: Is this correct so far? Ok. So, FPC will follow chrome/Delphi? Afaik there is no need to. Chrome is as relevant as C++, since it is a different language, and Delphi implements .NET stuff, and maybe provides a backwards compat kludge for win32 at best. For us, native is the core platform, and how they twist themselves to achieve compat between .NET and win32 (and how much .NET syntax they borrow) is not our problem. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
