pyscripter

I have tried with /Gs9999999 which suppresses the stack checking but I still got crashes. I suspect that pcre needs the stack checking. Please note __chkstk automatically allocates stack if needed. ;_chkstk - check stack upon procedure entry ; ;Purpose: ; Provide stack checking on procedure entry. Method is to simply probe ; each page of memory required for the stack in descending order. This ; causes the necessary pages of memory to be allocated via the guard ; page scheme, if possible. In the event of failure, the OS raises the ; _XCPT_UNABLE_TO_GROW_STACK exception. ; I understand that a DLL is a safer and easier option, but this is meant to be an enhancement of System.RegularExpressions which uses static linking of obj files.

Firstly I would like to report that the above works fine. Thanks @Mahdi Safsafi With minimal changes to System.RegularExpressionsAPI only, I got PCRE JIT to work in 64 bits (haven't fully sorted out 32 bits but I now know how to do it thanks to @Kas Ob.). I had one issue related to this Stackoverflow question that was resolved using @David Heffernan simple trick (thanks). Was it worth my while? Judge for yourselves. Here are the results of my standard re benchmark: Time | Match count ============================================================================== Delphi's own TRegEx: /Twain/ : 6.00 ms | 811 /(?i)Twain/ : 45.00 ms | 965 /[a-z]shing/ : 450.00 ms | 1540 /Huck[a-zA-Z]+|Saw[a-zA-Z]+/ : 455.00 ms | 262 /\b\w+nn\b/ : 680.00 ms | 262 /[a-q][^u-z]{13}x/ : 610.00 ms | 4094 /Tom|Sawyer|Huckleberry|Finn/ : 836.00 ms | 2598 /(?i)Tom|Sawyer|Huckleberry|Finn/ : 991.00 ms | 4152 /.{0,2}(Tom|Sawyer|Huckleberry|Finn)/ : 2755.00 ms | 2598 /.{2,4}(Tom|Sawyer|Huckleberry|Finn)/ : 3021.00 ms | 1976 /Tom.{10,25}river|river.{10,25}Tom/ : 464.00 ms | 2 /[a-zA-Z]+ing/ : 805.00 ms | 78423 /\s[a-zA-Z]{0,12}ing\s/ : 563.00 ms | 49659 /([A-Za-z]awyer|[A-Za-z]inn)\s/ : 837.00 ms | 209 /["'][^"']{0,30}[?!\.]["']/ : 321.00 ms | 8885 Total Time: 12853.00 ms ============================================================================== Delphi's own TRegEx with Study: /Twain/ : 6.00 ms | 811 /(?i)Twain/ : 49.00 ms | 965 /[a-z]shing/ : 318.00 ms | 1540 /Huck[a-zA-Z]+|Saw[a-zA-Z]+/ : 21.00 ms | 262 /\b\w+nn\b/ : 586.00 ms | 262 /[a-q][^u-z]{13}x/ : 417.00 ms | 4094 /Tom|Sawyer|Huckleberry|Finn/ : 27.00 ms | 2598 /(?i)Tom|Sawyer|Huckleberry|Finn/ : 216.00 ms | 4152 /.{0,2}(Tom|Sawyer|Huckleberry|Finn)/ : 2607.00 ms | 2598 /.{2,4}(Tom|Sawyer|Huckleberry|Finn)/ : 2768.00 ms | 1976 /Tom.{10,25}river|river.{10,25}Tom/ : 49.00 ms | 2 /[a-zA-Z]+ing/ : 758.00 ms | 78423 /\s[a-zA-Z]{0,12}ing\s/ : 565.00 ms | 49659 /([A-Za-z]awyer|[A-Za-z]inn)\s/ : 654.00 ms | 209 /["'][^"']{0,30}[?!\.]["']/ : 50.00 ms | 8885 Total Time: 9108.00 ms ============================================================================== Delphi's own TRegEx with JIT: /Twain/ : 12.00 ms | 811 /(?i)Twain/ : 13.00 ms | 965 /[a-z]shing/ : 11.00 ms | 1540 /Huck[a-zA-Z]+|Saw[a-zA-Z]+/ : 4.00 ms | 262 /\b\w+nn\b/ : 126.00 ms | 262 /[a-q][^u-z]{13}x/ : 169.00 ms | 4094 /Tom|Sawyer|Huckleberry|Finn/ : 22.00 ms | 2598 /(?i)Tom|Sawyer|Huckleberry|Finn/ : 63.00 ms | 4152 /.{0,2}(Tom|Sawyer|Huckleberry|Finn)/ : 273.00 ms | 2598 /.{2,4}(Tom|Sawyer|Huckleberry|Finn)/ : 334.00 ms | 1976 /Tom.{10,25}river|river.{10,25}Tom/ : 12.00 ms | 2 /[a-zA-Z]+ing/ : 86.00 ms | 78423 /\s[a-zA-Z]{0,12}ing\s/ : 158.00 ms | 49659 /([A-Za-z]awyer|[A-Za-z]inn)\s/ : 36.00 ms | 209 /["'][^"']{0,30}[?!\.]["']/ : 18.00 ms | 8885 Total Time: 1356.00 ms Almost a 10 fold speedup. Now here is my next question. System.RegularExpressionsAPI resolves the __chkstk dependency as follows. procedure __chkstk; asm end; This created all sort of unpredictable crashes. I am not sure whether the crashes were a result of lack of stack checking or a difference in the calling conventions or both. I had to resolve __chkstk by linking to chkstk.obj provided by Visual Studio, however this is kind of problematic because there are licensing issues and you cannot distribute chkst.obj. I have looked around and saw the the LLMV projects defines __chkstk as follows: // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. // See https://llvm.org/LICENSE.txt for license information. // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception #include "../assembly.h" // _chkstk routine // This routine is windows specific // http://msdn.microsoft.com/en-us/library/ms648426.aspx // Notes from r227519 // MSVC x64s __chkstk and cygmings ___chkstk_ms do not adjust %rsp // themselves. It also does not clobber %rax so we can reuse it when // adjusting %rsp. #ifdef __x86_64__ .text .balign 4 DEFINE_COMPILERRT_FUNCTION(___chkstk_ms) push %rcx push %rax cmp $0x1000,%rax lea 24(%rsp),%rcx jb 1f 2: sub $0x1000,%rcx test %rcx,(%rcx) sub $0x1000,%rax cmp $0x1000,%rax ja 2b 1: sub %rax,%rcx test %rcx,(%rcx) pop %rax pop %rcx ret END_COMPILERRT_FUNCTION(___chkstk_ms) #endif // __x86_64__ Any help in converting this to a Delphi assembler function would be highly appreciated.

Ssh-Pascal is a new free and open source library providing ssh support to Delphi, based on libssh2. Libssh2 is a mature ssh library used by PHP (built-in), Rust and many other languages and applications. Features: Extensive ssh features Support for different authorization methods (publickey, password, agent, hostbased and keyboard-interactive) Known host management. Execution of commands on the host capturing stdout and stderr Comprehensive sftp support Port forwarding (currently only local to remote) scp support High-level pascal-friendly, interface-based wrapping of ssh functionality. Lower-level usage is possible.

I also found FileBinReplace. (16K utility).

Does this EMB compiler not decorate the DLL imports? If say you add WinApi.Windows to your uses clause does it automatically fix resolve the symbols?

This is only relevant for calls to the C runtime. I am already doing that -DPCRE_STATIC_RUNTIME=ON Has the same effect (activates the /MT option)

Is there a long answer? Is there a way around it? I am desperate as you see. Is there a way to tell the C compiler not to add the decoration?

$addPath = 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin' $regexAddPath = [regex]::Escape($addPath) $arrPath = $env:Path -split ';' | Where-Object {$_ -notMatch "^$regexAddPath\\?"} $env:Path = ($arrPath + $addPath) -join ';' $pcrePath = 'pcre-8.44' Remove-Item –path $pcrePath –recurse Expand-Archive -LiteralPath $pcrePath'.Zip' -DestinationPath . copy CMakeLists.txt $pcrePath pushd $pcrePath cmake . -G "Visual Studio 16 2019" -A Win32 -DBUILD_SHARED_LIBS=OFF -DPCRE_BUILD_PCRE16=ON -DPCRE_BUILD_PCRE8=OFF -DPCRE_SUPPORT_UNICODE_PROPERTIES=ON -DPCRE_SUPPORT_JIT=ON -DPCRE_STATIC_RUNTIME=ON -DCMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH=OFF cmake --build . --config Release copy .\pcre16.dir\Release\*.obj ..\Source\obj\pcre\win32\ popd Using the above Powershell script if that matters. I have added the /GS- compiler flag to avoid further dependencies. FYI I am trying to compile PCRE with JIT support. This is what makes the Windows calls.

Also bugs reported as fixed are not fixed: RSP-29271 [DelphiLSP] Code Insight adds unneeded () when changing procedures/functions

Thanks for the info. I would like to link the object files into Delphi avoiding the need to deploy DLLs. It would be great if you were able to do this. This link shows how to use cmake to compile the dll with Visual Studio. The project also supports nmake. @Vincent ParrettYou appear to be the original author of System.RegularExpressions. How did you compile the C code of PCRE avoiding the need to bring in c runtime dependencies.

Putty splits the ssh functionality into different executables. ssh is provided by plink.exe. The project converted to a dll only psfpt.exe.

I guess you mean opinions 😀. I was not aware of tgputtylib, but it is commercial and only covers sftp. The other options had reasonable sftp functionality (however no handling of ~ in paths) but were based on old versions of libssh2 had numerous C to Delphi translation issues especially related to 64bits that needed fixing did not provide for remote execution of commands and port forwarding which was important to me and fundamental part of ssh.

Help wanted: libssh2 can be compiled so that it uses Windows CNG instead of OpenSSL, thus avoiding any dependence on other dynamic libraries. I wonder whether it would be possible to compile it into C obj files that can be linked into the Delphi executable. This would simplify the deployment greatly. Any help on this would be greatly appreciated.

Yes indeed.

No it is written in Delphi pascal.

No. It is (was) a stand-alone free and open source C/C++ IDE, working with the GNU compiler toolset built with Delphi and quite popular at its prime. There is a fork that includes a form designer for WxWidgets GUI applications. Does anyone recall the short-lived commercial C++ wxWidgets (then called WxWindows) Borland IDE (unrelated to Dev-C++)? I can't even remember what it was called.

Yes

Exactly. If you are familiar with Excel automation think about the Applications and the Workbooks collection. The second exists only as part of the first. The second could be implemented as a TContainedObject. What TAggregatedObject and TContainedObject have in common: They have no separate reference counting They should be created and destroyed by the Controller. How do they differ? (from the source code) TAggregatedObject simply reflects QueryInterface calls to its controller. From such an aggregated object, one can obtain any interface that the controller supports, and only interfaces that the controller supports. This is useful for implementing a controller class that uses one or more internal objects to implement the interfaces declared on the controller class. Aggregation promotes implementation sharing across the object hierarchy. TContainedObject is an aggregated object that isolates QueryInterface on the aggregate from the controller. TContainedObject will return only interfaces that the contained object itself implements, not interfaces that the controller implements.

If you are switching from another version of Synedit to Synedit-2 you need to uninstall the current version, remove all compiled packages and install from scratch. As mentioned above I am not sure which is the earliest version supported (same about the Turbo Synedit), however I am quite sure Delphi 10.2 should be good.

Does anyone know in which Delphi version TStrings got following properties: Encoding/DefaultEncoding TrailingLineBreak WriteBOM LineBreak Thanks...

A more advanced wrapper for Scintilla was in http://myarmor.users.sourceforge.net/. I had some involvement in the initial development. But it died many years ago. A more up to date wrapper exists in the Inno Setup source code https://github.com/jrsoftware/issrc/tree/main/Components. However it is based on Scintilla 2.22, when the current version is 4.4...

That would be good, but the author says it is not going to be easy.

It does, but the spacing is not very good.

To be frank I am not sure. Like the Turbo branch it is aimed at the most recent versions of Delphi. The code uses generics and unicode, so that I suppose determines the minimum version.

Unfortunately SynEdit's ShowModification is half-baked and does not work well when you undo. This is why it has not been ported to SynEdit-2. Proper support requires some work in the undo/redo system.