Dalija Prasnikar

Did the message came from the IDE or your application? Without having the message text and your code it is hard to diagnose what is wrong. Also, there are no critical sections in Vcl.Dialogs.

I somehow missed that one. Yes, this one looks serious. I don't know what is the status of this issue. I thought that my.embarcadero.com was also impacted by the outage. Anyway, I phrased my sentence a bit awkwardly, like the outage could be the only reason why fixes are not released yet as patch also needs to go through testing phase before it is finally released.

You mean the issue with division with $FFFFFFFF constant? That is nowhere near being a showstopper bug. As a workaround it is possible to use variable instead of constant. And this issue is fixed, but at the moment hotfix cannot be delivered due to outage.

Only you know that. But, if you are asking is Delphi dead, then the answer is No, it isn't. This was just a hiccup (even though, a huge one), and the resolution is just around the corner.

It is possible to have a dependency manager that does not have a single point of failure. There are probably others, and this is not exactly package manager as such, rather a build tool, but Gradle has a good dependency manager. https://docs.gradle.org/current/userguide/declaring_repositories.html Solution to a server being a point of failure is having multiple servers, and extension of that is that you allow user customizable list of servers (multiple ones) That way, if one server goes down other's would be available and it can be easy to extend the list with new servers if required. Once you have that, you can easily have even your own private server for distributing your own built packages within the company.

I wonder who has such landline these days. Our telecom switched to VoIP long ago. So I have a land network connection, but we no longer have classic telephone line.

https://docwiki.embarcadero.com/RADStudio/Athens/en/XML_Documentation_Comments There are also tools that can help in writing those, so you don't have to do that manually, like https://devjetsoftware.com/products/documentation-insight/

I don't think they or anyone needs advice from AI.

I meant that JIRA Server is no longer supported https://www.atlassian.com/migration/assess/journey-to-cloud and this was known for some time. Their internal JIRA will be migrated fully. So there will be no loss of issues in internal system. As far as the public one is concerned, I don't know whether it will be migrated or not and what are the possible issues. Evidently, it will not be migrated right away.

Moving QP is not about saving money, nor it is directly related to current outage. It was something that has been planed for quite some time (this has been disclosed to MVPs) because Atlassian no longer supports JIRA on premises which Embarcadero uses. https://blogs.embarcadero.com/embarcadero-quality-portal-migration/ So they are logically moving their internal system to Atlassian Cloud and the front for customers will use Jira Service Management. It would be rather ridiculous to use full fledged JIRA for customers and pay millions for features that we couldn't use anyway. JSM seems like a good option in this case. And issues will be visible to everyone.

Your assumption is correct. And like you said self hosted JIRA is no longer an option. AFAIK, there is an option to set visibility of all issues to be automatically visible to all customers, but that option is not a default one. So I don't think visibility should be a problem here.

https://blogs.embarcadero.com/we-are-experiencing-a-hardware-outage/ GetIt is still off line, but you can download RADStudio 12 ISO. There is a download link in that blog post.

I have multiple Delphi version installed and working on my machine, including Delphi 11 and 12. They all work fine. Installing new version didn't break my old versions. So the question is what you have done to have your Delphi 12 installation break Delphi 11 installation?

Only problem you can face is if you are using dynamically loaded packages as the RTTI for that package will point to invalid memory. But I am not sure how relevant is that to the macOS as I don't know if you can even use runtime packages there. Thanks! I added the test project.

AFAIK, Idera runs the whole IT infrastructure for multiple companies under their umbrella.

Yes, it will call EnsurePoolToken, but if the global token already exists it will not lock PoolLock while it tries to create one.

Yes, this looks like a classic deadlocking bug. One thread locks one lock, while another locks other and they are dead in the water. It should be reported. Possible workaround would be acquiring context at the application initialization (with KeepContext) and releasing it on shutdown. That way you would prevent EnsurePoolToken called from KeepContext to lock PoolLock.

https://blogs.embarcadero.com/we-are-experiencing-a-hardware-outage/

This is why I said that this was not a software problem, but a hardware problem. Beyond that anything anyone says is pure speculation.

It is directly dispatched in TCustomForm through procedure CMRelease(var Message: TMessage); message CM_RELEASE;

CM_RELEASE is simple procedure TCustomForm.CMRelease; begin Free; end; Yes, you can intercept it in your form.

Who said that it is server that failed? When workers cut my phone cable I was without access to Internet it for three days (that was long before broadband Internet was available). There is just some stuff where you cannot possibly have redundancy, or the cost would just be a way too much. It is not like they are running mission critical infrastructure, so they need to be prepared for absolutely every scenario. And even then, there are things that might happen outside of their (or anyone's) control. Not everything that ever happens is result of some incompetence. As far as Facebook is concerned you can read it here https://en.wikipedia.org/wiki/2021_Facebook_outage What this page does not cover is breaking into the server room, but that was something one of people involved posted on Twitter at the time. The problem was that entering the server room also required authentication which was not working because their whole network infrastructure was down. I have no idea what they have or have not learned from that incident.

Error happens when CM_RELEASE is sent to a form. The fix is to avoid calling VisualManager in that scenario. Instead in WndProc, you can also add check in VisualManager_AcceptMessage method before the code within tries to access FVisualManagerInitialized field. procedure TCustomForm.WndProc(var Message: TMessage); ... inherited WndProc(Message); if (Message.Msg <> CM_RELEASE) and VisualManager_AcceptMessage(Message) then VisualManager_WndProc(Message); end;

I am sure that everyone here has everything in duplicate, so when something dies they can replace it in an instance with minimal interruptions, especially if it dies over the weekend during the huge cold spell. Stuff happens, no matter how small or big the company is. Do I need to remind you that on one instance Facebook folks had to literally break into their server room because they got locked out of it. I am not going to defend the lack of official communication, this is something that needs to change, but this is also not something that people on lower hierarchy levels (meaning the ones that blog and communicate with us) can do on their own.

FWIW, you can forget about software jokes, it is piece of hardware that died.