pyscripter

You are not calling PythonEngine1.Load. Demo34 shows how to load a python engine dynamically, but please note that this is very tricky and things can go wrong.

Python4Delphi demo33 (multithread) does not work · Issue #373 · pyscripter/python4delphi (github.com) is now fixed.

Please see these earlier posts on SynEdit history: SynEdit preferred version? - Delphi Third-Party - Delphi-PRAXiS [en] (delphipraxis.net) Turbo SynEdit & Font Ligatures - VCL - Delphi-PRAXiS [en] (delphipraxis.net) DirectWrite and Unicode support One of the major flaws of SynEdit was the poor handling of Unicode. A major update has been committed to the TurboPack fork, that employs DirectWrite for text painting and fixes Unicode support. SynEdit should now be on a par with, if not better than, the best editors around with respect to Unicode handling. For example: Chinese is properly spaced and surrogate pairs and color emojis are fully supported: Bidirectional text editing is fully supported as well: WordWrap has been re-written and is now based on DirectWrite as well. This last update also includes other enhancements as for example an option to alpha blend the selection, another option for selection to cover just selected text instead of full lines, as in VS code and other editors, and horizontal mouse wheel scrolling: Other recent improvements: The undo/redo system was buggy and a mess, getting in the way of implementing new features. I has been reimplemented from scratch. The gutter has been reimplemented from scratch and is now flexible and extensible. A track changes bar like in Visual Studio has been added and unlike Delphi's it saves and restores line state correctly on undo/redo. The code base has been refactored cleaned-up, and partially documented, yet, and despite of the new features, it is thousands of lines shorter than the original. But a lot more can be done in this area. See here for the full list of enhancements in the the TurboPack fork. Backward compatibility Turbopack Synedit remains compatible with earlier versions of Synedit, but you do need to reinstall Synedit, load forms that use SynEdit ignoring error messages and save them again for the new properties to take effect. The use of DirectWrite though means that Windows XP is no longer supported. The TurboPack SynEdit fork supports Delphi versions Berlin or later. Future plans The next big planned feature is multi-selection and multi-cursor editing. Support the project Most of the bugs remaining in the issue tracker are C++Builder related. Also, the C++ packages have not been updated yet. We are actively seeking contributions on the C++Builder side of things (package updates, bug fixes). Of course you can also support the project by submitting bug reports and pull requests. Or, by implementing new features (e.g. minimap, Sync Edit like in Delphi, Delphi or VS-code like templates etc.) Note: Many thanks to @MarkShark for his great contributions to the SynEdit project.

TPythonEngine and TPyDelphiWrapper are singleton. You should not have two in the same application. Better to add your control wrapper to delphivcl and recompile.

System.Rtti contains a lesser known, but powerful class TMethodImplementation, which is basically hidden and used in TVirtualMethodInterceptor. Outside this use, it cannot be created directly and it can only be accessed by TRttiMethod.CreateImplementation. I recently discovered that Spring4d extends its use through a helper for TRttiInvokableType, so it can be used with standalone procedures and functions as well as with events. Here is a small console app showing how it can be used: program MethodImplementationTest; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils, System.TypInfo, System.Rtti, Spring; type TSimpleProc = function(I: Integer): Integer; procedure ImplCallback(UserData: Pointer; const Args: TArray<TValue>; out Result: TValue); begin WriteLn('From Implementation'); Result := Args[0].AsInteger * 2; end; var Proc: TSimpleProc; begin ReportMemoryLeaksOnShutdown := True; try var RTTIContext := TRttiContext.Create; var RTTIType := RTTIContext.GetType(TypeInfo(TSimpleProc)); var ProcImplementation := (RTTIType as TRttiInvokableType).CreateImplementation(nil, ImplCallback); Proc := TSimpleProc(ProcImplementation.CodeAddress); WriteLn(Proc(2)); ProcImplementation.Free; except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; ReadLn; end. Output: From Implementation 4 Simple and easy. Spring4D is full of gems. I wish the above functionality was part of the standard library. I can think of many uses: Python4Delphi contains a unit MethodCallback which uses complex assembly to convert methods into stubs that can be used with external C libraries. It could be rewritten using TMethodImplementation, without assembly code. Also in Python4Delphi, the implementation of Delphi events using python code could be very much simplified and generalized using TMethodImplementation. You can create Delphi functions, procedures and methods, event handlers on the fly that are implemented by python code. Similarly functionality can be provided with other scripting languages.

