I tried to use current http://code.google.com/p/python4delphi with Lazarus. Did somebody use P4D successfully with recent Lazarus? Patches? I face a few problems.

My aim is to test/use Lazarus+Python as efficient platform independent and free dev environment. As an alternative to the fat and baggy wxPython GUI system. Laz, with very small EXE footprint size and better RAD and tough speed - but just for rather naked GUI wiring (and few speedy loops - alt: Cython), while doing the actual app, data, algo, object, file, interface ... work and all, in Python. Python can also use reversely use Delphi objects/funcs quite simply. Laz claims to be mature, and the first impression is good, just re-compilation a little slower than Delphi. With Delphi I used this P4D method once in a smaller app some time ago - initially only wanting to re-use some Python modules and then found me shifting more and more all the data/algo work to Python. I felt a ">3x" coding speed up and much better readability, object orientation, overview, interfaces, flexibility, dynamics/introspection, debugging, testing etc. While GUI wiring was a lot tighter in D, than wx/wxGlade etc.

P4D worked principally with Lazarus, but only after a few a adaptations. Mainly setting DELPHI_4..7_OR_HIGHER. see the little patch in attachment. Is nobody using?

(After re-building Lazarus IDE for Visual Python Components it Crashes on usage of non-crucial TPythonGUIInputOutput, and the rebuilt Laz IDE here becomes at all somewhat instable!? But I stepped back and use the P4D-units/objects just manually, anyway only a few things to set up and wire...)

Yet when using the crucial VarPyth unit, upon basic things like pymod := VarPyth.Import('pymod') => EVariantError "Method TCustomVariantType.VarDataClear not yet supported"

VarPyth variants would allow to walk seamlessly and comfortably into the Python object tree with the '.' operator like pymod.myobj.myattr.x(7).y := z; ...
And without that option, much of the P4D charm disappears. In VarPyth.pas there are many $IFDEF FPC's , but it doesn't seem to work at all so far!?.

What about this problem, and what could be a workaround? http://code.google.com/p/python4delphi/source/browse/trunk/PythonForDelphi/Components/Sources/Core/VarPyth.pas

### from variants.pp #########
procedure TCustomVariantType.VarDataClear(var Dest: TVarData);
begin
     NotSupported('TCustomVariantType.VarDataClear');
end;
...
#########################

Robert

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed... Name: P4D-laz.patch
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20090530/0025d9e4/attachment.ksh>

There have been experiments in the past, but no steady maintainer. Often there are mails just like yours, partially working, little problems, but no final verdict. Try to communicate as much as possible back to the Delphi maintainer.

Note that a define system that works on Delphi versions is fundamentally flawed, most other open source projects abandonned that; read http://www.stack.nl/~marcov/porting.pdf

VarPyth variants would allow to walk seamlessly and comfortably into the Python object tree with the '.' operator like pymod.myobj.myattr.x(7).y := z; ...

That sounds like olevariant stuff. It is supported but only with FPC 2.3.1 (trunk) afaik. I don't know if P4D is already updated for those (2.3+) changes.

I implemented some methods in TCustomVariantType (subversion of today), but there are still quite some missing. Please test to see if it gets you any further.

Michael.

in the P4D Defines.inc etc there are already FPC and LINUX (Kylix/FPC) defines/conditions. Somebody has already worked on it in the past, so it should be principally possible.

