PDA

View Full Version : Free Pascal 2.0



WILL
16-05-2005, 06:42 AM
Wow, it's finally here... Free Pascal 2.0 has just been released! It is the first stable branch of the Pascal compiler that has been in development for 5 years, replacing the last stable version 1.0.10.


Get Free Pascal at www.freepascal.org ('http://www.freepascal.org/')!

savage
16-05-2005, 08:50 AM
Go FreePascal!!

cairnswm
16-05-2005, 10:12 AM
Now we just need to make a Game Dev version - then Will will be happy. :)

Robert Kosek
16-05-2005, 01:43 PM
Alright!

marmin
16-05-2005, 02:05 PM
Great! I've been waiting for it a long time.

Ultra
16-05-2005, 05:14 PM
Great news!

The betas have given me a couple of bugs which I hope are gone now. :wink:

cairnswm
17-05-2005, 05:21 AM
Anyone know the state of Larazus working with FPC 2.0.0.0.0.0.0.0.0.0.0.0?

{MSX}
17-05-2005, 06:56 AM
wow, we've also been slashdotted :P
http://it.slashdot.org/it/05/05/16/1934233.shtml?tid=156&tid=8

Legolas
17-05-2005, 12:05 PM
Anyone know the state of Larazus working with FPC 2.0.0.0.0.0.0.0.0.0.0.0?
I have recompiled Lazarus (from cvs, not stable) with fpc 2.0 and all seems working

savage
17-05-2005, 09:43 PM
I'm having some problems compile my JEDI-SDL stuff, that appeared to be working fine in 1.9.8. Anyone else experiencing problems?


On Linux, everything compiles, but when it comes to the linking stage it says cannot find "-lSDL". Any ideas?

On Win32 for another project it complains about mismatching types between POINT and TPoint but the same code compiles fine with Delphi 7 and used to compile with 1.9.8. Anyone know where POINT is defined in FPC?

cragwolf
18-05-2005, 12:43 AM
It compiles and links fine on my Linux system.


On Linux, everything compiles, but when it comes to the linking stage it says cannot find "-lSDL". Any ideas?

Do you have an libSDL.so link in your /usr/lib or /usr/local/lib directory?


On Win32 for another project it complains about mismatching types between POINT and TPoint but the same code compiles fine with Delphi 7 and used to compile with 1.9.8. Anyone know where POINT is defined in FPC?

The Point function is declared in the classes unit. It returns a TPoint record, which is defined in the types unit, as so:


{$ifdef Win32}
TPoint = Windows.TPoint;
{$else}
TPoint =
{$ifndef FPC_REQUIRES_PROPER_ALIGNMENT}
packed
{$endif FPC_REQUIRES_PROPER_ALIGNMENT}
record
X : Longint;
Y : Longint;
end;

savage
18-05-2005, 06:09 AM
In the Win32 project, my uses clause looks like this...

interface

uses
sdl,
SiegeInterfaces,
AdventureLog;
...
implementation

uses
{$IFDEF ver120}
FileCtrl,
{$ENDIF}
Classes,
SysUtils,
logger,
globals,
GameMainMenu;


and the procedure that causes the error looks like this...


procedure TGameJournal.MouseMove( Shift : TSDLMod; CurrentPos, RelativePos : TPoint );
const
FailName : string = 'TGameJournal.MouseMove';
begin
inherited;
end;


and when compiled it gives the following error...


GameJournal.pas(247,24) Error: function header doesn't match any method of this
class "TGameJournal.MouseMove(LongWord, POINT, POINT)"
GameJournal.pas(251,12) Error: Incompatible type for arg no. 3: Got "POINT", exp
ected "TPoint"


What's seems to be happening is that the implemenation code is using the Classes definition of TPoint, while the interface declaration is using the sdl definition of TPoint. This never happened in 1.9.8. if I comment out the Classes unit ( which I need for TStringList ), everything compiles, but I get an immediate AV when I try to run the exe.

Any suggestions?

On the Linux side of things, I will double check to see if I have a libSDL.so around.

Almindor
18-05-2005, 06:28 AM
Use sdl.TPoint;

Example:

procedure DoSomething(a: sdl.TPoint);
...

also in interface. This will clarify which TPoint is used and I think also cure the AV(IMHO it was caused by writing a Classes.TPoint into Sdl.TPoint which is much smaller)

