pyscripter

I am sure you know but, the form should not have ParentFont := True (disables per monitor scaling) but controls within the form could and should.

If Embarcadero wants to produce a per-monitor DPI-aware IDE (expected soon) they will have to deal with this issue. Let's see what they come up with.

What is your Auto invoke and Finish incomplete properties settings? Try switching off Auto-invoke.

You were dereferencing Py_Func without increasing the reference count first. Reference counting is tricky in Python. See Reference Counting in Python (tripod.com). This is why is safer to use VarPyth, which takes care of ref counting, even if is slower. The code below has not been tested: var PyFunc:= ExtractPythonObjectFrom(MainModule.calc_outflow); // borrowed reference var PE := GetPythonEngine; PE.Py_INCREF(PyFunc); // can skip since it is protected inside the temp variant MainModule.calc_outflow but is safer to inc it. var PyArgs := PE.PyTuple_New(1); // Will need to be deref for i:=1 to i_end do begin Input := Random * 10.0; var PyInput := PE.PythonEngine1.PyFloat_FromDouble(Input); PE.PyTuple_SetItem(PyArgs, 0, PyInput); // PyInput is now the responsibility of the tuple var PyValue := PyObject_CallObject(PyFunc, PyArgs); // the result of the function is your responsibility Output := PE.PyFloat_AsDouble(PyValue); PE.Py_DECREF(PyValue); end; PE.Py_DECREF(PyArg); PE.Py_DECREF(PyFunc); // to match the increment

For start you can use the fix here https://quality.embarcadero.com/browse/RSP-30931 See also this Per monitor DPI awareness - how to prevent flickering? - VCL - Delphi-PRAXiS [en]

PyObject *

Nοt wrappers but the exported C-API functions of the python DLL. You can get the PPyObject corresponding the python function by using ExtractPythonObjectFrom(MainModule.calc_outflow). Yes but bear in mind that the package structure was modified since the tutorial video was produced.

Does Output := MainModule.calc_outflow(Random * 10.0); work?

Your loop calls ExecStrings which means you have the overhead of string compilation. in every iteration What you can do instead is to wrap you python code in a function: def calc_outflow(inflow) if (inflow > 6) or (inflow < 2) : return 40 else: return 20 and call the function from Delphi. Uses VarPyth; script.LoadFromFile('loop.py'); PythonEngine1.ExecStrings(script); var CalcOutFlow: Variant := MainModule.calc_outflow; for i:=1 to i_end do begin Output := CalcOutFlow(Random * 10.0); end; You will get extra speed if instead of Output := CalcOupFlow(Random * 10.0); you call the function using low-level PythonEngine routines e.g. PythonEngine.PyObject_CallObject

Somebody had to do it: [RSP-33448] Memory leaks when using styles - Embarcadero Technologies Feel free to add to the report.

@FranzB Your need to assign the IO before loading the python dll. Otherwise the output is not redirected. FPythonEngine.IO := FPythonInOut; FPythonEngine.Loaddll;

@FranzBHave you tried debugging?

Can't you debug? Is PythonInputOutputSendUniData called? If yes why it does not produce output?

The installations issues are probably due to the fact that you are using Delphi 10.4 (is this the case?). Please upgrade to Delphi 10.4.1 or better to 10.4.2

Regarding numpy on Linux if you use the default python 3 installation it would suffice to install numpy via pip: pip3 install numpy

Just in case you have not seen it SamplingProfiler 64 – test version - DelphiTools, I mentioned earlier the updated instrumenting profiler ase379/gpprofile2017: Gpprof with unicode support and new features. (github.com). Between the two you can get the job done, but I admit being able to use VTune (also free) would be great.

The PythonVersions unit is of little value in Linux, where there is no Registry and no registered Python versions. You need to manually provide the DLLName and DLLPath. You can use some code that searches possible file locations. For example in the Mac you can do, something like: {$ifdef MACOS} for N:= 5 to 9 do begin S:= Format('/Library/Frameworks/Python.framework/Versions/3.%d/lib/libpython3.%d.dylib', [N, N]); if FileExists(S) then exit(S); end; {$endif} In Debian Linux you can search for file locations such as: /usr/lib/x86_64-linux-gnu/libpython3.7m.so /usr/lib/x86_64-linux-gnu/libpython3.7m.so.1 /usr/lib/x86_64-linux-gnu/libpython3.7m.so.1.0 but it may vary by python distribution.

