[fpc-pascal] [FCL-WEB] Multiple Modules - On Session

[African Wild Dog]

 Hello,


I am trying to implement authentication in my application using the
provided IniWebSession unit. I have created a separate module to handle
authentication. So, i have two modules modules. In my main module, in the
OnRequest event handle, i check for session variables ('username') to
determine if the user is logged in. If not, it redirects to the login page,
which is handled by the authentication module.

It seems that session management create one separate session by each
module. Both modules have the property "CreateSession" set to True. If i
turn off "CreateSession" property on MainModule, when i try to access
session variables in OnRequest event handler i get this error: "Default
session not available outside handlerequest".

What i am doing wrong? Please help

Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fcl-web - html web modules

[African Wild Dog]

2018-02-23 19:36 GMT-03:00 Michael Van Canneyt :

>
> What is not clear ? There are several samples available that show their
> use ?
>
> Also the WIKI has some pages about it
> http://wiki.freepascal.org/fcl-web
>
> There are some articles
> https://idefix.freepascal.org/~michael/articles/
>
> see the web1 and web2 and webserver articles.
>
> I think Web2 explains what you need.


According to your article, "Session support is introduced by
TSessionHTTPModule". However, TFPHTMLModule descends
from TCustomHTMLModule. TCustomHTMLModule descends from TCustomHTTPModule.
Then, there is no session support for  TFPHTMLModule.

Another point: using  TFPHTMLModule, request are handled by the module
itself through the OnGetContent event, not by the actions. In the other
words,  the request never is transferred to the actions.


*procedure TCustomHTMLModule.HandleRequest(ARequest: TRequest; AResponse:
TResponse);*
*Var*
*  FWriter : THTMLWriter;*
*  B : Boolean;*
*  M : TMemoryStream;*

*begin*
*  FDocument := CreateDocument;*
*  Try*
*FWriter:=CreateWriter(FDocument);*
*Try*
*  B:=False;*
*  If Assigned(OnGetContent) then*
*OnGetContent(Self,ARequest,FWriter,B);*
*  If Not B then*
*Raise EHTMLError.Create(SErrRequestNotHandled);*
*  If (AResponse.ContentStream=Nil) then*
*begin*
*M:=TMemoryStream.Create;*
*AResponse.ContentStream:=M;*
*end;*
*  FDocument.SaveToStream(AResponse.ContentStream);*
*Finally*
*  FreeAndNil(FWriter);*
*end;*
*  Finally*
*FreeAndNil(FDocument);*
*  end;*
*end;*
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] fcl-web - html web modules

[African Wild Dog]

Hello,

How to use action and sessions with HTML Web Modules?

It seems fcl-web is an incomplete work. How can i help? Is there any list
of incomplete implementations/to-do works?

Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] FCL-WEB HELP

[African Wild Dog]

Hello,

After trying unsuccessfully, I decided to ask for help.

I have a webmodule with five actions. The five actions share the same page
layout (including globals css and js files). Each action can add action's
specific css's and js's files and each action defines a specific content.

How to achieve this without duplicating code using:

1 - FPTemplates
2 - PageProducer


Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] fcl-web (WebLaz) - Duplicate Module Error

[African Wild Dog]

Hello,

Please confirm if this is a bug:

I have created a HTTP Server Application project and added a module called
"test_module" with an action "test_action".

When i run my application, when i access "http://localhost:8080/test_
module/test_action" for the first time it works, but in the subsequent
requests (like refreshing the page) i get the error '*Duplicate name: A
component named "test_module" already exists*'.


Environment: Debian Stretch 64 bits - fresh Lazarus 1.8 install

Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WinHTTP.h Translation

[African Wild Dog]

2017-11-10 4:48 GMT-02:00 Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org>:

>
> Yes, unit WinHTTP in packages/winunits-base.
>
>
This unit is missing in Lazarus setup. Thanks for the feedback.

Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] WinHTTP.h Translation

[African Wild Dog]

Hello,

Does Free Pascal has any header translations for WinHTTP.h

?

Ragards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Memory Leak's in XMLRead unit

[African Wild Dog]

2017-11-07 23:57 GMT-02:00 Michael Van Canneyt :

>
> The "memory leak" is the exception object: you are not catching the
> exception.
>
> Change your program to the below, and you'll see that it is not leaking
> memory in the XML routines itself.
>
> Michael.
>

In fact, protecting with Try..Except does not generate the leak. I will try
to reproduce this error again. I noticed this behavior in my FCGI APP: a
client was sending a mal-formed XML content and my app was generating the
leaks.

My environment: Linux Debian Stretch 64 bits - Lazarus 1.6.4 - fpc 3.0.2.

I'm quite impressed with the processing power of fastcgi fcl-web
applications: they consume little memory (less than 2 MB per instance) and
are very fast to process the requests.

Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Memory Leak's in XMLRead unit

[African Wild Dog]

Hello,

