pyscripter

Yes indeed. StringLists, TTextReader, SynEdit are full of this kind of shit. When you load a big file scanning millions of characters that has an impact.

The original post was about the best way to replace P^ in [#10, #13] with something concise and efficient in order to avoid the warning assuming the warning is valid. It also showed that the recommended way CharInSet is slow in Win64. So I guess there are two parts to the question: Can I safely ignore the warning? What is a concise and efficient way to achieve the same without a warning? The post also suggests that Ord(P^) in [10, 13] appears to be a good way of avoiding the warning without sacrificing speed or conciseness.

You could suppress just this warning by {$WARN WIDECHAR_REDUCED OFF} while (P < PEndVal) and not (P^ in [#10, #13]) do Inc(P); {$WARN WIDECHAR_REDUCED ON} I prefer the shorter while (P < PEndVal) and not (Ord(P^) in [10, 13]) do Inc(P); The question still is whether the warning makes any sense.

Exactly. For instance in Classes.TStringList,SetTextStr you have the following: while (P < PEndVal) and not (P^ in [#10, #13]) do Inc(P); P is a PChar (unicode characther). The problem is that if I put such code in my program it raises a warning. The whole (only) point of CharInSet is to avoid the warning, alas it appears suffering a speed penalty in Win64. My original posts examines alternatives that avoid the warning and the speed penalty. The warning is idiotic. You get the same warning if you write while (P < PEndVal) and not (P^ in [AnsiChar(#10), AnsiChar(#13)]) do Inc(P); So the warning is about downcasting the Unicode char to an AnsiChar. But if you look at the generated code, the compiler does the right thing and does not downcast the Unicode char. It compares the Word value of the Unicode char to the values of the elements of the set. It does the same thing as if you wrote: while (P < PEndVal) and not (Word(P^) in [Ord(#10), Ord(#13)]) do Inc(P); which does not raise a warning. I would appreciate an explanation of the rationale of this warning.

Sure. The CharInSet and the like are useful if you want to search your unicode string for unicode chars with values less than 255 and typically less than 128. Chars like " : CR LF \ /. These values can be represented as a Delphi set. This is a common operation and that's why doing it efficiently is important.

All of the above assume that the characters you are looking for have a value less than 256 so that the set can be represented as a Delphi Set. Otherwise TCharHelper.IsInArray or the case statement are the only readily available options.

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?

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.

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.

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.

@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?

x86 PyScripter Delphi 10.4: 11,975 KB PyScripter Delphi 11: 10,326 K 14% reduction!!

Already fixed.

Same here. PyScripter Delphi 10.4: 17,302 KB PyScripter Delphi 11: 15,523 KB 10% reduction, not bad. Any idea where this is coming from (generics?) Probably the first Delphi version that produces smaller executables that its predecessor.

I found a bug in Gnugettext and I thought I would let you know and ask your opinion about my fix. Gnugettext does not translate Action linked properties. It does that by calling a function ObjectHasAssignedAction and in TGnuGettextInstance.TranslateProperties there is the following code: if ObjectHasAssignedAction(AnObject, PropList, Count) then Continue; The problem is that if an object has an assigned Action property no property of that object gets translated action-linked or not. I got bitten by this since there was an action in PyScripter used in different menus, and in one of them I had overwritten the Caption, so the Caption of that item was in the dfm file and the default.po, but it did not get translated. The solution I am trying with success is to remove the above code in TranslateProperties and instead added a check as to whether the property is stored (IsStoredProp😞 if ((currentcm=nil) or (not currentcm.PropertiesToIgnore.Find(UPropName,i))) and (not TP_IgnoreList.Find(Name+'.'+UPropName,i)) and IsStoredProp(AnObject, PropInfo) and (not ObjectPropertyIgnoreList.Find(UPropName,i)) then begin TranslateProperty (AnObject,PropInfo,TodoList,TextDomain); I did check that action-linked properties are not translated multiple times (IsStoredProp returns False). The above also appears to speeds up the translation. But I do wonder whether the above fix has any obvious drawbacks. @dummzeuch Any thoughts?