DelphiUdIT

If this is so known and clear, Embarcadero was very "light" in proposing such a solution ... let's hope they propose another solution because the times with parallel processing are definitely interesting.

I do test with 1 bilions of elements, and there were no issue, but the test that Stefan (the first post, not the last) did was with limited value (only 16 values in 1 milions of elements). There are sure an issue with recursive and stack allocation (or may be the algorithm in the ICompare method). Try to modify the maximum stack allocation and vary the Random value to 24 (Random(24)) and all is running. Of course this is anyway an issue

All dates prior to 1900 will fail. I "simply" copy three routine form System.DateUtils to my implementation uses section (call them with My... like MyISO8601ToDate .....) and change that line. That seem to works.

May be there is an evaluation error in the routine with negative TDateTime (less then year 1900 in "System.DateUtils" at line 3487 ... the operation should be "minus" if the date il older then 1900 .... Value := LDate + LTime;

I use Delphi 12.2 (but with old version were always the same) and the program starts immediately. Also when invoke Debug there is no lag. I have been using Windows 11 (with defender and firewall active) for many years, but I don't remember any problems like this in the past (in Windows 10 for example). I have a laptop with I9-14900HX, 64GB, 2TB SSD, the previous one was similar but with I7-12700H and a rather old one was an I7-9750H. Bye

I try this test (changing the lengths of the array) with an Intel I9-14900HX: {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils, System.Classes, System.Generics.Collections, System.Threading, System.Diagnostics, WinApi.MMSystem; var SSortArray, PSortArray: TArray<double>; I: Integer; T: TStopwatch; begin try SetLength(SSortArray, 1_000_000_000); SetLength(PSortArray, 1_000_000_000); Writeln('Fill array (double), elements count: ', Length(SSortArray).ToString); for I := Low(SSortArray) to High(SSortArray) do begin SSortArray[I] := Random(MaxInt); PSortArray[I] := SSortArray[I]; end; // Boot up t. pool TTask.Create( procedure begin ; end).Start; Writeln('Start sorting ...'); // Serial sorting T := TStopwatch.StartNew; TArray.Sort<double>(SSortArray); T.Stop; Writeln('TArray.Sort (ms.): ', T.ElapsedMilliseconds.ToString); //Insertion of timeBegin... / timeEnd... make the parallel process more fast (10% more) //timeBeginPeriod(1); // Parallel sorting T := TStopwatch.StartNew; TParallelArray.Sort<double>(PSortArray); T.Stop; Writeln('TParallelArray.Sort (ms.): ', T.ElapsedMilliseconds.ToString); //timeEndPeriod(1); except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; SetLength(SSortArray, 0); SetLength(PSortArray, 0); Readln;

Hallo to all, after update the original version of Indy, Delphi12 with patch 1, I restore also the FireUI Live functionality and may be all the other functionalities (and this with only one Indy installed, no clone or separated project). EDIT: I confirm also the other package that was disabled (Embarcadero RAD Server Edge Components) is now restored. I research that because some new packets (like the new RDGoogleAI in getit) need some Indy component not present on GitHub. This post is a first little help to update Indy: https://en.delphipraxis.net/topic/6844-tls-v13/?do=findComment&comment=88750 This are the Images about FireUI working with the new Indy: Tomorrow I'll insert the instructions to reconstruct the functionalities inside IDE (now is too late ...)

Remy wanted to point out that the WINDOWS or WINAPI unit must not be present in an Android program and that IFDEF is normally used to distinguish Android from Windows (if the program must be multiplatform). Look in the USES of your program and REMOVE all the references to WINDOWS or WINAPI (or use IFDEF in your source to divide the platforms of use and include or not those units.).

To do what you need I would use computer vision, in particular the "pattern matching" technique. You can try to use the OpenCV environment which is developed in C++ but on the net there are several wrappers for Delphi (here is one: https://github.com/gidesa/ocvWrapper46). I can't help you with OpenCV though, I used it the last time more than twenty years ago. Now I use Halcon (www.mvtec.com) and doing this is not very complex. The problem is that Halcon is very expensive for the developer and there is a royalty for each distribution depending on the features used (up to 2k Euro). One of the last project, I used it to recognize up to sixty LEGO pieces in a selection line (total time near to 200 ms.). P.S.: Halcon doesn't support Delphi, but I can give you (should still be in some post in this forum) a Delphi wrapper around C Halcon DLL.

Which changes? https://github.com/IndySockets/IndyTLS-OpenSSL/pull/2/commits/c72d352232724df9c280dc00c21f2e3dbba8e0c1

In order for everything to compile correctly, there are two changes to make: 1) In the "IdRegisterOpenSSL.pas" file it is necessary to insert the following file "IdDsnCoreResourceStrings" among the uses because it is inside it that the string "RSRegIndyIOHandlers" is defined, which is necessary to register the graphic components. 2) The "IdRegisterCoolOpenSSL.dcr" file is missing .... just copy it (and then rename obviously) from the "IdRegisterCool.dcr" file). I tried to install with the changes proposed by "@esegece-com" and appropriately modifying the original "*register*" files to also activate the changes at design time level and everything worked perfectly. A project developed both in design and code is running correctly. Do not use with the original Athens 12.1 Indy distribution.