Using ReadXMLFile function from XMLRead unit generates memory leaks when
trying to read a invalid XML content.

 CODE 

program xml_leak_test;

uses
  heaptrc,
  Classes,
  DOM,
  XMLRead;
var
  XMLDocument: TXMLDocument;
  InvalidStream: TStringStream;

const
  INVALID_XML_CONTENT = '<<>>';

begin
  SetHeapTraceOutput('heap.trc');

  XMLDocument := nil;
  InvalidStream := TStringStream.Create(INVALID_XML_CONTENT);
  try
 ReadXMLFile(XMLDocument, InvalidStream);
  finally
InvalidStream.Free;
XMLDocument.Free;
  end;
end.

===


HEAP trace content:

 HEAP ===
Heap dump by heaptrc unit
105 memory blocks allocated : 18943/19216
101 memory blocks freed : 18639/18912
4 unfreed memory blocks : 304
True heap size : 491520 (192 used in System startup)
True free heap : 490400
Should be : 490512
Call trace for block $011EA650 size 40
  $0001B7AB
  $000100010A62
  $000100010B6C
  $7720812D
  $771F855F
  $7722BCB8
  $07FEFD0BA06D
  $BAADF00DBAADF00D
Call trace for block $01200B80 size 128
  $0001000141E6
  $0001B78B
  $0001000107D7
  $000100010896
  $000100037D56
  $000100037C6E
  $000100037A82
  $BAADF00DBAADF00D
Call trace for block $01208B70 size 88
  $000100014347
  $0001B78B
  $00015E15
  $0001513A
  $00010002B9E8
  $00010002C000
  $00010002E4AF
  $BAADF00DBAADF00D
Call trace for block $011EA350 size 48
  $0001B6F2
  $000190A7
  $0001000360A1
  $000100037C42
  $000100037A82
  $00010003786B
  $0001000389F8
  $BAADF00DBAADF00D
==
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FCL-WEB and PostgreSQL Support: Current Status

[African Wild Dog]

2017-09-27 12:29 GMT-03:00 Michael Van Canneyt :

>
> 2 - Are they recommended for use in production environments?
>>
>
> Absolutely. I use them in very high-load (and we're talking VERY high load)
> environments, with 24/7 availability.
>
>
Could you tell which web server you are using in this environment? Are you
using FastCGI?

Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] FCL-WEB and PostgreSQL Support: Current Status

[African Wild Dog]

Hello,

I am about to start a new project for a very small web application.

I have some questions:

1 - Are the fcl-web and postgres packages stable?
2 - Are they recommended for use in production environments?
3 - Do they have any serious bug (for example, memory leaks)?

Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] TInterfacedObject destructor reentrance bug

[African Wild Dog]

2017-07-16 6:03 GMT-03:00 Michael Van Canneyt :

>
>
> Please report it in the bugtracker, so it won't be forgotten.
>
> Michael.
>

Done. #0032168 . 

Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] TInterfacedObject destructor reentrance bug

[African Wild Dog]

Hello,

I have found a bug in the TInterfacedObject.

Better than explaining is to examine and execute the code below.
When executing the code below the destructor of the class
TCustomDestructorClass is called infinitely.
This is due to calling the procedure Foo inside the destructor of
TCustomDestructorClass, whhich causes the _addRef and _Release methods to
be called again. As the reference count reaches zero again, this triggers
the calling of the destructor again e and so the cycle will repeat
infinitely.

I think one solution would be the _Release method to check if the instance
is already being destroyed before calling the destructor of the class
(Destroy method). Currently the method only checks if the reference count
reaches zero.

 CODE BEGIN =

program interfaced_object_error_2;

type

  { TCustomDeestructorClass }

  TCustomDestructorClass = class(TInterfacedObject)
  public
destructor Destroy; override;
  end;

var
  DestrcutorCount: Integer = 0;
  CustomRef: IInterface;

procedure Foo(Value: IInterface);
begin
  if Value <> nil then
Inc(DestrcutorCount);
end;

{ TCustomDeestructorClass }

destructor TCustomDestructorClass.Destroy;
begin
  Foo(Self);
  inherited Destroy;
end;

begin
  CustomRef := TCustomDestructorClass.Create;
  CustomRef := TCustomDestructorClass.Create; // Forces execution of
destructor
end.

=== END ===
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Mutual Reference Interfaces and Memory Leaks

[African Wild Dog]

2017-06-26 12:45 GMT-03:00 Marcos Douglas B. Santos :

>
> Hi,
>
> I wrote an article about it https://goo.gl/Lij4hu
> But you need to translate from Portuguese to English.
>
> Best regards,
> Marcos Douglas
>

There are some parts of your article which are in English and you have
added a link to another article, so it helped me a lot.  Thanks for your
reply.

I researched a bit more in google and found interesting the approach used
in the Spring4D framework. I think it's compatible with Free Pascal.

For the compiler devs, will the compiler attributes features ([unsafe] and
[weak]) be implemented in the near future?

Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Mutual Reference Interfaces and Memory Leaks

