Stefan Glienke

A pair is a tuple where n is 2 - so yes it is a tuple

It was a must if you have done a bit more than just registering a component (such as custom designers and stuff) because then the package requires designide.bpl which you must not ship. Yet the IDE even in 11.1 creates new packages as design&runtime 🙄

That's up to the implementation of ReallocMem - the one that comes with Delphi (FastMM4) (I just looked into getmem.inc) has this comment:

FWIW I only use this to make my multicast events work on platforms where I don't have exactly that: handcrafted assembly code to do the parameter passing. And these run hundreds of times faster than using RTTI. You can turn on using RTTI instead of the asm code in Spring.Events Here is a simple benchmark result: asm (win32) Event invokes/ms: 14925 rtti Event invokes/ms: 205 I have already started digging more into the TMethodImplementation class to optimize its use for those platforms where I don't have the handcrafted asm. There are also libraries that avoid the overhead of the Delphi RTTI to do dynamic invocation by handling all the low level details: https://github.com/d-mozulyov/Tiny.Library#rtti but that requires doing the parameter passing via some stubs written in c asm

You don't need to manually create tasks - just use a TParallel.For and do proper partitioning - I wrote an answer on Stackoverflow about that subject some while ago. The code there which did some array processing should be easily be adaptable to your usecase

The WParam of TMessage is ultimately of type NativeUInt while the WParam parameter is of type Longint. Since Delphi 11 the default Debug config has Range and Overflow checks enabled which causes any signed to unsigned or vice versa assignment to possibly raise a range check error. Strictly speaking any assignment of signed to unsigned and vice versa is a potential defect - you can reveal them by turning W1071 on with {$WARN IMPLICIT_INTEGER_CAST_LOSS ON}

You forgot "no calling each other nazi" (see Godwin's law)

Using FastMM with the setting to mark freed memory with a certain pattern ($80808080 by default iirc) would have revealed that issue within a few minutes fwiw.

By that logic the Delphi team must be located near Piacenza 🙄

Only from TMonitor.CheckOwningThread (indirectly via the lookup mechanism from ErrorProc in ErrorAt) which gets called from two places: TMonitor.Exit and TMonitor.Wait.

My point is that posting a red herring won't get you much help. First task should be to get a proper call stack because that will directly point you to the source location that causes it without the need to poke in the dark hoping to find it. The exception is clear and this happens when a monitor lock is being exited or waited on from a different thread than the one that entered it.

The Eurekalog call stack makes zero sense compared to the code on github. Either you are using some outdated code or modified something yourself. There is nothing monitor in TThreadSafeQueue.Enqueue. It is using a critical section

My profile shows what I am using in production at work. That does not mean I don't also have access to 11.1 which had this issue addressed 😉

No.

Fun fact: it does with {$WARN IMPLICIT_CONVERSION_LOSS ON} (which is not turned on by default - probably because it would produce a ton of those in existing code)

IIRC in Delphi 7, you have to list all fields in a const record declaration while in later versions you can omit some as I did - they are then automatically initialized by their default value. And depending on the usage of such a record they don't matter like in my case because I never need the CurrencyString. And you don't need it either because JSON has no currency representation. If you need that usually its represented by different fields, the amount and the currency abbreviation Personally, I could not care less about a Delphi version from almost 20 years ago lol

The solution is to use the FloatToStr overload that takes a TFormatSettings and pass one that has DecimalSeparator set to dot. I typically declare such a TFormatSettings as const and fill all the fields that are required for JSON or some other textual format like this - the following for example is being used in Spring for converting various data types to string (from TValue): const ISO8601FormatSettings: TFormatSettings = ( DateSeparator: '-'; TimeSeparator: ':'; ShortDateFormat: 'YYYY-MM-DD'; LongDateFormat: 'YYYY-MM-DD'; TimeAMString: ''; TimePMString: ''; ShortTimeFormat: 'hh:nn:ss'; LongTimeFormat: 'hh:nn:ss'; DecimalSeparator: '.'; );

Yes, just as much as it was just recompiling VS for x64.

This is a pointless endeavor unless you have some proof that the new code in Delphi 11 has a performance regression - the generated assembly code for the purepascal code is almost identical to the handwritten version before on x86 and all other platforms it should be significantly faster than the previous pure pascal implementation. (I should know - I did that change)

You do a sort of the group by criteria 1-3, then you check if there are any ties between teams and build a subset of those teams and do a sort on those by criteria 4-6. That second step is actually similar to the first just that you don't have a full group but only 2 or 3 teams and the results of the matches between those.

MidStr has nothing to do with it - it's a bug in the evaluator. If you put MidStr(vLine, 6, 1) into the evaluator it properly shows 'n'. Please report

Indeed broken since after 10.2.3, can repro the F2084 in the evaluator in 10.3.3, 10.4.2 and 11.1

On the german Delphipraxis, it was mentioned that DevExpress has its developers in Russia - so their operations might be affected by the current situation.

You should really give TestInsight a try - it will make developing tests so much easier. Are you sure about that? Unless something on the CI system causes the tests to fail which is not the case locally you will see the exact spot when running them locally. FWIW DUnit has had support for stack trace collecting via either Jcl or madExcept for ages (enable via defines).

Nothing strange at all but standard pascal behavior - compiler only sees what has been declared so far. Possible solutions: - change implementation order - declare in separate unit interface part - use forward