pyscripter

1 hour ago, Lars Fosdal said:

Does CharInSet support multi-byte Unicode characters?

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.

Further to a previous post of mine, I have done some benchmarking to compare the different alternatives.  I am using some old benchmark code from Barry Kelly and added a few more options (word of char in, Char.IsInArray and if then).

Here are the 6 ways compared:

1. while not CharInSet(cp^, [#0, #13, #10]) do
2. case statement
3.   while not (cp^ in [#0, #13, #10]) do  (raises a warning)
4.   while not (Word(cp^) in [$0, $A, $D]) do
5.   while not (cp^.IsInArray([#0, #13, #10])) do
6.   while (cp^<>#0) and (cp^<>#$A) and (cp^<>#$D) do

Results with optimization turned on.

Win32

1. CharInSet:        0.037 seconds
2. case stmt:        0.039 seconds
3. set test:         0.036 seconds
4. Word set test:    0.037 seconds
5. InArray test:     0.219 seconds
6. if and test:      0.037 seconds

Win64

1. CharInSet:        0.106 seconds
2. case stmt:        0.047 seconds
3. set test:         0.042 seconds
4. Word set test:    0.044 seconds
5. InArray test:     0.248 seconds
6. if and test:      0.036 seconds

What is worrying is that in 64 bits both CharInSet and IsInArray (the recommended options) are much slower than the alternatives.  CharInSet is an inlined version of Option 3, but the code cannot take advantage of the specific contents of the set.  Here is the assembly code:

CharInSet.dpr.15: while not CharInSet(cp^, [#0, #13, #10]) do
0000000000429DAA 480FB708         movzx rcx,word ptr [rax]
0000000000429DAE 6681F9FF00       cmp cx,$00ff
0000000000429DB3 7711             jnbe P1 + $36
0000000000429DB5 480FB7C9         movzx rcx,cx
0000000000429DB9 480FA30D37000000 bt [rel $00000037],rcx
0000000000429DC1 0F92C1           setb cl
0000000000429DC4 EB02             jmp P1 + $38
0000000000429DC6 33C9             xor ecx,ecx
0000000000429DC8 84C9             test cl,cl
0000000000429DCA 74DA             jz P1 + $16

CharInSet.dpr.41: while not (cp^ in [#0, #13, #10]) do
000000000042A05A 480FB708         movzx rcx,word ptr [rax]
000000000042A05E 6683F90F         cmp cx,$0f
000000000042A062 7716             jnbe P3 + $3A
000000000042A064 66BA0100         mov dx,$0001
000000000042A068 D3E2             shl edx,cl
000000000042A06A 480FB70D3A000000 movzx rcx,word ptr [rel $0000003a]
000000000042A072 6685CA           test dx,cx
000000000042A075 0F95C1           setnz cl
000000000042A078 EB02             jmp P3 + $3C
000000000042A07A 33C9             xor ecx,ecx
000000000042A07C 84C9             test cl,cl
000000000042A07E 74D6             jz P3 + $16

CharInSet.dpr.51: while not (Word(cp^) in [$0, $A, $D]) do
000000000042A1AA 480FB708         movzx rcx,word ptr [rax]
000000000042A1AE 6683F90F         cmp cx,$0f
000000000042A1B2 7716             jnbe P4 + $3A
000000000042A1B4 66BA0100         mov dx,$0001
000000000042A1B8 D3E2             shl edx,cl
000000000042A1BA 480FB70D3A000000 movzx rcx,word ptr [rel $0000003a]
000000000042A1C2 6685CA           test dx,cx
000000000042A1C5 0F95C1           setnz cl
000000000042A1C8 EB02             jmp P4 + $3C
000000000042A1CA 33C9             xor ecx,ecx
000000000042A1CC 84C9             test cl,cl
000000000042A1CE 74D6             jz P4 + $16

Options 2 and 6 are too verbose and Options 1 and 5 too slow. Option 4 (Word(cp^) in [$0, $A, $D]) produces the same code as option 3 (cp^ in [#0, #13, #10]) without raising an exception and it sounds like a good choice.   Any downsides? 

Incidentally combining any of the above options with an initial test for the most common case e.g.   

while (Word(cp^) > $D) or not (Word(cp^) in [$0, $A, $D]) do

is much faster!

Source code attached.

CharInSet.dpr

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.

4 minutes ago, Uwe Raabe said:

That comes pretty near to Option to design in Screen PPI but save in 96 PPI

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.

13 minutes ago, David Heffernan said:

Certainly in the case of R it has a *nix heritage and is well supported on *nix and Windows platforms.

From R: Contributors (r-project.org)

Quote

The Windows port was developed by Guido Masarotto (for a while a member of R Core) and Brian Ripley, then Duncan Murdoch (a former member of R Core) and currently by Jeroen Ooms (base) and Uwe Ligges (packages).

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).

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

28 minutes ago, A.M. Hoornweg said:

I would be interested to know if x86 code has become tighter also?

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.

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

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? 

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.

23 minutes ago, wuwuxin said:

 

A valid python source file, after loaded by Python4D

What does "loaded by Python4D" mean?

23 minutes ago, wuwuxin said:

#1A

What kind of character is this?  Do you mean $A (LF)?