None of the python code is blocking other threads. But the following functions are blocking: PyGILState_Ensure PyEval_RestoreThread In other words you need to get and hold to the GIL to execute any python code. So take for example sleep. It works like windows sleep. But to let other threads to execute python code you need to use Py_Begin_Allow_Threads /Py_End_Allow_Threads before/after the sleep. Python deals with the threads it creates. (threading module).

Delphi 10.4.2 is advertised to be "Remote desktop friendly". Does anyone know what it takes to make Delphi applications remote desktop friendly?

In your code above you should destroy PY_SUBJECT before releasing the GIL Python has a lesser known feature called sub-interpreters, which allows you to use the interpreter from a clean state. This is what emNewInterpreter does. Normally I would not bother with that. The pattern you need to follow using the latest version of P4D: In your main thread to release the GIL after loading the Python dll: TPythonThread.Py_Begin_Allow_Threads (calls PyEval_SaveThread) In your Delphi threads including the main thread (or if you use ITask or TParallel) that execute python code (this is what TPythonThread does): fGILState := .PyGILState_Ensure; try Do python staff finally PyGILState_Release(fGILState); end; In your main thread before unlolading Python TPythonThread.Py_End_Allow_Threads (calls PyEval_RestoreThread) if you have a long running thread that does python stuff and you want allow other threads to do python stuff as well then the pattern is: fGILState := .PyGILState_Ensure; try Do python staff TPythonThread.Begin_Allow_Threads; try Other threads can run python code finally TPythonThread.End_ALlow_Threads; end; Do more python stuff. finally PyGILState_Release(fGILState); end; In PyScripter I have a utility function: type IPyEngineAndGIL = interface function GetPyEngine: TPythonEngine; function GetThreadState: PPyThreadState; property PythonEngine: TPythonEngine read GetPyEngine; property ThreadState: PPyThreadState read GetThreadState; end; function SafePyEngine: IPyEngineAndGIL; begin Result := TPyEngineAndGIL.Create end; type TPyEngineAndGIL = class(TInterfacedObject, IPyEngineAndGIL) fPythonEngine: TPythonEngine; fThreadState: PPyThreadState; fGILState: PyGILstate_STATE; private function GetPyEngine: TPythonEngine; function GetThreadState: PPyThreadState; public constructor Create; destructor Destroy; override; end; { TPyEngineAndGIL } constructor TPyEngineAndGIL.Create; begin inherited Create; fPythonEngine := GetPythonEngine; fGILState := fPythonEngine.PyGILState_Ensure; fThreadState := fPythonEngine.PyThreadState_Get; end; destructor TPyEngineAndGIL.Destroy; begin fPythonEngine.PyGILState_Release(fGILState); inherited; end; function TPyEngineAndGIL.GetPyEngine: TPythonEngine; begin Result := fPythonEngine; end; function TPyEngineAndGIL.GetThreadState: PPyThreadState; begin Result := fThreadState; end; which is used in the main or other threads as: var Py: IPyEngineAndGIL; begin Py := SafePyEngine; Py.Engine. whenever I need to execute Python code

What we now need is a bug report at Embarcadero, with a detailed description of the issue reproduction steps and the potential fixes. @balabuevAre you planning to submit one?

Code queued with ForceQueue is executed in the main thread with the same mechanism as Thread.Synchronize and not with PostMessage.

@Fr0sT.BrutalSure, you could also optimize DoubleBuffering (if you do use DoubleBuffering). But @Stephen Ball's fix addresses crashes that may occur during connection and disconnection, not the general slowness in painting.

I guess the issue would still be present if you now replace the ListView with anything that has scrollbars including a treeview. Is that right?

How about this one? class procedure TStyleEngine.DoRemoveControl(Control: TWinControl); begin if not (csDestroying in Control.ComponentState) and (FControls <> nil) and FControls.ContainsKey(Control) then begin var Hook := FControls.Items[Control]; TThread.ForceQueue(nil, procedure begin Hook.Free; end); FControls.Remove(Control); end; end; There may be more efficient solutions, such as adding the hooks for deletion to a List and process that list on idle time or on Hook creation.