Re: [fpc-pascal] How to avoid namespace name clashes after USES ?
Am 21.08.2012 21:42, schrieb Jorge Aldo G. de F. Junior: Instead of implementing the half-assed C++ namespace model, just add to the compiler a warning when it detects that there is a collision in the current scope (two functions with the same parameters from different units that can be called from the scope being inspected). I believe function overload alread provides the necessary hooks, but i cant do it because i have zero experience with FPC sources... The compiler can not detect such collisions, because it stops searching for a symbol if it found a suitable one. This also explains why you need the overload directives in certain cases of cross unit overloading (because then the compiler will search for more). This is one of the reasons why the compiler can compile code so fast: It does not need to check all loaded units of a unit (and there are units that contain many uses). So from me this gets a definit -1 in big letters. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] FPC unit testing generation program
Just saw this commit fly by: r22165 | michael | 2012-08-21 21:43:26 +0200 (di, 21 aug 2012) | 1 line * pas2ut, initial version (create unit tests from pascal unit) That looks very interesting! Thanks for this, I'll look into it. Regards, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TSQLDBLibraryLoader committed for SQLDB
After recent discussions about which library to load when loading DB client libraries, I changed the default names for Firebird, MySQL, Postgres. That was well in time ;) Thanks. Another little bug and patch in http://bugs.freepascal.org/view.php?id=22691 Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: How to avoid namespace name clashes after USES ?
On 08/22/2012 09:57 AM, Marco van de Voort wrote: In our previous episode, Marcos Douglas said: [...] Requiring all functions to be allways fully qualified will make the most commom case worse than current implementation just to be better for the uncommon case. This is a step back, not forward... Timothy Madden want this, not me. ;-) This is necessary in order to guarantee thare can be no conflicts whatsoever. No matter how many units you want to USE in your program, no matter what versions of the units. It is not that bad, python uses that from the start. You must call os.path.basename(), and there is not way for you to call basename() directly (well, there is one, but they have taken special measures for it, so no name conflicts are possible). But for this to work, I need a way to alias the importing module, because not all units have a 2-letter name like os, for example I need something like: USES 'TrigonometricLibrary' AS 'trig' in 'pas/TrigonometricLibrary.pas' Of course I will not remove the existing behavior for USES, that is programmers can still say: USES charset, matrix, socket; and they get the behaviour they know. But if the programmer says: USES charset AS cs, matrix AS matrix, socket AS socket; than no symbols are made directly visible, and all of them need their prefix now (one of cs. or matrix. or socket. ). These prefixes are chosen by the programmer so thay may not create conflicts, as long as programmer sticks to the new form of USES. If both forms of USES are intermixed, like USES unit1, unit2, charset AS cs, matrix AS matrix, socket AS socket; than there is a chance that prefix cs will conflict with some unit1.cs symbol (either now or in a future version of unit1, or unit2). In this case I think it is appropriate to make the prefix cs., introduced by charset AS cs, to have precedence over unit1.cs. This is because the programmer must use the prefix cs. a lot in the program ((s)he has no choice, since the prefix is the only way to access simbols from unit charset). In a corporate environment there will probably be some convention saying programmers have to use the second USES syntax at all times, to ensure no future name conflicts are possible. As I said many Java programmers have been bitten by this problem, and now they explicitly list every single symbol they need to import from every package, composing what is known as imports lists. Which is surely not fun at all, but it is safe! Most Java IDEs othen try to automate the generation of such lists, and collapse them when the source file is opened, because the lists can get very long. Regards, Timothy Madden ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: How to avoid namespace name clashes after USES ?
On 08/22/2012 11:30 AM, Sven Barth wrote: Am 21.08.2012 21:42, schrieb Jorge Aldo G. de F. Junior: Instead of implementing the half-assed C++ namespace model, just add to the compiler a warning when it detects that there is a collision in the current scope (two functions with the same parameters from different units that can be called from the scope being inspected). I believe function overload alread provides the necessary hooks, but i cant do it because i have zero experience with FPC sources... The compiler can not detect such collisions, because it stops searching for a symbol if it found a suitable one. This also explains why you need the overload directives in certain cases of cross unit overloading (because then the compiler will search for more). This is one of the reasons why the compiler can compile code so fast: It does not need to check all loaded units of a unit (and there are units that contain many uses). So from me this gets a definit -1 in big letters. All this discussion with a warning for duplicate symbols is not helpfull: - it is not backward compatible - as someone else in this thread said, it is possible to put the current lookup rules to good use - it is not enough to solve the problem I am talking about in this thread (that is, eliminate the risk of colisions when the compiler or the libraries are upgraded). Using aliases for imported units, and making them required on each symbol reference, will not affect compilation speed or lookup for unqualified names. Lookup for qualified names is faster than lookup for unqualified names. Regards Timothy Madden ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TSQLDBLibraryLoader committed for SQLDB
(In the IDE: drop, set connector type from picklist, maybe change library name, set to enabled). I'm having some problems using this in the IDE. The picklist is empty. Probably something missing in procedure TSQLDBConnectorTypePropertyEditor.GetValues( Proc: TGetStrProc); Var L : TStringList; I : Integer; begin L:=TStringList.Create; try for I:=0 to L.Count-1 do Proc(L[i]); finally L.Free; end; end; because that is a no-op. Also, if I understand the mode of operation correctly, the TSQLDBLibraryLoader, when enabled, loads the library before the TxxxConnection tries to load it. But how can you be sure TSQLDBLibraryLoader is streamed before a TxxxConnection that has connected set to true ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EControlC instead of EZeroDivide when using SSE instructions
Olivier SANNIER wrote:
Does any of you have any suggestion as to explain this behavior, and best of
all, how to fix it?
I went further and changed the code this so that I can get better
details as to where the exception is coming from:
program test;
uses
sysutils,
classes;
function GetMXCSR: Cardinal;
asm
stmxcsr Result
end;
var
PreviousExceptProc: TExceptProc;
PreviousErrorProc: TErrorProc;
procedure MyExceptProc(Obj: TObject; Addr: Pointer; FrameCount: LongInt;
Frame: PPointer);
begin
WriteLn('MyExceptProc: ' + IntToHex(GetMXCSR, 2));
WriteLn(Obj.ClassName);
PreviousExceptProc(Obj, Addr, FrameCount, Frame);
end;
Procedure MyErrorProc(ErrNo : Longint; Address,Frame : Pointer);
begin
WriteLn('MyErrorProc: ' + IntToHex(GetMXCSR, 2));
WriteLn(ErrNo);
PreviousErrorProc(ErrNo, Address, Frame);
end;
procedure MyTestExcept;
var
Tmp: Double;
begin
Tmp := 0.0;
Tmp := 5.0 / Tmp;
end;
begin
PreviousExceptProc := ExceptProc;
ExceptProc := MyExceptProc;
PreviousErrorProc := ErrorProc;
ErrorProc := MyErrorProc;
MyTestExcept;
end.
I compiled it in both x86 and x64 and then ran it. Here are the results:
== x86
MyErrorProc: 1900
217
MyExceptProc: 1900
EControlC
An unhandled exception occurred at $004017CE :
EControlC : Control-C hit
$004017CE MYTESTEXCEPT, line 64 of test.dpr
$00401815 main, line 76 of test.dpr
== x64
MyErrorProc: 1900
200
MyExceptProc: 1900
EDivByZero
An unhandled exception occurred at $0040189B :
EDivByZero : Division by zero
$0040189B MYTESTEXCEPT, line 64 of test.dpr
$004018FA main, line 76 of test.dpr
So clearly, there is an issue in the x86 build because the ErrorProc has
the wrong runtime error code. Strangely enough, the MXCSR has none of
its exception flags set, so it seems they are reset before ErrorProc is
called
I would very much appreciate any help in solving this issue.
Regards
Olivier
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EControlC instead of EZeroDivide when using SSE instructions
OBones wrote on Wed, 22 Aug 2012: Olivier SANNIER wrote: Does any of you have any suggestion as to explain this behavior, and best of all, how to fix it? I went further and changed the code this so that I can get better details as to where the exception is coming from: EControlC is the translation of run time error 217. The Win32 exception handler also sets error code 217 in case of an unknown exception (the Win64 exception handler does the same, for that matter). Apparently Win32 is not reporting that division-by-zero as either STATUS_INTEGER_DIVIDE_BY_ZERO or STATUS_FLOAT_DIVIDE_BY_ZERO, while Win64 does do this. You can try debugging syswin32_i386_exception_handler in rtl/win32/system.pp to see what exception Win32 reports instead. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TSQLDBLibraryLoader committed for SQLDB
On Wed, 22 Aug 2012, Ludo Brands wrote: After recent discussions about which library to load when loading DB client libraries, I changed the default names for Firebird, MySQL, Postgres. That was well in time ;) Thanks. Another little bug and patch in http://bugs.freepascal.org/view.php?id=22691 Applied, thank you. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: How to avoid namespace name clashes after USES ?
On 21/08/2012 17:43, Timothy Madden wrote: On 08/21/2012 03:10 PM, Jorge Aldo G. de F. Junior wrote: With no error messages, or even with no changes to the program since 1 and a half year in the repository, the scientific calculations are now all blown up, and program outputs only errors at runtime. The maintainer now curses and chases me for having the nerve to leave a program known as working in such a horrible mess in the repository. Never tested, but doesnt the compiler warn of the colision ? if not, it should. The problem is the language exposes my program to the risk of future collisions from the units I use. A warning is a little beyond the scope of this problem, because my program is working perfectly as of now. But next year, some unit I use will have reached a new version, and if I merely recompile my program I have already have a conflict, that was not there last year. Recompilation when one of units/libraries was upgraded, almost always implies rebuild. Who on Earth is so trigger-happy to upgrade, rebuild and not test for regressions? This is the only sane way to get the process going - document it *as MML said below*; This AFAIR is sane programming practice, EVERY change you make, you test. And your managers HAVE to allow room and time for that, no less, no more. If they don't, they shall not be IT managers. There is no room for 'program done, out the door' culture any more. /IF/ there is one, just treat the program with updated/upgraded units as completely new product, completely detached from its original, and show it as such to the managers, if they need explanations. (even in free-software/open-source, 'releases' always/usually carry the versions of libraries/sources they've been tested with, not just in Pascal, take a look at what your average C (including ++ and #), Java and other programmers do as 'dependencies'. Otherwise no one ever could wrap their head around the resulting heap of s*t.) And the new version for the unit in question is fully compatible with the old one, so you would say my code should still compile. The question here is if it would be possible for the language to prevent this problem, like python (and others) do. Otherwise, I could never upgrade a library, even if the vendor announces full compatibility with the previous version. Because I will still expose my old code to the risk of new collisions. Even worse, as the language currently stands, it is possible to upgrade a unit to a compatible version and get a different behaviour from my program. Without a single warning from the compiler. That's what /testing/ is for. There must be a rule: no untested changes are published. If there is none in your company, then *you* make one for yourself and keep to it. Thank you, Timothy Madden HTH, Lukasz ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EControlC instead of EZeroDivide when using SSE instructions
Jonas Maebe wrote:
OBones wrote on Wed, 22 Aug 2012:
Olivier SANNIER wrote:
Does any of you have any suggestion as to explain this behavior, and
best of
all, how to fix it?
I went further and changed the code this so that I can get better
details as to where the exception is coming from:
EControlC is the translation of run time error 217. The Win32
exception handler also sets error code 217 in case of an unknown
exception (the Win64 exception handler does the same, for that
matter). Apparently Win32 is not reporting that division-by-zero as
either STATUS_INTEGER_DIVIDE_BY_ZERO or STATUS_FLOAT_DIVIDE_BY_ZERO,
while Win64 does do this.
You can try debugging syswin32_i386_exception_handler in
rtl/win32/system.pp to see what exception Win32 reports instead.
Thanks for the confirmation as I was heading that way when I posted the
message, without much hope.
But now that I have put that idea to full length, it became clear that
the problem is not (entirely) with Win32 but because the exception
handler does not handle the STATUS_FLOAT_MULTIPLE_FAULTS and
STATUS_FLOAT_MULTIPLE_TRAPS cases.
And as you said, when it does not know what to do, it gives 217 that
gets later translated to Control C, which to me is a bit misleading. I'd
rather have a 202, External Exception.
Anyway, I installed my own exception handler using
SetUnhandledExceptionFilter, saving the return value and I wrote my own
overloaded version of the exception handler that does this:
function GetMXCSR: Cardinal;
asm
stmxcsr Result
end;
function MyUnhandledExceptionFilter(excep : PExceptionPointers) :
Longint;stdcall;
const
MXCSR_IE = $01; // invalid operation
MXCSR_DE = $02; // denormal
MXCSR_ZE = $04; // divide by zero
MXCSR_OE = $08; // overflow
MXCSR_UE = $10; // underflow
MXCSR_PE = $20; // precision
var
MXCSR: Cardinal;
begin
WriteLn('MyUnhandledExceptionFilter: ' + IntToHex(GetMXCSR, 2));
WriteLn(IntToHex(excep^.ExceptionRecord^.ExceptionCode, 8));
WriteLn(IntToHex(EXCEPTION_FLT_DIVIDE_BY_ZERO, 8));
if Assigned(PreviousUnhandledExceptionFilter) then
begin
if (excep^.ExceptionRecord^.ExceptionCode =
STATUS_FLOAT_MULTIPLE_FAULTS) or
(excep^.ExceptionRecord^.ExceptionCode =
STATUS_FLOAT_MULTIPLE_TRAPS) then
begin
MXCSR := GetMXCSR;
if MXCSR and MXCSR_IE = MXCSR_IE then
excep^.ExceptionRecord^.ExceptionCode :=
STATUS_FLOAT_INVALID_OPERATION
else if MXCSR and MXCSR_DE = MXCSR_DE then
excep^.ExceptionRecord^.ExceptionCode :=
STATUS_FLOAT_DENORMAL_OPERAND
else if MXCSR and MXCSR_ZE = MXCSR_ZE then
excep^.ExceptionRecord^.ExceptionCode :=
STATUS_FLOAT_DIVIDE_BY_ZERO
else if MXCSR and MXCSR_OE = MXCSR_OE then
excep^.ExceptionRecord^.ExceptionCode := STATUS_FLOAT_OVERFLOW
else if MXCSR and MXCSR_UE = MXCSR_UE then
excep^.ExceptionRecord^.ExceptionCode := STATUS_FLOAT_UNDERFLOW
else if MXCSR and MXCSR_PE = MXCSR_PE then
excep^.ExceptionRecord^.ExceptionCode :=
STATUS_FLOAT_INEXACT_RESULT;
end;
Result := PreviousUnhandledExceptionFilter(excep);
end;
end;
I know that I hide the case where there might be two errors at once, but
strangely enough, the MXCSR register only contained one exception bit
set in my case, so I don't understand why Win32 is giving a multiple
traps error.
So right, now, using this I'm getting the appropriate exception, I'm
just left wondering if this code (or a similar one) should be added to
FreePascal so that other people are not having the same issue as I'm having.
Note to others: this is only ever useful in Win32 because Win64 does not
use the handlers set by SetUnhandledExceptionFilter
Regards
Olivier
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TSQLDBLibraryLoader committed for SQLDB
Also, if I understand the mode of operation correctly, the TSQLDBLibraryLoader, when enabled, loads the library before the TxxxConnection tries to load it. But how can you be sure TSQLDBLibraryLoader is streamed before a TxxxConnection that has connected set to true Previous message was sent before I finished it completely;) Just produced a testcase where TSQLDBLibraryLoader is too late. Create new app, drop TPQConnection, fill in all needed, save project, drop a TSQLDBLibraryLoader on the form, enter PostGreSQL in ConnectionType, set enabled true and TPQConnection.Connected:=true. Run program: Exception=Error reading SQLDBLibraryLoader1.ConnectionType: SQLDBLibraryLoader1 : This operation is not allowed while the datatabase is loaded Reason: TPQConnection was already streamed and connection made with the default lib. Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TSQLDBLibraryLoader committed for SQLDB
On Wed, 22 Aug 2012, Ludo Brands wrote: (In the IDE: drop, set connector type from picklist, maybe change library name, set to enabled). I'm having some problems using this in the IDE. The picklist is empty. Probably something missing in procedure TSQLDBConnectorTypePropertyEditor.GetValues( Proc: TGetStrProc); Var L : TStringList; I : Integer; begin L:=TStringList.Create; try for I:=0 to L.Count-1 do Proc(L[i]); finally L.Free; end; end; because that is a no-op. Also, if I understand the mode of operation correctly, the TSQLDBLibraryLoader, when enabled, loads the library before the TxxxConnection tries to load it. But how can you be sure TSQLDBLibraryLoader is streamed before a TxxxConnection that has connected set to true First: When committing, I has a problem with conflicts. It seems that while resolving these conflicts, a line got lost. I re-added that line. Second, this problem is known, but there is no good solution to this problem, except not leaving connected to true. (which is bad practice anyway IMHO). There are more problems: the library name is not cross-platform, so the project will no longer be cross-platform. Which is a far more serious problem, IMHO. (and one which would exist even if I had followed your suggestion of implementing the property in TSQLConnection). Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: How to avoid namespace name clashes after USES ?
Am 2012-08-22 13:45, schrieb Lukasz Sokol: Recompilation when one of units/libraries was upgraded, almost always implies rebuild. Who on Earth is so trigger-happy to upgrade, rebuild and not test for regressions? This is the only sane way to get the process going - document it *as MML said below*; That's not the point. Why on earth should a programmer *not* get as much help as possible from a programming language/compiler? That's the genuine purpose of a programming language. Why stick with flaws if they are avoidable? *If* the issue Timothy reported can be avoided why *not* doing it? It would help avoiding many problems and reduce testing time. Although I have not such a strong feeling about it I would still appreciate the suggested addition. It would add a function for safer programming without drawbacks (except the coding effort of course). Though I don't know whether it can be implemented easily (if at all). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EControlC instead of EZeroDivide when using SSE instructions
OBones wrote on Wed, 22 Aug 2012: Jonas Maebe wrote: You can try debugging syswin32_i386_exception_handler in rtl/win32/system.pp to see what exception Win32 reports instead. Thanks for the confirmation as I was heading that way when I posted the message, without much hope. But now that I have put that idea to full length, it became clear that the problem is not (entirely) with Win32 but because the exception handler does not handle the STATUS_FLOAT_MULTIPLE_FAULTS and STATUS_FLOAT_MULTIPLE_TRAPS cases. I guess you mean a division by zero using an SSE instruction results in STATUS_FLOAT_MULTIPLE_FAULTS and/or STATUS_FLOAT_MULTIPLE_TRAPS? And as you said, when it does not know what to do, it gives 217 that gets later translated to Control C, which to me is a bit misleading. I'd rather have a 202, External Exception. 202 is stack overflow. 217 is also used in the RTL as unhandled exception. I don't know how come that this code is used both for ctrl-c and unhandled exception. Probably a simple error from a long time ago that never got corrected. So right, now, using this I'm getting the appropriate exception, I'm just left wondering if this code (or a similar one) should be added to FreePascal so that other people are not having the same issue as I'm having. Probably. At least a quick web search seems to indicate this is a fairly well-known problem with SSE exceptions and Win32. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: How to avoid namespace name clashes after USES ?
Jürgen Hestermann wrote on Wed, 22 Aug 2012: Am 2012-08-22 13:45, schrieb Lukasz Sokol: Recompilation when one of units/libraries was upgraded, almost always implies rebuild. Who on Earth is so trigger-happy to upgrade, rebuild and not test for regressions? This is the only sane way to get the process going - document it *as MML said below*; That's not the point. Why on earth should a programmer *not* get as much help as possible from a programming language/compiler? That's the genuine purpose of a programming language. Indeed. Though I don't know whether it can be implemented easily (if at all). There are definitely some practical problems: * class/record helpers. The last class/record helper for a particular type that has come into scope automatically adds its methods to the helped class/record. If symbols can only be accessed by explicitly qualifying them with a separately specified unit alias, I don't see how you would activate class helpers from aliased units. Would these be an exception to the rule? Or would this require a new language construct to import all desired helper types explicitly? * Objective-Pascal categories are the same as class helpers, except that there an unlimited number of categories can be active for a single class at the same time. In the end, it's the same problem as above though. * Objective-Pascal also has the special id type. It is possible to call any method of any class type (and associated categories) in scope on a variable of this type. Again, I don't see a way how the proposed mechanism could be used to tell the compiler which classes it should search and which not if it should only search fully qualified identifiers from aliased units. There may be more issues, but these are the ones I can immediately think of. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EControlC instead of EZeroDivide when using SSE instructions
Jonas Maebe wrote: OBones wrote on Wed, 22 Aug 2012: Jonas Maebe wrote: You can try debugging syswin32_i386_exception_handler in rtl/win32/system.pp to see what exception Win32 reports instead. Thanks for the confirmation as I was heading that way when I posted the message, without much hope. But now that I have put that idea to full length, it became clear that the problem is not (entirely) with Win32 but because the exception handler does not handle the STATUS_FLOAT_MULTIPLE_FAULTS and STATUS_FLOAT_MULTIPLE_TRAPS cases. I guess you mean a division by zero using an SSE instruction results in STATUS_FLOAT_MULTIPLE_FAULTS and/or STATUS_FLOAT_MULTIPLE_TRAPS? Yes, that's it, sorry for not making it clearer. And as you said, when it does not know what to do, it gives 217 that gets later translated to Control C, which to me is a bit misleading. I'd rather have a 202, External Exception. 202 is stack overflow. 217 is also used in the RTL as unhandled exception. I don't know how come that this code is used both for ctrl-c and unhandled exception. Probably a simple error from a long time ago that never got corrected. Woops, typo, I meant 212, as can be found in RunErrorToExcept from sysutils.inc. That's where the Control C is coming from by the way. So right, now, using this I'm getting the appropriate exception, I'm just left wondering if this code (or a similar one) should be added to FreePascal so that other people are not having the same issue as I'm having. Probably. At least a quick web search seems to indicate this is a fairly well-known problem with SSE exceptions and Win32. Well, once one knows about the multiple traps/multiple faults, yes, it's easy to find it. But when starting from just a control C, it's much more complex. Once again, thanks for your help. Olivier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TSQLDBLibraryLoader committed for SQLDB
There are more problems: the library name is not cross-platform, so the project will no longer be cross-platform. Which is a far more serious problem, IMHO. (and one which would exist even if I had followed your suggestion of implementing the property in TSQLConnection). That is not a problem, that is a given. When you use the OI to fill in platform specific values the app becomes non cross-platform, whether it is a library name or an InitialDir in TFileDialog or a Filter in TFileNameEdit or ... (too long a list). Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: How to avoid namespace name clashes after USES ?
Am 22.08.2012 12:37, schrieb Timothy Madden: On 08/22/2012 09:57 AM, Marco van de Voort wrote: In our previous episode, Marcos Douglas said: [...] Requiring all functions to be allways fully qualified will make the most commom case worse than current implementation just to be better for the uncommon case. This is a step back, not forward... Timothy Madden want this, not me. ;-) This is necessary in order to guarantee thare can be no conflicts whatsoever. No matter how many units you want to USE in your program, no matter what versions of the units. It is not that bad, python uses that from the start. You must call os.path.basename(), and there is not way for you to call basename() directly (well, there is one, but they have taken special measures for it, so no name conflicts are possible). But for this to work, I need a way to alias the importing module, because not all units have a 2-letter name like os, for example I need something like: USES 'TrigonometricLibrary' AS 'trig' in 'pas/TrigonometricLibrary.pas' Of course I will not remove the existing behavior for USES, that is programmers can still say: USES charset, matrix, socket; and they get the behaviour they know. But if the programmer says: USES charset AS cs, matrix AS matrix, socket AS socket; than no symbols are made directly visible, and all of them need their prefix now (one of cs. or matrix. or socket. ). These prefixes are chosen by the programmer so thay may not create conflicts, as long as programmer sticks to the new form of USES. If both forms of USES are intermixed, like USES unit1, unit2, charset AS cs, matrix AS matrix, socket AS socket; than there is a chance that prefix cs will conflict with some unit1.cs symbol (either now or in a future version of unit1, or unit2). In this case I think it is appropriate to make the prefix cs., introduced by charset AS cs, to have precedence over unit1.cs. This is because the programmer must use the prefix cs. a lot in the program ((s)he has no choice, since the prefix is the only way to access simbols from unit charset). Feel free to extend the compiler with such a feature and provide a patch. If you give enough thought to it, provide enough tests and ensure that this won't influence old code too much the chances that your patch gets applied shouldn't be too bad. If you don't implement it... well... it may sound harsh, but: there are already many (partly more important) features that we need/want to implement... Note: I definitely prefer your solution instead of a warning ;) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to avoid namespace name clashes after USES ?
On Wed, Aug 22, 2012 at 3:57 AM, Marco van de Voort mar...@stack.nl wrote: In our previous episode, Marcos Douglas said: Yes, we know too... but how prevent this using third-party libs? For example, what do you think if I have a project that have a file called lnet.pas? Can I use this identifier? As much as any identifier. If you uses lnet; in the same unit where you import an unit with lnet symbol, you have to qualify it fully. I said identifier, but I mean FILE and, in that case, I can't use it. can't because the lnet project already uses, right? But I didn't know before...ohh my... and now, I can't use this project because I will got a compiler error because cant have two units with the same name. Do you think this is right? Because of this conflict that I proposed the syntax: uses foounit as f1 in '/path_1/foounit.pas', foounit as f2 in '/path_2/foounit.pas'; That only fixed it for that compilation unit, if another unit just uses foounit that leads to an inconsistent state. First, this is an idea, so should be improved. Second, this is a problem of programmer; if he forget, sorry for him. Third, maybe this sintaxe should be used just on project (not unit) and in units only use the alias (f1 and f2 in that case). Requiring all functions to be allways fully qualified will make the most commom case worse than current implementation just to be better for the uncommon case. This is a step back, not forward... Timothy Madden want this, not me. ;-) I have experience with it, and it is a nice feature if it is not mandatory. So you don't _have_ to qualify. If you know that a certain unit contains a lot of fairly common symbol names you import it qualified. (like many large API units, typically you only uses an handfull symbols from e.g. Windows, and it is not mandatory for the other situations). Modula2 went a step to far to only allow unqualified use if you name the symbols. That is too laboursome. Simply unqualified (what we have now) and qualified would go a long way. ... and all its effects and sideeffects are known. I agree. Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EControlC instead of EZeroDivide when using SSE instructions
Am 22.08.2012 13:47, schrieb OBones:
Jonas Maebe wrote:
OBones wrote on Wed, 22 Aug 2012:
Olivier SANNIER wrote:
Does any of you have any suggestion as to explain this behavior, and
best of
all, how to fix it?
I went further and changed the code this so that I can get better
details as to where the exception is coming from:
EControlC is the translation of run time error 217. The Win32
exception handler also sets error code 217 in case of an unknown
exception (the Win64 exception handler does the same, for that
matter). Apparently Win32 is not reporting that division-by-zero as
either STATUS_INTEGER_DIVIDE_BY_ZERO or STATUS_FLOAT_DIVIDE_BY_ZERO,
while Win64 does do this.
You can try debugging syswin32_i386_exception_handler in
rtl/win32/system.pp to see what exception Win32 reports instead.
Thanks for the confirmation as I was heading that way when I posted the
message, without much hope.
But now that I have put that idea to full length, it became clear that
the problem is not (entirely) with Win32 but because the exception
handler does not handle the STATUS_FLOAT_MULTIPLE_FAULTS and
STATUS_FLOAT_MULTIPLE_TRAPS cases.
And as you said, when it does not know what to do, it gives 217 that
gets later translated to Control C, which to me is a bit misleading. I'd
rather have a 202, External Exception.
Anyway, I installed my own exception handler using
SetUnhandledExceptionFilter, saving the return value and I wrote my own
overloaded version of the exception handler that does this:
function GetMXCSR: Cardinal;
asm
stmxcsr Result
end;
function MyUnhandledExceptionFilter(excep : PExceptionPointers) :
Longint;stdcall;
const
MXCSR_IE = $01; // invalid operation
MXCSR_DE = $02; // denormal
MXCSR_ZE = $04; // divide by zero
MXCSR_OE = $08; // overflow
MXCSR_UE = $10; // underflow
MXCSR_PE = $20; // precision
var
MXCSR: Cardinal;
begin
WriteLn('MyUnhandledExceptionFilter: ' + IntToHex(GetMXCSR, 2));
WriteLn(IntToHex(excep^.ExceptionRecord^.ExceptionCode, 8));
WriteLn(IntToHex(EXCEPTION_FLT_DIVIDE_BY_ZERO, 8));
if Assigned(PreviousUnhandledExceptionFilter) then
begin
if (excep^.ExceptionRecord^.ExceptionCode =
STATUS_FLOAT_MULTIPLE_FAULTS) or
(excep^.ExceptionRecord^.ExceptionCode =
STATUS_FLOAT_MULTIPLE_TRAPS) then
begin
MXCSR := GetMXCSR;
if MXCSR and MXCSR_IE = MXCSR_IE then
excep^.ExceptionRecord^.ExceptionCode :=
STATUS_FLOAT_INVALID_OPERATION
else if MXCSR and MXCSR_DE = MXCSR_DE then
excep^.ExceptionRecord^.ExceptionCode :=
STATUS_FLOAT_DENORMAL_OPERAND
else if MXCSR and MXCSR_ZE = MXCSR_ZE then
excep^.ExceptionRecord^.ExceptionCode :=
STATUS_FLOAT_DIVIDE_BY_ZERO
else if MXCSR and MXCSR_OE = MXCSR_OE then
excep^.ExceptionRecord^.ExceptionCode := STATUS_FLOAT_OVERFLOW
else if MXCSR and MXCSR_UE = MXCSR_UE then
excep^.ExceptionRecord^.ExceptionCode := STATUS_FLOAT_UNDERFLOW
else if MXCSR and MXCSR_PE = MXCSR_PE then
excep^.ExceptionRecord^.ExceptionCode :=
STATUS_FLOAT_INEXACT_RESULT;
end;
Result := PreviousUnhandledExceptionFilter(excep);
end;
end;
I know that I hide the case where there might be two errors at once, but
strangely enough, the MXCSR register only contained one exception bit
set in my case, so I don't understand why Win32 is giving a multiple
traps error.
So right, now, using this I'm getting the appropriate exception, I'm
just left wondering if this code (or a similar one) should be added to
FreePascal so that other people are not having the same issue as I'm
having.
Note to others: this is only ever useful in Win32 because Win64 does not
use the handlers set by SetUnhandledExceptionFilter
Win64 (and Win32 systems after Windows XP) do all use
SetUnhandledExceptionFilter, but we do use AddVectoredExceptionHandler
on Win64 (at least if not compiled using the new Win64 SEH code in 2.7.1
;) ) of which the handlers are called before the handler set by
SetUnhandledExceptionFilter is called.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Link against .so generated by ppumove
I've created a .so from a unit by compiling it to .ppu and .o and then executes ppumove on the .ppu. Now I've got the .so and .ppl (extension specified with -e), how can I tell fpc to link against them instead of the .ppu and .o? I've tried with -XD with no success. -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Link-against-so-generated-by-ppumove-tp5710959.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Link against .so generated by ppumove
leledumbo wrote on Wed, 22 Aug 2012: I've created a .so from a unit by compiling it to .ppu and .o and then executes ppumove on the .ppu. Now I've got the .so and .ppl (extension specified with -e), how can I tell fpc to link against them instead of the .ppu and .o? I've tried with -XD with no success. You probably can't. The above is all part of what will be necessary for supporting Delphi-style packages, but the functionality is not finished (and has been that way since a long time). Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: How to avoid namespace name clashes after USES ?
On Wed, Aug 22, 2012 at 9:22 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: Jürgen Hestermann wrote on Wed, 22 Aug 2012: Am 2012-08-22 13:45, schrieb Lukasz Sokol: Recompilation when one of units/libraries was upgraded, almost always implies rebuild. Who on Earth is so trigger-happy to upgrade, rebuild and not test for regressions? This is the only sane way to get the process going - document it *as MML said below*; That's not the point. Why on earth should a programmer *not* get as much help as possible from a programming language/compiler? That's the genuine purpose of a programming language. Indeed. Though I don't know whether it can be implemented easily (if at all). There are definitely some practical problems: * class/record helpers. The last class/record helper for a particular type that has come into scope automatically adds its methods to the helped class/record. If symbols can only be accessed by explicitly qualifying them with a separately specified unit alias, I don't see how you would activate class helpers from aliased units. Would these be an exception to the rule? Or would this require a new language construct to import all desired helper types explicitly? * Objective-Pascal categories are the same as class helpers, except that there an unlimited number of categories can be active for a single class at the same time. In the end, it's the same problem as above though. * Objective-Pascal also has the special id type. It is possible to call any method of any class type (and associated categories) in scope on a variable of this type. Again, I don't see a way how the proposed mechanism could be used to tell the compiler which classes it should search and which not if it should only search fully qualified identifiers from aliased units. There may be more issues, but these are the ones I can immediately think of. At least you thought about it. :) Well, must be a solution, but this (new) feature should please everyone first, I think. Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: How to avoid namespace name clashes after USES ?
On Wed, Aug 22, 2012 at 11:05 AM, Sven Barth pascaldra...@googlemail.com wrote: Am 22.08.2012 12:37, schrieb Timothy Madden: On 08/22/2012 09:57 AM, Marco van de Voort wrote: In our previous episode, Marcos Douglas said: [...] Requiring all functions to be allways fully qualified will make the most commom case worse than current implementation just to be better for the uncommon case. This is a step back, not forward... Timothy Madden want this, not me. ;-) This is necessary in order to guarantee thare can be no conflicts whatsoever. No matter how many units you want to USE in your program, no matter what versions of the units. It is not that bad, python uses that from the start. You must call os.path.basename(), and there is not way for you to call basename() directly (well, there is one, but they have taken special measures for it, so no name conflicts are possible). But for this to work, I need a way to alias the importing module, because not all units have a 2-letter name like os, for example I need something like: USES 'TrigonometricLibrary' AS 'trig' in 'pas/TrigonometricLibrary.pas' Of course I will not remove the existing behavior for USES, that is programmers can still say: USES charset, matrix, socket; and they get the behaviour they know. But if the programmer says: USES charset AS cs, matrix AS matrix, socket AS socket; than no symbols are made directly visible, and all of them need their prefix now (one of cs. or matrix. or socket. ). These prefixes are chosen by the programmer so thay may not create conflicts, as long as programmer sticks to the new form of USES. If both forms of USES are intermixed, like USES unit1, unit2, charset AS cs, matrix AS matrix, socket AS socket; than there is a chance that prefix cs will conflict with some unit1.cs symbol (either now or in a future version of unit1, or unit2). In this case I think it is appropriate to make the prefix cs., introduced by charset AS cs, to have precedence over unit1.cs. This is because the programmer must use the prefix cs. a lot in the program ((s)he has no choice, since the prefix is the only way to access simbols from unit charset). Feel free to extend the compiler with such a feature and provide a patch. If you give enough thought to it, provide enough tests and ensure that this won't influence old code too much the chances that your patch gets applied shouldn't be too bad. I proposed this feature, a couple years ago, I said now again and got the same answer: Feel free to extend the compiler :( I never worked with compilers so, I'm not the programmer for that task, at first, sorry. If you don't implement it... well... it may sound harsh, but: there are already many (partly more important) features that we need/want to implement... Well, I will continue waiting a couple of year... :) Note: I definitely prefer your solution instead of a warning ;) Thanks. Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TSQLDBLibraryLoader committed for SQLDB
On Wed, 22 Aug 2012, Ludo Brands wrote: There are more problems: the library name is not cross-platform, so the project will no longer be cross-platform. Which is a far more serious problem, IMHO. (and one which would exist even if I had followed your suggestion of implementing the property in TSQLConnection). That is not a problem, that is a given. When you use the OI to fill in platform specific values the app becomes non cross-platform, whether it is a library name or an InitialDir in TFileDialog or a Filter in TFileNameEdit or ... (too long a list). Indeed. To fix the problem of Loaded, I will see for some kind of hook mechanism. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Easier fpmake
Hi, As you know, FPC uses fpmake to compile everything in packages. As I've been steadily improving fcl-passrc for fpdoc, (it's now almost on par with the compiler, barring errors and assembler statetements), I created a small tool pas2fpm which takes as input a bunch of unit names, and outputs a ready-to-go fpmake.pp file. This means that pas2fpcm -o fpmake.pp *.pp is all you need to create a fpmake.pp file. (provided the shell expands wildcards) It analyses the sources, and creates an fpmake file that contains all units, the units have the correct dependencies (it analyses that too) and sets the UseResourceStrings property. If a particular source file is not compilable (parseable), it will add it anyway, but with a comment. The resulting fpmake.pp should compile and do what it needs to do. The tool can be found in utils/pas2fpm. I'd be pleased to hear of any comments or suggestions for improvement. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Unit testing aid...
Hi, for those that do unit testing, I committed a small tool pas2ut which analyses a unit, and creates a unit with a number of (empty) test cases. Obviously, the unit should be compileable (well, at least it must be parseable). The output is very configurable, and should cover a lot of cases that one is likely to encounter when doing unit tests. In particular, it handles creates tests for all members of the classes it finds in the unit (visibilities can be specified). The basis for this tool is in the fcl-passrc unit pastounittest unit. I would appreaciate feedback and suggestions. (For one, integration with the Lazarus IDE is on my list) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unit testing aid...
On Wed, Aug 22, 2012 at 2:08 PM, Michael Van Canneyt mich...@freepascal.org I would appreaciate feedback and suggestions. I believe could be interesting to have a similar tool to generate annotations to a unit(or set of units). The obvious example: insert calls to logging procedures at the enter and exit of each method, procedure or function of a unit. With options to specify targets (all procedures, name some, etc... ) and templates to insert. But anyway, thank you for these two tools, the pas2ut in special I believe will be very helpful. Daniel ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unit testing aid...
On 22 August 2012 18:47, Daniel Gaspary dgasp...@gmail.com wrote: The obvious example: insert calls to logging procedures at the enter and exit of each method, procedure or function of a unit. This is already possible for some time. Take a look at the 'fpprofiler' project. I have a version of it that I worked on at: https://github.com/graemeg/fpprofiler But I think there is a newer fpprofiler repository hosted somewhere else now... -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unit testing aid...
On 22/08/2012 18:08, Michael Van Canneyt wrote: Hi, for those that do unit testing, I committed a small tool pas2ut which analyses a unit, and creates a unit with a number of (empty) test cases. Obviously, the unit should be compileable (well, at least it must be parseable). I just updated from SVN (after make clean), using fpc 2.6.0 (only ppc, no full install, I admit it could be may fault, I still dare to ask for help) make.exe -C fpcmkcfg all make.exe[3]: Entering directory `C:/FPC/SVN/trunc/utils/fpcmkcfg' C:/FPC/SVN/trunk_build/gmkdir.exe -p units/i386-win32 C:/FPC/SVN/trunc/compiler/ppc386.exe -XX -CX -Ur -Xs -O2 -n -O2 -FuC:/FPC/SVN/trunc/rtl/units/i386-win32 -FuC:/FPC/SVN/trunc/packages/paszli b/units/i386-win32 -FuC:/FPC/SVN/trunc/packages/fcl-process/units/i386-win32 -FuC:/FPC/SVN/trunc/packages/hash/units/i386-win32 -FuC:/FPC/SV N/trunc/packages/fpmkunit/units/i386-win32 -FuC:/FPC/SVN/trunc/packages/fcl-base/units/i386-win32 -FE. -FUunits/i386-win32 -gl -O3 -Or -CpPE NTIUMM -OpPENTIUMM -di386 -dRELEASE fpcmkcfg.pp make.exe[3]: Leaving directory `C:/FPC/SVN/trunc/utils/fpcmkcfg' make.exe -C pas2ut all make.exe[3]: Entering directory `C:/FPC/SVN/trunc/utils/pas2ut' C:/FPC/SVN/trunk_build/gmkdir.exe -p units/i386-win32 C:/FPC/SVN/trunc/compiler/ppc386.exe -XX -CX -Ur -Xs -O2 -n -O2 -S2h -FuC:/FPC/SVN/trunc/rtl/units/i386-win32 -FuC:/FPC/SVN/trunc/packages/p aszlib/units/i386-win32 -FuC:/FPC/SVN/trunc/packages/fcl-process/units/i386-win32 -FuC:/FPC/SVN/trunc/packages/hash/units/i386-win32 -FuC:/F PC/SVN/trunc/packages/fpmkunit/units/i386-win32 -FuC:/FPC/SVN/trunc/packages/fcl-passrc/units/i386-win32 -FE. -FUunits/i386-win32 -gl -O3 -O r -CpPENTIUMM -OpPENTIUMM -di386 -dRELEASE pas2ut.pp pas2ut.pp(20,45) Fatal: Can't find unit CustApp used by pas2ut Fatal: Compilation aborted make.exe[3]: *** [pas2ut.exe] Error 1 make.exe[3]: Leaving directory `C:/FPC/SVN/trunc/utils/pas2ut' make.exe[2]: *** [pas2ut_all] Error 2 make.exe[2]: Leaving directory `C:/FPC/SVN/trunc/utils' make.exe[1]: *** [utils_all] Error 2 make.exe[1]: Leaving directory `C:/FPC/SVN/trunc' make.exe: *** [build-stamp.i386-win32] Error 2 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Easier fpmake
On 22 Aug 12, at 19:03, Michael Van Canneyt wrote: Hi Michael, As you know, FPC uses fpmake to compile everything in packages. As I've been steadily improving fcl-passrc for fpdoc, (it's now almost on par with the compiler, barring errors and assembler statetements), I created a small tool pas2fpm which takes as input a bunch of unit names, and outputs a ready-to-go fpmake.pp file. This means that pas2fpcm -o fpmake.pp *.pp is all you need to create a fpmake.pp file. (provided the shell expands wildcards) It analyses the sources, and creates an fpmake file that contains all units, the units have the correct dependencies (it analyses that too) and sets the UseResourceStrings property. If a particular source file is not compilable (parseable), it will add it anyway, but with a comment. The resulting fpmake.pp should compile and do what it needs to do. The tool can be found in utils/pas2fpm. I'd be pleased to hear of any comments or suggestions for improvement. Like support for platforms where wildcards are not expanded by shell? ;-) Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] a queried interface destroyed after writeln the address of it
I don't know if it's an undefined behavior or a bug.
The environment is fpc 2.6-bugfix branch x86-64 linux.
See the details in the attached code
program t2;
{$mode objfpc}
uses sysUtils;
type
ip= interface ['{f0cea771-a3f1-4223-bea2-c46c5f0f61fa}']
end;
iq= interface ['{11d7c834-7fcf-4837-bccc-fa92418a049b}']
end;
cl= class(tInterfacedObject, ip, iq)
public
destructor destroy; override;
end;
destructor cl.destroy;
begin
writeln('cl destroyed');
end;
type
cm= class(tInterfacedObject, ip, iq)
public
fi: cl;
property i0: cl read fi implements ip;
property i1: cl read fi implements iq;
constructor create; virtual;
destructor destroy; override;
end;
constructor cm.create;
begin
fi:= cl.create;
end;
destructor cm.destroy;
begin
freeAndNil(fi);
end;
var v: cm;
i: ip;
begin
v:= cm.create;
writeln(ptruint(v));
writeln(ptruint(v as ip));
// it prints 'cl destroyed'
// i:= v; // if uncommented this line, no exception would be raised. But in delphi, the next statement works well even leave it commented.
writeln(ptruint(v as iq));
// EAccessViolation : Access violation
end.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
