Jump to content

pyscripter

Members
 View Profile  See their activity

  • Content Count

    1005

  • Joined

  • Last visited

  • Days Won

    65

Posts posted by pyscripter

  1. Posted · Edited by pyscripter

    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?

    • Like 2

  2. Posted · Edited by pyscripter

    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.

    • Like 2

  4. Posted

    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?

     

  6. Posted · Edited by pyscripter

    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
    • Like 2

  11. Posted

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

  12. Posted · Edited by pyscripter

    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? 

    • Thanks 1

  13. Posted

    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.
     

  16. Posted

    45 minutes ago, Uwe Raabe said:

    Well, I see the font size (and thus TFont.Size) as an invariant in regard to the dpi of the media it is displayed. Keeping the font size constant when changing dpi will always neutralize any rounding errors due to consecutive dpi changes. It doesn't matter if that the current and past implementation doesn't follow this approach. It is never too late to do it right.

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

     

    46 minutes ago, Uwe Raabe said:

    BTW, regarding TFontDialog and High DPI: https://quality.embarcadero.com/browse/RSP-34122

    Voted for that.

  17. Posted

    5 minutes ago, Uwe Raabe said:

    The advantage of my suggested approach is, that it fixes a whole bunch of scaling errors still existent in Delphi 11.

    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.

  18. Posted · Edited by pyscripter

    6 hours ago, Uwe Raabe said:

    I may be wrong, but I think the underlying reason is: Font.Size and Font.PixelsPerInch do not respect per-monitor scaling

     

    This has been discussed a lot and font scaling is now re-evaluated.

    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.

  22. Posted

    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?

×