pyscripter

And here is a less simple way running Python code in a thread and keeping the main thread free to handle printing. It also shows how to buffer the output. LessSimpleDemo.zip

Here is a super simple approach. SimpleDemo.zip

Have you set UnicodeIO to true? Otherwise the OnSendData handler is called instead of OnSendUniData.

Indeed. Just voted and invite everyone to do so.

A Vcl Memo is a Windows native control and different from the FMX Memo. Your code keeps the main thread busy. Sleep passes control to other threads. Why don't you try something along the lines of what I suggested above.

And by the way this is nasty bug you should be aware of when working with the Delphi 11 designer.

The new High DPI Form Designer in Delphi gives you the following choices: Low DPI (96) default Auto DPI FIxed DPI Choice sounds good, however none of the choices is satisfactory: Working with the Low DPI setting in a High DPI monitor is next to impossible given the minute size of the form. Auto DPI is the version control nightmare. If you have different developers working with different screen resolutions, or even one developer working on say sometimes on a desktop with a DPI 96 and sometimes on a high DPI laptop, every time you touch the form on a machine with a different resolution all the coordinates widths and heights of the components will change. Absolutely no go. Fixed DPI has the same issues as Low DPI. You set the Fixed DPI to match one of the screen resolution, but when you open the form to another computer the form will show either too big or too small. What I would like to have is Fixed DPI, so that you avoid the version control issues, but automatic scaling of the form into the Screen coordinates and back to the Fixed DPI when you save the form. I know that the scaling from one DPI to another and back may result in changes of the original values. But the scaling back to the Fixed DPI does not need to happen unless a control is moved or resized. Is it just me that have issues with High-DPI designer? @Marco Cantu @David Millington Your comments will be appreciated.

Hard to tell without knowing what you are doing. If you keep the main thread busy with your python script, your application may not repaint the controls until it gets idle. You could force a repaint though: - Assign and event handler to OnSendUniData. Inside that event handler do something like: GuiInputOutput1.DisplayString(Data); Edit1.Repaint; The above could slow down things though. I assume you have DelayWrites set to False.

From R: Contributors (r-project.org) Incidentally, and off-topic, did you know that Duncan Murdoch was a originally a Turbo/Borland Pascal enthusiast, with many contributions to the Pascal community?

There are many good reasons (and some not so good ones) for using P4D and one of them is to get access to the libraries available for python (another one is for application scripting), Quite a few of python libraries already make use of the available CPUs or even GPUs (e.g. Tensorflow, PyTorch, scikit-learn etc.). There is absolutely no benefit (maybe the opposite) in using multi-threading or multi-processing with say Tensorflow stuff. For other tasks you need to bear in mind: Avoid premature optimization and then identify and focus only on bottlenecks Tasks you implement in Delphi instead of pure python are likely to be much faster, even before you employ Delphi multi-threading. Use TPythonThread mainly to avoid blocking the Delphi main thread, but not as a tool to process things faster. You can use multi-processing as a last resort. In the vast majority of cases you should not need to do that. Make sure you know what you are doing before trying to use Python threads (and multi-threading in general) . Study Demo 33 in depth for instance. By the way the list of languages that have the same limitations as python in not being able to exploit multiple CPUs directly via threading, includes other popular languages such as JavaScript, Ruby and R. It is interesting that this limitation has not prevented their widespread adoption in an era in which the main increase in processing power comes from the increase in the number of cores.

By the way TList.Destroy is called myriads of times by TWinControl.AlignContols. I wonder whether using some other structure than a TList would make better sense.

In System.Classes we have the following: destructor TList.Destroy; begin Clear; end; I know that TObject.Destroy does nothing. Is calling inherited Destroy from TObject direct descendants just a good practice or there are other considerations? Is the omission of the call to inherited just to save a few ms for the call to an empty procedure?

@Stefan GlienkeI would add more likes if I could. Not just for this. Just look at: https://quality.embarcadero.com/browse/RSP-34681?jql=reporter%3D"Stefan Glienke" Isn't [RSP-34681] Get rid of TListHelper and use strongly typed field (TArray<T> - Embarcadero Technologies also relevant?

The Jcl project analyzer shows the largest differences in size to be in the following units. But there are small size reductions in many other units (rtl and mine). Delphi 10.4 Size Delphi 11 Size2 Diff Vcl.Themes 292380 Vcl.Themes 215,944 76,436 System.Classes 360524 System.Classes 314,652 45,872 SVG 124584 SVG 87,720 36,864 System.Threading 119156 System.Threading 87,640 31,516 System.Rtti 219480 System.Rtti 191,064 28,416

@Stefan Glienke @Marco Cantu @Dmitry Arefiev Could you please enlighten us as to how this substantial reduction in executable size has been achieved? And why has not this been advertised?