Jump to content
Laurent ESPARIAT

LSP - Alexandria

Recommended Posts

Hi

 

We migrate yesterday on Alexandria. 

We have a lot of troubles with Ctrl + Click feature (working, not working).

We would like to activate LSP log to understand.

Do you know how to active these logs ?

 

On previous versions we find this topic :

 

 

Filing Bugs and Log Files

To enable log files, open the registry:

·         Create a key:

HKEY_CURRENT_USER\Software\Embarcadero\BDS\21.0\LSP

·         Create a DWORD value called DelphiLSPLog with value hex $ff or decimal 255

Log files will be located in C:\Users\<User>\AppData\Local\Temp\DelphiLSP.

Make sure you include the log files with every bug report in the Quality Portal. They are extremely helpful to track down the cause of issues.

 

Thanks

Share this post


Link to post

Did you change "HKEY_CURRENT_USER\Software\Embarcadero\BDS\21.0\LSP" to  "HKEY_CURRENT_USER\Software\Embarcadero\BDS\22.0\LSP" ?



 

Edited by mvanrijnen

Share this post


Link to post

Yes but we had another error in registry. We don't work on "BDS".

Logs are working now

Sorry

 

But DelphiLSP doesn't work very well. "Agent" subprocess dies and starts all the time.

 

Laurent

Share this post


Link to post

This is as known problem on complex projects. We have the same things and sent the logs to EMB. Essentially, the LSP parser is taking too long to compile the code. Because it is taking so long, the LSP parser thinks there is a problem and restarts. This happens over and over again.

 

I was not able to get the logs to EMB before Delphi 11 was in beta and David Millington said they could not fix it in time for Alexandria. We reported the problem in Delphi 10.4.2 but evidently according to David, and now your experience, it still persists in Delphi Alexandria.

 

I was not able to get clarity exactly what about the code (if even there was anything particular) that was making the LSP take so long.

 

You can look on the LSP progress bar and see the progress bar going forever basically. Sometimes it stopped for a brief time, then restarted.

Edited by Dave Novo

Share this post


Link to post

Hi Dave
Your explanation is very interesting. 
Logs were sent to Embarcadero and we are waiting. Perhaps, a "light" Insight configuration could help Delphi LSP.exe (Error insight, code completion, ...)
Thanks for your feedback.

 

Laurent

Share this post


Link to post

We do have too many semi-circular references. We are working on removing them slowly over time, which we thought would improve the compile time as well. But it seems not to improve the compile time very much and it takes tons of time.

Share this post


Link to post
3 hours ago, Dave Novo said:

This is as known problem on complex projects. We have the same things and sent the logs to EMB. Essentially, the LSP parser is taking too long to compile the code. Because it is taking so long, the LSP parser thinks there is a problem and restarts. This happens over and over again.

 

I was not able to get the logs to EMB before Delphi 11 was in beta and David Millington said they could not fix it in time for Alexandria. We reported the problem in Delphi 10.4.2 but evidently according to David, and now your experience, it still persists in Delphi Alexandria.

Thanks for this info. I've been wrestling with this issue for a while. 10.x had the ability to turn LSP off and use the legacy version, which often fixed the Ctrl-click issues. Not being able to Ctrl-click an identifier drives me nuts and I'm always looking for a good resolution.

 

Newly opened projects seem to have less of an issue, but it is definitely the longer units for more complex projects that fail.

  • Like 1

Share this post


Link to post

FWIW I asked if there was a secret registry code that could turn on the "classic compiler" but I did not hear back about it.

Share this post


Link to post
33 minutes ago, Dave Novo said:

We do have too many semi-circular references. We are working on removing them slowly over time, which we thought would improve the compile time as well. But it seems not to improve the compile time very much and it takes tons of time.

Whether it improves compile time depends on just how many Unit Dependency Cycles you have. In a large legacy project, it can be a very large number, and reducing that number can greatly help with build time. Also not, "build" not "compile". 

Share this post


Link to post
23 minutes ago, Dave Novo said:

FWIW I asked if there was a secret registry code that could turn on the "classic compiler" but I did not hear back about it.

No, there is no flag. Classic code insight has been completely removed in Delphi 11. I don't know the details, but there were some interference issues that could not be resolved otherwise.

Share this post


Link to post
On 10/14/2021 at 8:48 PM, Bill Meyer said:

Whether it improves compile time depends on just how many Unit Dependency Cycles you have. In a large legacy project, it can be a very large number, and reducing that number can greatly help with build time. Also not, "build" not "compile". 

from @Vincent Parrett in another thread about 10.2.4 LSP : "If the code is too complex for the tooling, then the tooling needs improving, valid compiling code should not be a problem." 

 

 

Share this post


Link to post
On 10/16/2021 at 10:04 AM, ConstantGardener said:

from @Vincent Parrett in another thread about 10.2.4 LSP : "If the code is too complex for the tooling, then the tooling needs improving, valid compiling code should not be a problem." 

The key phrase being "valid compiling." And even that is not without limit.

In a large application, when the Unit Dependency Cycles (UDCs) reach some threshold, the build time begins to increase exponentially. The exponent has been, in my experience, relatively small, so things do not grind immediately to a halt. But even a 3% degradation can't be sustained -- eventually, a build takes minutes to complete. In Delphi, that is pretty shocking.

The problem is in how to reduce the UDCs, since they derive in large measure from poor design. Reducing them is a matter of making real design repairs, and that is expensive.

 

But if you think there is a brute force "solution" I would love to hear of it. I can readily imagine ways of obtaining more breathing space: faster CPUs, more compiler threads, more memory available for compilation. But all you get from those is a limited ability to delay the necessary repairs.

Share this post


Link to post

This may be the case for very complex projects, but when the Tooltip show's you the right file and classname and an Ctrl+click shows you nothing (don't open this file/class) in a not so big project (build's in 17 sec)? This drives me crazy!

Share this post


Link to post

Ctrl + click also doesn't work for me sometimes. I just have such a mini project:classic_sad: But the "Find Declaration" popup menu works

Share this post


Link to post
17 hours ago, Bill Meyer said:

eventually, a build takes minutes to complete

You should try one of the compilers other than the 32 bit Windows compiler!! 

 

I 100% agree with the sentiment that the tooling should work. 

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×