Stefan Glienke

5 minutes ago, David Heffernan said:

%appdata% surely. But why not the registry? 

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

2 hours ago, Steve Maughan said:

Have they done that? Why would they do that?

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...

On 7/26/2019 at 7:57 PM, Remy Lebeau said:

Nor does it make sense to allow that anyway.

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

12 hours ago, David Heffernan said:

EnsureRange in the RTL, Math unit IIRC

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.

3 minutes ago, Rollo62 said:

In recent versions of the IDE this was much improved, and I haven't used it anymore since the last versions.

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)

1 minute ago, PeterPanettone said:

That would be like Christmas, Easter and birthday together.

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

10 hours ago, TurboMagic said:

But it didn't show any message box.

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.

1 hour ago, Steve Maughan said:

It looks like a modified priority queue is the best solution. This keeps track of the minimum value and self balances when an internal node's value changes.

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")