Jump to content

pyscripter

Members
 View Profile  See their activity

  • Content Count

    1020

  • Joined

  • Last visited

  • Days Won

    66

Posts posted by pyscripter

  3. Posted · Edited by pyscripter

    1 hour ago, Vincent Parrett said:

    MS ActiveScripting

    Wow.  Once, I had very high hopes for this technology, but it became another abandonware of Microsoft.

     

    Have you considered using python (pyscripter/python4delphi: Free components that wrap up Python into Delphi and Lazarus (FPC))?  

    I guess though you were using JScript and you want to stick to JavaScript.

     

    For JavaScript there is also Microsoft's ChacraCore, which used to be the JavaScript engine of the old Edge browser.  There is a good Delphi wrapper.  See also the blog.

  8. Posted · Edited by pyscripter

    @Kas Ob. There are many ways to skin a cat.  The approach adopted in pascal-process uses asynchronous (overlapped) IO with  alertable wait.  So there are no tight loops with Sleep, or additional threads for reading.  I think it is as efficient as it can get.    

     

    I compared your code to pascal-process by using: 'cmd /v:on /c "set start=!time! && dir C:\Windows /s && set end=!time! && echo Start time: !start! && echo End time: !end!"'#13#10

     

    Your code:

      

    Start time: 14:31:08.09
End time: 14:31:22.64

    about 14 secs

     

    pascal-process

      

    Start time: 14:35:54.74
End time: 14:36:04.58

    about 9 secs.

     

    To make sure disk caching did not play a role, I run your code again, with similar results:

      

    Start time: 15:01:58.56
End time: 15:02:14.17

    About 15 secs.

     

    Of course one should not read much in a single benchmark.    But, I do not see any reason your code is faster or otherwise better than the one used in pascal-process.

     

    Regarding AttachConsole do you happen to know, in which Delphi version it was first declared?

     

  11. Posted · Edited by pyscripter

    @Dave Nottage Thanks for testing. 

     

    I have updated the Readme with the corrected parameter list for OnRead.

    Regarding the conversion to string, the whole point of the library is that you get bytes.  It is up to the user to use the bytes whichever way is appropriate.  The console encoding may be not be Delphi's default encoding.   In Linux it is most likely UTF8.   On Windows one might use the GetConsoleOutputCP API to get the code page for the output.   However even that is not reliable, For instance, on Windows, the scp command expects input and produces output in UTF8 encoding irrespective of the console encoding. The use of ANSI encoding on the project page was just an example. 

     

    I agree thought that for the example TEncoding.Default is a better choice.  So I have updated that as well.

     

  15. Posted · Edited by pyscripter

    I have installed the Linux platform support and I am able to run simple Linux console applications targeting WSL.  However, I cannot find the Posix source files, such as Posix.Base, Posix.SysTypes etc.   What am I missing? 

     

    I am using Delphi 12.3.  I can see the files in my Delphi 11 installation.

  16. Posted · Edited by pyscripter

    On 11/30/2022 at 9:19 AM, Fr0sT.Brutal said:

    TurboPower was an amazing company, they had so much open source components

    For the record, TurboPower was a good company, but their components were commercial.   They were open-sourced their products when the company shut-down their component business.   However, they are products of the previous century and they show it.   And incidentally, TurboPower was owned by a gambling business (a Casino or something).

  19. Posted · Edited by pyscripter

    There are many components/libraries available for running processes and capturing their output.  But, I got frustrated with their design and functionality, mostly for the following reasons:

    • Fixation with and premature conversion to strings. Processes produce and consume bytes.
    • Blocking reading of process output, resulting to inefficiencies (tight loops with Sleep, or separate threads for reading the output or providing input to the process)
    • Incomplete features and/or over-bloated

     

    So, I have made my own pascal-process single unit library.

     

    Main features:

    • Asynchronous reading of process output
    • Separate stdout and stderr reading which can optionally be merged
    • Ability to consume output as it is produced or else let it accumulate and read the final result
    • Ability to provide input to the running process before or while the process is running.
    • Ability to terminate the running process.
    • Synchronous and asynchronous execution of processes.
    • Interfaced-based facilitating memory management.
    • MIT licence

     

    Usage:

    You do not need to install the library. Just download or clone the repo and add the source subdirectory to the Library path.  Then add PascalProcess to your uses clause.

     

    If you just want to get the output of a process you can use the class functions of TPProcess.

      

      TPProcess = class(TInterfacedObject, IPProcess)
    class function Execute(const ACommandLine: string;
      const ACurrentDir: string = ''): TBytes; overload;
    class procedure Execute(const ACommandLine: string;
      const ACurrentDir: string; out Output, ErrOutput: TBytes) overload;
  end;

    This is an example: 

    var
  Output: TBytes;
