-
Content Count
346 -
Joined
-
Last visited
-
Days Won
19
Brandon Staggs last won the day on November 1
Brandon Staggs had the most liked content!
Community Reputation
270 ExcellentTechnical Information
-
Delphi-Version
Delphi 12 Athens
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
-
Buying a mini pc to install Delphi
Brandon Staggs replied to Alberto Paganini's topic in Tips / Blogs / Tutorials / Videos
Funny, that was the first step in the right direction I've seen Bezos take with the Washington Compost. -
I'm seeing this more and more lately. It is very worrisome that people actually think these autocomplete engines are authoritative and will actually argue with you if you present facts that disagree with the text generated by these tools. They may have their uses, but this is borderline scary.
-
The fact is that any design-time component can crash the IDE. All you have to do is uninstall them all and see if your problem persists. If it does, you can be relatively certain it is the IDE itself and not a component. You seem very resistant to this basic troubleshooting step. That doesn't seem rational. I agree that Delphi quality is not where it needs to be. I do not agree that the IDE is as useless and impossible to use as you have said. Shrug.
-
Do you need an ARM64 compiler for Windows?
Brandon Staggs replied to Lars Fosdal's topic in Cross-platform
To be clear, I do compile MacOS (Arm64) targets. It seems self-evident to me that the comparison you suggest is invalid. Doesn't make a difference either way; unless Windows on ARM is a passing fad, which I doubt, we need a compiler that can target it. -
Do you need an ARM64 compiler for Windows?
Brandon Staggs replied to Lars Fosdal's topic in Cross-platform
I can't compare emulated Delphi x64 code on Windows vs compiled ARM64 code because Embarcadero doesn't offer the latter yet. Ostensibly, the benefit will be not having to rely on a layer of processor architecture emulation. I certainly can't see the benefit of Embarcadero pretending there is no ARM64 Windows executable format and ignoring it altogether. If you decide the x64 output works better you aren't going to be forced to distribute ARM64 binaries. -
Do you need an ARM64 compiler for Windows?
Brandon Staggs replied to Lars Fosdal's topic in Cross-platform
This also depends on application. There is no way I would trade my desktop AMD cpu for Snapdragon. I do not care about power consumption there and there is no comparison on performance. But on a laptop, I am already using Snapdragon and I am pleased with it. I don't know what we're arguing about here. Personally I want the ability to target Arm64 on Windows now that there are seriously good Windows computers using the architecture. -
Do you need an ARM64 compiler for Windows?
Brandon Staggs replied to Lars Fosdal's topic in Cross-platform
I wouldn't know. I don't build for Linux and I don't work for Embarcadero. -
Do you need an ARM64 compiler for Windows?
Brandon Staggs replied to Lars Fosdal's topic in Cross-platform
The x64 compiler is no paragon of code output. I think it would be nice to not have to rely on Embarcadero writing its own compilers. Obviously it goes without saying I would hope they configure the toolchain properly for good output, too. Performance and power use. So far the testing of Windows applications on Snapdragon indicates you're going to get the best performance and efficiency with native code, which is exactly what one would expect... -
Do you need an ARM64 compiler for Windows?
Brandon Staggs replied to Lars Fosdal's topic in Cross-platform
The events of the last six months have certainly changed some of my opinions on this, but I am still trepidatious about an LLVM ARM64 Windows compiler "just working" with code that has been in production for 25 years. And regardless of my concerns about potential issues, I very much want an ARM64 Windows compiler as soon as possible. I'd actually like the option to build x64 with LLVM as well. Whatever issues there are to deal with, such as making sure exception handling works as I expect it to, I'll deal with them. -
You may not understand how Delphi works. In Delphi, all of your third-party components are DLLs running in the IDE's process. That's how RAD works, for better or worse, and it means that problems in third-party components will often cause havoc in your IDE. If you are unwilling to start from scratch with no third-party components and do some basic trial-and-error you will never know if the problem you are having is Delphi or not. I can say I do simple and complex searching in the IDE every day many many times as I work and I do not have any problems with those features. The most likely difference between my setup and yours is going to be what components we have running in the IDE, so, it's a good place to start.
-
Do you need an ARM64 compiler for Windows?
Brandon Staggs replied to Lars Fosdal's topic in Cross-platform
Right now it's obviously a question of whether you want performance or efficiency. If you want to prognosticate you're going to decide if you think ARM will catch up and surpass on performance or if x64 will catch up on efficiency (it doesn't need to surpass on performance). Regardless, it seems clear ARM is here to stay even on Windows machines. -
Do you need an ARM64 compiler for Windows?
Brandon Staggs replied to Lars Fosdal's topic in Cross-platform
Yes, we need an ARM64 Windows compiler, unless you think all of these Windows ARM64 machines are just a passing fad. Emulation is only intended to bridge the gap until applications can be rebuilt for native architecture. Whether or not Linux is more urgent depends on what you are building, I suppose. For me, Linux is irrelevant and I would rather have a Windows ARM64 compiler than Linux features. Also, that is not leaked information and does not confirm anything. You're making a big assumption about what that sentence means to the person writing it. It's a safe bet we will eventually get an ARM64 compiler for Windows, but I suspect it is going to come with some caveats. Unless Embarcadero wants to write their own, we are going to have to settle for an LLVM compiler which means our Windows builds will not work exactly as they have for the last 30 years, particularly when it comes to exception handling. -
The problem described sounds like what happens when a third-party component is crashing the IDE. Nobody at Embarcadero can help with that issue, you will need to resolve it on your own. Assuming that is the problem of course, but you would need to take a few minutes to figure that out. 🤷♂️
-
How about removing all of your third-party components from the IDE, and adding each one back until you determine which one is the problem?
-
Anyway it would be interesting to know what the actual problem is that the OP wants to solve. If we're considering really bad ideas, there is an actual answer that could be considered: fork System.Classes, add the desired property to TCompoent, and rebuild everything. Literally everything; you'll have to drop to the command line to rebuild all of the DCUs in Delphi, and rebuild every single component you're using in the IDE. That's a last resort, but it would work. Of course, there is probably a much easier and less brutal way to accomplish the OP's goal, if we only knew what that is.