[African Wild Dog]

Hello,

What is the recommended way to avoid memory leaks in mutual interface
references?

>From delphi 10.1 Berlin it is possible to use [unsafe] e [weak] attributes.
http://blog.marcocantu.com/blog/2016-april-weak-unsafe-interface-references.html
.

Is there a workaround in Free Pascal 3?

Regards

 CODE 

type
  IMyInterfaceA = interface
 procedure Foo;
  end;

  IMyInterfaceB = interface
procedure Bar;
  end;

  TMyInterfaceA = class(TInterfacedObject, IMyInterfaceA)
  private
 var FMyInterfaceB: IMyInterfaceB;
  
  end;


  TMyInterfaceB = class(TInterfacedObject, IMyInterfaceB)
  private
 var FMyInterfaceA: IMyInterfaceA;
  
  end;

   .

=
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Hash List

[African Wild Dog]

2017-04-12 10:57 GMT-03:00 Michael Van Canneyt :

we could put it in contnrs, and alias it in inifiles.pp
>
>
+1
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Platform Dependent Integer Types

[African Wild Dog]

2017-04-07 12:33 GMT-03:00 Michael Van Canneyt :

>
>
> On Fri, 7 Apr 2017, African Wild Dog wrote:
>
> 2017-04-07 12:10 GMT-03:00 Michael Van Canneyt :
>>
>>
>>> NativeInt and NativeUInt are indeed provided for Delphi compatibility.
>>>
>>> Which integer type to chose : That depends. What do you want to achieve
>>> exactly ?
>>>
>>>
>>> In Delphi, if i want an integer type which depends on the target platform
>> (32 or 64 bits) i can use the NativeInt and NativeUInt types. What is the
>> FPC standard type for this? PrtInt and PtrUInt? (I usually mix both delphi
>> mode and objfpc mode units in the same project).
>>
>
> You can use PrtInt and PtrUInt for this or NativeInt and NativeUINT, they
> should be equivalent.
>
> The only 'dubious' case may be the 8086 msdos case, which is somewhat
> confused
> about what exactly constitutes a pointer... There you may be better off
> with NativeInt and NativeUINT.
>
>
Thank you for the clarification.

Best regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Platform Dependent Integer Types

[African Wild Dog]

2017-04-07 12:10 GMT-03:00 Michael Van Canneyt :

>
> NativeInt and NativeUInt are indeed provided for Delphi compatibility.
>
> Which integer type to chose : That depends. What do you want to achieve
> exactly ?
>
>
In Delphi, if i want an integer type which depends on the target platform
(32 or 64 bits) i can use the NativeInt and NativeUInt types. What is the
FPC standard type for this? PrtInt and PtrUInt? (I usually mix both delphi
mode and objfpc mode units in the same project).
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Platform Dependent Integer Types

[African Wild Dog]

2017-04-06 18:50 GMT-03:00 Mattias Gaertner :

> Why do you think that Delphi's longint has 64bits anywhere?
> Delphi's NativeInt is 32 or 64bit depending on platform.
>
>
http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Internal_Data_Formats_(Delphi)#Platform-Independent_Signed_Integer_Types
.
As Marco have pointed out, in Windows the Delphi's LongInt type is always
32-bits. On other platforms is platform dependent.


>
> > The documentation says "every platform has a ”native” integer size,
> > depending on whether the platform is 8-bit, 16-bit, 32-bit or 64-bit.
> e.g.
> > On AVR this is 8-bit. ", but it is not clear about which integer types
> are
> > "natives".
>
> Most of FPC's integer types defined via IFDFEs. See
> fpc/rtl/inc/systemh.inc
> You can use Lazarus' Find Declaration on any type and see the
> definition.
> For example:
>
> {$ifdef CPU64}
>   SizeInt = Int64;
>   SizeUInt = QWord;
>   PtrInt = Int64;
>   PtrUInt = QWord;
>   ValSInt = int64;
>   ValUInt = qword;
>   CodePointer = Pointer;
>   CodePtrInt = PtrInt;
>   CodePtrUInt = PtrUInt;
> {$endif CPU64}
>
> {$ifdef CPU32}
>   SizeInt = Longint;
>   SizeUInt = DWord;
>   PtrInt = Longint;
>   PtrUInt = DWord;
>   ValSInt = Longint;
>   ValUInt = Cardinal;
>   CodePointer = Pointer;
>   CodePtrInt = PtrInt;
>   CodePtrUInt = PtrUInt;
> {$endif CPU32}
>
>
>   { NativeInt and NativeUInt are Delphi compatibility types. Even though
> Delphi
> has IntPtr and UIntPtr, the Delphi documentation for NativeInt states
> that
> 'The size of NativeInt is equivalent to the size of the pointer on the
> current platform'. Because of the misleading names, these types
> shouldn't be
> used in the FPC RTL. Note that on i8086 their size changes between
> 16-bit
> and 32-bit according to the memory model, so they're not really a
> 'native
> int' type there at all. }
>

Still not clear for me. Are NativeInt and NativeUInt provided for Delphi
compatibility, right? So, if i need an integer type which depends on
platform/fpc compilation mode, which one should i use?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Platform Dependent Integer Types

[African Wild Dog]

2017-04-07 11:15 GMT-03:00 Marco van de Voort :

> In our previous episode, African Wild Dog said:
> > Which integer types have their size dependent on platform?
> > E.g. in Delphi, LongInt can 32 or 64 bits depending on the platform.
>
> In Delphi they retroactively equated longint to C long, being 32-bit on
> 64-bits windows and 64-bit on Linux. The Delphi Linux compiler is btw a
> different compiler than windows.
>
> On FPC it is always 32-bit. Ptrint and ptruint scale with pointer size, and
> integer depends on compilation mode, 16 or 32-bit.
>
>
So, is the size of  "Integer" type dependent on the compilation mode?
(Delphi is always 32 bits)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Platform Dependent Integer Types

[African Wild Dog]

Which integer types have their size dependent on platform?
E.g. in Delphi, LongInt can 32 or 64 bits depending on the platform.
The documentation says "every platform has a ”native” integer size,
depending on whether the platform is 8-bit, 16-bit, 32-bit or 64-bit. e.g.
On AVR this is 8-bit. ", but it is not clear about which integer types are
"natives".

Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] String Constants and Source File Code Page (Cross-platform)

