pyscripter

I had the same problem. I though I had installed the patch through Getit but it was not actually installed. After reading this thread I installed by the command prompt. It appears that just clicking on the bat file via the File Explorer did not work despite getting the elevation prompt.

lol. It reminded me of the Ecumenical Liberation Army from the Network film. Great film by the way.

You can apply it manually to your own version (it only takes a couple of minutes, because the changes are few) and you only need to do it once). You can then submit a pull request with the patch in your Delphi version.

Here it is not an issue of compiler/interpreter because PERL is using a C library anyway. Perl uses its own regular expression engine not PCRE. There are many other options, Google RE, Intel's Hyperscan to mention a couple. PCRE+JIT is one of the fastest around and most widely used. I should not forget to mention FLRE written in Pascal, which is probably the fastest of all! Sometime ago I had posted in Google+ a benchmark comparing many of the above, But I not sure how to access Google+ material. Also note that the number of matches differs between Delphi and Perl. This is not surprising, because there are subtle differences in how these engines work.

There is an RSP https://quality.embarcadero.com/browse/RSP-21733 that asks for PCRE JIT support in the Delphi RTL. If you want the extra PCRE performance please vote for this. Off-topic. What does RSP stand for?

Not possible I am afraid and not easier. You just need to add the patched System.RegularExpressionsAPI to your project uses clause.

Still unable to login. Who do I need to contact?

Here it is https://github.com/pyscripter/Pcre-Jit-Delphi. Enjoy

