Brandon Staggs

I am hoping someone else has experienced this and can share a solution. Last week my debugging MacOS applications through PAServer became extremely slow. Code executes but (apparently) the communication between the debugging process on the Mac and on the Windows PC is so slow as to be unusable. If I detach from the process the application will suddenly start running at normal speeds. No breakpoints are needed for this problem to happen, just the act of running it with the debugger attached slows everything down to an unusable speed. It is possible, but I do not know if this timing is correct, that this happened after updating the Mac to Sequoia 15.4. The Mac is an M2 Pro model with a 2.5 gig wired ethernet connection (wifi disabled). Deploying to the Mac is super fast from Delphi. It's not a network speed issue. I have already tried updating XCode and updating the SDK profile in Delphi. Details: Apple M2 Pro, Sequoia 15.4 Wired ethernet (2.5 gig), deployment speed is very very fast even for large transfers. Delphi 12.2. Target: MacOSX ARM 64 bit, SDK 15.4. Does anyone who debugs MacOS FMX applications have any suggestions on what might be suddenly slowing down the debug process? I can confirm that code is running and I can step through it, it's just SUPER slow to do so, the main form takes several minutes to appear (but eventually does), after which it remains ultra-slow.

Used Apple's support for dual-boot to install Sonoma. Debugging works perfectly fine there.

This did not make a difference.

Well, I did say other Delphi code, but as it turns out, I am able to debug some applications nice and fast, but the "big ones" are ultra-slow. The only difference I can think of that would matter is that the main large application I am having trouble with creates a lot of threads. I know on Windows this can slow debugging down depending on what DLLs are being attached to the threads. So I created a simple app that spins off 100 threads just to see if I could debug it reasonably. That worked fine. So clearly, something we are doing in our application is, somehow, affecting debugging speed. I don't know what that could be. One test I did was to directly run the LLDB debugger from within the PAServer 23 application bundle. It was able to run the application at what seemed to be full speed. I am tempted to learn how to properly use LLDB just because it seems to provide a very snappy debugging experience, even if it is limited since it is not connected with the IDE at all... In desperation I updated to MacOS 15.5 beta 2 just to see if anything would change. Nothing did. I am pretty much stumped at what could cause MacOS ARM64 debugging session to slow to a crawl in Delphi that wouldn't also cause things to go slow on an Intel-based Mac. If I deploy the exact same project to my old Intel MacBook, the main difference being that the build generates x64 code of course, it debugs acceptably. If I deploy it to my M2 (ARM64 build), it debugs at a snail's pace. Ugh.

Other Delphi code. I updated the Mac from 15.3 to 15.4. Sequoia 15.3 was working fine, but I am not 100% sure that this issue coincided with the update. PAServer is deploying over 150 megs of binaries (the app and a bunch of dylibs) in just a few seconds; I use a 2.5 gig wired network connection for this and disable wifi so that PAServer doesn't try to use a slow connection. If there are network issues it's not due to speed but could still be other problems. I will look into that. I am also wondering if upgrading to Delphi 12.3 with the updated PAServer will matter. That's kind of a last resort at this point and seems very unlikely to make a difference.

I'm developing on real hardware. As far as I know there is no legitimate way to run MacOS in a VM, but my information may be outdated. I switched to using a much older Intel MacBook Pro with an older OS, and debugging speed is acceptable on that. I do suspect the OS update. Before this began, debugging and stepping through ARM64 code on the Mac was actually quicker than stepping through Win64 code on the same PC as the Delphi IDE, which I always found ironic. I tried debugging other code on the M2 and all of it was extremely slow.

No, I don't see the point -- there are already so many people who actually do hardware comparisons for a living writing about it. Aside from commenting here in the context of a Delphi developer, I don't have time to write my experience in detail. I will just add this: I bought a Snapdragon Windows PC when I saw that users of my software were installing it on Snapdragon Windows PCs, but that the 32-bit version of my software was appearing instead of the 64-bit. I quickly realized this was due to how the Inno Setup script was written, which assumed that if x64 was not available that the system needed the 32-bit x86 binaries installed. Inno added support for some additional scripting functions to better handle this and I wanted to test my software on Snapdragon so I bought one and fixed the install script. That works perfectly. And now any time I need to grab a portable PC I take the Snapdragon one because its the lightest Windows PC I have and the one with the best battery life. I've had no issues doing what I need to do on it. This is not some cheesy WinRT netbook from 12 years ago that can only open a web browser and play Candy Crush and run Office apps. This is the Windows answer to an Apple MacBook (which I have two of also).