[African Wild Dog]

2017-03-31 15:43 GMT-03:00 Jonas Maebe :

>
> http://wiki.freepascal.org/FPC_Unicode_support#Source_file_codepage
> http://wiki.freepascal.org/FPC_Unicode_support#String_constants
>
>
Thank you!

Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] String Constants and Source File Code Page (Cross-platform)

[African Wild Dog]

Hello,

What is the recomended way to deal with string constants in units which are
shared in cross-platforms projects?

For example, i started a project in Linux, where the source code files are
saved in UTF-8. If i use theses files in Windows, the constants aren't
automatically converted to the system code-page. So, i am getting wrong
characters when i access theses constants in Windows.

Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Questions About Constructors

[African Wild Dog]

2017-03-30 4:25 GMT-03:00 Michael Van Canneyt :

>
>
> On Thu, 30 Mar 2017, African Wild Dog wrote:
>
> Hello,
>>
>> 1 - What happens if my constructor raise an exception? Is my destructor
>> automatically called?
>>
>
> Yes.
>
>
>> 2 - Are the class fields automatically initialized to Default(T) just like
>> in Delphi?
>>
>
> Yes. The're zeroed out when the memory for the class is allocated.
>
>
Thanks for the clarification.
I've issued # <http://bugs.freepascal.org/view.php?id=31619>0031619
<http://bugs.freepascal.org/view.php?id=31619>  to add these details in the
documentation.


Best regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Questions About Constructors

[African Wild Dog]

Hello,

1 - What happens if my constructor raise an exception? Is my destructor
automatically called?

2 - Are the class fields automatically initialized to Default(T) just like
in Delphi?


Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Critical Section and Recursive Calls

[African Wild Dog]

Hello,

I'm writing a function protected by a critical section which can have
recursive calls under certain conditions.

Using the TCriticalSection class, after my thread acquires a critical
section, if my thread make 6 additional calls to TCriticalSection.Enter, to
release the critical section my thread will have to make 6 additional calls
to TCriticalSection.Leave?

If so, is this behaviour the same on all platforms?

>From the Windows API:

*"After a thread has ownership of a critical section, it can make
additional calls to EnterCriticalSection or TryEnterCriticalSection without
blocking its execution. This prevents a thread from deadlocking itself
while waiting for a critical section that it already owns. The thread
enters the critical section each time EnterCriticalSection and
TryEnterCriticalSection succeed. A thread must call LeaveCriticalSection
once for each time that it entered the critical section."*

Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Delphi RTTI vs Free Pascal RTTI

[African Wild Dog]

2017-03-25 5:40 GMT-03:00 Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org>:

> Am 24.03.2017 19:55 schrieb "Michael Van Canneyt"  >:
> >
> >
> >
> > On Fri, 24 Mar 2017, African Wild Dog wrote:
> >
> >> Hello,
> >>
> >> I need to write a code compatilble with both free pascal and delphi
> using
> >> the old style RTTI.
> >> What are the diferences between delphi's and free pascal's
> approach/types?
> >>
> >> I took a look at delphi's and fpc's TypInfo unit and it looks like the
> >> types/functions are compatible.
> >
> >
> > They are. There is one dereference on Delphi which is not present in fpc,
> > although in fpc trunk, this additional dereference is there. If you use
> the
> > standard functions you should not notice this.
>
> The binary data of RTTI added before 3.1.1 now has the double indirection,
> but the Delphi-compatible "field" names have only a single indirection for
> backwards compatibility (they are properties to the double indirection
> fields). RTTI data added in 3.1.1 only has the double indirection.
> So this difference needs to be kept in mind and will always result in
> ifdefs for RTTI code that handles both Delphi and FPC.
>
> Regards,
> Sven
>
>
Thanks for the clarifications.

Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Delphi RTTI vs Free Pascal RTTI

