Dalija Prasnikar

Imagine how slow would compilation be with those optimizations turned on. I hope than newer LLVM could be faster, but I wouldn't keep my hopes up https://discourse.llvm.org/t/if-llvm-is-so-slow-is-anything-being-done-about-it/75389

Delphi is not memory safe language. But, at the end it all depends on the kind of code you write.

Forget about that. While there is always a possibility that speed may be slightly improved, slowness is a feature of LLVM backend.

The best would be to contact support https://www.embarcadero.com/support choose "Registration and Installation" issues there.

Each permission affects different functionality so it is only natural that there will be different rules because the impact and the consequences of abuse can be vastly different. But guessing what the actual rules are, beyond what is written in official documentation would be just playing guessing games.

You should remove any permissions you don't need for application functionality. Applications are analyzed when posted on Play Store and having more dangerous permissions defined can put your application under the magnifying glass and you may need to give additional explanations or comply to some other policies than regular applications that don't use those permissions. Some unneeded permissions can even cause your application to be rejected from Play Store until you fix your submission. Official documentation is usually the best starting point for being up to date with requirements https://developer.android.com/guide/topics/permissions/overview and https://support.google.com/googleplay/android-developer/answer/9888170

At that time there were not single license keys for multiple versions. You would need to have separate key for XE5. Serial keys should be listed at https://my.embarcadero.com/ But, I don't know if all keys are listed or just the ones that were activated at some point. For user that purchased and had active subscription for XE3, they would have received have a XE4 and very likely a XE5 license (the XE5 was released a within a year and few days of XE5 release, so only those that bought XE3 immediately would have not received XE5 license, without prolonging their subscription)

If they do that, some comments miraculously survive that process and others don't.

The only self explanatory code is the trivial one. In other situations there is no such thing as self explanatory code, especially if it also needs to be performant and thread-safe. I have written tons of self explanatory code, for which now I don't know what was I smoking at the time. Sometimes, after a lot of digging I can remember why it was written like that and why it should stay that way, but mostly no. So I am not sure if it was just crappy code from the times I didn't know better, or there are valid reasons behind the awkward design choices.

No questions. Just a comment. This is not thread safe code. No amount of testing can prove that code is thread safe, you can only be lucky enough to catch the issue and prove it is not safe. But, just because it seems fine in your testing, does not mean it would never blow up.

I cannot comment on deadlock trigger being too sensitive as I haven't explored that part of code and its behavior much and whether solution for the deadlock by expanding threads is the most appropriate one. However, you are using separate pool for your parallel for loop. So there is no danger of it deadlocking. You just need to set UnlimitedWrokerThreadsWhenBlocked to False and that pool will be restricted to the number of threads you have specified. function TThreadUtils.GetLoadflowThreadPool: TThreadPool; begin if not Assigned(LoadflowThreadPool) then begin aThreadLock.Enter; try if not Assigned(LoadflowThreadPool) then begin LoadflowThreadPool := TThreadPool.Create; LoadflowThreadPool.SetMinWorkerThreads(TThreadPool.Default.MaxWorkerThreads div 2); LoadflowThreadPool.SetMaxWorkerThreads(TThreadPool.Default.MaxWorkerThreads div 2); LoadflowThreadPool.UnlimitedWorkerThreadsWhenBlocked := False; end; finally aThreadLock.Leave; end; end; Result := LoadflowThreadPool; end; Of course, this might not be enough if you have other pools that run intensive tasks that can create excessive number of threads which can slow down everything.

The reason for expanding number of threads is to avoid deadlock with nested TParallel.For loops. If you want to use old behavior then you should set UnlimitedWorkerThreadsWhenBlocked to False on each ThreadPool you are using, including the default one. For any other issues you mention, there is nothing we can do if you don't provide details about your code and implementation of your parallel loop mechanisms. While it is always possible that there are other bugs in System.Threading, it is also quite possible that your code has bugs, too. Just because you get access violation in Delphi RTL code, that does not mean that the cause is not in your code. For debugging multithreaded applications, especially the ones that spawn many threads, it is more suitable to use logger and inspect code behavior through logs instead of using debugger. Debuggers are usually too intrusive for multithreaded debugging that involves more that few of background threads as it severely impacts timing.

This is for C++ Builder PRO TERM LICENSE https://www.embarcadero.com/products/cbuilder/product-editions Delphi doesn't even have such option.

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.