Yes, I remember that. However, we are already well-past that point for two reasons: 1. Windows on ARM is not a competing operating system or any more than Windows x64 with WOW was competing with x86. 2. There is already massive support for ARM64 Windows in the form of tons and tons of native binaries already available. Nobody has to wait for this to eventually happen. It is happening now. Actually, it happened at the end of last year.

We're not talking about some stripped-down WinRT "Windows store only" operating system that doesn't run 99.99% of the software made for Windows, like the previous Windows on ARM devices. The current offering from Microsoft runs both x86 and x64 binaries and does not require the Windows Store (unless someone buys a Windows-S version of the OS, but that is also shipped on x64 and has nothing to do with ARM). The Prism emulation layer is seamless. As long as you aren't expecting to run AAA games on one, or other software requiring that kind of hardware, ARM is a viable choice, and in fact a superior choice if you need portability with energy performance. This is an expansion of the Windows ecosystem because vendors now have the ability to offer hardware with far better energy performance than what x64 CPUs allowed in the past. A hardware vendor does not have to take a bet that Microsoft will succeed with a new platform -- Microsoft has owned this market for 30 years. Of course Delphi needs to offer an ARM64 compiler for Windows. And why should that be a problem? Delphi has shipped with ARM compilers for years.

Everything I have used on my Lenovo CoPilot+ notebook runs seamlessly, including my own compiled Delphi applications. I cannot perceive any difference between it and my other laptop when it comes to running Windows applications. I have not installed Delphi on it (no reason for me to do that) but keep in mind Delphi has been working just fine on Apple Silicon in Parallels for years. I imagine that the Prism emulator in Windows would not be an issue for the Delphi IDE. But I am not testing that.

Windows on ARM does not need to unseat two entrenched ecosystems to be successful like Windows Phone did. There is no comparison. Most of the people buying a Windows computer do not need to care if the CPU is ARM or x64. On the flip side, however, since ARM-based Windows machines run x64 apps just fine, there is no real pressure on Embarcadero to rush offering a compiler.

Delphi is notoriously without any public timelines. They have on occasion published very vague outlooks, but AFAIK no public roadmaps of any reasonable detail exist. During their last release webinar it was Ian, I believe, who suggested this is entirely due to Idera's policies. The old excuse about different countries having different laws about forward-looking statements was mentioned in that context, if I am not mistaken. One wonders how other technology companies with far deeper pockets (hence, bigger targets for lawyers) are able to make all sorts of roadmaps and timelines. I wouldn't blame anyone working on Delphi for the lack of a roadmap, but it's still kind of a running joke for the last decade or more... Prior attempts at Windows on ARM were complete failures, but this one is obviously going to stick, and has nothing in common with Microsoft's previous attempts. I have a Snapdragon Windows PC and it's definitely "for real this time." I don't see any reason why Delphi shouldn't offer Windows on ARM as a compiler target.

I can only imagine how bad AI will be in the future when it is pulling in this kind of garbage text and putting out even more garbage text. Some people dream of AI being able to design new levels of AI. But I think what will happen is AI will just churn out more useless gobbledygook in larger and larger quantities in a feedback loop until all the universe's data capacity is consumed by mounds of useless generated text that is grammatically reasonable but doesn't say a thing.

Oh come off it. Nobody cares if you use it or not. Your posts are so overly verbose and grandiose that even if there is merit in what you are asking for, nobody can find it. In fact, you seem like you are trolling us with AI generated gibberish that almost but not quite seems to be making a point. And I would prefer not to feed trolls.

Since the Windows 8 debacle, Microsoft hasn't had a coherent GUI/platform strategy. I can't see any reason why Embarcadero would try to chase Microsoft's fleeting "latest and greatest" in that area. They already have VCL and FMX. That's enough. I'd rather them complete their 64-bit IDE and give me an ARM compiler for Windows than bother trying to get Microsoft pinned down on the "right way" to make new Windows projects. It will just change again in a couple of years.