In using delphivcl.pyd the user can attach an arbitrary python method as an event handler to any vcl component at runtime. The event handler needs to be created on-the-fly, since you do not know in advance what python method will attach to which events. TMethodImplementation can do just that. Create an event handler of the right type when it is need. In this use case the callback would translate the Args to their python equivalents and call the python code. The callback can be an anonymous method, but this is not important. The important thing is that the event handler needs to be created at runtime and not at compile time. Currently python4delphi needs to provide helper classes for each event type (TNotifyEventHandler for TNotifyEvent etc.). All this code can go away and have just one generic implementation of event handling that can deal with any kind of event. For example in the code below: class MyForm(Form): def __init__(self, owner): self.timer = Timer(self) self.timer.Interval = 10 self.timer.OnTimer = self.__on_timer self.timer.Enabled = True def __on_timer(self, sender): self.CheckBox1.Enabled = True when self.timer.OnTimer = self.__on_timer is executed an event handler needs to be attached to the OnTimer event of a Delphi timer object that will run the python method.

Did you read my first post? It answers your question providing some use cases. Spring4d also uses this for supporting multicast events.

Here is an example of making an event handler on the fly using spring4d, TMethodImplementation and a callback routine, in case anyone has a use for it. program MethodImplementationTest2; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils, System.TypInfo, System.Rtti, Spring; type TSimpleEvent = function(I: Integer): Integer of object; TTestClass = class private fEvent: TSimpleEvent; published property Event: TSimpleEvent read fEvent write fEvent; end; procedure ImplCallback(UserData: Pointer; const Args: TArray<TValue>; out Result: TValue); begin WriteLn('From Implementation'); WriteLn(Args[0].AsObject.ClassName); Result := Args[1].AsInteger * 2; end; begin ReportMemoryLeaksOnShutdown := True; var TestObj := Shared.Make(TTestClass.Create)(); try var RTTIContext := TRttiContext.Create; var RTTIType := RTTIContext.GetType(TypeInfo(TTestClass)); var RTTIMethodType := RTTIType.GetProperty('Event').PropertyType; var MethodImplementation := (RTTIMethodType as TRttiInvokableType).CreateImplementation(nil, ImplCallback); var Method: TMethod; Method.Code := MethodImplementation.CodeAddress; Method.Data := TestObj; SetMethodProp(TestObj, 'Event', Method); WriteLn(TestObj.Event(2)); MethodImplementation.Free; except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; ReadLn; end. Output: From Implementation TTestClass 4

Feature request submitted: [RSP-38690] Add CreateImplementation method for TRttiInvokableType - Embarcadero Technologies

This was due to a bug (TPyDelphiObject.SetAttrO causes memory leak · Issue #368 · pyscripter/python4delphi (github.com)) which is now fixed. It may take some time for the fix to be reflected in the pip installable delphivcl, but you can always compile your own delphivcl.pyd from the github sources. @shineworldThanks for discovering the issue.

Just to clarify. a) No memory leakage happens if your timer routine is: def __on_timer(self, sender): pass b) The increase in memory usage increases indefinitely when self.CheckBox1.Enabled = True is called inside the timer routine. c) Could this be tracemalloc overhead? (the memory traces take memory space). For example does the memory gets released with tracemalloc.clear_traces() (tracemalloc — Trace memory allocations — Python 3.10.5 documentation) d) Do you see Windows memory allocated to the process increasing without tracemalloc

