pyscripter

Not quite. WebAssembly (WASM in short) is a binary executable format supported by all major browsers. See WebAssembly. Various compilers of different programming languages produce WASM code. Fpc is already moving ahead with support for Webassembly target. See WebAssembly/Roadmap - Lazarus wiki (freepascal.org). Overall WebAssembly is an alternative to compilation to JS. .Net has already a WASM target they call Blazor.

The DLLPath was always meant to be the full path to the DLL. If it worked it was by accident rather than by design. Why don't you just use: PythonEngine.DllPath := TPath.Combine(ExtractFilePath(Application.ExeName), 'Python') in the OnBeforeLoad event for instance?

Have a look at the Webinars at python4delphi/Tutorials at master · pyscripter/python4delphi (github.com), The Webinar II video covers the creation of extension modules. The demo code is for Delphi. Quite a bit of that can be easily adapted for Lazarus or you can use the Delphi Community edition.

Mostly agree. The problem with TEdit is a Windows and not a Delphi one. Notepad and VSCode have similar issues. If you are not rendering text it probably does not matter. I got interested in this because SynEdit does not handle complex unicode characters well. Other scenarios for using libraries such as ICU include proper sorting of multi-lingual text, proper change of capitalization, string normalization etc. (I mean better in corner cases than what Windows provides and more compatible with Unicode standards),

It appears that ICU is the way to go. ICU is now bunded in Windows, .NET 5 is based on ICU, also android Unicode and internationalization support | Android Developers and iOS ICU usage in Swift - Development / Standard Library - Swift Forums

And attached here is a text element enumerator that handles 🤷🏽‍♀️ correctly using ICU. Note though that the Edit Box and the List Box do not display 🤷🏽‍♀️correctly (shown as two characters). The content of the EditBox is åá̂̃̄🤷🏽‍♀️ (copied and pasted here). EnumTextElements.pas

I did say I did not test . One missing line now added to the code. (FStart := FEnd); Works as expected in: var TestString := 'å'+#$0061#$0301#$0302#$0303#$0304; for var S in TextElements(TestString) do Writeln(S); and yes it does not work as it should with complex emojis. Interestingly even VScode does not handle 🤷🏽‍♀️ correctly. Paste the symbol and then try to delete it with Backspace. It takes pressing backspace multiple time to actually delete this emoji.

CharNext does handle surrogate pairs, diacritics and other multi-codepoint sequences reasonably well. Cleary it does not handle emojis well. Nor does any other Windows function that I know of. But I was mostly trying to show that doing the text enumeration is the easy part. The .NET 5 unicode support is based on the ICU library. See Globalization and ICU | Microsoft Docs for details. There is an ICU Delphi wrapper but it has not been updated for years. ICU has been included in the Windows Creators update. The dll names the the header files are listed here. It would be nice to have translations of the headers to pascal and even better some higher level wrappers.

Here is an implementation of a TextElementEnumerator (not tested): Note that in Windows CharNext is the best but still not perfect way to get text elements. See What('s) a character! | The Old New Thing (microsoft.com) You should then be able to write code such as: for var Element in TextElements(MyString) do: interface type TTextElementEnumerator = record private FStart: PChar; FCurrent: string; public constructor Create(const AValue: string); function MoveNext: Boolean; inline; function GetCurrent: string; inline; property Current: string read GetCurrent; end; TTextElementEnumeratorHelper = record private FString: string; public constructor Create(const AValue: string); function GetEnumerator: TTextElementEnumerator; end; function TextElements(const AValue: string): TTextElementEnumeratorHelper; implementation {$REGION Text Element Enumberator} { TTextElementEnumerator } constructor TTextElementEnumerator.Create(const AValue: string); begin FStart := PWideChar(AValue); end; function TTextElementEnumerator.GetCurrent: string; begin Result := FCurrent; end; function TTextElementEnumerator.MoveNext: Boolean; Var FEnd : PWideChar; begin if FStart^ = #0 then Exit(False); FEnd := Windows.CharNext(FStart); SetString(FCurrent, FStart, FEnd - FStart); FStart := FEnd; Result := True; end; { TTextElementEnumeratorHelper } constructor TTextElementEnumeratorHelper.Create(const AValue: string); begin FString := AValue; end; function TTextElementEnumeratorHelper.GetEnumerator: TTextElementEnumerator; begin Result.Create(FString); end; function TextElements(const AValue: string): TTextElementEnumeratorHelper; begin Result.Create(AValue); end; {$ENDREGION}

TPythonGUIInputOutput only captures output sent to to sys.stdout and sys.stderr. It will not capture the output generated by sub-processes and printed to the console. You can capture the output of sub-processes and make it available to Delphi or print it from the script that creates the sub-processes. See subprocess — Subprocess management — Python 3.9.2 documentation for details

Have you seen the last comment in AttributeError: partially initialized module 'cv2' has no attribute 'VideoCapture' · Issue #303 · pyscripter/python4delphi (github.com) I am not sure whether specifying the dependency with a manifest file as in P4DPython26 · pyscripter/python4delphi Wiki (github.com) might help. A minimal script reproducing the error would be a lot more helpful instead of your long python script.

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