[African Wild Dog]

Hello,

I need to write a code compatilble with both free pascal and delphi using
the old style RTTI.
What are the diferences between delphi's and free pascal's approach/types?

I took a look at delphi's and fpc's TypInfo unit and it looks like the
types/functions are compatible.

Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Interface Inheritance Bug

[African Wild Dog]

2017-03-19 5:25 GMT-03:00 Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org>:

> Am 19.03.2017 05:07 schrieb "African Wild Dog" :
> >
> > Hello,
> >
> > Test env: debian jessie amd64 - fpc 3.0.2
> >
> > It seems free pascal have a bug when handling interface inheritance
> using generics.
> >
> > When i try to compile the unit bellow, i get this error:
> >
> > "interface_bug.pas(41,44) Error: Incompatible types: got
> "TImplementor" expected "IParentInterface LongInt>""
>
> I think this will happen with non-generic interfaces as well. So please
> test with those and if possible also with 3.1.1 and report a bug if
> necessary (preferable with a non-generic example, makes things easier to
> debug ;) ).
>
>
Bug confirmed on 3.1.1.
Issued as http://bugs.freepascal.org/view.php?id=31568.
<http://bugs.freepascal.org/view.php?id=31568>

Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics Bug

[African Wild Dog]

2017-03-18 19:29 GMT-03:00 African Wild Dog :

> 2017-03-18 18:41 GMT-03:00 Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org>:
>
> Nested specializations are currently not supported though they *might*
>> work with 3.1.1.
>>
>
> I will do test some tests with 3.1.1.  Thanks.
>
> Regards
>

I have tested with 3.1.1. Nested specializations works in 3.1.1.

Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Interface Inheritance Bug

[African Wild Dog]

2017-03-19 15:20 GMT-03:00 Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org>:

> But without the cast you get the same error, yes?
>
> Regards,
> Sven
>
>
Yes, i need to cast.

Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Interface Inheritance Bug

[African Wild Dog]

2017-03-19 5:25 GMT-03:00 Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org>:

> I think this will happen with non-generic interfaces as well. So please
> test with those and if possible also with 3.1.1 and report a bug if
> necessary (preferable with a non-generic example, makes things easier to
> debug ;) ).
>
>
With non-generic types there is a workaround: cast to parent interface:

...

ParentImplementorInstance := TImplementor.Create as IParentInterface;

..
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Interface Inheritance Bug

[African Wild Dog]

Hello,

Test env: debian jessie amd64 - fpc 3.0.2

It seems free pascal have a bug when handling interface inheritance using
generics.

When i try to compile the unit bellow, i get this error:

"interface_bug.pas(41,44) Error: Incompatible types: got
"TImplementor" expected "IParentInterface""


=== CODE ===

*unit* interface_bug;

{$mode delphi}

*interface*

*type*

  IParentInterface = *interface*
['{0F78D56E-85A6-4024-98D7-720D7C7B9573}']
*procedure* Foo;
  *end*;

  IChildInterface = *interface*(IParentInterface)
['{1AB2EB85-6843-462E-8CE4-32ECC065011E}']
*procedure* Bar;
  *end*;

  TImplementor =  class(TInterfacedObject, IChildInterface)
  *public*
*procedure* Foo;
*procedure* Bar;
  *end*;

*var*
  ParentImplementorInstance: IParentInterface;

*implementation*

*procedure* TImplementor.Foo;
*begin*

*end*;

*procedure* TImplementor.Bar;
*begin*

*end*;

*initialization*
  ParentImplementorInstance:=TImplementor.Create;

*end*.


===
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics Bug

[African Wild Dog]

2017-03-18 18:41 GMT-03:00 Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org>:

Nested specializations are currently not supported though they *might* work
> with 3.1.1.
>

I will do test some tests with 3.1.1.  Thanks.

Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Forward Generic Type Declaration Bug

[African Wild Dog]

2017-03-18 18:40 GMT-03:00 Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org>:

> Forward declarations for generic types are not supported.
>
> Are there plans for add suport for this in fpc 3.2?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Generics Bug

[African Wild Dog]

Hello,


Please confirm this bug.

The unit code bellow won't compile (fpc 3.0.2 - debian jessie amd64):

"generics_bug.pas(17,48) Fatal: Syntax error, "," expected but "<" found"

=== CODE  ===

*unit* generics_bug;

{$mode delphi}

*interface*

*type*

  TPair = *record*
Key: TKey;
Value: TValue;
  *end*;

  TEnumerator = *class*
  *end*;

  TGenericClass = *class*(TEnumerator>)
  *end*;