I am not sure what is the problem you are trying to solve. Your "Second attempt" should work. In your "First attempt" myV := PythonModule1.GetVarAsVariant('myboxes'); fails because PythonModule1 has no variable 'myboxes'. myboxes will be part of the main module namespace after your code gets executed. GetVarAsVariant can be improved to avoid the access violation. function TPythonModule.GetVarAsVariant( const varName : AnsiString ) : Variant; var obj : PPyObject; begin CheckEngine; with Engine do begin obj := GetVar( varName ); if Assigned(obj) then try Result := PyObjectAsVariant( obj ); finally Py_XDecRef(obj); end; end; end;

for var V in VarPyIterate(MainModule.myboxes) do V will be a python variant pointing to whatever is inside myboxes. Listbox1.items.add(V); The above converts the python variant to string.

You can use either VarPy or the low-level python API to manipulate python tuples (e.g PyTuple_GetItem, PyTuple_SetItem etc.) with VarPyth the unit tests give you a good idea of things you can do: c := VarPythonCreate([1, 2, 3, 4], stTuple); // test a tuple Assert.IsTrue( VarIsPythonTuple(c) ); Assert.IsTrue( VarIsPythonSequence(c) ); Assert.IsTrue( c.GetItem(1) = 2 ); Assert.IsTrue( c.Length = 4 ); c := NewPythonTuple(3); c.SetItem(0, 1); c.SetItem(1, 2); c.SetItem(2, 3); Assert.IsTrue( VarIsPythonTuple(c) ); Assert.IsTrue( VarIsPythonSequence(c) ); Assert.IsTrue( c.GetItem(1) = 2 ); Assert.IsTrue( c.Length = 3 ); from python4delphi/VarPythTest.pas at master · pyscripter/python4delphi (github.com)

The function return value is a tuple containing your lists.

Args is a tuple not a dictionary. Search in the P4D source code for PyArg_ParseTuple to see how to make use of Args. There are hundreds of examples!

I am new to DUnitX and I am trying to get stacktraces working, so that when a test case fails, I can see the source code line containing the Assertion that failed. I have done the following: Added DUnitX.StackTrace.Jcl, to the project uses clause. Edited C:\Program Files (x86)\Embarcadero\Studio\20.0\source\DunitX\DUnitX.Stacktrace.inc to enable the JCL define Compiled generating a full MAP file which was converted to jdbg and inserted into the executable. The MAP file is also present. I still do not get stack traces for failures. What am I missing? Another small issue is the XML report shows asserts="0" despite the fact that there are many Assert.IsTrue in the Test cases. Is this feature not working?

np_array.SetItem(0) should work. From VarPyth source code: // here we handle a special case: COM (or Delphi?) doesn't allow you to have index properties // on a variant except from a true array variant! So if myVar is a Python variant that holds // a Python list, I can't write something like: myVar[0]! But if the list is a member of a // Python instance, it will work fine! Like: myInst.myList[0] // So, to handle this problem we detect some special names: GetItem, SetItem and Length // that will do the same as: // myList[0] <-> myList.GetItem(0) // myDict['Hello'] := 1 <-> myDict.SetItem('Hello', 1) // len(myList) <-> myList.Length() // we get some bonus with the slices and in operators also: // myList = [0, 1, 2, 3]; myList.GetSlice(1, 2) --> [1, 2] // myList.Contains(2) <-> 2 in myList

Have you seen python4delphi/Tutorials/Webinar II at master · pyscripter/python4delphi (github.com)? The VarPyth demo shows how to work with numpy arrays (two way link).

indeed.

Study demo 33 on how to interrupt a running python thread. (TSortThread.Stop).

Yes.

SynEdit has been updated since these demos have been created. I am not sure what version of SynEdit you are using, but the solution to such problems is to open the unit with the form in the IDE ignoring all errors and then save the unit again.

Getit has not been updated. To use the latest version use the Github repo instead.

@balabuevThis appears to be fixed in Delphi 11.1, and I cannot reproduce it anymore. But I cannot see any change that could have fixed that. Any ideas,