Leaderboard

https://delphisorcery.blogspot.com/2021/06/spring4d-20-sneak-peek-evolution-of.html

A few months ago I replaced all RTL collections (apart from TStringList) with spring4d 2.0 collections and I saw noticeably smaller binaries (exe/bpl) and faster overall application performance. Spring4D collections are just so much nicer to use, being interface based is a plus for me, and the LINQ like functionality makes it really easy to do sorting, filtering, projections etc - if only Delphi had lambdas so the predicates etc were not so damned verbose! I'm extremely thankful for the work @Stefan Glienke has put into Spring4D 👍

The opposite - by forcing many specialized types into Spring.Collections.dcu it avoids stuffing them into each and every other dcu that might use them. Try following: create 10 units each with a simple class and a function that calls TCollections.CreateList<TThatClass> - now compile the project once with 1.2 and once with 2.0 and look at the dcus. Also I can only repeat my suggestion: precompile Spring and use its dcus and don't recompile it over and over every time you compile your project. Because then you will gain the main benefit - most commonly used specializations are in Spring.Collections.dcu and the compiler just needs to reference them. Compiletime and memory usage of the compiler for projects using Spring 2.0 have dropped significantly.

@marcocir start from the assumption that the compiler is correct and that your code is faulty. That's far and away the most likely explanation. With that mindset, read Arnaud's answer again.

Of course it is. If another thread holds the lock, PyGILState_Ensure blocks until the GIL becomes available, i.e. the holding thread calls PyGILState_Release. If more than one threads are waiting for GIL then I think it is assigned of FCFS basis. The automatic switching that you described only applies to threads created with the threading code. All other threads need to get the GIL before executing python code and then release it. Yes you do need to call Py_Begin_Allow_Threads in the main thread. When the python DLL loads, the main thread owns the GIL and it needs to release it before other threads can execute python code.

The Win64 assembly is not inefficient. It is almost the same code as the Win32 version. And my guess is that Win64 code would be faster. The on-stack TPanel is initialized with explicit zero fill of all bytes in Win32 in a loop, whereas it is with zero fill only of some managed fields within TPanel in Win64, if I understand well the generated asm. Then the RTL calls are comparable. So at execution, my guess is that the Win64 version is likely to be faster. So the compiler is not faulty. On the other hand, your code could be enhanced. One simple optimization would be to write "const Programma: TProgrammaCalcio;" for your program parameter to avoid a RTL array copy call (stack allocation + movsd/movsq + AddRefArray). Using "const" for managed types (string, arrays, records) is always a good idea. Actual stack variable use may be the real cause of the Stack Overflow problem. My guess is that you are abusing of huge variable on stack. Each calls seems to consume $8cb08 bytes on the stack. Much too big! So to fix it: 0) read more about how records and static arrays are used by Delphi, especially about memory allocation and parameter passing 1) use const to avoid a temporary copy on the local stack 2) don't use fixed size arrays for TProgrammaCalcio but a dynamic array allocated on heap 3) TPanel may also be somewhat big - consider using classes and not records to use the heap instead of the stack 4) If you are sure that heap allocation is a bottleneck (I doubt it here), you may create a temporary TPanel within the main TfrmFixedCalcio instance and reuse it Before wondering about the code generated by the Delphi compiler, please review your own code, which is likely to be the real bottleneck for performance. And in such a method, the FMX process and the GUI computation is likely to be the real bottleneck, not your Delphi code, and especially not the prolog/epilog generated by the Delphi compiler. "Premature Optimization is the root of all evil"! (DK)

My dzlib has TFilesystem.CopyFileWithProgress in unit u_dzFileUtils. It's a wrapper around the WinAPI function CopyFileEx. I also seem to remember such a functionality in the jcl.

To make results easier to read, could the numbers have thousand separators? At least for me it is hard to compare two numbers if they aren't next to each other: 23432422 .... .... .... .... .... .... ... .... ... 4343241 Are they even at same ballpark. Some people have very good eye on are things on same line, for me it is almost impossible 🙂 -Tee-

Make sure that Count is not 0, otherwise Str[1] will report a range error if Range Checking is enabled. I would use PAnsiChar(Str)^ instead to avoid that check. Also, you are not checking ReadFile() for failure. Try this instead: function Tcomportserver.ReadString(var Str : AnsiString; Count : Integer) : Integer; var Overlapped : TOverlapped; BytesRead : DWORD; begin Result := 0; if Count <= 0 then Exit; SetLength(Str, Count); FillChar(Overlapped, SizeOf(Overlapped), 0); Overlapped.hEvent := CreateEvent(nil, True, True, nil); if Overlapped.hEvent = 0 then raise EWriteError.Create('Unable to create overlapped event object: ' + LastErr); try if not ReadFile(ComHandle, PAnsiChar(Str)^, Count, BytesRead, @Overlapped) then begin if GetLastError() <> ERROR_IO_PENDING then raise EWriteError.Create('Unable to read from port: ' + LastErr); end; if not GetOverlappedResult(ComHandle, Overlapped, BytesRead, True) then raise EWriteError.Create('Unable to read from port: ' + LastErr); SetLength(Str, BytesRead); Result := BytesRead; finally CloseHandle(Overlapped.hEvent); end; end;

