Re: [fpc-pascal] FSplit is deprecated
In our previous episode, Bernd said: > > So use functions from 2.0.x like sysutils.extract* > > Found it, thank you. > > I was a little bit impatient yesterday, I should have searched a > little longer on my own. > > Due to the extraordinarily high quality of FPC and Lazarus I have > begun to take absolute perfection for granted and when I then > accidentally stumble over one little trivial imperfection (every 6 > months or so) while I am in a hurry (always) it irritates me sometimes > ;-) Free Pascal has history. Nowadays the dos <-> sysutils split is not as bad anymore, except for Turbo Vision code. But having two sets of everything is not ideal. Unixutil is a bit doubtful unit. It should be cleaned out, but some functions can't move to their logical place (e.g. sysutils) because they are used in units much lower in the hierarchy. (in units that are used to implement units that are used to implement sysutils). So fully eliminating it is hard. Anyway, I started making notes about any deprecated functionality that has been deprecated long, and will try to clean some of it out with 2.8.0. I already started with cleansing the unix unit a bit in 2.7.1 (which has routines deprecated since april 2007) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicodestrings and Assign(File)
> Given that, it doesn't really make sense to use the *A versions at all
> in Windows (Unless you want to support very old Windows versions).
> Thus the approach for Windows should be the opposite of Unix, I suppose.
> UTF8 or ANSI gets converted to UTF16 and call the *W functions.
That's true. In general the data type with the most information
(UnicodeString
in this case) should be used as much as possible and only when functions
require other (lower) data types a conversion should be done.
Otherwise Information gets lost.
> I have the same time problem, but I will take a look at the source code,
> I don't think it should be very difficult to figure out.
I had a look at the sources and found the following
(it's a bit longer, so if you are not interested just stop reading ;-)):
1.) The 2 fundamental file types filerec and textrec (for standard files and
text files) are defined in
fpc\fpc\rtl\inc\filerec.inc and
fpc\fpc\rtl\inc\textrec.inc
Both differ only by some buffer structures at the end but share the
first part
(including file name). The file name is of type
array[0..255] of char;
and needs to be replaced by UnicodeString.
This requires other changes:
1.) The order of elements in the file data structures have to be changed.
The name has to become the first element as in:
---
TextRec = Packed Record
name : UnicodeString;
Handle: THandle; // Handle has to be directly after
name, see Assign!
Mode : longint;
bufsize : SizeInt;
_private : SizeInt;
bufpos,
bufend: SizeInt;
bufptr: ^textbuf;
openfunc,
inoutfunc,
flushfunc,
closefunc : pointer;
UserData : array[1..32] of byte;
LineEnd : TLineEndStr;
buffer: textbuf;
{$ifdef FPC_HAS_CPSTRING}
CodePage : TSystemCodePage;
{$endif}
End;
---
Reason: See next item 2.)
2.) The Assign routine in \fpc\rtl\inc\file.inc overwrites the
whole file data structure with zeros (using fillchar). The
name has to be omitted from this action because it is now
managed automatically. So Assign needs to be changed to:
---
Procedure Assign(out f:File;const NewName:string);
{ Assign Name to file f so it can be used with the file routines }
Begin // Assign
FillChar(FileRec(f).Handle,SizeOf(FileRec)-Sizeof(FileRec(f).name),0);
FileRec(f).Handle := UnusedHandle;
FileRec(f).mode := fmClosed;
FileRec(f).Name := NewName;
End; // Assign
---
3.) The routine do_open in \fpc\rtl\win\sysfile.inc has to be
changed at 3 lines to (see "// THIS LINE CHANGED!")
---
procedure do_open(var f; p:UnicodeString; flags:longint); //
THIS LINE CHANGED!
{ filerec and textrec have both handle and mode as the first items so
they could use the same routine for opening/creating.
when (flags and $100) the file will be append
when (flags and $1000) the file will be truncate/rewritten
when (flags and $1) there is no check for close (needed for
textfiles) }
Const file_Share_Read = $0001;
file_Share_Write = $0002;
file_Share_Delete = $0004;
Var shflags,
oflags,cd : longint;
security : TSecurityAttributes;
begin // do_open
DoDirSeparators(p);
{ close first if opened }
if ((flags and $1)=0) then
begin
case filerec(f).mode of
fminput,fmoutput,fminout :
Do_Close(filerec(f).handle);
fmclosed : ;
else {not assigned}
inoutres:=102;
exit;
end; // of case
end;
{ reset file handle }
filerec(f).handle := UnusedHandle;
{ convert filesharing }
shflags := 0;
if ((filemode and fmshareExclusive)=fmshareExclusive) then { no sharing }
else
if (filemode=fmShareCompat) or ((filemode and
fmshareDenyWrite)=fmshareDenyWrite) then
shflags := file_Share_Read
else
if ((filemode and fmshareDenyRead)=fmshareDenyRead) then
shflags := file_Share_Write
else
if ((filemode and fmshareDenyNone)=fmshareDenyNone) then
shflags := {$ifdef WINCE}
{ WinCE does not know file_share_delete }
file_Share_Read or file_Share_Write;
{$else WINCE}
fmShareDenyNoneFlags;
{$endif WINCE}
{ convert filemode to filerec modes }
case (flags and 3) of
0 : begin
filerec(f).mode := fminput;
oflags := longint(GENERIC_READ);
end;
1 : begin
filerec(f).mode := fmoutput;
oflags := longint(GENERIC_WRITE);
end;
2 : begin
filerec(f).mod
Re: [fpc-pascal] Extend multiple classes with same code
On Sat, May 19, 2012 at 2:10 AM, Jorge Aldo G. de F. Junior < jagf...@gmail.com> wrote: > You simply cant do it. Not even multiple inheritance would help you in > this case. > > You will have to extend each class by hand. > > Multiple inheritance would allow you to join back branches in the > class hierarchy, but in this case you want to add the same > functionality to multiple branches, but keep the branches separate > entities. This is impossible with current freepascal OOP and i dont > think this is even a good thing to have. > > I have no Idea about "multiple inheritance". I am thinking now if i can assign a helper to more than one class by make base helper, then inherit it for every class B1 and B2. I will try and post a feedback. > It could be done multi-class helper, kind of class helper that works > on multiple classes. But i dont even know of a language that has such > possibility (i dont know much languages anyway). > I hope i can find one, not for me for my kids in the future ;) Best Regards Zaher Dirkey ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicodestrings and Assign(File)
On 19.05.2012 13:12, Jürgen Hestermann wrote: 3.) Of course, there are lots of places where the file data structures filerec and textrec are used in the code. But in most cases only non-changed record elements are used (so no changes are required) and only seldomly the name is used/changed or the whole data structure is modified. So I think the above modifications require to check a lot of code but only a few modifications (hopefully). I would be willing to do these changes but I am not sure whether I have overlooked something obvious. These are very fundamental changes which affect all operating systems so it may have unexpected side affects. I also need to get familiar with SVN. While I can not comment on the changes you listed (though they sound more or less valid) I can comment on those you didn't list: If you change do_open to support Unicode you should do this for the other functions (e.g. write, read) as well so that only the *W functions are used for them. Also you need to keep in mind that do_open is used by platform independant code so you would need to change the declarations/handling for all other platforms as well. Also you need to change the declaration of Assign as this expects a Short-/AnsiString. Also I don't know whether the Unix users would be happy if we'd push UnicodeString upon them or whether they'd prefer AnsiString(CP_UTF8). In the end maybe it should be AnsiString(CP_UTF8) for Unix systems and UnicodeString for Windows systems and AnsiString(CP_SCP) (the current string) for the other systems, so especially the platform independant code needs to be adjusted to support all three cases without problems (which might not need that much work in the end...). I hope other core developers comment on this as well, as I'm not so firm regarding the consequences of such changes... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Extend multiple classes with same code
On 19.05.2012 16:28, Zaher Dirkey wrote: On Sat, May 19, 2012 at 2:10 AM, Jorge Aldo G. de F. Junior mailto:jagf...@gmail.com>> wrote: You simply cant do it. Not even multiple inheritance would help you in this case. You will have to extend each class by hand. Multiple inheritance would allow you to join back branches in the class hierarchy, but in this case you want to add the same functionality to multiple branches, but keep the branches separate entities. This is impossible with current freepascal OOP and i dont think this is even a good thing to have. I have no Idea about "multiple inheritance". I am thinking now if i can assign a helper to more than one class by make base helper, then inherit it for every class B1 and B2. I will try and post a feedback. Yes, you can do that basically: type T_AHelper = class helper for T_A end; T_B1Helper = class helper(T_AHelper) for T_B1 end; T_B2Helper = class helper(T_AHelper) for T_B2 end; Please not that the extended classes (in this case T_B1 and T_B2) need to inherited from T_A, otherwise the compiler will complain. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicodestrings and Assign(File)
In our previous episode, Sven Barth said: > While I can not comment on the changes you listed (though they sound > more or less valid) I'm not sure if the *rec records can handle pointers, one probably can't use reference types in them, because the standard filedescriptions are threadvars. Think what happens if those are simply "cloned". > I can comment on those you didn't list: If you > change do_open to support Unicode you should do this for the other > functions (e.g. write, read) as well so that only the *W functions are > used for them. Also you need to keep in mind that do_open is used by > platform independant code so you would need to change the > declarations/handling for all other platforms as well. Also you need to > change the declaration of Assign as this expects a Short-/AnsiString. > Also I don't know whether the Unix users would be happy if we'd push > UnicodeString upon them or whether they'd prefer AnsiString(CP_UTF8). Probably they will be rawbytestring, so both can be passed to it, and the per platform code must then change it to whatever encoding (ansi,utf8,utf16) the API expects. > In the end maybe it should be AnsiString(CP_UTF8) for Unix systems and > UnicodeString for Windows systems and AnsiString(CP_SCP) (the current > string) for the other systems, so especially the platform independant > code needs to be adjusted to support all three cases without problems > (which might not need that much work in the end...). I'm not sure that is true even without the above remark. I would say for *nix it just remains "ansistring", the default 1-byte encoding. This fixes the case where e.g. embedded Linux doesn't expect utf8, which could otherwise have undesirable effects. Note that the default encoding can be the same as utf8. (and probably will be on desktop unix) > I hope other core developers comment on this as well, as I'm not so firm > regarding the consequences of such changes... There are some interesting discussions on various lists you might want to read :-) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicodestrings and Assign(File)
Sven Barth schrieb: > If you change do_open to support Unicode you should do this for the other functions (e.g. write, > read) as well so that only the *W functions are used for them. I think read/write only work on the file handle and don't use the file name. So no changes are needed here (I think). But of course there are other functions that need changing, for example Assign Reset Rewrite FindFirst(File) Rename some others. > Also you need to keep in mind that do_open is used by platform independant code > so you would need to change the declarations/handling for all other platforms as well. Yes. It can be a can of worms. ;-) Although, as said: Only very few functions realy act on the file name. Most use the file handle only (which will not change). > Also you need to change the declaration of Assign as this expects a Short-/AnsiString. I think it should be declared as "UnicodeString" or "String" so that other string types that are handed over are converted automatically. > Also I don't know whether the Unix users would be happy if we'd push UnicodeString upon them or whether they'd prefer AnsiString(CP_UTF8). Yes, this is a general question: What kind of string type should be used within Free Pascal mainly? I am not sure how this is all affected by http://wiki.freepascal.org/FPC_Unicode_support#Roadmap_of_RTL_Unicode_support_with_UnicodeString > In the end maybe it should be AnsiString(CP_UTF8) for Unix systems and UnicodeString > for Windows systems and AnsiString(CP_SCP) (the current string) for the other systems, > so especially the platform independant code needs to be adjusted to support all three > cases without problems (which might not need that much work in the end...). As far as I know currently all platforms share the same filerec/textrec definitions (which is an array of bytes now). If that is changed then it would be changed for all platforms. But it can be changed to generic string type too. I am not so sure what this actually means when the type differs from one platform to the other. For example, I have to use a "pointer to widestring" for CreateFileW for Windows. So I need to convert to a null terminated widestring from the existing string type and this conversion must work under all circumstances. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicodestrings and Assign(File)
On Sat, May 19, 2012 13:12, JĂźrgen Hestermann wrote: . . > 1.) The 2 fundamental file types filerec and textrec (for standard files > and > text files) are defined in > fpc\fpc\rtl\inc\filerec.inc and > fpc\fpc\rtl\inc\textrec.inc > Both differ only by some buffer structures at the end but share the > first part > (including file name). The file name is of type > > array[0..255] of char; > > and needs to be replaced by UnicodeString. > This requires other changes: > > > 1.) The order of elements in the file data structures have to be changed. I don't know what's the order used by Delphi (assuming that file and text as basic Pascal constructs are still supported there), but it's certainly better not to change the order of the attributes at the beginning; changing the call to FillChar is no problem. Also, it may be better keeping the current field for 8-bit name and add the UnicodeString as a new field instead in order not to require encoding between 8-bit charsets and UnicodeString on platforms not having UnicodeString support. Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicodestrings and Assign(File)
Marco van de Voort schrieb: > I'm not sure if the *rec records can handle pointers, one probably can't use > reference types in them, because the standard filedescriptions are > threadvars. > Think what happens if those are simply "cloned". Of course, all "cloning" needs to be changed too so that the name pointer is not cloned (but assigned in a standard way). The alternative would be to reserve a 64k buffer for the file name in the *rec structures. I am not sure whether this is intended and useful. And in 10 or 20 years this limit is breached again and another change is necessary. Double work IMO. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicodestrings and Assign(File)
On 19.05.2012 17:36, Marco van de Voort wrote: In our previous episode, Sven Barth said: While I can not comment on the changes you listed (though they sound more or less valid) I'm not sure if the *rec records can handle pointers, one probably can't use reference types in them, because the standard filedescriptions are threadvars. Think what happens if those are simply "cloned". Why shouldn't reference types work in threadvard records? As long as the reference count mechanism does it's work correctly it should work. In the end there will be only one way to find out: try it (even if it's only locally). I can comment on those you didn't list: If you change do_open to support Unicode you should do this for the other functions (e.g. write, read) as well so that only the *W functions are used for them. Also you need to keep in mind that do_open is used by platform independant code so you would need to change the declarations/handling for all other platforms as well. Also you need to change the declaration of Assign as this expects a Short-/AnsiString. Also I don't know whether the Unix users would be happy if we'd push UnicodeString upon them or whether they'd prefer AnsiString(CP_UTF8). Probably they will be rawbytestring, so both can be passed to it, and the per platform code must then change it to whatever encoding (ansi,utf8,utf16) the API expects. Right... forgot about that one. I hope other core developers comment on this as well, as I'm not so firm regarding the consequences of such changes... There are some interesting discussions on various lists you might want to read :-) I know these discussions, but somehow the results/decisions (if there were any) got lost in the noise... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicodestrings and Assign(File)
On 19.05.2012 18:22, Sven Barth wrote: On 19.05.2012 17:36, Marco van de Voort wrote: In our previous episode, Sven Barth said: While I can not comment on the changes you listed (though they sound more or less valid) I'm not sure if the *rec records can handle pointers, one probably can't use reference types in them, because the standard filedescriptions are threadvars. Think what happens if those are simply "cloned". Why shouldn't reference types work in threadvard records? As long as the reference count mechanism does it's work correctly it should work. Wait... now I understand what you meant with "cloning"... this might indeed be a problem, I haven't tested something like that yet... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicodestrings and Assign(File)
On 19.05.2012 17:47, Jürgen Hestermann wrote: > Also you need to keep in mind that do_open is used by platform independant code > so you would need to change the declarations/handling for all other platforms as well. Yes. It can be a can of worms. ;-) Although, as said: Only very few functions realy act on the file name. Most use the file handle only (which will not change). Regarding the filename, yes, but while we're at it we could also change functions like WriteFile to WriteFileW (etc.)... > Also I don't know whether the Unix users would be happy if we'd push UnicodeString upon them or whether they'd prefer AnsiString(CP_UTF8). Yes, this is a general question: What kind of string type should be used within Free Pascal mainly? I am not sure how this is all affected by http://wiki.freepascal.org/FPC_Unicode_support#Roadmap_of_RTL_Unicode_support_with_UnicodeString I don't know how up to date and valid that page is... the latest changes in 2012 were only cosmetically and the ones before that were in 2009 way before the merge of cpstrnew. > In the end maybe it should be AnsiString(CP_UTF8) for Unix systems and UnicodeString > for Windows systems and AnsiString(CP_SCP) (the current string) for the other systems, > so especially the platform independant code needs to be adjusted to support all three > cases without problems (which might not need that much work in the end...). As far as I know currently all platforms share the same filerec/textrec definitions (which is an array of bytes now). If that is changed then it would be changed for all platforms. But it can be changed to generic string type too. I am not so sure what this actually means when the type differs from one platform to the other. For example, I have to use a "pointer to widestring" for CreateFileW for Windows. So I need to convert to a null terminated widestring from the existing string type and this conversion must work under all circumstances. Well... you can define a "RTLString" type which is an alias to another string type depending on the platform and which is then used in the records. Or, as Marco suggested, we use RawByteString for this. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicodestrings and Assign(File)
On 19.05.2012 13:12, Jürgen Hestermann wrote:
2.) The Assign routine in \fpc\rtl\inc\file.inc overwrites the
whole file data structure with zeros (using fillchar). The
name has to be omitted from this action because it is now
managed automatically. So Assign needs to be changed to:
---
Procedure Assign(out f:File;const NewName:string);
{ Assign Name to file f so it can be used with the file routines }
Begin // Assign
FillChar(FileRec(f).Handle,SizeOf(FileRec)-Sizeof(FileRec(f).name),0);
FileRec(f).Handle := UnusedHandle;
FileRec(f).mode := fmClosed;
FileRec(f).Name := NewName;
End; // Assign
---
I just noticed: FillChar will be no problem here. It sets the name field
(which is an implicit pointer) to Nil which is equal to "empty string".
So no need to change the FillChar calls for FileRec (the only exception
might be if you FillChar an existing file passed by a "var", but then a
"finalize(f)" might be sufficient before calling FillChar).
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicodestrings and Assign(File)
In our previous episode, Sven Barth said: > > Think what happens if those are simply "cloned". > > > > Why shouldn't reference types work in threadvard records? As long as the > reference count mechanism does it's work correctly it should work. Afaik because the ref count mechanism doesn't. The cloning process might be done by the OS. So you have a record with that points to an ansistring with ref count 1, and then you create twenty threads, and you have 20 records that point to an ansistring with refcount 1. For the same reason, the content of the buffer is duplicated. If e.g. you have 'blabla' in a threadvar filerec buffer, create a few threads and flush them, you will have several times 'blabla' written But Pierre and Sergei have done so much on TLS, that I don't know the current situation. > >> I hope other core developers comment on this as well, as I'm not so firm > >> regarding the consequences of such changes... > > > > There are some interesting discussions on various lists you might want to > > read :-) > > I know these discussions, but somehow the results/decisions (if there > were any) got lost in the noise... This is the part where there is still consensus. It gets harder when you get to classes, or global variables or functions that write/return strings. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicodestrings and Assign(File)
On 19.05.2012 18:59, Marco van de Voort wrote: In our previous episode, Sven Barth said: Think what happens if those are simply "cloned". Why shouldn't reference types work in threadvard records? As long as the reference count mechanism does it's work correctly it should work. Afaik because the ref count mechanism doesn't. The cloning process might be done by the OS. So you have a record with that points to an ansistring with ref count 1, and then you create twenty threads, and you have 20 records that point to an ansistring with refcount 1. For the same reason, the content of the buffer is duplicated. If e.g. you have 'blabla' in a threadvar filerec buffer, create a few threads and flush them, you will have several times 'blabla' written But Pierre and Sergei have done so much on TLS, that I don't know the current situation. After writing the mail you answered to this occured to me as well which is why I wrote another mail directly after that ;) But nevertheless thank you for explaining. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Extend multiple classes with same code
So basically they are in the same branch (Well you could argue that every object inherits from TObject, but i cant imagine someone creating a helper class for TObject). > Please not that the extended classes (in this case T_B1 and T_B2) need to > inherited from T_A, otherwise the compiler will complain. > > Regards, > Sven > > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Extend multiple classes with same code
On Sat, May 19, 2012 at 7:54 PM, Jorge Aldo G. de F. Junior < jagf...@gmail.com> wrote: > but i cant imagine someone > creating a helper class for TObject). > It is in the example above but in real it base class of mine, TmncCustomField in fact But it fail for me, because there is overridden functions. BTW thanks for you all Best Regards Zaher Dirkey ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicodestrings and Assign(File)
On 19 May 2012, at 17:36, Marco van de Voort wrote: > I'm not sure if the *rec records can handle pointers, one probably can't use > reference types in them, because the standard filedescriptions are > threadvars. > > Think what happens if those are simply "cloned". Threadvars are never cloned. They are always initialized with 0 for new threads. We have special hooks that are called initialize the default system threadvars whenever a new thread is started. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Darwin i386
I'm having a hard time with GDB and debugging threads on a OSX 10.7.4 with fpc/trunk The shipped gdb worked great with the exception of threads calling methods via synchronize (so I can debug). I'm in the process of building GDB from download and configure set gdb to x64 darwin. Configure detected correctly but my gdb 7.4.1 app fails to load with some ioctl error. I'm assuming fpc can't compile darwin x64 yet. I tried # gdb ./configure --target=i386-apple-darwin but I think it needs i386 gcc compiler. I downloaded gcc from subversion and tried to configure and it too configures make files to x64 darwin :-( Has anyone got the latest GDB running on darwin? Any instructions or tips for getting gdb 7.4 working properly? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