@Mahdi SafsafiThanks!! Now it works in 32-bits as well. 32-bit benchmark Time | Match count ============================================================================== Delphi's own TRegEx: /Twain/ : 6.00 ms | 811 /(?i)Twain/ : 41.00 ms | 965 /[a-z]shing/ : 448.00 ms | 1540 /Huck[a-zA-Z]+|Saw[a-zA-Z]+/ : 528.00 ms | 262 /\b\w+nn\b/ : 634.00 ms | 262 /[a-q][^u-z]{13}x/ : 543.00 ms | 4094 /Tom|Sawyer|Huckleberry|Finn/ : 896.00 ms | 2598 /(?i)Tom|Sawyer|Huckleberry|Finn/ : 1063.00 ms | 4152 /.{0,2}(Tom|Sawyer|Huckleberry|Finn)/ : 2980.00 ms | 2598 /.{2,4}(Tom|Sawyer|Huckleberry|Finn)/ : 3088.00 ms | 1976 /Tom.{10,25}river|river.{10,25}Tom/ : 528.00 ms | 2 /[a-zA-Z]+ing/ : 918.00 ms | 78423 /\s[a-zA-Z]{0,12}ing\s/ : 548.00 ms | 49659 /([A-Za-z]awyer|[A-Za-z]inn)\s/ : 775.00 ms | 209 /["'][^"']{0,30}[?!\.]["']/ : 312.00 ms | 8885 Total Time: 13321.00 ms ============================================================================== Delphi's own TRegEx with Study: /Twain/ : 6.00 ms | 811 /(?i)Twain/ : 40.00 ms | 965 /[a-z]shing/ : 318.00 ms | 1540 /Huck[a-zA-Z]+|Saw[a-zA-Z]+/ : 24.00 ms | 262 /\b\w+nn\b/ : 619.00 ms | 262 /[a-q][^u-z]{13}x/ : 450.00 ms | 4094 /Tom|Sawyer|Huckleberry|Finn/ : 31.00 ms | 2598 /(?i)Tom|Sawyer|Huckleberry|Finn/ : 256.00 ms | 4152 /.{0,2}(Tom|Sawyer|Huckleberry|Finn)/ : 2875.00 ms | 2598 /.{2,4}(Tom|Sawyer|Huckleberry|Finn)/ : 2905.00 ms | 1976 /Tom.{10,25}river|river.{10,25}Tom/ : 63.00 ms | 2 /[a-zA-Z]+ing/ : 829.00 ms | 78423 /\s[a-zA-Z]{0,12}ing\s/ : 569.00 ms | 49659 /([A-Za-z]awyer|[A-Za-z]inn)\s/ : 685.00 ms | 209 /["'][^"']{0,30}[?!\.]["']/ : 56.00 ms | 8885 Total Time: 9746.00 ms ============================================================================== Delphi's own TRegEx with JIT: /Twain/ : 12.00 ms | 811 /(?i)Twain/ : 13.00 ms | 965 /[a-z]shing/ : 13.00 ms | 1540 /Huck[a-zA-Z]+|Saw[a-zA-Z]+/ : 3.00 ms | 262 /\b\w+nn\b/ : 189.00 ms | 262 /[a-q][^u-z]{13}x/ : 154.00 ms | 4094 /Tom|Sawyer|Huckleberry|Finn/ : 22.00 ms | 2598 /(?i)Tom|Sawyer|Huckleberry|Finn/ : 64.00 ms | 4152 /.{0,2}(Tom|Sawyer|Huckleberry|Finn)/ : 371.00 ms | 2598 /.{2,4}(Tom|Sawyer|Huckleberry|Finn)/ : 497.00 ms | 1976 /Tom.{10,25}river|river.{10,25}Tom/ : 12.00 ms | 2 /[a-zA-Z]+ing/ : 105.00 ms | 78423 /\s[a-zA-Z]{0,12}ing\s/ : 197.00 ms | 49659 /([A-Za-z]awyer|[A-Za-z]inn)\s/ : 39.00 ms | 209 /["'][^"']{0,30}[?!\.]["']/ : 19.00 ms | 8885 Total Time: 1730.00 ms I will release it at Github (watch for announcement). Then @Kas Ob.you can try to get rid of __chkstk and see what happens.

@David Heffernan I explained why I am linking C code earlier... @Kas Ob.I would rather use the default options if I can. For example I am not sure of the performance implications of PCRE_NO_RECURSE. Now, if nothing else worked, I will try.

Well yes. I need a 32-bit __chkstk Here is the Visual Studio masm code page ,132 title chkstk - C stack checking routine ;*** ;chkstk.asm - C stack checking routine ; ; Copyright (c) Microsoft Corporation. All rights reserved. ; ;Purpose: ; Provides support for automatic stack checking in C procedures ; when stack checking is enabled. ; ;******************************************************************************* .xlist include vcruntime.inc .list ; size of a page of memory _PAGESIZE_ equ 1000h CODESEG page ;*** ;_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. ; ; NOTE: Currently, the (EAX < _PAGESIZE_) code path falls through ; to the "lastpage" label of the (EAX >= _PAGESIZE_) code path. This ; is small; a minor speed optimization would be to special case ; this up top. This would avoid the painful save/restore of ; ecx and would shorten the code path by 4-6 instructions. ; ;Entry: ; EAX = size of local frame ; ;Exit: ; ESP = new stackframe, if successful ; ;Uses: ; EAX ; ;Exceptions: ; _XCPT_GUARD_PAGE_VIOLATION - May be raised on a page probe. NEVER TRAP ; THIS!!!! It is used by the OS to grow the ; stack on demand. ; _XCPT_UNABLE_TO_GROW_STACK - The stack cannot be grown. More precisely, ; the attempt by the OS memory manager to ; allocate another guard page in response ; to a _XCPT_GUARD_PAGE_VIOLATION has ; failed. ; ;******************************************************************************* public _alloca_probe _chkstk proc _alloca_probe = _chkstk push ecx ; Calculate new TOS. lea ecx, [esp] + 8 - 4 ; TOS before entering function + size for ret value sub ecx, eax ; new TOS ; Handle allocation size that results in wraparound. ; Wraparound will result in StackOverflow exception. sbb eax, eax ; 0 if CF==0, ~0 if CF==1 not eax ; ~0 if TOS did not wrapped around, 0 otherwise and ecx, eax ; set to 0 if wraparound mov eax, esp ; current TOS and eax, not ( _PAGESIZE_ - 1) ; Round down to current page boundary cs10: cmp ecx, eax ; Is new TOS bnd jb short cs20 ; in probed page? mov eax, ecx ; yes. pop ecx xchg esp, eax ; update esp mov eax, dword ptr [eax] ; get return address mov dword ptr [esp], eax ; and put it at new TOS bnd ret ; Find next lower page and probe cs20: sub eax, _PAGESIZE_ ; decrease by PAGESIZE test dword ptr [eax],eax ; probe page. jmp short cs10 _chkstk endp end

There are no conversions needed for Win64. For Win 32 I have the issue of windows calls (such as __imp__VirtualFree@12. Fortunately there is just one obj file that makes such calls and I will find a way to work around it (see earlier posts). Why not use bcc32c... I have only access to the free tools that only compile x86 code pcre has a number of configuration steps and options and cmake makes it very easy and convenient to automate everything. It would be very hard to do that manually correctly. cmake has a generator for bcc32c but is rather new and I am not sure how well tested that is. Saddly, I have more trust in the Visual Studio compiler, especially for code that requires stack checking. Does bcc32c do that? When I finish I will release the stuff at github, so people can take a look and make adjustments. Embarcadero can use their own compiler if they wish.

PCRE16. This is what Delphi uses and for a reason. It avoids conversions between delphi strings and PCRE strings.

I would prefer to not mess around with the c files and I think that pcre_jit_compile needs the stack checking anyway. Could anyone help translate the LLMV code to Delphi PLEASE? The prize is that everyone gets a much faster System.RegularExpressions and we may even convince Embarcadero to implement the changes which are really minor.

Use @David Heffernan trick mentioned above. It works fine. Your ld stuff does not appear to work with Visual studio object files (only gnu). I have tried /Gs1000000 but did not help. and yes I am aware of the other stuff you mention and can work around them.

In Visual Studio /GsX is the same as /GcX in other compilers. I am pretty sure: With the current __chkstk a crash occurs when this is called (debugging using the CPU window) Replacing that with linking VSs chkstk.obj works very smoothly

You are confusing /Gs with /GS https://docs.microsoft.com/en-us/cpp/build/reference/gs-control-stack-checking-calls?view=vs-2019https://docs.microsoft.com/en-us/cpp/build/reference/gs-control-stack-checking-calls?view=vs-2019 Already using /GS.

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?