DelphiUdIT

How is your RIDL definition of COM class ... may be there is the issue ...

To summarize: x86 (32-bit): 1) "Quiet NAN" can always be used; 2) UnMasked Invalid Operation : - "Signaling NAN" throws an exception if used with FPU registers (i.e function return value); 3) Masked Invalid Operation: - "Signaling NAN" is switched to "Quiet NAN" if used with FPU registers (i.e function return value); N.B.: if you pass the "Signaling NAN" via function parameter then you can use it 'cause no FPU register is involving. x64 (64-bit): 1) "Quiet NAN" can always be used; 2) "Signaling NAN" can always be used;

The result value is coming from FPU register ST(0) like @David Heffernan told. The issue is that the code load in ST(0) the correct signaling NAN, but become quieted NAN in ST(0). This is not an Issue from Embarcadero, but may be an hardware setting. I am far from FPU registers (working with them at time of I486DX ). EDIT: From what I read in the Intel manuals, it seems that the impersonation is internally QNAN if the FPU "invalid operation" exception is masked. (ref 4.8.3.6 of Intel manual "325462-sdm-vol-1-2abcd-3abcd-4"). There are many tables inside that show how hardware treats the NAN.

The Indy "Crew" sayd that this change will be done in the next version (Indy 11). By now you can only change (may be MUST) that at your hand. This is necessary if you want maintain compatibility with Embarcadero tools and also some thirdy party components that use Indy. But Embarcadero is interested in Indy's progression, so things will be fine (https://www.indyproject.org/2024/08/05/ongoing-work-in-indy-for-openssl-updates/)

The "sasl-oauth" branch will also be useful to enable the use of the OAUTH protocol, especially for email client functions.

Uhmm ... during my tests maximum charge of CPU is 4% ... I don't think that any other normal load can change the timing in impressive way. Of course depends where you need these works. In my applications I will not able to use parallel algo, like already discuss in other posts cause heavy load (85% of CPU). but I never used in my life any sort algo, 'cause normally I had only maximum of some hundred of elements and I use normal shitfing (memcopy) in entrance of array. Bye

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