Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On Tue, 27 Nov 2012, luiz americo pereira camara wrote: 2012/11/27 Michael Van Canneyt mich...@freepascal.org: On Tue, 27 Nov 2012, luiz americo pereira camara wrote: Hi, i requested a change to observer interface with some considerations in http://bugs.freepascal.org/view.php?id=23394 It will not happen. If you want to pass around interfaces safely, then you need to implement them as descendents of IUnknown to maintain reference counts. They are implemented as CORBA interfaces exactly to avoid the overhead of IUnknown. The consequence is that you must pass around the objects themselves. I don't see the point. It would be true if the IFPObserved (e.g., TPersistent) takes ownership of the attached observers. That is not the case. Currently, in the observer feature, there's no difference between plain TObject and corba interface (IFPObserver) regarding the life cycle management. Correct. Both there are no guarantees that they will still be alive when accessed. The current approach limits the programmer flexibility and adds unnecessary overhead. As practical example take a LCL Form that is supposed to be observed. It takes an Observer property and attach it to certain child controls (TEdit etc) 1) Currently i'm forced to declare as the Observer property as an TObject. If i declare Observer property as IFPObserver i cannot attach to children controls. I do not understand this ? 2) Each time i attach to a child control this Observer property will be queried to see if implements IFPObserver (but we already know that it implements, we already checked !!!) You only gain speed when notifying. When calling FPOAttachAbserver or FPODetachAbserver, you would need to typecast some object anyway if we would change the interface, so there is no speed gain there... During notification, we can gain speed by internally storing the interface. So, i keep my points. Even because is not a big change with easy implementation that will fix the above issues. It IS a big change. There is production code out there that uses this, and this is an incompatible change. I can change the internals so speed is gained during notifyobservers, but I do not see sufficient reasons to change the interface and introduce an incompatibility. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
2012/11/28 michael.vancann...@wisa.be It IS a big change. There is production code out there that uses this, and this is an incompatible change. Then Luiz is right on time with his proposal, with the frist release candidate of the first release that contains this feature. If production code already uses it, then the production code writers must have taken a risk for change knowing that this was a not yet released feature. I can change the internals so speed is gained during notifyobservers, but I do not see sufficient reasons to change the interface and introduce an incompatibility. Incompatibility with not yet released code? Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
28.11.2012 16:23, Vincent Snijders wrote: 2012/11/28 michael.vancann...@wisa.be It IS a big change. There is production code out there that uses this, and this is an incompatible change. Then Luiz is right on time with his proposal, with the frist release candidate of the first release that contains this feature. If production code already uses it, then the production code writers must have taken a risk for change knowing that this was a not yet released feature. This is exactly my minds. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On Wed, 28 Nov 2012, Vincent Snijders wrote: 2012/11/28 michael.vancann...@wisa.be It IS a big change. There is production code out there that uses this, and this is an incompatible change. Then Luiz is right on time with his proposal, with the frist release candidate of the first release that contains this feature. If production code already uses it, then the production code writers must have taken a risk for change knowing that this was a not yet released feature. It's rather the opposite. This code was developed and has been in use since years. I simply integrated the code in the classes unit, making the production code simpler. Apart from that, I don't see the point in changing it to an interface. At some point, there must be an object, and at some point, there is a typecast, this is unavoidable. Nothing is gained by changing the API to use an interface. I can see the speed argument when notifying, but that can be changed by an internal change, without API changes. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
In our previous episode, michael.vancann...@wisa.be said: Then Luiz is right on time with his proposal, with the frist release candidate of the first release that contains this feature. If production code already uses it, then the production code writers must have taken a risk for change knowing that this was a not yet released feature. It's rather the opposite. This code was developed and has been in use since years. I simply integrated the code in the classes unit, making the production code simpler. Yes, and by doing that you submit it to public scrutiny, risking other opinions. Apart from that, I don't see the point in changing it to an interface. At some point, there must be an object, and at some point, there is a typecast, You often can't reroot external components, but if they support tcomponent (and thus Tinterfacedobject), you can add an interface in a child class. I can see the speed argument when notifying, but that can be changed by an internal change, without API changes. As Paul and Vincent correctly state, from the view of the FPC project, the interface is not yet fixed. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On 2012-11-28 08:23, Vincent Snijders wrote: production code already uses it, then the production code writers must have taken a risk for change knowing that this was a not yet released feature. +1 I thought it was a known fact that if you use FPC Trunk in production code, you stand a very likely chance that your production code will be broken at some point. Nothing in FPC Trunk is cast in stone. Though I must admit, this code has been around for some time (at least in my Inbox). I can see where Luiz is coming from. Most Observer implementations seem to be based on interfaces - but that is no hard and fast rule. I also understand Michael's point that AddObserver() and AttachObserver() doesn't need to take interfaces as a parameter. Most developers think that all Interface code is reference counted, but this is simply not true. eg: CORBA interfaces, which is used internally for the Observer support in FPC. The FPC implementation is very similar to what we have in tiOPF for many years, and there it works very well. Though in tiOPF the AttachObserver() and DetachObserver() parameters are a class type we know supports the the observer interface. In FPC this is not the case, though still not a show-stopper. You simply need to double check with a few Supports(obj, IFPObserved, intf) calls where needed. Luiz, could you produce a small sample application (or show the code you are working on for Lazarus) where you think the current FPC Observer implementation doesn't work. Your initial bug report doesn't include any test project to show the issue. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On Wed, 28 Nov 2012, Marco van de Voort wrote: In our previous episode, michael.vancann...@wisa.be said: Then Luiz is right on time with his proposal, with the frist release candidate of the first release that contains this feature. If production code already uses it, then the production code writers must have taken a risk for change knowing that this was a not yet released feature. It's rather the opposite. This code was developed and has been in use since years. I simply integrated the code in the classes unit, making the production code simpler. Yes, and by doing that you submit it to public scrutiny, risking other opinions. Sure. Based on feedback, the interface was already changed slightly, but not in a super invasive way as asked here. Apart from that, I don't see the point in changing it to an interface. At some point, there must be an object, and at some point, there is a typecast, You often can't reroot external components, but if they support tcomponent What does reroot external components mean ? (and thus Tinterfacedobject), you can add an interface in a child class. The interfaces are CORBA, so there is no need for TInterfacedObject. That the interface is CORBA was a conscious decision so reference counting and all the overhead associated with it was avoided. As far as I know, this rules out COM provided interfaces (if this is what you refer to by external components). That is a tradeoff I find acceptable. I can see the speed argument when notifying, but that can be changed by an internal change, without API changes. As Paul and Vincent correctly state, from the view of the FPC project, the interface is not yet fixed. Correct. But I want to see some stronger reasons than the ones given before I change the API. Like I said: The one about speed in notifyupdates is not a problem, I'll improve that, implementation speed is important. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On 2012-11-28 09:41, Marco van de Voort wrote: You often can't reroot external components, but if they support tcomponent (and thus Tinterfacedobject), you can add an interface in a child class. You can add a CORBA interface to any existing class, and it doesn't need to descend from TInterfacedObject either. CORBA is not COM interfaces. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On 2012-11-28 10:07, Graeme Geldenhuys wrote:
You can add a CORBA interface to any existing class, and it doesn't need
to descend from TInterfacedObject either. CORBA is not COM interfaces.
In case anybody is in doubt. Here is a small example where CORBA
interfaces are attached to TComponent (aka TInterfacedObject
descendants) and TObject classes.
With CORBA interfaces - unlike COM interfaces - we can extend *any*
class. A lot more useful!
8-8-8-8-8
MyShape was created
MyShape is being freed
MyShape was created
AttachObserver called - MyShape
MyShape is being freed
MyNonInterfacedObjectClass was created
AttachObserver called - MyNonInterfacedObjectClass
MyNonInterfacedObjectClass is being freed
8-8-8-8-8
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
program test;
{$mode objfpc}{$h+}
{$ifdef mswindows}
{$apptype console}
{$endif}
{$interfaces corba}
uses
Classes, SysUtils;
type
IObserved = interface
['{5DEEE4A1-8D50-4EA2-96C6-E47EFB65A563}']
procedure AttachObserver(AObserver: TObject);
end;
{ 3rd party component - out of our control }
TShape = class(TComponent)
private
FName: string;
public
constructor Create(const AName: string); virtual; reintroduce;
property Name: string read FName write FName;
end;
{ my personal extensions }
TSquare = class(TShape, IObserved)
private
FSize: integer;
{ IObserved interface }
procedure AttachObserver(AObserver: TObject);
public
property Size: integer read FSize write FSize;
end;
{ my non-TInterfacedObject class }
TMyClass = class(TObject, IObserved)
private
FName: string;
{ IObserved interface }
procedure AttachObserver(AObserver: TObject);
public
property Name: string read FName write FName;
end;
{ TShape }
constructor TShape.Create(const AName: string);
begin
inherited Create(nil);
FName := AName;
end;
procedure TSquare.AttachObserver(AObserver: TObject);
begin
writeln('AttachObserver called - ', Name);
end;
{ TMyClass }
procedure TMyClass.AttachObserver(AObserver: TObject);
begin
writeln('AttachObserver called - ', Name);
end;
var
s1: TShape;
s2: TSquare;
s3: TMyClass;
intf: IObserved;
begin
{ Lets try the Shape first }
s1 := TShape.Create('MyShape');
writeln(s1.Name + ' was created');
if Supports(s1, IObserved, intf) then
intf.AttachObserver(nil);
writeln(s1.Name + ' is being freed');
s1.Free;
writeln('');
{ now lets try the Square }
s2 := TSquare.Create('MyShape');
writeln(s2.Name + ' was created');
if Supports(s2, IObserved, intf) then
intf.AttachObserver(nil);
writeln(s2.Name + ' is being freed');
s2.Free;
writeln('');
{ now lets try the the non-TInterfacedObject class }
s3 := TMyClass.Create;
s3.Name := 'MyNonInterfacedObjectClass';
writeln(s3.Name + ' was created');
if Supports(s3, IObserved, intf) then
intf.AttachObserver(nil);
writeln(s3.Name + ' is being freed');
s3.Free;
writeln('');
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Are global variables guaranteed to be zero?
On 28 Nov 2012, at 08:47, Alexander Klenin wrote: Will global variables and static global arrays be always initialized to zero? Yes. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On 28 Nov 2012, at 09:23, Vincent Snijders wrote: 2012/11/28 michael.vancann...@wisa.be It IS a big change. There is production code out there that uses this, and this is an incompatible change. Then Luiz is right on time with his proposal, with the frist release candidate of the first release that contains this feature. Personally, I think a release candidate is too late. A release candidate freezes all interfaces (even a beta release does so already, normally). Generally the only fixes still performed afterwards are for blocking crashers/failures, major security holes or build issues. I do believe that maybe this functionality was put in a release too soon after being committed to trunk, given that it changes the interface of the base units and hence the changes are more or less cemented once they are released. But that's a separate issue, which at best can be taken into account in the future. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
In our previous episode, michael.vancann...@wisa.be said: At some point, there must be an object, and at some point, there is a typecast, You often can't reroot external components, but if they support tcomponent What does reroot external components mean ? (Change the root of their inheritance tree. e.g. something that doesn't inherit from interfacedobject to inherit from it) (and thus Tinterfacedobject), you can add an interface in a child class. The interfaces are CORBA, so there is no need for TInterfacedObject. Ok. I assumed they also had to be COM compatible because of tiopf. That the interface is CORBA was a conscious decision so reference counting and all the overhead associated with it was avoided. As far as I know, this rules out COM provided interfaces (if this is what you refer to by external components). That is a tradeoff I find acceptable. For me personally that is unacceptable. But that is not with just an FPC hat on. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] FPC's -A option
What is the intent of -Adefault Use default assembler -Aas Assemble using GNU AS on classic unix systems e.g. SPARC and MIPS? Is it that -Aas selects gas (and assumes that gas's command-line is consistent for cross-builds etc.) and that -Adefault selects whatever variant of as is provided by the non-GNU unix (e.g. Solaris and IRIX) provided by the originally-dominant manufacturer (e.g. Sun and SGI)? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On Wed, Nov 28, 2012 at 5:23 AM, Vincent Snijders vincent.snijd...@gmail.com wrote: 2012/11/28 michael.vancann...@wisa.be It IS a big change. There is production code out there that uses this, and this is an incompatible change. Then Luiz is right on time with his proposal, with the frist release candidate of the first release that contains this feature. If production code already uses it, then the production code writers must have taken a risk for change knowing that this was a not yet released feature. +1 I can change the internals so speed is gained during notifyobservers, but I do not see sufficient reasons to change the interface and introduce an incompatibility. Incompatibility with not yet released code? I agree. Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On 2012-11-27 16:19, Michael Van Canneyt wrote: The consequence is that you must pass around the objects themselves. I'm curious to see Luiz's code example of what issues he has, but in the mean time, maybe it wouldn't be such a bad idea to update (with latest FPC changes and Observer support) the LCLMediators code and demos you emailed me a couple years back. [time permitting of course] If you haven't made other changes to those LCL Mediators since the code you emailed me, I could take a look at updating the code for Lazarus too. That's a perfect example of the FPC Observers support being fully functional as-is. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC's -A option
On 28 Nov 2012, at 12:05, Mark Morgan Lloyd wrote: What is the intent of -Adefault Use default assembler -Aas Assemble using GNU AS on classic unix systems e.g. SPARC and MIPS? Is it that -Aas selects gas (and assumes that gas's command-line is consistent for cross- builds etc.) and that -Adefault selects whatever variant of as is provided by the non-GNU unix (e.g. Solaris and IRIX) provided by the originally-dominant manufacturer (e.g. Sun and SGI)? -Adefault simply selects whatever the compiler uses as the default for the platform. That may be GNU AS, or something else. Normally, if multiple assemblers are supported then there will also be a separate - A option to explicitly select this other assembler. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On Wed, 28 Nov 2012, Marco van de Voort wrote: In our previous episode, michael.vancann...@wisa.be said: At some point, there must be an object, and at some point, there is a typecast, You often can't reroot external components, but if they support tcomponent What does reroot external components mean ? (Change the root of their inheritance tree. e.g. something that doesn't inherit from interfacedobject to inherit from it) (and thus Tinterfacedobject), you can add an interface in a child class. The interfaces are CORBA, so there is no need for TInterfacedObject. Ok. I assumed they also had to be COM compatible because of tiopf. That the interface is CORBA was a conscious decision so reference counting and all the overhead associated with it was avoided. As far as I know, this rules out COM provided interfaces (if this is what you refer to by external components). That is a tradeoff I find acceptable. For me personally that is unacceptable. But that is not with just an FPC hat on. The probability of using COM with the observer interface is IMHO almost zero. That's simply not the main intended use case, in casu: GUI elements observing business objects: both will normally be in-process. Given the benefit of no reference counting and all that implies (TInterfacedObject etc), it was obvious that CORBA interfaces were the way to go. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
2012/11/28 michael.vancann...@wisa.be: On Tue, 27 Nov 2012, luiz americo pereira camara wrote: 2012/11/27 Michael Van Canneyt mich...@freepascal.org: As practical example take a LCL Form that is supposed to be observed. It takes an Observer property and attach it to certain child controls (TEdit etc) 1) Currently i'm forced to declare as the Observer property as an TObject. If i declare Observer property as IFPObserver i cannot attach to children controls. I do not understand this ? I can post a simple example showing what i mean I'll do today later. Currently i don't have access for a computer with fpc 2) Each time i attach to a child control this Observer property will be queried to see if implements IFPObserver (but we already know that it implements, we already checked !!!) You only gain speed when notifying. When calling FPOAttachAbserver or FPODetachAbserver, you would need to typecast some object anyway if we would change the interface, so there is no speed gain there... In this case there's a gain. The typecast would be done once when setting the parent property (IFPObserver) Afterwards (setting children) would be no typecast, different as today During notification, we can gain speed by internally storing the interface. OK. Seems here that we pacify the point of the reference count (not) requirement to store the interface pointer So, i keep my points. Even because is not a big change with easy implementation that will fix the above issues. It IS a big change. There is production code out there that uses this, and this is an incompatible change. 1) The change in code can be tedious but is simple. from Attach(MyObj) to Attach(MyObj as IFPObserver) 2) I 'm assuming this as the first public release for wide test so the best moment for such change Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
2012/11/28 Graeme Geldenhuys gra...@geldenhuys.co.uk: Luiz, could you produce a small sample application (or show the code you are working on for Lazarus) where you think the current FPC Observer implementation doesn't work. Your initial bug report doesn't include any test project to show the issue. Yes. I'll do later today. Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
2012/11/28 Jonas Maebe jonas.ma...@elis.ugent.be: Personally, I think a release candidate is too late. A release candidate freezes all interfaces (even a beta release does so already, normally). Generally the only fixes still performed afterwards are for blocking crashers/failures, major security holes or build issues. Yes. This proposed change breaks the concept of release candidate. My point here is this is the first release open for wide test with this feature. A feature that lives in a low level class and is supposed to be a standard in fpc development. Given that better discuss / test / change such important change earlier than later, nothing stops to treat this release as a beta (or whatever name is appropriate) even if was formally released as a RC. Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Interface usage causes FPC to crash
Hi,
I tested the attached program under Delphi 7 and FPC 2.6.0 and FPC 2.7.1
(dated 2012-11-15).
The test application tests two things:
1) Interface delegation via another class
2) Overriding a interface implementation using method resolution
Under Delphi 7 the test application compiles and runs as expected.
Under FPC (both 2.6.0 and 2.7.1)
- I get a compiler error. I thought interface delegation was
supported in FPC?
- I also get a compiler crash with an AV - in both versions.
Isn't interface delegation supported in FPC?
Is method resolution supported in FPC?
Why does the compiler crash while compiling?
8-8-8-8-8
Free Pascal Compiler version 2.6.0 [2011/12/23] for x86_64
Copyright (c) 1993-2011 by Florian Klaempfl and others
Target OS: Linux for x86-64
Compiling test.pas
test.pas(38,76) Error: Class TMyIntfClass does not implement interface
IMyIntf
Fatal: Compilation aborted
An unhandled exception occurred at $0054CA3D :
EAccessViolation : Access violation
$0054CA3D
$00532148
$0056CEF4
$0042392F
8-8-8-8-8
The expected output when running the test application should be:
--
c:\Programming\test\interface_delegation_2test
TMyIntfClass.P1
TMainForm.MyP2
--
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
program test;
{$ifdef FPC}
{$mode objfpc}{$H+}
{$else}
{$APPTYPE CONSOLE}
{$endif}
uses
Classes;
//-- Interface --
type
IMyIntf = interface(IInterface)
['{ED858BD2-0E49-4B42-861D-6F415A7C0CF0}']
procedure P1;
procedure P2;
end;
{ Delegation class.
NOTE: Documenatation suggested we use the TAggregatedObject, but
under Delphi 7 (at least) we can use TObject too. }
TMyIntfClass = class(TObject)
private
{ IMyIntf implementation }
procedure P1;
procedure P2;
end;
TMainForm = class(TComponent, IMyIntf)
private
FMyIntfClass: TMyIntfClass;
{ delegate IMyIntf implementation to another class }
property MyIntfClass: TMyIntfClass read FMyIntfClass implements IMyIntf;
public
constructor Create(AOwner: TComponent); override;
destructor Destroy; override;
procedure Run;
{ overrides the IMyIntf.P2 implementation using name resolution }
procedure IMyIntf.P2 = MyP2;
procedure MyP2;
end;
//-- Implementation --
procedure TMyIntfClass.P1;
begin
Writeln(Classname + '.P1');
end;
procedure TMyIntfClass.P2;
begin
Writeln(Classname + '.P2');
end;
constructor TMainForm.Create(AOwner: TComponent);
begin
inherited Create(AOwner);
FMyIntfClass := TMyIntfClass.Create;
end;
destructor TMainForm.Destroy;
begin
FMyIntfClass.Free;
inherited Destroy;
end;
procedure TMainForm.Run;
begin
(self as IMyIntf).P1;
(self as IMyIntf).P2;
end;
procedure TMainForm.MyP2;
begin
Writeln(Classname + '.MyP2');
end;
// - Application starting point -
var
frm: TMainForm;
begin
frm := TMainForm.Create(nil);
try
frm.Run;
finally
frm.Free;
end;
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On 28 Nov 2012, at 16:02, luiz americo pereira camara wrote: 2012/11/28 Jonas Maebe jonas.ma...@elis.ugent.be: Personally, I think a release candidate is too late. A release candidate freezes all interfaces (even a beta release does so already, normally). Generally the only fixes still performed afterwards are for blocking crashers/failures, major security holes or build issues. Yes. This proposed change breaks the concept of release candidate. My point here is this is the first release open for wide test with this feature. The first release of new features in FPC always happens via the svn repository. That is the moment to test them and give feedback. Once they end up in a release, they are final. Daily snapshots of FPC that can be used for testing are available from the Lazarus project. Given that better discuss / test / change such important change earlier than later, nothing stops to treat this release as a beta (or whatever name is appropriate) even if was formally released as a RC. The appropriate name would be alpha. What stops treating the release candidate as an alpha and making invasive changes to it, is that this would significantly slow down the release process (every time we ship a release candidate, someone could pop and say hey, please change this RC to an alpha version and add/change this -- this would also discourage people from testing the svn versions, since they'd assume they can always delay the release if there's something they don't like). The only possible alternative in this case that I can see would be to remove the new feature altogether from the release (that's still a change, but one thta changes things back to the situation of the previous release and hence is known to be stable). However, from what I read from Michael's replies, that would not help since he does not seem to be inclined to change things. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On 2012-11-28 15:02, luiz americo pereira camara wrote: Given that better discuss / test / change such important change earlier than later, nothing stops to treat this release as a beta (or whatever name is appropriate) even if was formally released as a RC. [Not related to the issue in question] Indeed, just because it is tagged as RC doesn't mean everything must be cast in stone. A RC tag is *not* an official release yet. Nothing stops the FPC team from creating another 10 RC releases before the official FPC 2.6.2 - and maybe fixing last minute critical bugs etc. The more important thing is to get the issue at hand [if there is one] resolved. Many developers don't use Trunk, and only start testing new FPC releases when RC's are announced. Yes, this is definitely not ideal for the FPC team, but this is often how it works - roll with it. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
2012/11/28 Graeme Geldenhuys gra...@geldenhuys.co.uk: On 2012-11-27 16:19, Michael Van Canneyt wrote: If you haven't made other changes to those LCL Mediators since the code you emailed me, I could take a look at updating the code for Lazarus too. That's a perfect example of the FPC Observers support being fully functional as-is. I don't discuss being fully functional as is. But you must agree that, if an architeture works in a scenario does not mean it's good or at least could not be improved. I just proposed a change that will give more flexibility for the programmer when designing his application interface. As a plus with less typecasts, so less overhead. I believe such feature at a low level class must be as generic and flexible as possible. If the design minimizes performance issues better yet. Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] calling convention on mac
It does not matter if I compile it with stdcall, cdecl, pascal. The below on a 32 bit intel mac (fpc 2.6.0) always returns result in 2 registers (eax, edx) Is there a way to change this (some declaration in the source, some switch)? function Point(AX, AY: Integer): TPoint; begin with Result do begin X := AX; Y := AY; end; end; Background. I am trying to get PascalScript to work. But it doesnt knom about edx. And I don't know enough about it and/or calling convention to change pascalscript (within the amount of time, I can currently set aside for this) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] calling convention on mac
On 28 Nov 2012, at 21:36, Martin wrote: It does not matter if I compile it with stdcall, cdecl, pascal. The below on a 32 bit intel mac (fpc 2.6.0) always returns result in 2 registers (eax, edx) Is there a way to change this (some declaration in the source, some switch)? It's a bug that's fixed in trunk: http://wiki.freepascal.org/User_Changes_Trunk#Location_of_certain_function_result_types Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] ActiveX and HeapTrace
Hello I have a problem when using ActiveX and HeapTrace -gh. I've imported a type libary using the Lazarus tool: C:\Windows\System32\Speech\Common\sapi.dll - SpeechLib_5_4_TLB.pas From these imported controls, I'm using TAxcSpVoice with this code (testing): -- uses SpeechLib_5_4_TLB; var vc:TAxcSpVoice; begin vc:=TAxcSpVoice.Create(nil); ... vc.free; end; -- Everything is fine so far. It works (and speaks) without error messages. However, when I use HeapTrace (-gh) it crashes at vc.free External SIGSEGV fpc_intf_assign . 0040C125 488b00 mov(%rax),%rax 0040C128 ff5010 callq *0x10(%rax) 0040C12B 488b442420 mov0x20(%rsp),%rax 0040C130 488903 mov%rax,(%rbx) 0040C133 488b5c2428 mov0x28(%rsp),%rbx 0040C138 4883c438 add$0x38,%rsp 0040C13C c3 retq 0040C13D add%al,(%rax) 0040C13F 00 add%cl,-0x7d(%rax) fpc_intf_as 0040C140 4883ec38 sub$0x38,%rsp 0040C144 48895c2430 mov%rbx,0x30(%rsp) What can it be? Can I ignore it? it works fine without heaptrace. I'm using FPC and Lazarus from SVN (updated today) on Win7, everything 64 bit. Thank you Theo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] calling convention on mac
Op 28-11-2012 21:50, Jonas Maebe schreef: On 28 Nov 2012, at 21:36, Martin wrote: It does not matter if I compile it with stdcall, cdecl, pascal. The below on a 32 bit intel mac (fpc 2.6.0) always returns result in 2 registers (eax, edx) Is there a way to change this (some declaration in the source, some switch)? It's a bug that's fixed in trunk: http://wiki.freepascal.org/User_Changes_Trunk#Location_of_certain_function_result_types As the author of pascalscript, I wasn't aware of this issue, however now I'm in a dilemma. FPC breaks things very often, and that url shows just one of these. If I want to fix this bug in Pascal Script, I have to undo the fix in 6-12 months again (or use version specific defines). I'm getting a bit frustrated with FPC changing things back and forward all the time (this isn't a new thing, this has been going on since I first ported it to FPC). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] calling convention on mac
On 28 Nov 2012, at 22:04, Carlo Ko wrote: Op 28-11-2012 21:50, Jonas Maebe schreef: On 28 Nov 2012, at 21:36, Martin wrote: It does not matter if I compile it with stdcall, cdecl, pascal. The below on a 32 bit intel mac (fpc 2.6.0) always returns result in 2 registers (eax, edx) Is there a way to change this (some declaration in the source, some switch)? It's a bug that's fixed in trunk: http://wiki.freepascal.org/User_Changes_Trunk#Location_of_certain_function_result_types As the author of pascalscript, I wasn't aware of this issue, however now I'm in a dilemma. FPC breaks things very often, and that url shows just one of these. It's not useful to talk in general terms when discussing specific issues. Would you have preferred that this particular bug had remained in the compiler, in the interest of backward compatibility? Additionally, the URL does not just show one of these, but a bunch of those. We do our best to document every such case, and always in the same place on the wiki. If I want to fix this bug in Pascal Script, I have to undo the fix in 6-12 months again (or use version specific defines). The correct fix is indeed an version-specific define. I'm getting a bit frustrated with FPC changing things back and forward all the time (this isn't a new thing, this has been going on since I first ported it to FPC). back and forward suggests that we change it in one way in one version, and then back again to the old behaviour in a successive version. Afaik that has never happened until now. We do occasionally fix bugs that break backward compatibility, but as explained above I don't see an alternative to leaving in such bugs forever. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Tests of observer feature [was: Considerations about observer]
Given the considerations i did about the observer feature, here are some simple projects that supports my concerns and therefore the request i made to change the interface of two functions. Test1 As is today, if you have a reference to a IFPObserver is not possible to use it to attach to, e.g., child objects. This occurs because AFAIK you can't get a TObject from a interface reference. This limits the programmer choice to use a TObject in such situations, in this case the Observer property. The option of using a interface reference instead of TObject is valid and has some advantages like implementation decoupling and making clear what the programming contract is by the declaration itself, i.e., if i have a Observer: IFPObserver property i know what to expect from it different from Observer: TObject It's possible to use a specialized class but it will create a dependency to a specific implementation In my proposition, the programmer could use a TObject or a Interface reference such cases, without any overhead. Test2 This test shows the duplication of typecasts when adapting Test1 to match the current observer implementation. ObserverObj is tested/casted to IFPObserver 1 + 2 * Children.Count In the example 7 times. Yes the same test is done 7 times. In my proposition, it could be implemented (test1) with only 1 typecast Test3 Pretty simple: if you don't know if a TObject descendant instance implements a IFPObserver (most cases) you have to do a check before attaching to a IFPObserved otherwise an exception is raised. In the current implementation the same test is done twice, one in caller and another in the callee In my proposition there would be only one test (caller) So, i hope i made my points clear and exemplified. Although the examples are abstract they derives from a concrete example like having using a TForm/TFrame with a Observer property that would be responsible to attach the Observer for some child controls. The change is simple with a leaner implementation, although breaks interface. This fact is minimized since it's the first public fpc release with this feature PS: The main objection by Michael seems to be code that relies on the current interface. The proposed change needs only to change as the argument is called without any logic change. Luiz ObserverTest1.lpr Description: Binary data ObserverTest2.lpr Description: Binary data ObserverTest3.lpr Description: Binary data ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On 2012-11-27 16:19, Michael Van Canneyt wrote: Correct. But the design should also not try to cover all possible use cases at any cost. Till now, I have not seen a common use case that will not work. See Test1 in a separate message i sent. It will not work with the current implementation I just proposed a change that will give more flexibility for the programmer when designing his application interface. As a plus with less typecasts, so less overhead. If we assume for a second that the internal change to store the interface instead of the instance is done: There are not less typecasts executed, they are in a different place simply. You must always type the typecast before calling AttachObserver, I do it inside AttachObserver. My code is therefore simpler to read, generates less code and hence is preferable. See Test2 in the message i sent. The same Obj is tested for IFPObserver 7 times while would be one movq$_$PROGRAM$_Ld1,%rsi movqU_$P$PROGRAM_$$_C,%rdi callfpc_class_as_corbaintf movq%rax,%rdi callP$PROGRAM_$$_DOI$MYI This kind of code you will generate for each call to AttachObserver/DetachObserver. Not necessarily. Using GetInterface or Supports will avoid the direct typecast Plus: 1) Currently if you don't know before hand if the object implements IFPObserver (most cases), you will have to do the check in the caller anyway 2) Like in Test1 (see other message) there'll be cases that no check or typecast, by the caller or by the callee, will be done at all So, not requiring the interface to be passed on saves code if you use corba interfaces. Using COM classes would generate even more code for each invokation. Just to show why I prefer to avoid COM interfaces and the whole 'as' when possible. Just to be clear: i'm not proposing to use COM interfaces BTW: CORBA interfaces does not requires TGUID so you can remove: GUIDObserved : TGUID = BaseGUIDObserved; GUIDObserver : TGUID = BaseGUIDObserver; If it had been possible to implement the whole observer thing without using interfaces, I would have done it, but alas... Yep. The first time i saw the generated code for interface i think: God: i will never use this. Today i use in selected cases. Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