begin
  Output := TPProcess.Execute('cmd /c echo Hi');
  Writeln(TEncoding.ANSI.GetString(Output));
end;

    For more demanding cases you can use the IPProcess interface.

     

    Example: 

    type
  TUtils = class
    class procedure OnRead(Sender: TObject; const Bytes: TBytes);
  end;

class procedure TUtils.OnRead(Sender: TObject; const Bytes: TBytes);
begin
  Writeln(TEncoding.ANSI.GetString(Bytes));
end;

procedure Test2;
// Processes ouput as it gets produced
// The main thread terminates the process
var
  Process: IPProcess;
begin
  Process := TPProcess.Create('cmd /c dir c:\ /s');
  Process.OnRead := TUtils.OnRead;
  WriteLn('Press Enter to start the process. Press Enter again to terminate');
  ReadLn;
  Process.Execute;
  ReadLn;
  Process.Terminate;
end;

    See here the definition of IPProcess.

     

    Limitations:

    Currently the library is Windows only.  The intention is to support other platforms (help wanted).

    • Like 8
    • Thanks 3

  20. Posted · Edited by pyscripter

    For now, there are very serious limitations you need to consider when using emNewInterpreterOwnGIL  to achieve true parallelism.  See for instance the limitations in What’s new in Python 3.14 — Python 3.14.0b3 documentation.   

     

    Even the innocent looking print command is not thread-safe.  And almost nothing can be share between the interpreters.  Also there are limitations about what you can import, and P4D modules are not yet considered safe for use with emNewInterpreterOwnGIL.  

     

    This is changing with the forthcoming python 3.14.  It will include a new module concurrent.interpreters that exposes the interpreters with their own GIL to pure python code.  There will also be an addition of ways to communicate between the interpreters using queues.  See PEP 734.   So for example you could store your output to such a queue and print it when everything is finished.  

     

    But all the above is cutting edge and unless you really need it you should avoid it,  If you decide to use it then make sure you fully understand the limitations and implications.

     

    I will try to make P4D modules compatible with emNewInterpreterOwnGIL and that would at least give you the option to say add output to a Delphi string list (or something similar) protected with a global lock on the Delphi side.

     

    Note that all the above are not related to the free-threading version of Python, which in itself is another story altogether.

     

     

    • Like 2

  22. Posted · Edited by pyscripter

    These two tests appear to be identical.

     

    Parsing them leads to a call 

     

    result := TJSONNumber.Create(str);

     

    where str = '0.1.2'

     

    Apparently this succeeds in Delphi 10.4 but correctly fails in later versions.  This is easily fixed by using TryStrToFloat before creating the TJSONNumber. 

    @dummzeuch I have committed a potential fix for the above10.4 failed invalid tests.  Could you please try again.

    • Like 1

  23. Posted · Edited by pyscripter

    17 minutes ago, dummzeuch said:

    That's TStringList.Contains which doesn't find. And that apparently was introduced in Delphi 12.

    I have now replaced that call to Contains.  Tested with Delphi 11. 

    ✖  comment\after-literal-no-ws.toml: 'inf' is not a valid floating point value
✖  float\inf-and-nan.toml: 'nan' is not a valid floating point value
✖  spec-1.0.0\float-2.toml: 'inf' is not a valid floating point value

Completed: 205, Succeeded: 202, Failed: 3

Completed: 529, Succeeded: 529, Failed: 0
✓ All tests passed!

     

    I think I can live with that.  Apparently StrToFloat was extended to cope with inf, nan, and -inf in Delphi 12.  In Delphi 12 you can serialize such special floating point values.

     

    Could you please test again with Delphi 10.4  The parsing might work, but the serializer had many bugs in 10.4.

  24. Posted

    Backward compatibility is going to be an issue at least for the serializer part.  Right now I am trying to fix Delphi 11 compatibility.

    It should be possible to make the parsing staff made compatible with earlier versions of Delphi, as long as TJSONObject exists.

     

     

×