*implementation*

*end*.

===


This code compiles in Delphi XE 2.

Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Forward Generic Type Declaration Bug

[African Wild Dog]

Hello,

Please confirm if this is a bug.

When I try to compile the unit below I get the error:

"generics_bug.pas(14,43) Fatal: Internal error 2012101001"

It seems the compiler has bug when handling forward generics declaration.

Tested on: Debian Jessie amd64 - fpc 3.0.2

=== CODE ===

*unit* generics_bug;

{$mode delphi}

*interface*


*type*

  IGenericInterface = *interface*; // Forward

  TGenericClass = *class*
  *private*
FGenericInterface: IGenericInterface;
  *end*;

  IGenericInterface = *interface*
  *end*;


*implementation*

*end*.

===


Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Hash List

[African Wild Dog]

Thanks for your reply Giuliano, Silvio.

To be more specific, i need a generic hash map similar to the Delphi's
TDictionary.

It seems THashmap from the ghashmap unit is the most close to TDictionary.

Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Hash List

[African Wild Dog]

Hello,

Ia there any hash list implementation in free Pascal?

Ghashmap has no documentation. Is it stable for production use?


Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Threadvar member field

[African Wild Dog]

2017-03-17 5:50 GMT-03:00 Michael Schnell :

> On 16.03.2017 19:38, African Wild Dog wrote:
>
>> I have a class where its instances are shared between multiple threads.
>> How can I declare one variable per instance per thread?
>>
> Does this really make sense ?
>
> Accessing threadvars (in fpc) costs a lot more CPU cycles (i.e. involves
> an OS call) than accessing normal variables.
>
> Supposedly the way to go is to do per-thread instances of a class, that
> might reference the other classes you want to instantiate.
>
>
I have huge collection of objects (abot 1 million) in memory so if i go
with per-thread instance it will consume the entire memory ram.
I will have to redesign my classes =(.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Thread Variables Initial Values

[African Wild Dog]

2017-03-17 13:09 GMT-03:00 Michael Van Canneyt :

>
> Nil.
>
> What exactly is not clear about the documentation ?
>

The documentation says ".. Note that the copy is made with the original
value of the variable ..". But, whats is the original value?
I think the documentation should be clearer about the initial values of
thread variables. From what i I understand, the value is default(T) for all
threads. So, the documentation should mention that.

Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Thread Variables Initial Values

[African Wild Dog]

Hello,

The documentation is not clear about the initial values of thread variables:




*"If threads are used then a copy is made for each thread (including the
main thread). Note that the copy is made with the original value of the
variable, not with the value of the variable at the time the thread is
started."*
So, if i declare a threadvar:

threadvar
  MyObject: TObject;


What will be the initial value of the variable when each thread uses its
copy for the first time?


Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Threadvar member field

[African Wild Dog]

I have a class where its instances are shared between multiple threads.
How can I declare one variable per instance per thread?

The code below does not compile (fpc 3.0.0):

TMyClass = class
public
  threadvar MyValue: Integer;
end;

Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics and Scopes

[African Wild Dog]

2016-11-10 1:30 GMT-02:00 African Wild Dog :

> 2016-11-07 14:15 GMT-02:00 Sven Barth :
>
>> Am 07.11.2016 15:58 schrieb "African Wild Dog" :
>> > It is intended to change such compiler behavior in the future? It is
>> incompatible with Delphi and moreover it force us to break the
>> encapsulation of the Generic types.
>>
>> I can't answer this without you providing an example that fails.
>>
>
> Sorry for the noise. Some of my classes were bad designed. They look like
> this sample (Delphi XE 6 compiles):
>
>  CODE BEGIN 
>
> unit sample;
>
> {$MODE delphi}
>
> interface
>
> type
>   TGenericRecord = record
>   strict private
> Interf: IInterface;
> type
>   TMockIntfObject = record // Nested generic declaration
>   end;
>
>   public
> FValue: T;
> procedure SetValue(Value: T);
>   end;
>
> implementation
>
> { TGenericRecord }
>
> procedure TGenericRecord.SetValue(Value: T);
> begin
>   Interf := TMockIntfObject.Create;
> end;
>
> end.
>
>
>  END 
>
>
>  With fpc i got the error "Fatal: Declation of generic class inside
> another generic class is not allowed".
>
> Best regards
>
>
This is the correct sample:

=== CODE BEGIN ===

unit sample;

{$MODE delphi}

interface

type
  TGenericRecord = record
  strict private
type
  TMockRecord = record // Nested generic declaration
  end;

  public
FValue: T;
procedure SetValue(Value: T);
  end;

implementation

{ TGenericRecord }

procedure TGenericRecord.SetValue(Value: T);
begin
end;

end.


=== END ===

Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics and Scopes

[African Wild Dog]

2016-11-07 14:15 GMT-02:00 Sven Barth :

