Re: [fpc-devel] Free Pascal 2.6.0 released!
Am 03.01.2012 11:43, schrieb Michalis Kamburelis: Felipe Monteiro de Carvalho wrote: On Sun, Jan 1, 2012 at 2:12 PM, Jeff Duntemannj...@duntemann.com wrote: Bravo! My only question is: Are there any particular issues with respect to using 2.6.0 with Lazarus? For desktop platforms I don't know any issues. It works just as good as 2.4 I just found one small issue: if you use Lazarus 0.9.30.2 to compile graphic applications, it will pass -WG option to FPC, on all platforms. However FPC 2.6.0 rejects this option (Error: Illegal parameter: -WG) on platforms where it's not sensible (like Linux). Bottom line: you can't graphic applications from Lazarus (including lazbuild) 0.9.30.2 using FPC 2.6.0 on Linux. This is of course fixed in Lazarus SVN by Mattias already :) See revisions 31125 and 31127 (http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revroot=lazarusrevision=31125 and http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revroot=lazarusrevision=31127 ). To workaround, you may need to backport these changes for Lazarus 0.9.30.2 (or just switch to Lazarus SVN, which was my solution :). You should mention this on the Lazarus list if you haven't done so already. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] Misterious error
Hello FPC, Tuesday, January 3, 2012, 10:01:54 PM, you wrote: Do you know which kind of code I must look for to isolate the problem ? SG I'd suggest looking at the constructors containing an 'exit' statement, SG but I'm not entirely sure. SG Does restoring removed line 287 of psub.pas remove the segfault? SG (The line was: SGinclude(current_procinfo.flags,pi_needs_implicit_finally); ) No, it does not :( The problem seems to happend in a destroy process, but as it only happends on close window, and in the close process a lot of objects and interfaces are destroyed I can not track each one :( I'll try to create a minimun project that fails, it would need a firebird and zeoslib. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pointer cache for fast class/pointer access.
-Original Message- From: Hans-Peter Diettrich Sent: Tuesday, January 03, 2012 14:56 To: FPC developers' list Subject: Re: [fpc-devel] Pointer cache for fast class/pointer access. Skybuck Flying schrieb: vValue := mDepth1.mDepth2.mDepth3.mValue; You can implement such a funny hierarchy in any language. So what? For the performance of the line of code above it matters if TObject or Object is used. Or as somebody else mentioned: object vs class. I could give a full test program which illustrates it ;) (It's kinda big though, a generator). But if you know anything about assembler you should be able to figure that stuff out yourself ?!? ;) :) But perhaps you more of a parser/text guy and less of an assembly/binary guy ? ;) Anyway what remains is the question: what's different between object and class or Tobject and object when it comes to capabilities. Also the slightly different syntax is kinda a shame... this would make it a little bit difficult to flip/flop between different object models. Flexible software is nice for when requirements change so it would be nice if changing object model would be easy to do to a certain degree ;) For example: MyClass := TMyClass.Create; versus MyObject.Create; ^ Why this difference ? It makes it less flexible to flip/flop :( Bye, Skybuck :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pointer cache for fast class/pointer access.
On Tue, Jan 3, 2012 at 11:26 AM, Skybuck Flying skybuck2...@hotmail.com wrote: -Original Message- From: Hans-Peter Diettrich Sent: Tuesday, January 03, 2012 14:56 To: FPC developers' list Subject: Re: [fpc-devel] Pointer cache for fast class/pointer access. Skybuck Flying schrieb: vValue := mDepth1.mDepth2.mDepth3.mValue; You can implement such a funny hierarchy in any language. So what? For the performance of the line of code above it matters if TObject or Object is used. Or as somebody else mentioned: object vs class. I said that. ;-) I could give a full test program which illustrates it ;) (It's kinda big though, a generator). But if you know anything about assembler you should be able to figure that stuff out yourself ?!? ;) :) But perhaps you more of a parser/text guy and less of an assembly/binary guy ? ;) Anyway what remains is the question: what's different between object and class or Tobject and object when it comes to capabilities. Also the slightly different syntax is kinda a shame... this would make it a little bit difficult to flip/flop between different object models. Flexible software is nice for when requirements change so it would be nice if changing object model would be easy to do to a certain degree ;) For example: MyClass := TMyClass.Create; versus MyObject.Create; ^ Why this difference ? It makes it less flexible to flip/flop :( TMyClass.Create: this is a call to the class constructor. MyObject.Create: this is a call to a method. Object type is (very) older than Class type and I don't think the core team wanted some similarity between Object and Class types. Everybody prefer classes so, the Object type was forgotten. I thinking if the Object type will be deprecated in the future... I hope not. Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pointer cache for fast class/pointer access.
Am 04.01.2012 13:33, schrieb Marcos Douglas: Object type is (very) older than Class type and I don't think the core team wanted some similarity between Object and Class types. Everybody prefer classes so, the Object type was forgotten. It wasn't the core team who introduced the differences between classes and objects, but Borland, who first created the object system in Turbo Pascal and later switched to the more advanced class system. I thinking if the Object type will be deprecated in the future... I hope not. As Free Pascal still writes on its flag that it is compatible to Turbo Pascal I doubt that it will be deprecated (also there is quite some code in the compiler and also in some packages which use object). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pointer cache for fast class/pointer access.
On 12/30/2011 07:09 PM, Hans-Peter Diettrich wrote: Better question: what common capabilitiers are implemented differently in Object and TObject? The funny thing being that TObject is a class and not an Object :-) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pointer cache for fast class/pointer access.
On Wed, Jan 4, 2012 at 10:26 AM, Sven Barth pascaldra...@googlemail.com wrote: Am 04.01.2012 13:33, schrieb Marcos Douglas: Object type is (very) older than Class type and I don't think the core team wanted some similarity between Object and Class types. Everybody prefer classes so, the Object type was forgotten. It wasn't the core team who introduced the differences between classes and objects, but Borland, who first created the object system in Turbo Pascal and later switched to the more advanced class system. True, you're right. I thinking if the Object type will be deprecated in the future... I hope not. As Free Pascal still writes on its flag that it is compatible to Turbo Pascal I doubt that it will be deprecated (also there is quite some code in the compiler and also in some packages which use object). Good to know ;) And, as somebody asked, what the advantages (performance?) using Object instead Class? I like to use Object to group routines instead of using procedure/functions... as a 'namespace' to not use the unit name as a prefix. I would to know what do you, guys, think about it. Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pointer cache for fast class/pointer access.
Am 04.01.2012 14:51, schrieb Marcos Douglas: I thinking if the Object type will be deprecated in the future... I hope not. As Free Pascal still writes on its flag that it is compatible to Turbo Pascal I doubt that it will be deprecated (also there is quite some code in the compiler and also in some packages which use object). Good to know ;) And, as somebody asked, what the advantages (performance?) using Object instead Class? They are basically similar to records with methods (which we now have as well...) if you use them directly (this means: not as pointer types): they are located on the stack and nested objects are part of the memory structure of the object. But if you use references to objects you work more like with classes as you have constructors, virtual methods and the objects are then located on the heap (thus you need to care for the memory management yourself). I like to use Object to group routines instead of using procedure/functions... as a 'namespace' to not use the unit name as a prefix. I would to know what do you, guys, think about it. I haven't implemented objects yet myself (besides testing whether some feature that was implemented for classes works for objects as well - which many features do!) and I also haven't used the new advanced records, so I'm the wrong person to ask this question ;) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Misterious error
04.01.2012 15:58, José Mejuto пишет:
Hello FPC,
Tuesday, January 3, 2012, 10:01:54 PM, you wrote:
Do you know which kind of code I must look for to isolate the problem
?
SG I'd suggest looking at the constructors containing an 'exit' statement,
SG but I'm not entirely sure.
SG Does restoring removed line 287 of psub.pas remove the segfault?
SG (The line was:
SG include(current_procinfo.flags,pi_needs_implicit_finally); )
No, it does not :( The problem seems to happend in a destroy process,
but as it only happends on close window, and in the close process a
lot of objects and interfaces are destroyed I can not track each one
:(
I was hoping otherwise... Actually it is very strange that reverting changes at line 700 (which you
mentioned earlier) removes the crash, while reverting line 287 does not, because removing
pi_needs_implicit_finally flag is the condition under which code at line 700 could ever execute.
I'll try to create a minimun project that fails, it would need a
firebird and zeoslib.
This is of course the best thing to do.
However, you can as well try the attached simple patch. It prevents temps referenced from 'finally'
blocks from being placed to registers.
Regards,
Sergei
Index: nflw.pas
===
--- nflw.pas(revision 19960)
+++ nflw.pas(working copy)
@@ -2000,12 +2000,23 @@
{*
TTRYFINALLYNODE
*}
+function reset_regvars(var n: tnode; arg: pointer): foreachnoderesult;
+ begin
+case n.nodetype of
+ temprefn:
+make_not_regable(n,[]);
+end;
+result:=fen_true;
+ end;
constructor ttryfinallynode.create(l,r:tnode);
begin
inherited create(tryfinallyn,l,r,nil,nil);
include(current_procinfo.flags,pi_uses_exceptions);
implicitframe:=false;
+{ Setting pi_uses_exceptions forces local vars to memory, but not
temps.
+ Make temps non-regable here. }
+foreachnodestatic(r,@reset_regvars,nil);
end;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Misterious error
On 04 Jan 2012, at 15:12, Sergei Gorelkin wrote: However, you can as well try the attached simple patch. It prevents temps referenced from 'finally' blocks from being placed to registers. While I'm not immediately certain how that would be done in the easiest way, it would be best if that were only done for temps that are also used outside the finally block. Temps that are created and destroyed inside the finally block can remain regable without any problems. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] Misterious error
Hello FPC, Wednesday, January 4, 2012, 3:12:55 PM, you wrote: SG I was hoping otherwise... Actually it is very strange that SG reverting changes at line 700 (which you SG mentioned earlier) removes the crash, while reverting line SG 287 does not, because removing SG pi_needs_implicit_finally flag is the condition under which SG code at line 700 could ever execute. I'll retest everything again with clear compiles to be sure... SG This is of course the best thing to do. SG However, you can as well try the attached simple patch. It SG prevents temps referenced from 'finally' SG blocks from being placed to registers. If it still crashes I'll apply the patch and retest again. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] property cam access private symbol from class in other unit
Only tested with 2.4.4; so if changed in 2.6 in unit2 TFoo = class(TObject) private FBar: integer; public property Bar: integer read FBar write FBar; end; which means in unit1, it is not allowed to access TFoo.FBar But it can be done: property Num: Integer read FFoo.FBar; see attached privprop.rar Description: Binary data ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property cam access private symbol from class in other unit
On 04 Jan 2012, at 18:13, Martin wrote: Only tested with 2.4.4; so if changed in 2.6 http://wiki.freepascal.org/User_Changes_2.6.0#Inaccessible_symbols_and_properties Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pointer cache for fast class/pointer access.
Michael Schnell schrieb: On 12/30/2011 07:09 PM, Hans-Peter Diettrich wrote: Better question: what common capabilitiers are implemented differently in Object and TObject? The funny thing being that TObject is a class and not an Object :-) That makes *what* difference? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pointer cache for fast class/pointer access.
Sven Barth schrieb: I thinking if the Object type will be deprecated in the future... I hope not. As Free Pascal still writes on its flag that it is compatible to Turbo Pascal I doubt that it will be deprecated (also there is quite some code in the compiler and also in some packages which use object). I don't see any reason why the Object type should be dropped. It's close to C++ objects, useful in porting code. It allows for static objects, e.g. in the stack, while TObject is bound to the heap (without tricks). I used Object types to e.g. emulate C bitfields, with a simple typecast of a variable into the according object... DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pointer cache for fast class/pointer access.
Sven Barth schrieb: And, as somebody asked, what the advantages (performance?) using Object instead Class? They are basically similar to records with methods (which we now have as well...) if you use them directly (this means: not as pointer types): they are located on the stack and nested objects are part of the memory structure of the object. To clarify nested: object types can inherit from other objects, like TObject can do - that's an advantage over records. They even can emulate multiple inheritance, because (as you pointed out) contained objects become part of the composed object, do not reside in a different (heap) area. But if you use references to objects you work more like with classes as you have constructors, virtual methods and the objects are then located on the heap (thus you need to care for the memory management yourself). Objects with virtual methods must not necessarily reside in the heap. A VMT reference is inserted into the object, as soon as the first virtual method is added. This leads to VMT pointers which do not reside at the begin of the instance memory, similar to interface references. OTOH the VMT (classtype!) reference at the begin of *every* TObject allows for is and as operators (RTTI). DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pointer cache for fast class/pointer access.
Skybuck Flying schrieb: -Original Message- From: Hans-Peter Diettrich Sent: Tuesday, January 03, 2012 14:56 To: FPC developers' list Subject: Re: [fpc-devel] Pointer cache for fast class/pointer access. Skybuck Flying schrieb: vValue := mDepth1.mDepth2.mDepth3.mValue; You can implement such a funny hierarchy in any language. So what? For the performance of the line of code above it matters if TObject or Object is used. Ah, now I understand what you mean. Nonetheless I don't see sane reasons for creating such (deeply nested) structures in real life code - records would serve the same (demonstrated) purpose. Also the slightly different syntax is kinda a shame... this would make it a little bit difficult to flip/flop between different object models. I don't see much of a difference here. Objects without constructors can be declared as simple variables. Objects on the heap have no advantage over TObjects, so that class types can be used for that purpose everywhere. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pointer cache for fast class/pointer access.
On Wed, Jan 4, 2012 at 3:03 PM, Hans-Peter Diettrich drdiettri...@aol.com wrote: Sven Barth schrieb: I thinking if the Object type will be deprecated in the future... I hope not. As Free Pascal still writes on its flag that it is compatible to Turbo Pascal I doubt that it will be deprecated (also there is quite some code in the compiler and also in some packages which use object). I don't see any reason why the Object type should be dropped. It's close to C++ objects, useful in porting code. It allows for static objects, e.g. in the stack, while TObject is bound to the heap (without tricks). So, Object types is indicated only for compatibility? In your opinion, for the atual code, we have some benefit using Object (stack) instead Class (heap)? I used Object types to e.g. emulate C bitfields, with a simple typecast of a variable into the according object... What is bitfields? Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property cam access private symbol from class in other unit
On 04/01/2012 17:27, Jonas Maebe wrote: On 04 Jan 2012, at 18:13, Martin wrote: Only tested with 2.4.4; so if changed in 2.6 http://wiki.freepascal.org/User_Changes_2.6.0#Inaccessible_symbols_and_properties I just upgraded to 2.6.0 - It still compiles (recompiling fpc trunk now, may test that later) Note, that I am not accessing a private field of the parent class (like in the link). TForm1 = class(TForm) public FFoo: TFoo; property Num: Integer read FFoo.FBar; end; TForm1 and TFoo are not related. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property cam access private symbol from class in other unit
On Wednesday, January 04, 2012 01:26:52 pm Martin wrote:
TForm1 = class(TForm)
public
FFoo: TFoo;
property Num: Integer read FFoo.FBar;
end;
Just a 'for your info' note: Kylix doesn't allow the above. Nor does it allow
accessing the property FFoo.Bar as a parameter to the read. This makes sense
to me, though, because FFoo may very well be nil when code tries to read
Form1.Num.
Here are my foo and form units, as well as the command line compiler's
complaint about them:
~/tmp/k3tests/access_private_class_member $dcc Project1.dpr
Borland Delphi for Linux Version 14.5
Copyright (c) 1983,2002 Borland Software Corporation
main_unit.pas(13) Error: Record, object or class type required
main_unit.pas(25)
Project1.dpr(6) Fatal: Could not compile used unit 'main_unit.pas'
Sorry if this is old news. :) Here are the files:
unit foo_unit;
interface
uses
Classes;
type
TFoo = class
private
FBar : Integer;
public
property Bar : Integer read FBar write FBar;
end;
implementation
end.
unit main_unit;
interface
uses
SysUtils, Types, Classes, Variants, QTypes, QGraphics, QControls, QForms,
QDialogs, QStdCtrls, foo_unit;
type
TForm1 = class(TForm)
public
Foo : TFoo;
property Num: Integer read Foo.Bar;
end;
var
Form1: TForm1;
implementation
{$R *.xfm}
end.
Best regards,
Pete C.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property cam access private symbol from class in other unit
On 04/01/2012 20:01, Pete Cervasio wrote: On Wednesday, January 04, 2012 01:26:52 pm Martin wrote: TForm1 = class(TForm) public FFoo: TFoo; property Num: Integer read FFoo.FBar; end; Just a 'for your info' note: Kylix doesn't allow the above. Nor does it allow accessing the property FFoo.Bar as a parameter to the read. This makes sense to me, though, because FFoo may very well be nil when code tries to read Form1.Num. Well the property is rejected by fpc too. But then a property is always treated as if it was a function (or procedure for the setter). So that is more than referring to a field. To be honest I discovered this by accident, it was meant to use a field from a record... the nil situation is not a concern here, a programmer can always write code that can fail on nil pointers. FFoo could well have the same live time as the Form... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pointer cache for fast class/pointer access.
Am 04.01.2012 19:24, schrieb Hans-Peter Diettrich: Skybuck Flying schrieb: -Original Message- From: Hans-Peter Diettrich Sent: Tuesday, January 03, 2012 14:56 To: FPC developers' list Subject: Re: [fpc-devel] Pointer cache for fast class/pointer access. Skybuck Flying schrieb: vValue := mDepth1.mDepth2.mDepth3.mValue; You can implement such a funny hierarchy in any language. So what? For the performance of the line of code above it matters if TObject or Object is used. Ah, now I understand what you mean. Nonetheless I don't see sane reasons for creating such (deeply nested) structures in real life code - records would serve the same (demonstrated) purpose. If one really suffers from cache misses, then using prefetch(...) might be a good idea. And if data is heavily used, the CPU keeps it in the caches anyways and then CPU is very good in this. I doubt any serious perforance where data locked into L1 cache could improve program performance. Experience showed that any static predictions like this are much worse than that what the CPU can do at run time. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] cortex-m0 support
With the cortex-m0 parts now hitting the market I think it is time to bring up the topic of thumb support again, not arm not thumb2 but thumb (the only common instruction set across almost the entire arm family (the exception being the pre-armv4t)). cortex-m0 and -m1 are armv6-m based, the -m3 and -m4 are armv7m based. I count something like 20 armv6m instructions that are not in the all thumb variants category. something like 148 armv7m that are not supported by armv6m nor all thumb variants. Just a rough count. This is why you will see folks saying that the cortex-m0 and -m1 are thumb only not thumb2. The cortex-m0 based mbed's have hit the street btw, available at sparkfun and other places. Note that gcc and llvm fail to build working code for the cortex-m0, when you specify cortex-m0 you get thumb2 code which fails miserably. David ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
