David Heffernan

Not according to Embarcadero. According to Embarcadero Delphi is blazing fast because it uses native code. We all know that to be absolute marketing BS and in fact Delphi compilers produce shitty code that often runs very slowly. Yes, my original post was sarcasm.

Delphi produces native code, and therefore is fast

That's not my example. Nobody wants to do this with a value type because it's a non terminating recursion. Have a look at my example code to see what I'm actually talking about.

None of that applies to my example above.

I don't really follow this. If you have to modify your code to add the message dialog, before you start debugging, then I'm not quite sure why you can't run with a debugger attached. If you are happy to attach the debugger later, why can't you attach it at the start?

This isn't really a great example. The sort of thing that I want to do with records, but cannot, is this: type A = record; B = record; A = record function foo: B; end; B = record function bar: A; end; I can get round this using helpers right now, but I don't understand why I can't do this directly as above.

If you are debugging then throwing an exception is the way to do it. Then the debugger freezes all threads. You surely don't want the other threads to continue running at this point.

Hardly, because you've now ruined your production program.

Reporting error dialogs from thread pool threads sounds terrible. Stop doing it at all and then you don't need to think that one message box function is better than any other.

hahahaha

Step 1 to solving the problem is to understabd why you are compiling delphi rtl libraries

I would read the documentation the same way you did

Then you'll have two different instances of the VCL which is why packages exist.

I don't think this is a good idea. Just share the source code between your 5 different programs. Trying to setup inter process communication will complicate things massively, and probably needlessly. It will also be difficult to maintain the feel of this being one integrated app if you have multiple processes.

Make a minimal yet complète program that demonstrates the issue. Until you isolate the problem by doing this, everything is likely to be a waste of time with irrelevant speculation and guesswork.

What's the reputational cost of the current fiasco?

Who'd engage with this without any idea on the details like compensation??

I've never understood why anyone would use getit over the main source repo for open source projects

I love these kind of posts. Just because you don't understand the problem does not mean the problem does not exist.

Sucks to be us

It's ironic that the download spikes caused by all the Delphi 12 downloads have caused this

"This is caused by a hardware outage at one of our data centers. RAD Studio 12 download volume spikes tasked our infrastructure more than expected. " Why would it spike weeks after release of the software??

If I'm running a company like Emba, then I'm not putting production servers on physical hardware with single points of failure. I mean, perhaps there are some incompetent people at Facebook too. I wonder if they learnt from this and changed.

No idea whether or not this is true. However, there's this really recent tech called virtualisation that allows you to be resilient to hardware failures. I definitely think it has a lot of potential for the future.

Actually this just looks like what you'd expect to see during process creation. First we check for app compat. We don't find that, fine as you say. And then we map the exe.