> Am 07.11.2016 15:58 schrieb "African Wild Dog" :
> > It is intended to change such compiler behavior in the future? It is
> incompatible with Delphi and moreover it force us to break the
> encapsulation of the Generic types.
>
> I can't answer this without you providing an example that fails.
>

Sorry for the noise. Some of my classes were bad designed. They look like
this sample (Delphi XE 6 compiles):

 CODE BEGIN 

unit sample;

{$MODE delphi}

interface

type
  TGenericRecord = record
  strict private
Interf: IInterface;
type
  TMockIntfObject = record // Nested generic declaration
  end;

  public
FValue: T;
procedure SetValue(Value: T);
  end;

implementation

{ TGenericRecord }

procedure TGenericRecord.SetValue(Value: T);
begin
  Interf := TMockIntfObject.Create;
end;

end.


 END 


 With fpc i got the error "Fatal: Declation of generic class inside another
generic class is not allowed".

Best regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] New Feature: "Management Operators"

[African Wild Dog]

Hello,

I saw on the bug tracker a patch submission by Maciej Izak about the
feature "Management Operators".

This feature is related to Automatic Reference Counting?

Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Generics and Scopes

[African Wild Dog]

Hello,

I have tried to compile some delphi projects using the latest FPC (3.0.0)
release, and i got several errors related to Ggenerics feature. Reading the
FPC documentation (section 8.8 - A Word About Scope) i have found that FPC
requires that all external types and procedures used in the the Generic
type implementation must be visible when the Generic type is specialized.

It is intended to change such compiler behavior in the future? It is
incompatible with Delphi and moreover it force us to break the
encapsulation of the Generic types.

Best regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Variants - Auto-convert nulls

[African Wild Dog]

Hello,

I need the variant type converting automatically  null values to the
default value of the target type (e.g False for Booleans, 0 for
Integers/Floats).
I know that i can achieve this by setting the variable NullStrictConvert
(unit Variants) to False. However, this is a global setting and therefore
is not safe using such method.

What would be the best way to solve my problem?

Best regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC 3.0.2 Release Date

[African Wild Dog]

2016-08-19 4:22 GMT-03:00 Jonas Maebe :

> African Wild Dog wrote:
>
> > There are some critical bugs in fpc 3.0 which are already fixed. So, why
> > the 3.0.2 version was not released yet? Do you have any estimate about
> > when it will be released?
>
> My guess is that RC1 will be released between the end of August and mid
> September, and the final release somewhere in October


As we are already in November, do you have a new estimate?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] LLVM Backend Support

[African Wild Dog]

Em quarta-feira, 31 de agosto de 2016, Jonas Maebe <
jonas.ma...@elis.ugent.be> escreveu:
> On 31/08/16 05:11, African Wild Dog wrote:
>>

> The code optimizers, yes. The rest, not so much.
>
>> Will the FPC team, somewhere in the future, adopt the LLVM as the
>> backend on all platforms ?
>
> No, for various reasons:

Again,thanks for the detailed explanation. As this is a recurrent
topic,maybe it would be a good ideia to create a wiki page with all these
points.

And about GCC? It supports a wide variety of processors and OS.

Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] LLVM Backend Support

[African Wild Dog]

2016-08-19 4:55 GMT-03:00 Jonas Maebe :

> African Wild Dog wrote:
>
> > What is the current status of the LLVM backend support?
>
> "make cycle" works on my machine for Darwin/x86-64, and most test suite
> failures (apart from exception handling tests if the optimisation level
> is increased, see point 2 below) are related to LLVM limitations rather
> than to bugs in the FPC code generator to LLVM. I have not yet committed
> everything, because some changes still need to be implemented in a
> cleaner way.
>

Thanks for the detailed explanation. I asked about it because apparently it
is a good idea to adopt the LLVM as the backend for FPC compiler.
This would free the FPC's core developers from the task of maintain the
backend portion of the compiler, which is not a trivial task, considering
the dozens of architectures and operating systems which is currently
supported, and other details such as the code optimizer.

Will the FPC team, somewhere in the future, adopt the LLVM as the backend
on all platforms ?

Best regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] LLVM Backend Support

[African Wild Dog]

Hello,

What is the current status of the LLVM backend support?

Best regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Free Pascal Foundation Roles and Goals

[African Wild Dog]

Hello,

>From what i understand, the primary goal of the FPC Foundation is to raise
funds to support the FPC and Lazarus development. In the future, the
foundation will play another roles like e.g., coordinate and manage FPC and
Lazarus projects?

Best regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] FPC 3.0.2 Release Date

[African Wild Dog]

Hello,

There are some critical bugs in fpc 3.0 which are already fixed. So, why
the 3.0.2 version was not released yet? Do you have any estimate about when
it will be released?

Best regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Improvement to TFPHTTPClient Class

[African Wild Dog]

2016-07-20 3:45 Michael Van Canneyt :

