Leaderboard

Did you know that LEGO and Michelin are competitors? They both manufacture tires...

Neat: https://www.idera.com/ppc/uptime-infrastructure-monitor/it-performance-monitoring

Don't use GetIt to handle your library sources. Although I may use GetIt to install some of its libraries, I always put those into my own repository where they can be accessed from the build server.

But it was a good find 🙂 It works well so far. Thanks again.

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.

Hi... ...encrypt not the file, only the information. 😉 XML like INI: <Password>xbWONK6X9KT/Pq1LFcV+4VRA8tePadM1yL+iVp3hA4rkgkbckH/EG00NYnuCkN22Zyg=</Password> There are several methods of encryption. DEC for example: https://github.com/MHumm/DelphiEncryptionCompendium

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.

I would think delivering software and information to customers would be mission-critical infrastructure. Honestly, if you're in charge of a data center, redundancy and failover are basic elements of the job, like making sure a bank account isn't overdrawn is to accounting. Netflix periodically shuts down 10% of its infrastructure to be sure their system is resistant to failure! Just like the old forum used to be made of custom code held together with wire and chewing gum and managed by a volunteer employee in their spare time, it sounds like Embarcadero has one on-premises server for all the Delphi stuff with no failover, geographically-separated redundancy, etc. Given the rock-bottom price of hardware today in addition to the ready availability of cloud virtualization, there's no excuse for not having a physical or virtual standby. On top of that, server problems aren't a sudden development like your severed cable example. Drawing upon what Uwe said, it seems reasonable to conclude they just kept ignoring recurring problems or beating it with a stick until a component failed completely, at which point they ordered a replacement.

Good to hear that D12 is so successful that datacenters starts boiling Move on like that

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

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.

For me it's the lack of communication. Errors happen, but at a certain stage they should start to communicate about the error and give some advice about expected timeframe for fixing the problem, possible workarounds and so on. I really don't care (that much) how long this takes - but it would be nice to get some regular updates about the progress made. We are now in a situation where we have to review our development environment and make it as independent as possible from the availability of Embarcadero servers. In result we have to stop using GetIt, and other services may follow.

Maybe if they just built the web servers with Delphi and use the Delphi philosophy, they'd work

The problem is not so much the bug/fault on the site (it happens to everyone) but the time taken to resolve it. Not serious.

I didn't know what I was missing, thanks, @Lars Fosdal.

It's getting ridiculous now with these servers and software shutdowns

If you know absolutely nothing about threads, then Sleep can be a first step towards solution. It will at least give you a simple proof of concept code. If you need to learn everything at once it can be overwhelming. But, again, at this point we are discussing the Sleep vs events while we don't even know if we are going in the right direction.

You cannot terminate the thread while it's blocked by sleep. +1 for SimpleEvent and Waitfor.

No official fix as yet, however I have come up with the following workaround - Note: this has had no testing beyond a blank app: 1. Copy FMX.Platform.iOS from source\fmx into your project folder. 2. In the TApplicationDelegate.applicationDidFinishLaunchingWithOptions method towards the end, make the following change (i.e. add the one line of code indicated😞 // Creating window WindowManager := PlatformCocoaTouch.WindowManager; WindowManager.Window := TFMXWindow.Create(MainScreen.bounds); WindowManager.RootViewController := TFMXViewController.Create; // *** iOS17 SDK crash issue - Add the following line: *** WindowManager.RootViewController.Super.init; WindowManager.NativeWindow.makeKeyAndVisible; Note also that this measure is needed only if you are building against the iOS 17 SDK - it is not required when building against earlier SDKs.

If this application is for wider use, you need to make sure IPv6 is enabled on the PC, otherwise the binding will fail. Many people disable IPv6 to quickly solve problems rather than fixing them properly. Angus

If your PC supports IPv6, using localhost will try both IPv6 and IPv4, so best to have your server listening on both 127.0.0.1 and ::1. I recently changed the ICS TSimpleWebServer to do exactly this, for this reason. You may think you can ignore IPv6, but life is not that simple for developers. Angus