Mac OS X and lazarus compatibility

[GoogleCodeExporter]

Some fixes to make Demo8 work

- Use Python framework instead of load library

- Stack alignment in asm routines

- Some compiler incompatibilities 

Original issue reported on code.google.com by andrey.g...@gmail.com on 9 Nov 2010 at 4:31

Attachments:

• macosx.patch

[GoogleCodeExporter]

Could you please submit another patch against the latest sources?

Original comment by pyscripter on 10 Dec 2011 at 5:19

[GoogleCodeExporter]

I'll try to produce a new patch to support both FPC and Delphi XE2 for Mac OS 
target 

Original comment by andrey.g...@gmail.com on 10 Dec 2011 at 11:34

[GoogleCodeExporter]

Thanks a lot.  At the moment everything compiles and runs under win32, both FPC 
and Delphi.  Look at the WrapDelphi FPC demo 31 in SVN.  

Since it appears that you know assembler, is there any chance that you can port 
MethodCallback.pas to 64bit?  This is the only assembler stuff now used in FPC. 
 Please see my question at StackOverflow 
(http://stackoverflow.com/questions/8283490/how-to-turn-a-method-to-a-callback-p
rocedure-in-64bit-delphi-xe2).  See also 
http://code.google.com/p/python4delphi/wiki/LazarusCompatibility/.

Original comment by pyscripter on 10 Dec 2011 at 2:14

[GoogleCodeExporter]

I'm also interested in 64 bit porting
But function GetCallBack looks really bad.  
I think it should be removed or replaced with some other callback solution
There is only one calling convention in 64 bit systems (but they are different 
in Windows and non-Windows). They are cdecl like, but first arguments are 
passed in registers. And registers are depend on argument type (float or 
non-floan)
I'll see if I can do something about asm.

Original comment by andrey.g...@gmail.com on 10 Dec 2011 at 4:44

[GoogleCodeExporter]

As I can see PythonEngine.pas uses GetOfObjectCallBack function only with 2 or 
3 arguments. In this case 64 bit proxy callback function does not need to deal 
with stack. It just shifts values in 4 registers and jumps to real function 
address.
In case of 4 and more arguments 64 bit proxy function must do something like 32 
bit cdecl proxy does. 
I don't know if this callback system widely used in projects.
If not, my suggestion is to create new private functions for 3 arguments 64 bit 
and 32 bit cdecl and leave current 32 bit windows implementation as legacy 
functions.  
If GetOfObjectCallBack is really important as export function and must be 
available for library users, I'll try to make 64 bit proxy function with 
unlimited number of arguments.

Original comment by andrey.g...@gmail.com on 11 Dec 2011 at 7:45

[GoogleCodeExporter]

Thanks very much dealing with this.  CreateStub, mentioned in the Stackoverflow 
question, is used to turn a method into a procedure pointer that, for example, 
can be passed to Windows API as a callback function.  A typical use from 
http://code.google.com/p/mustangpeakeasylistview/source/browse/trunk/Source/Easy
ScrollFrame.pas

      TimerStub := CreateStub(Self, @TCustomEasyScrollButton.TimerProc);
      TimerID := SetTimer(Handle, TIMER_AUTOSCROLLDELAY, AutoScrollDelay, TimerStub)

Note also that the madExcept library has a similar function called 
MethodToProcedure (http://help.madshi.net/MethodToProc.htm).  Unfortunately 
noone has come up with a 64bit port yet.  Delphi itself as well has and uses a 
similar function MakeObjectInstance declared in Classes.pas in XE2.  Of course 
this has been ported to Win64 but it only handles WindowProc declarations.

So if you could help in converting MethodCallBack to Win64, you will be my 
hero.  

Now regarding P4D we have code such as:

function  TMethodsContainer.AddDelphiMethod( AMethodName  : PAnsiChar;
                                             ADelphiMethod: TDelphiMethod;
                                             ADocString : PAnsiChar ) : PPyMethodDef;
begin
  Result := AddMethod( AMethodName,
                       GetOfObjectCallBack( TCallBack(ADelphiMethod), 2, ctCDECL),
                       ADocString );
end;

I am not sure how a private function can eliminate the need for 
GetOfObjectCallBack.

Also

        tp_new              := GetCallBack( Self, @TPythonType.NewSubtypeInst, 3, ctCDECL);

The reason tp_new is handled with GetCallBack and not in the same way as say 
tp_init is that if you look at tp_init implementation

function  TPythonType_InitSubtype( pSelf, args, kwds : PPyObject) : Integer; 
cdecl;
begin
  Result := PythonToDelphi(pSelf).Init(args, kwds);
end;

in tp_init we can get access to the Python object through the 
PythonToDelphi(pSelf) hackery, whilst tp_new can be called with a type Python 
object different than FType, so that we cannot use the same trick.

By the way it may be easier to carry this conversation by email (please email 
at pyscripter at gamail dot com)

Original comment by pyscripter on 11 Dec 2011 at 12:02

[GoogleCodeExporter]

I tried very hard to think of a way to factor out the need MethodCallBack but I 
could not come-up with a good solution.  Of course if you can come up with such 
a way that may be the preferred route.

Original comment by pyscripter on 11 Dec 2011 at 12:06

[GoogleCodeExporter]

Original comment by pyscripter on 15 Dec 2011 at 2:33

• Changed state: Fixed