Most scaring are a few x86 Assembler things in PythonEngine.pas and WrapXXXX.pas (where I wonder if its even 64bit compatible; don't use so far)

interesting. Yet the other patch showed that its principally already in 2.2.2

2.3.1 shall have a lot of memory leak problems still regarding the other mail.

Robert

thanks, I took&compiled only the new variants.pp into the RTL

Then VarPyth.Import worked and walking/calling the Python object tree works now.
But any assignments to or from Python and argument passing fail.

  pp := Import('pp');
  pp.x.y();     // works!
  i := pp.f();  // EVariantTypeCastError (i:Integer or LongInt)
  pp.a := 99;   // TCustomVariantType.RaiseDispError not supported
  pp.f(6);      // TCustomVariantType.RaiseDispError not supported

Does it help to take more of current SVN ? or a principal problem with Typecasts?

Robert

#0 fpc_raiseexception at :0
#1 VARUTILS_VARIANTTYPEMISMATCH$WORD$WORD at :0
#2 VARUTILS_VARIANTTOLONGINT$TVARDATA$$LONGINT at :0 #3 VARIANTS_SYSVARTOINT$VARIANT$$LONGINT at :0
#4 SYSTEM_assign$VARIANT$$LONGINT at :0
#5 ?? at :0
#6 TFORM1__FORMCREATE(0x12a4b8, 0x12a4b8) at main.pas:114 #7 TCUSTOMFORM__DOCREATE(0x12a4b8) at customform.inc:659 #8 TCUSTOMFORM__CREATE(0xf6308, 0x0, 0x12a4b8) at customform.inc:1448 #9 TFORM__CREATE(0xf6308, 0x1, 0x12a4b8) at customform.inc:2202 #10 TAPPLICATION__CREATEFORM(<incomplete type>, void, 0xf6308) at application.inc:1837

#0 fpc_raiseexception at :0
#1 VARIANTS_NOTSUPPORTED$ANSISTRING at :0
#2 VARIANTS_TCUSTOMVARIANTTYPE_$__RAISEDISPERROR at :0 #3 PARSEPARAM(0, 0x7fb74) at VarPyth.pas:1056
#4 TPYTHONVARIANTTYPE__DODISPINVOKE(0x0, {VTYPE = 527, RES1 = 0, RES2 = 0, RES3 = 0, VSMALLINT = 22640, VINTEGER = 743536, VSINGLE = 1.04191585e-039, VDOUBLE = 3.6735559404621709e-318, VCURRENCY = 743536, VDATE = 3.6735559404621709e-318, VOLESTR = 0xb5870, VDISPATCH = 0xb5870, VERROR = 743536, VBOOLEAN = true (22640), VUNKNOWN = 0xb5870, VSHORTINT = 112, VBYTE = 112, VWORD = 22640, VLONGWORD = 743536, VINT64 = 743536, VQWORD = 743536, VWORD64 = 743536, VSTRING = 0xb5870, VANY = 0xb5870, VARRAY = 0xb5870, VPOINTER = 0xb5870, VRECORD = 0xb5870, PRECINFO = 0x0, VLONGS = {0, 743536, 0}, VWORDS = {0, 0, 0, 22640, 11, 0, 0}, VBYTES = #0#0#0#0#0#0'pX'#11#0#0#0#0}, 0x571e88, 0x7fc44, 0xaed48) at VarPyth.pas:1106
#5 TPYTHONVARIANTTYPE__DISPINVOKE(0x0, {VTYPE = 527, RES1 = 0, RES2 = 0, RES3 = 0, VSMALLINT = 22640, VINTEGER = 743536, VSINGLE = 1.04191585e-039, VDOUBLE = 3.6735559404621709e-318, VCURRENCY = 743536, VDATE = 3.6735559404621709e-318, VOLESTR = 0xb5870, VDISPATCH = 0xb5870, VERROR = 743536, VBOOLEAN = true (22640), VUNKNOWN = 0xb5870, VSHORTINT = 112, VBYTE = 112, VWORD = 22640, VLONGWORD = 743536, VINT64 = 743536, VQWORD = 743536, VWORD64 = 743536, VSTRING = 0xb5870, VANY = 0xb5870, VARRAY = 0xb5870, VPOINTER = 0xb5870, VRECORD = 0xb5870, PRECINFO = 0x0, VLONGS = {0, 743536, 0}, VWORDS = {0, 0, 0, 22640, 11, 0, 0}, VBYTES = #0#0#0#0#0#0'pX'#11#0#0#0#0}, 0x571e88, 0x7fc44, 0xaed48) at VarPyth.pas:942
#6 VARIANTS_SYSDISPINVOKE$PVARDATA$TVARDATA$PCALLDESC$POINTER at :0 #7 fpc_dispinvoke_variant at :0
#8 TFORM1__FORMCREATE(0x12a4b8, 0x12a4b8) at main.pas:115 #9 TCUSTOMFORM__DOCREATE(0x12a4b8) at customform.inc:659 #10 TCUSTOMFORM__CREATE(0xf6308, 0x0, 0x12a4b8) at customform.inc:1448 #11 TFORM__CREATE(0xf6308, 0x1, 0x12a4b8) at customform.inc:2202 #12 TAPPLICATION__CREATEFORM(<incomplete type>, void, 0xf6308) at application.inc:1837

This needs investigation.

pp.a := 99; // TCustomVariantType.RaiseDispError not supported pp.f(6); // TCustomVariantType.RaiseDispError not supported

These are caused by what is still missing in custom variants :-)

Does it help to take more of current SVN ? or a principal problem with Typecasts?

I'll need to check what is still missing. The variants unit could use some cleaning up.

Michael.

I used the latest laz0.9.27+fpc2.3.1 build of today 31May2009 Same problem:

  v := pp.a;        // works so far; Python-Integer to Variant
  i := v;           // Invalid Variant type cast! ; Variant to
Pascal-Integer

#0 fpc_raiseexception at :0
#1 VARUTILS_VARIANTTYPEMISMATCH$WORD$WORD at :0
#2 VARUTILS_VARIANTTOLONGINT$TVARDATA$$LONGINT at :0 #3 ?? at :0
#4 ?? at :0
#5 ?? at :0
#6 $FORMS$_Ld22 at :0
#7 VARIANTS_SYSVARTOINT$VARIANT$$LONGINT at :0
#8 ?? at :0
#9 ?? at :0
#10 SYSTEM_assign$VARIANT$$LONGINT at :0
#11 ?? at :0
#12 TFORM1__FORMCREATE(0xa9048, 0xa9048) at main.pas:124 #13 TCUSTOMFORM__DOCREATE(0xa9048) at .\include\customform.inc:684 #14 TCUSTOMFORM__CREATE(0x9e1c0, 0x0, 0xa9048) at
.\include\customform.inc:1498
#15 TFORM__CREATE(0x9e1c0, 0x1, 0xa9048) at .\include\customform.inc:2371 #16 TAPPLICATION__CREATEFORM(<incomplete type>, void, 0x9e1c0) at .\include\application.inc:1912