The missing -lSDL is defenetly missing libsdl.so. Make sure you have developmenet packages of SDL installed.

{MSX}
18-05-2005, 07:05 AM
Umm i've recompiled one of my project with FPC 2 and it gives AV. With old versions it was running just fine. :?
I'll indagate a little

savage
18-05-2005, 08:31 AM
Use sdl.TPoint;

Sure this is a work around I tried already, but should not be necessary. As I mentioned , this code worked without errors with the v1.9.8 compiler. It should not be necessary because interface scoped references, in this case sdl.TPoint, should take precedence over implemenation scoped references like Classes.TPoint. At least, that is how it works in Delphi.

Also as I already mentioned, if I remove Classes from the uses clause ( and the associated TStringList code ) it compiles, but I still get and AV on startup :(.

It seems that MSX is having a similar problem with the AV.

cragwolf
18-05-2005, 11:14 AM
I reproduced your error on my win32 machine with the following test project (and unit):

testpoint.dpr:

program testpoint;

uses
SDL, testunit;

var
P: TPoint;
begin
P.X := 10;
P.Y := 5;
P := SwapXY(P);
Writeln('P.X = ', P.X, ', P.Y = ', P.Y);
end.

testunit.pas:

unit testunit;

interface

uses
SDL, Classes;

function SwapXY(P: TPoint): TPoint;

implementation

function SwapXY(P: TPoint): TPoint;
begin
SwapXY.X := P.Y;
SwapXY.Y := P.X;
end;

end.

I will test on Linux later.

savage
18-05-2005, 11:26 AM
Can this be passed on to the FreePascal guys?

I still think that the order and scope of the definitions should determine which unit take precedence. Does others agree or not?

cragwolf
18-05-2005, 11:35 AM
OK, I tested it on Linux and also reproduced the error.

Interestingly, if you swap the order of SDL and Classes in the uses section of the testunit.pas unit file, then it compiles properly and uses the SDL.TPoint definition. Perhaps this is by design, I don't know. I can post this on the Free Pascal forum if you like, and see what they have to say about the matter. But we need someone with FPC v1.9.8 (or less) to test it using my source code above to verify that things have changed from v1.9.8 (or less) to v2.0.0.

savage
18-05-2005, 11:45 AM
I have 1.9.8 on one of my other machines so will test you test app when I get home this evening.

Are you having the same problem with the AV? I will be re-installing my Win32 installation of 2.0 to make sure that an old install isn't interfereing.

cragwolf
18-05-2005, 11:52 AM
Here, I found this on page 107 (second-last paragraph) of the ref.pdf document that comes with FPC v2.0.0:


The uses clause serves to identify all units that are needed by the program. The system unit doesn?¢_Tt have to be in this list, since it is always loaded by the compiler. The order in which the units appear is significant, it determines in which order they are initialized. Units are initialized in the same order as they appear in the uses clause. Identifiers are searched in the opposite order, i.e. when the compiler searches for an identifier, then it looks first in the last unit in the uses clause, then the last but one, and so on.

This explains the behaviour we are seeing. In the source code above, when the compiler encounters TPoint in the testunit.pas file, it first looks in Classes, which is the last unit in the uses clause and where it finds the definition of TPoint, at which point it complains about incompatible types.

I will look at my earlier versions of this document to see if it's different.

cragwolf
18-05-2005, 11:53 AM
I'm not having the same problem with the AV. Just the compiler error. If you reinstall FPC, make sure that your PATH environment variable is correct. Remove all references to earlier versions of FPC. I access the PATH variable in WinXP by right clicking on My Computer then choosing Properties | Advanced | Environment Variables.

cragwolf
18-05-2005, 12:06 PM
The information is identical in earlier versions of the ref.pdf document. This suggests that if the compiler didn't complain about your code in earlier versions of FPC, then this must have been a bug in those earlier versions which has been fixed in v2.0.0. I can't access the Free Pascal web site at the moment or I could check their bug list to see if it was indeed a bug.

As to whether type definitions should be searched for in backwards order or forwards order, I'll leave that to the experts to mull over! :)

savage
18-05-2005, 02:39 PM
I'm not having the same problem with the AV. Just the compiler error. If you reinstall FPC, make sure that your PATH environment variable is correct. Remove all references to earlier versions of FPC. I access the PATH variable in WinXP by right clicking on My Computer then choosing Properties | Advanced | Environment Variables.

Yes that is the way I set it up last time.

savage
18-05-2005, 02:40 PM
The information is identical in earlier versions of the ref.pdf document. This suggests that if the compiler didn't complain about your code in earlier versions of FPC, then this must have been a bug in those earlier versions which has been fixed in v2.0.0. I can't access the Free Pascal web site at the moment or I could check their bug list to see if it was indeed a bug.

Maybe it's just me then, getting things confused. I put it down to old age.

savage
18-05-2005, 10:14 PM
OK the linking error on Linux is now sorted. Thanks guys.

Re-installed 2.0.0 and still get the AV on startup once the SoAoS project compiles. Smaller demos, like that ones that ship with JEDI-SDL compile and work fine, but the Siege of Avalon one just won't work with 2.0.0.

I just compiled SoAoS.dpr with 1.9.4 and it compiles and runs, not flawlessly, but I definately don't get any AVs. Just to clarify, by not flawlessly I mean that that version of the FreePascal compiler had some other issues which show themselves at runtime, but no AVs.

My next step will be to try and compile Siege of Avalon on Linux using FreePascal 2.0. That will need to wait until the morning as I am knackered.

savage
19-05-2005, 08:20 AM
ok I tried recompiling the project on Linux using 2.0 and it compiles but, again at run-time I get an Access Violation. I will need to uninstall 2.0. So there definatley seems that something has changed in the 2.0 compiler. As I mentioned this all used to work with 19.4-1.9.8 versions of the compiler.

savage
20-05-2005, 08:22 AM
Just to confirm, I reinstalled FPC 1.9.8 on Linux last night and as mentioned everything compiles and and I don't get an AV on startup. It doesn't work perfectly, but definately does not AV on startup.

This has been using the Delphi compatability mode ( -Sd ) all along. What are other developer's experiences with using the normal FreePascal ( objfpc I think it's called ) mode.