I'm not expert on C++, but you must expose all members of your "struct", and some of them are not integral or something equivalent to Delphi like "vector<...>". See this: https://blogs.embarcadero.com/vector-containers-for-delphi/ How do you translate the "struct" and ALL the members in Delphi ? There are few information (or better none information) to help you, but I think that the problems are the "translation" the structs from c++ and records in Delphi. After you resolve this you must go on and try to implement a procedure .... Bye

I use them (almost more then 10 years) and I never had any issue with. And in every project there are one or more component of Jedi (visual and not visual). I always use the github version https://github.com/project-jedi

Take from "System.Curl"

There is an help in Rad Studio, It's old but some it is still valid.

But you don't need it, it was only a demonstration, I think from your last post that you are already resolved. Bye

I attached a zip file in the previous post : https://en.delphipraxis.net/applications/core/interface/file/attachment.php?id=11265 Inside there is all, two Delphi projects and a Python script.

Let's explain ... I'm not an expert about Python, but i work on some P4D projects and I see some issues (they are not really issues, but you cannot do some things if those happens). Look for script TEST.PY and Delphi lib pyTRYSF.pyd in the attached example. First of all: instead to do "onefile", do the standard distribution that pyinstaller do ... try only (from the pyinstaller environment): pyinstaller test.py This will create the folders that containing the executable and all the necessary files (including your .pyd library compiled with Delphi): dist\test\_internal Inside "dist\test" ther will be an executable (test.exe) and in the subfolder "_internal" should be all necessary for running the exe, INCLUDED pyTRYSF.pyd) !!!! For running any delphi library with Python is necessary to link the Pythonxxx.dll main engine at runtime. This mean that this engine should be found. When you run a python script that import a Delphi dll normally (eg. after you installed Python in Windows) your module can link the standard pythonxxx.dll library installed and is the same that the python "shell" call. If you are running the test.exe program created by pyinstaller, the pythonxxx.dll library is not the standard library, but is the DLL that is inside the "_internal" subfolder, where the pyd module is too. This "_internal\pythonxxx.dll" should be link at runtime by Delphi dll (pyTRYSF.pyd in the example). If you don't link this at runtime, you will never be able to execute your "pyd". In the example attached there is an example how I modified the link engine procedure to search the correct lib ... it works without changes with installed python engine or with pyinstaller (but no with --onefile parameters). Why the --onefiles parameters doesn't works ? 2 are the issues: 1) The pyd is not included by pyinstaller in the executable (with --onefile). 2) The executable unzip the same files like "_internal" in a temporary directory. This lead the impossibility to link the pythonxxx.dll because when the test.exe is executed the execution path is the ".\" of the test.exe an not the temporary directory. There are no chance for Delphi pyd module to link the correct pythonxxx.dll. May be the P4D guru can help in this. Bye N.B.: the example works only with Python 3.12 by now. DelphiDLLforPython.zip

I have a lot of components installed and had no issue (except for know incompatibility beetwen "new Indy from repo" and "Embarcadero RAD Server Edge Components"). I don't usually use plugins, and I found the same like others told, Parnassus Debugger plugin emit every time some AV, either in debugger sessions (not often) or when closing Rad Studio with open project ( issue from old portal is RSP-43335, issue from new portal RSS-1243). I simply use TaskManager ('analyzes waiting chain' or similar) and Process Explorer to find the module (apparently responsible).

It seems that, according to the limited documentation, they never left the "alpha" phase (year 2005).

To view COM components from IDE, your assembly should be compiled for 32 BIT explicitly (so you must have two dll register, 1 for 32 bit and one for 64 bit if you produce 64 exe). Other way is to import it using the bin64\tlibimp,exe or /bin/tlibimp.exe utility (produce the _tlb pas file). If you have only the 64 bit dll, you can use it at runtime. Example: "C:\Program Files (x86)\Embarcadero\Studio\23.0\bin64\tlibimp.exe" -Ha+ -Hs+ -Hr+ -Ya- -O+ -R+ -W+ -Wc+ -P+ "C:\Windows\System32\Speech\Common\sapi.dll" Import SAPI COM from Windows system and generate _TLB PAS file (also call wrapper).

To @Remy Lebeau if you want add this library (OpenSSL Android 1.1.1n) to experimental binary directory on Indy repo. https://cloud.dyn-o-saur.com/Android lib 1.1.1n.zip I try this version on Android 11 phone (Arm 64 bit), of course with Indy and new SSL IO Handler (PR299 archive). Bye

He said to use 1.0.2s version. This means that the library should be that version. I only suggest to load on the default library path and see what happens. In the past time I have some issues with some versions of Android with .so libs loaded around the systems (in Shared Doc, External Doc, etc...). So I always loaded them in the default library paths.

I'm using to deploy the .so files in "library\lib\arm64-v8a\" and I don't have to do nothing at startup, no loads or other ... Try to put only: ShowMessage(OpenSSLVersion()); in a Form Create event and see if the version will show.

This may help: https://learn.microsoft.com/en-us/windows/package-manager/winget/upgrade