Because all Pascal TCP toolkits out there offer a HTTP Client. (lnet, indy,
> synapse). By doing this, I leave the choice up to the user which one to use
> for various APIs that are built ON TOP of HTTP.
>
> Your use case is simply one I didn't foresee,
> Because I assume that any decent TCP toolkit offers a HTTP client.
>
> However, now that I understand what you actually need, we can consider
> this use-case.
>
>
The change I am proposing should be accepted even if i did not have that
problem to solve. Decoupling the TFPHTTPClient class from the underlying
socket framework brings many benefits. Perhaps, the most important benefity
is improving the testability of the class. For example, one can test the
core functionality of the TFPHTTPClient through "fake" TCP adapters.


> I will accept the patch, on the condition that you provide a binding for a
> C
> TCP/IP library too. If your c library is open source, then we can use that.
> if not, then I'd ask you to provide an libevent implementation.
>
> It has no point abstracting out something if we have only 1 implementation.
>
>
Great! I will provide the bindings. My bindings are for the Mozilla 's NSPR
toolkit .

Best regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Improvement to TFPHTTPClient Class

[African Wild Dog]

2016-07-19 4:52 GMT-03:00 Michael Van Canneyt :

>
> 1. The whole point of TFPHTTPClient is exactly to couple it to sockets
>framework (fcl-net).
>If you want to use synapse, use httpsend. lnet has a similar component
>for the http protocol.
>
>
I dont want to use synapse. I am developing bindings for a c library. The
library offers TCP connection functionality but does not provide any
support for http. I need to use that library due to some particularities of
my project.

I do not understand the need for such coupling between http client and
fcl-net. It is like coupling SQLDb with a specific RDBMS.


> 2. I favour the opposite approach. Abstract out the underlying HTTP
> implementation
>at a higher level.
>

Why should we duplicate the code? Why should we implement the same
functionality in several diferent places?


>
>For this I have introduced FPWebclient, which has 2 implementations:
>TFPHTTPClient and Synapse.
>
>
Through TAbstractWebClient you are introducing another level of complexity
to do the same task: perform http requests. TAbstractWebClient is actually
an adapter to diferent http implementations. TAbstractWebClient is an
interesting class. However, It is a poor solution, IMHO.

Best regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Improvement to TFPHTTPClient Class

[African Wild Dog]

Hello,

The current version of the TFPHTTPClient (the one shipped with fpc 3.0) is
coupled to the fpc's sockets framework (fcl-net) so we can't utilize other
tcp connection framework (e.g Synapse) to perform HTTP requests using
TFPHTTPClient.

I have made an improvement to the TFPHTTPClient class (unit fphttpclient,
package fcl-web) which consists of decoupling the client from the socket
framework that is used to perform HTTP requests.

My solution is quite simple: i created a new class called
TTCPConnectionAdapter (as the name suggests, i used the Adapter pattern)
and changed the http client class to perform requests using a
TCPConnectionAdapter instance . The connection adapter is passed as a
parameter to the constructor of the TFPHTTPClient class (dependency
injection). So, the TFPHTTPClient is not tied to the a particular socket
framework anymore. If one wants to perform http requests using e.g Synapse,
just implement the appropriate TTCPConnectionAdapter descendant and inject
it into TFPHTTPClient.

The code below shows the TInetAdapter


==

{ TTCPConnectionAdapter }

TTCPConnectionAdapter = class(TStream)
  strict private
FHost: String;
FPort: Word;
procedure ValidateConnection;
  strict protected
procedure DoConnect(const AHost: String; const APort: Word); virtual;
abstract;
function DoRead(var Buffer; Count: Longint): Longint; virtual; abstract;
function DoWrite(const Buffer; Count: Longint): Longint; virtual;
abstract;
function GetConnected: Boolean; virtual; abstract;
  public
procedure Connect(const AHost: String; const APort: Word);
procedure Disconnect; virtual; abstract;
function Read(var Buffer; Count: Longint): Longint; override;
function Seek(Offset: Longint; Origin: Word): Longint; override;
function Write(const Buffer; Count: Longint): Longint; override;
property Connected: Boolean read GetConnected;
property Host: String read FHost;
property Port: Word read FPort;
  end;

{ TInetConnectionAdapter }

  TInetConnectionAdapter = class(TTCPConnectionAdapter)
  strict private
FSocket: TInetSocket;
procedure FreeSocket;
  strict protected
procedure DoConnect(const AHost: String; const APort: Word); override;
function DoRead(var Buffer; Count: Longint): Longint; override;
function DoWrite(const Buffer; Count: Longint): Longint; override;
function GetConnected: Boolean; override;
  public
destructor Destroy; override;
procedure Disconnect; override;
  end;

  { TFPCustomHTTPClient }

  TFPCustomHTTPClient = Class(TComponent)
  private
..
FTCPConnection: TTCPConnectionAdapter;
  public
Constructor Create(const ATCPConnection: TTCPConnectionAdapter);
  end;

==

Best regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal