pyscripter

Multi-phase extension module initialization has been implemented. See Multi-phase module initialization implemented · pyscripter/python4delphi · Discussion #505 for details. What this means is that you can now create python extension modules with P4D that can be used with sub-interpreters including those created with the new concurrent.interpreters module of python 3.14.

Another abandonware of Microsoft! It first sounded real good.

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.

@Vincent ParrettOut of curiosity, what are you using QuickJS for?

By the way, TThread.Yield is the cross-platform way to call SwitchToThread.

I set the pascal-process buffer to 4 *1024 for the comparison.

Although, it does not look like it, the alertable wait does the same.

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

@Kas Ob. This is an open-source project. You are welcome to create PRs, open issues, make suggestions etc.

For some reason, I do not see the May Patch.

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

pascal-process is now multi-platform! So now there is a Delphi library to match fpc's TProcess. Desktop POSIX platforms (LINUX and MACOS) are now supported in addition to Windows. I have tested with LINUX. Since, I do not have a MACOS system available, I would appreciate some help in testing with MACOS.

As mentioned I can compile code. Just the sources in the above path are missing.

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.