For years LSP has been broken on our very large code base. The main problem being "Find Declaration" is non-functional. We also experience problems when switching between Win64 and MacOS build targets; usually doing so without cleaning the project results in the IDE crashing or the compiler crashing or both. I complained about this earlier today in this post: Today, I was stepping through code in our MacOS build when I noticed that the IDE was taking me to the wrong source file. That clued me into what was going on. This project has about 40 local copies of Delphi source files to fix various bugs and add some needed access to private fields, etc. (Trust me, we hate to do this, we don't want to do this, but when the FMX code base assumes only one thread will ever want to use bitmaps and stuff like that, we have no choice). Of course these local copies appear first in the search path. This naturally necessitates that the other source files are rebuilt, and they are listed in the search path, lower down. The compiler works perfectly fine; our modifications are built without issue. But the IDE and LSP hate this. While stepping through code, it took me to the original FMX.COntrols.pas file, not the local copy that is being compiled into the build. No amount of tweaking the search path or browsing path helped. This got me thinking that this could be related to code navigation issues. So I went into the Rad Studio installation folder and renamed all of the source files for which we have a local copy, so that it would be impossible for the IDE or LSP Server to reach them. And like magic, every single problem I have been having with code navigation suddenly went away. Even switching between MacOS and Win64 build targets and compiling became a seamless operation. So, it appears clear that the LSP Server and IDE do not take the same clues as the compiler or linker or whatever when it comes to search paths. And chaos ensues, due probably to incompatible interfaces that exist between unmodified fmx classes and our local forks. Now I could be overstating the effectiveness of this fix, but I spent an hour doing things I know break the IDE and they all worked. The problem is now I have gone nuclear on the Delphi source folders and no other projects can use them. What I would like to do is have a different copy of the BDS /source/ folder that is used for this project. But we already know a wholesale copy into the search path won't fix it, because those files are already there. We need the IDE to treat a different folder as canonical for $BDS/source. I already use the -r command line switch for the IDE to isolate this project into its own registry hive, but I could not find a way to override the BDS variable (nor do I think that is the right solution). This brings me to my question -- going to Tools/Options and trying to override the BDS environment variable creates an error since it is "built-in." My current solution is clunky -- maintain two source copies of the BDS source folder, one with all the files and one with files removed that we have local copies of -- and switch between the two depending on what project I am working on. But is there a way to tell the IDE and LSP Server to use a different source folder? (Probably not, because if so, it would already be working based on the project settings, LOL!) If I can get time I may try to make a small project that reproduces one of these problems, but this is a million+ line project and it could have to do with a combination of factors, not just the fact that we have local copies of stuff like FMX.Controls with incompatible interfaces.

Of course. If someone wants to pay me my going rate, I'd stop everything and create one. As it stands, I hope to find time to work on creating one. The million+ lines of code that don't belong to me can't just be posted in attlasian's system.

Sure. I've said that three times already in this thread, so that would be appropriate.

In a recent post, Marco said much the same thing as was said in the Webinar: https://embt.atlassian.net/servicedesk/customer/portal/1/RSS-1887 My original inference that they are starting over with a new approach seems correct in light of this. Here we have "back to the drawing board" and "architecture" in the same sentence. Surely Marco knows how this will be interpreted.

A non-starter for us, as the 64-bit LSP Server only supports Windows targets.

The changes are work product for one company. They can't be used by other projects. I'm sure someone else may suggest a VM. That would work if it wasn't for the fact that our products don't work in a VM which makes developing that way a major pain. What I was left wishing for is a docker container for Windows GUI applications. I'd like to just shove an instance of Delphi into a container so I can run on the metal and modify the installed files without affecting other projects that don't need them.

Without adding the other VCL (or rtl, fmx, etc) paths, the modified pas file will not link with the others. We've modified System.Classes, for example. Almost all of the RTL and FMX units have to be rebuilt.

No amount of tweaking the browsing path was able to work around the problem. In fact the reason this took me so long to work around is because I trusted the documentation. I had to actually make the original source files unreachable.

I'd like to, but without including an example project that shows the problem, it will be ignored. I haven't had time to see if I can make a small application that uses a local copy of an rtl or fmx unit with an incompatible interface to see if it works as an example. And the LSP issues we experienced were intermittent -- LSP would be okay 20% of the time, so I suspect it's a combination of factors.

I went ahead and installed 12.3 in a VM to see if LSP would work properly in our large code base. It actually seemed worse -- I had 12.2 open in one and 12.3 open in another and Find Declaration was working better in 12.2 (that is to say, on the same symbol, I could get to the declaration in 12.2 when I couldn't in 12.3). That isn't saying much though -- they both fail to work most of the time, and both of them will consistently open the wrong source file if the declaration exists in a forked FMX/VCL/RTL unit. I suspect in our case the forked units are probably causing LSP to trip up. We have fixed numerous problems in FMX in particular and have no choice but to maintain our own copies of these units. They appear in the search path properly and compile correctly, but using the stack trace or find declaration in these typically opens the wrong source file (going to the BDS source folder instead of our local copies). I have experimented with the browsing and search paths to no avail. Even though the compiler uses the correct unit, the IDE just can't seem to cope, and I suspect that incompatibilities are messing up LSP, but I have no way to know for sure. What's really funny is that sometimes CTRL+Click will take me to the BDS source file on the wrong line but CTRL+G will take me to the (correct) local copy. Usually neither work at all though.