Stefan Glienke

For me it was. As far as I can see GExperts just lists actions with a shortcut - not all shortcuts that you can register via OTA. For example most prominently it does not list Ctrl+#. If you are using Documentation Insight - that one also assigns Ctrl+Alt+C but is not listed by GExperts.

Reading the documentation is underrated these days, eh? http://docwiki.embarcadero.com/RADStudio/Rio/en/Declared_Constants#Typed_Constants To solve this particular case of providing structured data to unit tests via attributes I am referring to an approach where you specify where to get the data from in the test attribute and write the code that then does not have to be const in methods that are accessible via RTTI. Here an example how to use this with the Spring.Testing extensions for DUnit: https://bitbucket.org/snippets/sglienke/pe7xAK/dunit-with-external-test-data The approach itself is borrowed from NUnit - see https://github.com/nunit/docs/wiki/TestCaseData

Yeah, minimal... like dealing with every possible language for weekdays the mail could contain regardless the local language of the system the software is running on...

The opposite - I suggested %localappdata% but you suggested the better %appdata% which roams - registry does not by default (to my knowledge)

One reason lies in the answer you just gave opposed to using %localappdata% ... the others you can find on google from various sources.

Storing dialog sizes and positions in the registry is not best practice imo and should be stored in %localappdata% or similar

The return type combo box seems to be some special thing The drop down arrow looks different from the usual combobox ones and the "set to void" button next to it looks to be a little smaller than the usual toolbar buttons

Yes but don't ask me why - I've been told that some of the optimizations slow down compile time even more than already happening on LLVM based compilers compared to the classic ones but fwiw I would not care for longer compile time on release config.

If they hardcode turn off many optimization options in the LLVM backend it won't produce any "as fast as it could be" code...

It does. The reason it's not supported is because Delphi Interfaces are COM based which restricts this. A generic type parameter on a method is just that: a parameter - but resolved at compiletime to provide type safety. You probably have never used any language where interfaces easily support methods with generic type parameters - otherwise you would not have this opinion. FWIW this is one of the reasons I so strongly wish for interface helpers because then it would be possible to add such methods via helper - the COM based interface itself is not affected but you can easily augment them with such methods. In 2014 I wrote some code that shows how such interface helper methods could be invoked similar to record helpers: https://pastebin.com/acp2i645

There is no DSharp version compatible with Spring4D hotfix 1.2.3

It's not about the level of nesting but about the number of cores you have and if the outer loop already produces enough threads to utilize all of them. If that's the case it does not make sense to parallelize even further because your CPU is already saturated

You are right - now I wonder why that was not used - probably the author of that code also forgot about those 😉

It's also a bit irritating that Delphi with all its different sized ordinal types does not have built-in clamp functions to this day...

The only instances the container takes ownership of are singletons

It still baffles me that DXScene or VGScene were usable given the years it took FMX to properly work.

The memory consumption of the compiler highly depends on the code you are dealing with - heavy usage of otherwise harmless generics can quickly explode (I know this because I heavily worked on that subject as much as I could for spring4d 2.0)

Experience has told me to not get too excited yet 😉

Known issue: https://quality.embarcadero.com/browse/RSP-20760 Maybe with the reworked tooling based on LSP in 10.4 it will work.

Then put a breakpoint into the finalization of System.pas and step through FinalizeMemoryManager

Inspect System.IsConsole

Is it possible, that somehow your application is flagged as console application? Because then it prints the leak report to the stderr

Typo and for whatever reason it does not let me edit it. Edit: now it worked, fixed If you can prove that checking i for 0 impacts performance any negatively then sure go for your version. My point still stands regardless.

No way - a priority queue that balances when any value changes takes way more work than n-1 comparisons I am pretty sure that nothing beats the following code performance nor simplicity wise: for i := Low(data) to High(data) do begin // update data[i] if (i = 0) or (data[i] < min) then min := data[i]; end;

When you say bug you obviously mean exception because the debugger does not detect bugs but exceptions and breaks if they occur. Now if the debugger stops at a wrong line it could be because you have incorrect(*) line endings in your file. (*) for the Delphi IDE/debugger any line break that is not the standard windows line ending (CRLF) confuses it and causes all kinds of wrong behavior, from stopping at wrong lines to messing up units when using code completion. Open your unit in an editor that can show line endings and even convert them (personally I use notepad++ for that but there are obviously other editors that can do that as well). Now if that is not the cause for the debugger breaking at the wrong location it can still be the debugger or the compiler that produces the debug symbols the debugger uses has a bug.