Stefan Glienke

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.

Depends on what happens more often: changing the values or asking the lowest item. Getting the min of 200 unordered items takes 199 comparisons. Keeping the min item up to date on every update takes a comparison every time you update an item (either to know if the item you updated is now lower than the current min item or if it is still the min item).

The guys at HGGC and TA Associates ultimately are making the decisions...

If you have documentation you cannot just yolo refactor code every release and break something...

I am not going to argue with you why mutable(!) global state is bad because a ton of respected people in the software development community have already proven that. As I said a singleton can be the easy solution - that does not make it a good one. Putting any code into an otherwise no or hard testable software component is only a crutch - there are ways to design software to be testable by default which does not only make it easily testable but also more robust and maintainable. Just read "Clean Code" and/or watch "Clean code talks" on Youtube. Also fwiw there is a difference between Singleton as in the GoF Singleton (ensuring that there is only one instance and preventing everyone from ever instantiating a second instance of that) and "singletoness" (establishing the contract of only having one instance but not preventing anyone from instantiating one on its own and inject it somewhere). Even in DI driven architectures there are singletons, but it is controlled via the DI system that there is only one instance being created and passed around. That decouples any consumer from the actual implementation of that singleton and makes it easily testable/mockable (see "seam")

A singleton is never a good solution - it might be the easy one in the middle of a DI unfriendly architecture but that's it. Singletons do not only couple pieces together that don't have to but they also allow all kinds of crazy and hard to find errors - as every global state does.

If you think that it's related to .NET then call dcc yourself and see if that works - as I said already the error comes from the dcc. So it can only be that msbuild is passing down different values than before causing it to behave differently. To rule that out, eliminate the suspected factor from the equation, troubleshooting 101

I think I once saw there was an issue with non ascii characters in the path causing trouble.

Googling for this error and drf yields this: Source

I don't see an msbuild error - the error is from the delphi commandline compiler (dcc) and you see the error it raised: F2039 I guess drf is your custom file extension for the project being compiled? Make sure the file is not write protected or accessed by any other program if already existing.

What memory leak? That assert is telling you that CRYPTO_set_mem_functions returned 0

If with "you" you mean @Der schöne Günther then yes.

The compiler is responsible for writing typeInfo into the binary.

It seems indeed as if the TIntfFlag enum was never extended since Delphi6 (I think that was when interface RTTI was introduced) - I can confirm that at least since XE an interface type with $M+ gets a fourth flag (lets call it ifHasMethodInfo) set. If the type is an anonymous method type (see https://stackoverflow.com/q/49950534/587106) then there is a 7th enum value in the set. The situations where bit 5 and 6 are set are unknown to me. You might want to file an issue in QP about this. @Remy Lebeau Your diagnosis is still wrong - if the debugger shows then that means it has the 4th bit set. I can confirm my findings with this code: uses SysUtils, Rtti; type TIntfFlagEx = (ifHasGuid, ifDispInterface, ifDispatch, ifMethodInfo, ifUnknown, ifUnknown2, ifAnonymousMethod); TIntfFlagsEx = set of TIntfFlagEx; {$M+} IFoo = interface ['{35CFB4E2-4A13-48E9-8026-C1558001F4B7}'] procedure Main; end; {$M-} {$M+} IBar = interface(TProc) ['{AB2FEC1A-339F-4E58-B3DB-EC7B734F461B}'] end; {$M-} {$M+} TMyProc = reference to procedure; {$M-} procedure PrintIntf(typeInfo: Pointer); var context: TRttiContext; rttiInterface: TRttiInterfaceType; flags: TIntfFlagsEx; begin rttiInterface := context.GetType(typeInfo) as TRttiInterfaceType; flags := TIntfFlagsEx(rttiInterface.IntfFlags); Writeln(rttiInterface.Name, ' ', TValue.From(flags).ToString); end; begin PrintIntf(TypeInfo(IInterface)); PrintIntf(TypeInfo(IInvokable)); PrintIntf(TypeInfo(IFoo)); PrintIntf(TypeInfo(TProc)); PrintIntf(TypeInfo(TFunc<Integer>)); PrintIntf(TypeInfo(TMyProc)); PrintIntf(TypeInfo(IBar)); Readln; end. prints this: IInterface [ifHasGuid] IInvokable [ifMethodInfo] IFoo [ifHasGuid,ifMethodInfo] TProc [ifAnonymousMethod] TFunc<System.Integer> [ifAnonymousMethod] TMyProc [ifMethodInfo,ifAnonymousMethod] IBar [ifHasGuid,ifMethodInfo,ifAnonymousMethod]

The block will happen less than two months from now - read for yourself: https://android-developers.googleblog.com/2019/01/get-your-apps-ready-for-64-bit.html

Ah, I see now, they are all hidden in that innocently looking TestParse and TestEmit methods - was expecting to see them more fine grained :) I have some suggestions for some possible low level optimizations (for example eliminating some unnecessary code from function prologues and epilogues caused by usually not raised exceptions but the fact the exception creation code is directly coded into the methods (and in fact is repeated multiple times) - will file a PR.