pyscripter

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?

@shineworldThanks for your help. In fact. with the change above, I do not see any issues when changing the language say from English, to Chinese, to Italian and back. Maybe this is because of some fixes applied to dxgnugettext.pas. My version is based on the JVCL one and you can find it here.

PyScripter uses dxgettext and it uses www,transifex.com for managing the translation team, which provides workflow and github integration. This is important if a team is working on different translations. However the fact that is not actively maintained is a serious issue. Jvcl contains a fork but this is also not maintained. You have to fix the bugs yourself. And there are some bugs, although it is generally solid. Regarding platforms the file I am using from Jvcl has the following: {$ifdef MSWINDOWS} Windows, {$else} Libc, {$ifdef FPC} CWString, {$endif} {$endif} So it does not appear to be Windows or Vcl dependent, but I have not tried. Gettext does support context specific and plural translations, but they take some effor to implement. If you just translate forms and resource strings there is not much need to mess up the source code, except for adding ingnore class/property directives. Fpc includes its own gettext unit, unrelated to dxgettext. Python also has gettext standard module based on GNU gettext.

VarPyth.Import just calls the Python function PyImport_Import which AFAIK does not modify files in any way.

What does "loaded by Python4D" mean? What kind of character is this? Do you mean $A (LF)?

The following statement compiles under Delphi 11 64 bits but produces an error in 32 bits. Assert.AreEqual(Rec.SubRecord.DoubleField, 3.14); [dcc32 Error] WrapDelphiTest.pas(357): E2532 Couldn't infer generic type argument from different argument types for method 'AreEqual' Here is the definition of Assert.AreEqual class procedure Assert.AreEqual<T>(const expected, actual: T; const message: string); Any idea why?

I actually agree, but I wish this was implemented a few years back. Voted for that.

With due respect, I think the bugs can be fixed without implementing your proposal. I have made a number of components (SpTBXLIB, zControls, VirtualExplorerTree, JvDocking, SynEdit, helped with VirtualTreeView) and applications per monitor DPI aware, so I am talking from experience.

A few points related to this: It has been like this since High DPI support came to Delphi many versions back. Developers of High Dpi apps have been taking this into account. Changing this now will break many applications. PixelPerInch is not part of FontData. It is Delphi that sets it to Screen.PixelsPerInch when a font is created. Bear in mind that the same font can be used in different devices with different DPI Font.Size is a calculated property. It has always been. Font. Height is what is persisted. The correct way to set a Font to a GivenSize in a form is: Form.Font.Height := MultDiv(GivenSize, Form.CurrentPPI, 72) When a form is scaled it is the Font.Height that is scaled. Given that both Font.Height and Font.Size are integer properties, they will never be in perfect match. One of them will be off by a little. I think it is better to get the pixels right and get used to think in terms of Font.Height. Also bear in mind that the Windows Font dialog is not per monitor DPI aware and should not be used to set the Font size in per Monitor DPI aware applications. See High DPI Scaling Improvements for Desktop Applications and “Mixed Mode” DPI Scaling in the Windows 10 Anniversary Update (1607) - Windows Developer Blog for a way to work around this, but it is messy. It is better to just let the user select a font size from a drop down box and set the Font.Height as suggested above.

Not that I know of.

@Uwe Raabe@Kas Ob. You are both right. double(3.14) resolves the problem. The documentation at Floating Point Constants - RAD Studio (embarcadero.com) states that "In the absence of any suffixes, floating-point constants are of type double. " This is irrespective of the compiler target. Is this a documentation error?

Yes.