Brandon Staggs

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.

That's fair. In my mind, when we start talking about a "new architecture," we go beyond fixing bugs in a system to using a new approach. But it could be that I am misunderstanding what is intended by the statement "new architecture." Though one wonders why this "new architecture" requires waiting for a breaking release. The impression I was left with, after watching that segment of the video three times in a row, was that they know full-well that LSP is still very broken and requires a redesign and they are waiting for a major release rather than fixing the thing in 12.1 or 12.2 or now 12.3. I watched the webinar live and tried to ask a follow-up question about LSP fixes and again felt as though they were saying big changes coming in 13, but that is just an impression and the Q&A is not available in the YouTube post. Too bad we don't have something like a road map to clarify things for us.

Edit: as was pointed out by someone else, this non-native speaker may not mean what I mean by "new architecture." But here's what I was referring to: 42 minute mark. Listen carefully where he says there will be a "new architecture" in the next major release.

Delphi 12.0, .1, and .2 have been especially hard for us with our million+ line project. 80% of the time Find Declaration doesn't work, and the other 20% of the time it seems random which way works -- CTRL+G or CTRL+Click, sometimes one will work when the other one doesn't. We of course cannot email the "crown jewels" entire proprietary project to Emba for them to test with. I understand they need reproducible examples, but they have also said during the release webinar that they are aware LSP doesn't work acceptably and will be replacing the current system with a completely new approach in 13. Well, this is a fundamental, basic function of any IDE, and personally I question this decision to add new features of any kind while something so basic is known to be non-functional for so many users. But, trying to be fair, I'm sure not all of their developers are qualified to work on LSP so they will naturally be focused on multiple areas at once. I can guess at why LSP has such a hard time with our code base, and I have spent a lot of time trying to remove legacy anti-patterns and cleaning out uses clauses, etc, but in the end, it all compiles just fine, so it should not be a problem for the editor to navigate. An editor should be able to navigate and offer functional code completion with broken code, let alone code that compiles without issue.

Obviously I was referring to the 64-bit compiler that was added in 12.2 for the Enterprise level, not the 32-bit compiler that can target 64-bit builds that we have had all these years.

It is a priori "OK" because they are a private company which can decide how to spend their R&D money and we are free agents that can decide whether or not to subscribe. I don't know a single Delphi developer who doesn't have a heap of legitimate complaints about the product, but I don't know how this is anything other than a step in the right direction. Is it enough? That's up to each subscriber to decide. I also was pretty harsh on them for packing the 64-bit compiler as a top-tier option prior to this (unavailable to Pro level subscribers), but seen in the light of them trying to work their way to a stable 64-bit IDE, I get it.

I don't know that it "doesn't work." But I presume they are doing their best to get to a robust release of the 64-bit IDE as soon as they think they can given their resources. Rolling it out as they are along with a point release seems like an understandable way to get there with more testing and feedback. Shrug. It is "pretty lame" that Delphi is not getting the development and enhancement that it needs, but I don't know that there is any reality-bending that could happen to change that. It's been gone over before. It's a proprietary legacy system and it's clear that their resources are limited.

To be fair, they are being very straightforward about it being a "version 1" release and it isn't even enabled by default.

I'm curious to hear from people who have experienced failures in 12.2 with code insight and basic navigation features like Find Declaration if this is improved in 12.3.

I think this debate will never achieve any real consensus, and in the end, each of us needs to just decide what makes sense. Here's a nice fun read from 15 years ago: https://blog.therealoracleatdelphi.com/2010/02/a-case-against-freeandnil_5.html Interesting that Bauer and Primoz take opposite sides.

Assuming this is what you want me to explain: If you have two places that call FreeAndNil on the same reference, and a logic problem that can lead to both places being called without a clear intent to do so, you will not know about the second FreeAndNil because it will succeed and move on, where a second call to .Free will instead cause a pointer error. Is the second call to FreeAndNil a problem? Maybe not, but the code that runs around it is working on the assumption that the pointer is valid, and you have hidden an error that would expose the problem. David asked what the harm in using FreeAndNil can be. That's what we are discussing. You're allowed to disagree, of course. But the point is to answer the questions about why FreeAndNil should be used for its intended purpose, rather than a debugging tool.

To be precise, you are using it to catch access to NILLED object pointers. And you believe this is a debugging tool. But really this is just debugging theater. Anyone using FreeAndNil to force AVs when the object reference is next used is de-facto claiming otherwise, and this is where you seem to have gotten lost in my explanation. A *LOT* can happen on a nilled object reference without creating an AV. Understanding why it is designed that way should be enough to answer your own questions about why you should not be abusing FreeAndNil as a debugging tool. There are purpose-built tools for catching use-after-free conditions. FreeAndNil is not one of them. I am just saying it is better to use the purpose-built tools for this instead of relying on a side-affect of FreeAndNil which can only catch use-after-free SOMETIMES. In the projects I work on where FreeAndNil is used everywhere (without need) I just assume that I cannot know for sure if those variables are actually intended to be used again or not. That's fine. In my own code I just make my intent clear by only using FreeAndNil when it is appropriate for the code -- not as a halfway debugging tool.

This idea has already been debunked in this thread. For example, you can call any function you want on a nil object pointer and those functions could easily affect other things in memory (global variables, for example). It will only AV if that function somehow leads to instance memory being used. For example, you can easily call .Free on a nil object pointer, and it will succeed just fine, and you may actually be hiding a logic error in your code by nilling the object before calling free a second time.