Stefan Glienke

Because there isn't (at least not in the RTL) - ChatGPT is making that up (as so often).

Uploaded the latest version - you can download from https://files.spring4d.com/UsesHelper/latest/UsesHelperSetup.zip

https://delphisorcery.blogspot.com/2021/04/testinsight-12-released.html

Uploaded the latest release - 1.2.0.4 - you can download from https://files.spring4d.com/TestInsight/latest/TestInsightSetup.zip

Funny that you name the topic dynamic array not working when in fact you are declaring a const Anyhow this is a known bug at least since 2018 - see https://quality.embarcadero.com/browse/RSP-19816

I wonder what tech GetIt is implemented in that it cannot cope with a bit of workload

It is being used by the compiler generated template code for C++ (see the code above the implementation of CPPFreeAndNil)

Yes instead of 0 it will be vmtAfterConstruction div SizeOf(Pointer)

This

Is that the same Intel that disabled AVX-512 on Alder lake?

Planet of the Firemonkeys?

Already wrote it: https://www.delphipraxis.net/208147-json-serializer-und-guid.html IMO the solution with the converter has the benefit that you don't need to pollute all your classes with these unnecessary attributes. I guess when using the REST unit there is no way to pass a converter to the underlying serializer/reader/write - the entire architecture is a huge clusterf**k.

TGUID contains this field: D4: array[0..7] of Byte; which does not emit typeinfo for its type You can see this with the following code: uses System.Rtti; var ctx: TRttiContext; begin var t := ctx.GetType(TypeInfo(TGUID)); for var f in t.GetFields do Writeln(f.ToString); readln; end. The issue (not specifically for TGUID) is reported: https://quality.embarcadero.com/browse/RSP-27329 Now even if the RTTI would be available it would serialize TGUID in some format that is most likely not desired. However TGUID <-> string serialization should be supported out of the box imo.

The problem within the global begin/end block is special - usually, inline variables are shown in the debugger but with the limitation that the compiler does not emit so-called live-range data for them which the debugger can use to know the locations they are valid for. For example having two nested variables of the same name causes issues with properly inspecting them because the debugger always shows the value of the first (which causes wrong data to be shown) which also has been reported multiple times.

No, just pray the issue gets fixed in your lifetime

No, because the parameterless TObjectList<T> constructor sets OwnsObjects to True. And that is nothing new but also already was the case in the old TObjectList from Contnrs.pas I am glad I can use Spring4D and have several flavors of multimaps at my disposal

It is from my own experience and analyzing generated code in several different scenarios. I have seen the inliner generating like x times more instructions including ridiculous amounts of mov instructions to and from the stack just to inline a harmless little function which it could way better if the inliner and the register allocator would not have been absolute trash. Plus there are "funny" little issues like this: https://quality.embarcadero.com/browse/RSP-30930 Here is an example where inlining creates some ridiculous amount of instructions: https://quality.embarcadero.com/browse/RSP-31720 (which is not caused by auto but the fact that the getter is being marked as inline)

I would never ever turn it to AUTO because that causes the compiler to inline every function that has a size of 32 bytes or less. The inliner of the Delphi compiler is really bad and while one might think that inlining code usually makes stuff better/faster that is not the case and usually (decent) library developers know where to put inline and where not to put inline.

I assumed it would be obvious from the uses

TJsonTextReader calls Close during Destroy on its FReader and that as Dalija explained might still work on Windows because even though the object and its memory is not valid anymore it has not been reused yet. You can test this quite easily with this code: uses FastMM5, System.Classes, System.JSON.Readers; begin FastMM_EnterDebugMode; var LStringReader := TStringReader.Create(''); var LJsonTextReader := TJsonTextReader.Create(LStringReader); LStringReader.Free; LJsonTextReader.Free; end. And you get a nice "A virtual method was called on a freed object" exception resulting from the FReader.Close call in TJsonTextReader.Close

Why would LSPServer affect anything that dcc32/64 do?

Not tested for correctness but translating this C++ code into Delphi should be easy enough: https://de.wikipedia.org/wiki/Voronoi-Diagramm#Programmierung

The default string comparison is done via lexicographic order - what you need is natural sorting - you can achieve this by providing a custom comparer to TArray.Sort that handles that - on windows you can use https://learn.microsoft.com/en-us/windows/win32/api/shlwapi/nf-shlwapi-strcmplogicalw for that

GitLab is amazing and you can host on-premise - for some people including our company, this is important.

i7-12700 at work, i5-13600 at home