A doesn't grip here, so the
compiler does not invoke VarPyth.pas for the conversion to Pascal.

when the returned Variant is passed back to Python as Variant, it goes correctly through:

  v := pp.a;        // works so far; Python-Integer to Variant
  pp.f(v);          // works!

Also it works the hard way:

  if VarIsPythonNumber(v) then
    i := PE.PyInt_AsLong( ExtractPythonObjectFrom(v) )
  else
    raise EPyTypeError.Create('type error');

Just the Python Variant cast to Pascal type doesn't work.

Yes, but the underlying problem was in VarPyth.pas, a $IFDEF FPC (Line ~1057) due to a former FPC restriction is dispensable meanwhile

The := 99 assignment then worked too.

-

And only after a strange change in VarPyth.pas of line

  //if (Length(Arguments) = 1) and VarDataIsEmptyParam(Arguments[0])

into

if (Length(Arguments) = 1) and VarIsEmptyParam(Variant((Arguments[0])))

the call with paramater now works also. Before always empty parameters were passed to Python, though given.
VarDataIsEmptyParam() in variants.pp should do the very same simple transition, but it is either not reflected in the compiled unit. Or there is something very strange going on. When I recompile variants.pp in my project folder, the checksums (&number of symbols) change unfortunately critically...

-

For more than 2 arguments "pp.f(6,7)", the reverse order f(7,6) arrived in Python: in FPC the last argument is the first item in DispInvoke's ?Params? (array of TVarData). I made a FPC-conditional inversion in VarPyth.pas. Is this right? or should FPC turn to use the same internal 1:1 ordering like Delphi ?

-

Named arguments "pp.f(6,7, z:=88);  "pp.f(z:=88)""  are compiled and
executed, but it has no effect: behavior just positional, as if "z:="
would be not there.  The compiler-passed ?CallDesc.namedargcount? is
always 0.

-

furthermore, while

  pp.f();

works correctly as call, with

  v := pp.f();

the function is not called at all, but v becomes the function object itself !?
CallDesc^.CallType is not CDoMethod (1) , but CPropertyGet(2) But with one or more arguments

  v := pp.f(11,22);

the function is again called correctly and v becomes correctly the returned thing.

Thanks so far. Would be really great if the few remaining things, mainly the cast of Python-Variants to Pascal vars, and the assignment upon no-arg-call become principally possible. That Python-Lazarus bridge would open many doors.

Robert

..to add: in attachment my patch so far to the P4D files -------------- next part --------------
An embedded and charset-unspecified text was scrubbed... Name: p4d_laz.patch
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20090531/83d0c511/attachment.ksh>

I'm happy that also others try to work with p4d, not only me.

With this i can add a Delphi-Variable/Class to Python:
MyPyForm := PyFormType.CreateInstance;
(PythonToDelphi(MyPyForm) as TPyForm).Control:= Self;
PyClassMod.SetVar('MainForm', MyPyForm);

But when I wanted to change the Caption I got Access Violation so now these Patch fixing it?

And how to create Forms within PythonCode and use them also in Python?

PS: Could u add the patches to this Bug-Report I made? http://code.google.com/p/python4delphi/issues/detail?id=2

I already have added 2 patches, but I think there not that right.

Best Regards,
Eugen

Found, that the origin of this casting problem is obviously, that TPythonVariantType.CastTo is not called by FPC, like it is in Delphi. In variants.pp there are some ?FindCustomVariantType ... Handler.CastTo?s , but it does not work as it should?

When I switch VarPyth into Atom-Mode by the following {$IFDEF FPC}, this problem can be worked around for now. But some things are limited then....

### VarPyth.pas ###############
constructor TPythonData.Create(AObject: PPyObject);
begin
  PyObject := AObject;  // property; does XIncRef
  {$IFDEF FPC}
  //#TODO FreePascal Variants don't late-invoke our
TPythonVariantType.CastTo/.Copy,
  // when the living Python object inside the Variant needs to be
converted to a
  // static type.  ( v := pymod.a;  intvar := v; boolvar := v; ... )
  // As of 2009May31, v2.2.2 / v2.3.1.  So we have to use VarPyth in
Atom-Mode,
  // and then a sterotype conversion to a Pascal type is tried as soon
as the
  // variant receives the Python object (without knowing the target type
/ best
  // conversion.
  // Remove this behavior as soon as we have full support for
late-casting in FPC.
  fPythonAtomCompatible := True;
  {$ELSE}
  fPythonAtomCompatible := False;
  {$ENDIF}
end;

Robert

Did not so far try these WrapDelphi... things. Just the Python Module definition, and some simple callback mechanism so far. Maybe later.

Robert

Please submit an FPC bug report showing the problem in a program as small as possible.