In your code above you should destroy PY_SUBJECT before releasing the GIL Python has a lesser known feature called sub-interpreters, which allows you to use the interpreter from a clean state. This is what emNewInterpreter does. Normally I would not bother with that. The pattern you need to follow using the latest version of P4D: In your main thread to release the GIL after loading the Python dll: TPythonThread.Py_Begin_Allow_Threads (calls PyEval_SaveThread) In your Delphi threads including the main thread (or if you use ITask or TParallel) that execute python code (this is what TPythonThread does): fGILState := .PyGILState_Ensure; try Do python staff finally PyGILState_Release(fGILState); end; In your main thread before unlolading Python TPythonThread.Py_End_Allow_Threads (calls PyEval_RestoreThread) if you have a long running thread that does python stuff and you want allow other threads to do python stuff as well then the pattern is: fGILState := .PyGILState_Ensure; try Do python staff TPythonThread.Begin_Allow_Threads; try Other threads can run python code finally TPythonThread.End_ALlow_Threads; end; Do more python stuff. finally PyGILState_Release(fGILState); end; In PyScripter I have a utility function: type IPyEngineAndGIL = interface function GetPyEngine: TPythonEngine; function GetThreadState: PPyThreadState; property PythonEngine: TPythonEngine read GetPyEngine; property ThreadState: PPyThreadState read GetThreadState; end; function SafePyEngine: IPyEngineAndGIL; begin Result := TPyEngineAndGIL.Create end; type TPyEngineAndGIL = class(TInterfacedObject, IPyEngineAndGIL) fPythonEngine: TPythonEngine; fThreadState: PPyThreadState; fGILState: PyGILstate_STATE; private function GetPyEngine: TPythonEngine; function GetThreadState: PPyThreadState; public constructor Create; destructor Destroy; override; end; { TPyEngineAndGIL } constructor TPyEngineAndGIL.Create; begin inherited Create; fPythonEngine := GetPythonEngine; fGILState := fPythonEngine.PyGILState_Ensure; fThreadState := fPythonEngine.PyThreadState_Get; end; destructor TPyEngineAndGIL.Destroy; begin fPythonEngine.PyGILState_Release(fGILState); inherited; end; function TPyEngineAndGIL.GetPyEngine: TPythonEngine; begin Result := fPythonEngine; end; function TPyEngineAndGIL.GetThreadState: PPyThreadState; begin Result := fThreadState; end; which is used in the main or other threads as: var Py: IPyEngineAndGIL; begin Py := SafePyEngine; Py.Engine. whenever I need to execute Python code

Hello. I have a problem with a comercial android app. The app runs fine in the majority of android devices. But it's fail in two popular model in Spain: Galaxy A10 (With android 9) and Galaxy J7 Prime (Android 8 ) y Galaxy XCover4 SM-G390F (Android 9). I have no problem with more than 24 samsung tested models I've tested the two first devices in browserstack.com and i have the attached logcat Could someone help me? I don't know where to start Thanks in advance. (and sorry, my English is not good) log-all.txt log-onlypackage.txt

Thanks for that information. It might help other developers who make the same error. You're welcome!

Hello Dave, I've discovered the problem. I upload and 64 bits apk with a reference to a prebuilt 32 bits apk. I had problems with the aab support in the previous version of Delphi and I prefer this way. The problem was that I referenced an old .so file in the Android64 deployment window. Samsung J3, Samsung A10... are 32 bits. Problem Solved. I've learned: check carefully the libs and so referenced in deployment. Dave: THANK YOU VERY MUCH. It's not the first time you try to help me, and you don't know how useful was your workarounds and firebase examples in your blog. Very talented Delphi developer, no doubt Thanks

I have updated the demo. The demo now includes saving and loading refresh tokens, as well as checking for expired access_tokens and refreshing them with the refresh_token. Have a look at https://github.com/geoffsmith82/GmailAuthSMTP/ Geoffrey

I've updated my project so it now not only sends messages via gmail... but it can send hotmail.com/live.com/outlook.com emails. GmailAuthSMTP supports the XOAUTH2 and OAUTHBEARER authentication types and so could probably support other mail providers if they use those standards as well. https://github.com/geoffsmith82/GmailAuthSMTP/

Indy does not currently support OAuth yet. However, it would be fairly simple to create a TIdSASL-derived component that can be added to the TIdSMTP.SASLMechanisms collection to transmit an OAuth bearer token using the SMTP "AUTH XOAUTH2" command. But getting that token in the first place is the tricky part, and has to be done outside of SMTP.

Hi @Ugochukwu Mmaduekwe, Have a look at https://github.com/geoffsmith82/GmailAuthSMTP/ I just created a simple demo for you. You will need to get a client_id from google in their developer toolbox. Geoffrey

Fellow Delphi developers, This is with great pleasure that we announce the immediate availability of HelpNDoc 7.4, an easy to use yet powerful help authoring tool producing CHM help files, responsive HTML 5 and mobile Web Sites, DocX and PDF manuals, Markdown documents, ePub and Kindle eBooks as well as Qt Help files from a single source. HelpNDoc is Free for personal use and evaluation purposes and is available at: https://www.helpndoc.com HelpNDoc 7.4 provides many new features and enhancements such as the ability to produce an inline table of contents in HTML topics, a new kind of hyperlink to "counters" instances, an enhanced HTML documentation format with better Core Web Vitals, a better syntax highlighter, improved documentation generation, and much more... You can learn more about this update at: https://www.helpndoc.com/news-and-articles/2021-06-15-inline-table-of-contents-greatly-improved-html-documentation-generation-and-more-in-helpndoc-7.4/ Video of some of the new features in HelpNDoc 7.3: Download HelpNDoc now and use it for free for personal and evaluation purposes: https://www.helpndoc.com/download Follow our step-by-step video guides to learn how to use HelpNDoc: Best regards, John, HelpNDoc team. https://www.helpndoc.com