savage
21-05-2005, 01:24 PM
One of the guys on the JEDI-SDL list narrowed it down and I managed to put together a small sample application that shows the Access Violation.

program Project1;

{$APPTYPE CONSOLE}

uses
SysUtils;

type
TMyNotifyEvent = procedure of object;

TMyBaseWindow = class( TObject )
private
FOnRender: TMyNotifyEvent;
public
property OnRender: TMyNotifyEvent read FOnRender write FOnRender;
end;

TBaseInterface = class( TObject )
protected
procedure Render; virtual; abstract;
public
MainWindow : TMyBaseWindow;
constructor Create;
destructor Destroy; override;
procedure ResetInputManager;
end;

TMyInterface = class( TBaseInterface )
protected
procedure Render; override;
end;


{ TBaseInterface }
constructor TBaseInterface.Create;
begin
inherited;
WriteLn( 'TBaseInterface.Create' );
MainWindow := TMyBaseWindow.Create;
ResetInputManager;
end;

destructor TBaseInterface.Destroy;
begin
MainWindow.Free;
inherited;
end;

procedure TBaseInterface.ResetInputManager;
begin
WriteLn( 'ResetInputManager' );
MainWindow.OnRender := Render;
end;

{ TMyInterface }
procedure TMyInterface.Render;
begin
WriteLn( 'Rendering' );
end;

var
MyInterface : TMyInterface;

begin
MyInterface := TMyInterface.Create;

MyInterface.Render;

MyInterface.Free;
end.


When executed, this code works in 1.9.4-1.9.8, but does not work in 2.0.0.

I have submitted a bug report to the FreePascal site and it is bug ID 3997 (http://www.freepascal.org/bugs/showrec.php3?ID=3997).

{MSX}
31-05-2005, 10:39 AM
I have submitted a bug report to the FreePascal site and it is bug ID 3997 (http://www.freepascal.org/bugs/showrec.php3?ID=3997).

Any news on this bug? it's still unfixed.. did they tell anything on the ML?

savage
31-05-2005, 11:03 AM
That bug is still listed as "Unfixed". Another bug I submitted to do with IniFiles has now been fixed, but then I did supply a patch for it ( though it was not used ). Maybe if someon has the time to look at the compiler source and submit a patch it would get fixed more quickly.

Is the compiler source part of the source distro?

savage
01-06-2005, 11:37 AM
Are there any instructions on building Lazarus on Linux for the v2.0.0 compiler?