Re: [fpc-pascal] How to avoid namespace name clashes after USES ?

2012-08-22 Thread Sven Barth

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

2012-08-22 Thread Reinier Olislagers
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

2012-08-22 Thread Ludo Brands
 
 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 ?

2012-08-22 Thread 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).

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 ?

2012-08-22 Thread Timothy Madden
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

2012-08-22 Thread Ludo Brands
 (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

2012-08-22 Thread OBones

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

2012-08-22 Thread Jonas Maebe


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

2012-08-22 Thread michael . vancanneyt



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 ?

2012-08-22 Thread Lukasz Sokol
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

2012-08-22 Thread 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


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

2012-08-22 Thread Ludo Brands
 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

2012-08-22 Thread michael . vancanneyt



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 ?

2012-08-22 Thread Jürgen Hestermann

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

2012-08-22 Thread Jonas Maebe


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 ?

2012-08-22 Thread Jonas Maebe


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

2012-08-22 Thread OBones

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

2012-08-22 Thread Ludo Brands
 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 ?

2012-08-22 Thread Sven Barth

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 ?

2012-08-22 Thread Marcos Douglas
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

2012-08-22 Thread Sven Barth

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

2012-08-22 Thread leledumbo
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

2012-08-22 Thread Jonas Maebe


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 ?

2012-08-22 Thread Marcos Douglas
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 ?

2012-08-22 Thread Marcos Douglas
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

2012-08-22 Thread michael . vancanneyt



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

2012-08-22 Thread Michael Van Canneyt

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...

2012-08-22 Thread Michael Van Canneyt


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...

2012-08-22 Thread Daniel Gaspary
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...

2012-08-22 Thread Graeme Geldenhuys
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...

2012-08-22 Thread Martin

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

2012-08-22 Thread Tomas Hajny
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

2012-08-22 Thread ZAN DoYe

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