Re: [fpc-devel] Proof of Concept ARC implementation
Sven Barth schrieb: Hello together! I've now finished my Proof of Concept ARC implementation which is based on the RFC I published a few weeks back: http://lists.freepascal.org/fpc-devel/2014-September/034263.html Fine :-) To recap: [...] - a class instance is destroyed once the reference count reaches zero (and Free does not work for them) Shouldn't Free be usable as a finalizer, clearing all references to other objects within this instance? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Proof of Concept ARC implementation
Hello together!
I've now finished my Proof of Concept ARC implementation which is based
on the RFC I published a few weeks back:
http://lists.freepascal.org/fpc-devel/2014-September/034263.html
To recap:
- there are no reference counted classes by default, but reference
counting can be introduced to sub hierarchies by declaring a class as
"refcounted"
- only variables with a static type of those "refcounted" classes will
experience reference counting and thus IncRef/DecRef calls
- a class instance is destroyed once the reference count reaches zero
(and Free does not work for them)
- variables/paremeters/fields can be declared as "weak" which disables
reference counting for them
- all variables/parameters/fields that are of a non reference counted
class type are implicitely assumed as "weak" (also "self" is assumed as
"weak")
- TObject is extended with methods to allow manual reference counting
and to determine whether an instance is reference counted
Please keep in mind that this is a proof of concept implementation to
have something on which further discussions can be based on, thus there
can still be bugs here and there (that said: the testsuite completes
without regressions). Also it's nowhere said that this will be merged to
trunk as is in the future.
The code is available here:
http://svn.freepascal.org/svn/fpc/branches/svenbarth/arc
And here is a test program (and compiled with -gh no leaks are reported
;) ):
=== code begin ===
program trefcounted;
{$mode objfpc}
type
TTest = class refcounted // a parent class would follow immediately
after "refcounted" like for "sealed" and "abstract"
Field: LongInt;
constructor Create;
destructor Destroy; override;
procedure IncField;
end;
TTest2 = class
Test1: TTest;
Test2: TTest weak;
Test3: TTest;
constructor Create(aTest1: TTest; aTest2: TTest weak);
end;
TTest3 = class(TTest)
end;
TTestRec = record
NonWeak: TTest;
IsWeak: TTest weak;
end;
constructor TTest.Create;
begin
Field := $1234ABCD;
end;
destructor TTest.Destroy;
begin
Writeln(ClassName, '.Destroy');
inherited;
end;
procedure TTest.IncField;
begin
Inc(Field);
end;
constructor TTest2.Create(aTest1: TTest; aTest2: TTest weak);
begin
Test1 := aTest1;
Test2 := aTest2;
Test3 := TTest.Create;
end;
procedure TestValue(aTest: TTest);
begin
Writeln(aTest.ARCRefCount);
end;
procedure TestConst(const aTest: TTest);
begin
Writeln(aTest.ARCRefCount);
end;
procedure TestVar(var aTest: TTest);
begin
Writeln(aTest.ARCRefCount);
end;
procedure TestWeak(aTest: TTest weak);
begin
Writeln(aTest.ARCRefCount);
end;
function TestWeakResult(aTest: TTest weak): TTest weak;
begin
Result := aTest;
end;
procedure Test;
var
t: TTest;
t2: TTest;
o: TObject;
t3: TTest weak;
begin
Writeln('Test');
Writeln(HexStr(Pointer(t)));
t := TTest.Create;
Writeln(HexStr(t));
Writeln('Before TTest assignment: ', t.ARCRefCount);
t2 := t;
Writeln('Before TObject assignment: ', t.ARCRefCount);
o := t;
Writeln('Before weak assignment: ', t.ARCRefCount);
t3 := t;
Writeln('Before TestValue: ', t.ARCRefCount);
TestValue(t);
Writeln('Before TestConst: ', t.ARCRefCount);
TestConst(t);
Writeln('Before TestVar: ', t.ARCRefCount);
TestVar(t);
Writeln('Before TestWeak: ', t.ARCRefCount);
TestWeak(t);
Writeln('Before TestWeakResult: ', t.ARCRefCount);
t2 := TestWeakResult(t);
Writeln('Before IncField: ', t.ARCRefCount);
t.IncField;
end;
procedure Test2;
var
r, r2: TTestRec;
begin
Writeln('Test2');
Writeln(HexStr(Pointer(r.NonWeak)), ' ', HexStr(Pointer(r.IsWeak)));
r.NonWeak := TTest.Create;
Writeln('After create: ', r.NonWeak.ARCRefCount);
r.IsWeak := r.NonWeak;
Writeln('After weak assignment: ', r.NonWeak.ARCRefCount);
r2 := r;
Writeln('After record assignment: ', r.NonWeak.ARCRefCount);
r.NonWeak := Nil;
Writeln('After nil: ', r2.NonWeak.ARCRefCount);
end;
procedure Test3;
var
t, t1: TTest;
t2: TTest2;
begin
Writeln('Test3');
t := TTest.Create;
t1 := TTest.Create;
t2 := TTest2.Create(t, t1);
Writeln('t: ', t.ARCRefCount, ' t1: ', t1.ARCRefCount);
t2.Free;
Writeln('t: ', t.ARCRefCount, ' t1: ', t1.ARCRefCount);
end;
procedure Test4;
var
t: TTest;
t2, t1: TTest3;
begin
Writeln('Test4');
t2 := TTest3.Create;
Writeln('t2: ', t2.ARCRefCount);
t := t2;
Writeln('t2: ', t2.ARCRefCount);
t1 := t2;
Writeln('t2: ', t2.ARCRefCount);
t := Nil;
Writeln('t2: ', t2.ARCRefCount);
end;
begin
Test;
Test2;
Test3;
Test4;
Writeln('Done');
end.
=== code end ===
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dumping the syntax tree
I didn't knew about that! This can be very helpful for generating C compatible interfaces for DLLs. On Thu, Oct 23, 2014 at 10:36 PM, Michael Van Canneyt < mich...@freepascal.org> wrote: > > See the FPC sources: > > packages/fcl-passrc/examples/test_parser.pp > > Michael. > > > On Thu, 23 Oct 2014, Vsevolod Alekseyev wrote: > > What test program, please? Where? >> >> On 10/23/2014 4:12 PM, Michael Van Canneyt wrote: >> >>> >>> >>> You had better use the fcl-passrc units. They dump a complete syntax >>> tree. >>> It is used to generate (a currently limited version of) javascript, and >>> used to create documentation. >>> >>> so it should be usable to generate C code... >>> >>> The test program re-dumps a pascal program. Presumably you can adapt >>> that to generate C. >>> >>> Michael. >>> >>> On Thu, 23 Oct 2014, Kostas Michalopoulos wrote: >>> >>> Lazarus has a Pascal tokenizer unit under components\mpaslex\mpaslex.pp. It seems old and doesn't look like it supports the full FPC syntax, but it might be a starting point since most likely you can convert the code to C++ with GNU GCC extensions (nested functions, etc) straightforward. >>> ___ >>> fpc-devel maillist - fpc-devel@lists.freepascal.org >>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel >>> >>> >> ___ >> fpc-devel maillist - fpc-devel@lists.freepascal.org >> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel >> >> ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
On 10/24/2014 03:32 PM, Joost van der Sluis wrote:
On 10/24/2014 12:39 AM, Jonas Maebe wrote:
On 23/10/14 17:16, Vsevolod Alekseyev wrote:
There's no separate makefile for fpcmake alone, is there?
It used to be as simple as going into utils/fpcm and performing a "make
all", but with the new FPC-based build system I think that is
unfortunately no longer possible.
The same holds with the fpmake-system. When your fpmake uses some new
functionality that is only available in the new compiler or a new
fpmkunit-unit, you have a problem. For this case fppkg uses two
configurations. One to compile the fpmake.pp-files, and one to compile
the actual packages. But that's not configured by default.
I've tried to build trunk's fpcm with fpc 2.6.2 and that failed due to
new features being used in the fpmake.pp. ;(
So in this case already you'll need the double-fpmake-setup. Or you can
use the attached patch.
Joost.
Index: utils/fpcm/fpmake.pp
===
--- utils/fpcm/fpmake.pp (revision 28900)
+++ utils/fpcm/fpmake.pp (working copy)
@@ -85,7 +85,9 @@
BuildEngine.Log(vlWarning, 'File revision.inc not found. Svn-revision will not be included in fpcmake executable.');
Exit;
end;
-
+{$IFDEF VER2_6}
+ Exit;
+{$ELSE}
// Run svn info, and catch output.
P := sender as TPackage;
P.Options.Add('-dREVINC');
@@ -194,6 +196,7 @@
end
else
BuildEngine.Log(vlWarning,'Subversion executable (svn) not found. Svn-revision in fpcmake executable might be out of date.');
+{$ENDIF}
end;
end;
{$endif HAS_UNIT_PROCESS}
@@ -221,7 +224,9 @@
P.Directory:=ADirectory;
{$endif ALLPACKAGES}
P.Version:='2.7.1';
+{$IFNDEF VER2_6}
P.SeparateArchive:=false;
+{$ENDIF}
P.Dependencies.Add('fcl-base');
@@ -233,8 +238,10 @@
writeln('Process-unit not available. Svn-revision in fpmake executable might be out-of-date.');
{$endif HAS_UNIT_PROCESS}
+{$IFNDEF VER2_6}
Data2IncBin := AddProgramExtension('data2inc',Defaults.BuildOS);
p.Commands.AddCommand(caBeforeCompile, Data2IncBin, '-b -s fpcmake.ini fpcmake.inc fpcmakeini','fpcmake.inc','fpcmake.ini');
+{$ENDIF}
T:=P.Targets.AddUnit('fpcmmain.pp');
T.install:=false;
T.ResourceStrings:=true;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
On 10/24/2014 12:39 AM, Jonas Maebe wrote: On 23/10/14 17:16, Vsevolod Alekseyev wrote: There's no separate makefile for fpcmake alone, is there? It used to be as simple as going into utils/fpcm and performing a "make all", but with the new FPC-based build system I think that is unfortunately no longer possible. With the fpcmake-buildsystem it was possible to build one package from fpc-trunk using a fpc-release-compiler with a simple "make all". But the release-version of all dependencies were used. So when fpcm-trunk uses a new feature in trunk-fcl-base, there was no way to compile the trunk-version of fpcm with a release-compiler. With fppkg this all changed. Now it's always possible to compile (single) trunk-packages using the latest release-compiler. The command has been altered, though. You have to do 'fppkg build', instead of 'make all'. Fppkg will then compile all the packages that fpcm depend on using the new compiler. This does not work if the new fpcm-package uses new compiler features offcourse. And the same holds for the rtl because that one is still compiled using the fpcmake-system. There's one problem, still, and that's the same problem you have with the fpcmake-system. When the Makefile's do not support a new target, you have to re-generate those first using a new version of fpcmake. The same holds with the fpmake-system. When your fpmake uses some new functionality that is only available in the new compiler or a new fpmkunit-unit, you have a problem. For this case fppkg uses two configurations. One to compile the fpmake.pp-files, and one to compile the actual packages. But that's not configured by default. Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
On 24 Oct 2014, at 14:29, Marco van de Voort wrote: Btw, afaik running make in utils/fpcm would only work if you had reached fcl-base, since you need those include dirs. It worked because the release compiler would use its own fcl-base units. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
In our previous episode, Jonas Maebe said: > The question here was about implementing a new target in FPC and then > regenerating the makefiles for that new target. This requires an fpcmake > built from the trunk sources. Yes, I thought it was the common missing fpcmake during the install stage, sorry for that. Btw, afaik running make in utils/fpcm would only work if you had reached fcl-base, since you need those include dirs. Maybe copying the .fpcmake files will help, but I think this is better fixed first on a supported target. I played a bit, and just running fpcmake -Tall Makefile.fpc.fpcmake won't work since it drags in the fpmkunit dependency of fcl-base fpmake oriented Makefile.fpc. So one would need to copy fcl-base's Makefile.fpc.fpcmake to Makefile.fpc first or adapt fpcmake -Tall to give .fpcmake preference over Makefile.fpc if the argument ends in .fpcmake or so. Or remove the requires from the fpcm Makefile.fpc.fpcmake file, and then regenerate and pass suitable -Fu and -Fi paths to fcl-base in OPT ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
