Language server won't automatically start compiling the change source code

[Hanna19]

Hi,
I created the openedge_project file with all folders which I need to compile. When I manually Restart Language Server, it always knows what was changed correctly. But it doesn't check itself. I always need to call Restart Language Server. It would be acceptable for the initial phase, but it has a serious side-effect. It creates a new process each time when Restart Language Server is called, all attached to VSCode. All will be detached when VSCode is closed, freezing the entire server eventually.
I am using VSCode client on Windows PC and VSCode server on the remote Linux server. My extensions are: abl riverside, git Lens. remote ssh.
Is it a bug, or some obvious problem in the configuraton
Thank you
Hanna

[gquerret]

What do you mean by "it doesn't check itself" ?
Make sure the language server output is correct (check the entire file, not only the last line). You can also check the "Language Server Debug output" in the settings and restart the language server. You can also include the content of your openedge-project.json here.
You can also clone this project on your remote host, and open it with VS Code. Apart from the DB that has to be created from the command line, the project is configured, and compilation will be done automatically.

[Hanna19]

By "it doesn't check itself" I mean that Language Server doesn't recompile automatically newly updated procedures, however when manually restarted, it will recompile the changed procedures correctly. It looks that Language Server doesn't watch the project's folders for new updates.
Language Server Output looks correct, the only error which I see is:

[2024-10-23T08:44:07.714-0400] [ERROR] Unable to fetch documentation from https://progress-be-prod.zoominsoftware.io/api/bundle/openedge-abl-reference-122/toc?language=enus .

I assumed that it was not critical, is it?
I checked "Language Server Debug output" and restarted the language server and I see all [DEBUG] lines. No errors. I updated one of the procedures in the project and nothing is happening on the language server output.
I also noticed that restarting the language server won't close the current one, eventually freezing the server.
Originally, I started the project locally on linux using the same openedge-project.json file and, as far as I remember, the language server worked as expected, recompiling automatically all updated procedures.
We'd like to replace PDSOE with VSCode for all our development and we want to have it in the client(Windows)-server(Linux) mode.
We have python3-inotify installed on the linux (remote) server. Can you suggest a way to test if it is working for the language server? Any logs?
I appreciate your insights
Hanna

[gquerret]

I can't do divination, I'm not able to solve problems without facts. Please include the configuration file and log output.
You can do that with the sample project that I mentioned in my previous comment if you're afraid of sharing private information.

[Hanna19]

Gilles,
My apology, I mislead you and, in fact, myself. During my tests, I didn't update source code from the project folders. I deleted some r-code files, assuming that it will trigger the the compilation. I guess, it was not part of the design.
So, to clarify. The updated files, will be automatically recompiled. This applies to the include files also. So all works great, as expected.
But the 'freezing' issue is very concerning. Every time when I switch the project or open VSCode, the new ABL Language Server will start. This is like what it looks like on my server.

if992381 199593      1  2 11:48 ?        00:02:30 /home/if992381/.vscode-server/extensions/riversidesoftware.openedge-abl-lsp-1.13.6/jre/bin/java -Dorg.slf4j.simpleLogger.showLogName=false -Dorg.slf4j.simpleLogger.defaultLogLevel=INFO -jar /home/if992381/.vscode-server/extensions/riversidesoftware.openedge-abl-lsp-1.13.6/resources/abl-lsp.jar

The 4th column is CPU usage. It went down to 2% , but it started with over 90%.
Is it something what was caused by the incorrect configuration on my part? I am attaching my openedge-project.json file in case it can help.
Hanna
openedge-project.json

[gquerret]

My apology, I mislead you and, in fact, myself. During my tests, I didn't update source code from the project folders. I deleted some r-code files, assuming that it will trigger the the compilation. I guess, it was not part of the design.

Yes, deleting rcode doesn't trigger compilation.

But the 'freezing' issue is very concerning

LS initialization requires reading files from disk and computing data structures (some of them being read from cache). This is done in multiple threads so, depending on the CPU and disk speed, that may take some time. LS startup freezing your machine probably means that your machine is very slow and/or lacking cores.

[gquerret]

There are currently no specific guidelines, you'll have to do your own tests on your codebase. Fast disks will be useful for that. Monitor memory if you have multiple concurrent developers on the same machine. LS startup is time consuming, so the developers can also keep their session opened instead of frequently restarting VSCode.

[Hanna19]

Thank you, Gilles.
During my tests, I noticed that when I close VSCode, there are orphaned processes left behind. They were spawned from VSCode process. However, each time when I switch projects the previous project's process is orphaned and never deleted. Do you plan to terminate these orphaned processes as they are certainly consuming resources? We are considering creating a process that will be periodically remove them,. Good idea?

if992381  69374      1  5 22:04 ?             00:00:42 /home/if992381/.vscode-server/extensions/riversidesoftware.openedge-ab 
if992381  69914      1 12 22:11 ?            00:00:43 /home/if992381/.vscode-server/extensions/riversidesoftware.openedge-ab    
if992381  70289      1 16 22:12 ?            00:00:42 /home/if992381/.vscode-server/extensions/riversidesoftware.openedge-ab    
if992381  70747  70633 31 22:15 ?        00:00:28 /home/if992381/.vscode-server/extensions/riversidesoftware.openedge-ab 

Hanna

[gquerret]

Are those Java processes or Progress processes ? I think such a problem was already reported, but never reproduced internally. If it's possible to reproduce then that will be fixed in the product. In the meantime, you can kill those orphans.

[gquerret]

Update: this behaviour has been reproduced. It's now fixed in the pre-release stream (1.13.7)
Update 2: ok, not completely fixed :-(
Update 3: fixed in 1.13.8

[Hanna19]

Yes, they are Java processes:

if992381  70289      1 17 22:12 ?        00:00:42 /home/if992381/.vscode-server/extensions/riversidesoftware.openedge-abl-lsp-1.13.6/jre/bin/java -Dorg.slf4j.simpleLogger.showLogName=false -Dorg.slf4j.simpleLogger.defaultLogLevel=INFO -jar /home/if992381/.vscode-server/extensions/riversidesoftware.openedge-abl-lsp-1.13.6/resources/abl-lsp.jar.

I am using now v1.13.6.

[Hanna19]

I noticed that if I use "Restart Language Server", the new process will be created but the current one won't be orphaned.
Is this also fixed in 1.13.8?

[gquerret]

Have a look at the latest pre-releases, but yes, that's supposed to be fixed. Please include the output of the "ABL" tab and "ABL Language Server" tab in case you still have issues.

[Hanna19]

I use v 1.14.1 now and I don't see the issues with orphaned processes of LS anymore.

[Hanna19]

I've just realized that only .I files are considered as includes for ABL-LS. If updated, they will trigger recompile.
In our application we have all kinds of extensions for include files: .IP, I1 and many more. Progress will accept any name in {}.
Is it any plan to change the behavior of ABL-LS in this matter?
Hanna

[gquerret]

That's already available in the LS: #95
Only for include files, not for procedures / classes.

[Hanna19]

Thank you. It worked however the extensions must be entered in the lower case. Our files are in upper case so I automatically used upper case in "includeFileExtensions": [".I",".IP"] and it didn't work. It took me a while to figure it out. Shouldn't it be changed in certain point?

[gquerret]

You're right, something is not consistent, that will be fixed.

[Hanna19]

Our application consists of around 20 000 programs to compile. After compiling them all with VSCode, I calculated CRC for each r-code. Then, I compared it with CRCs on r-code compiled by ant using PCT compiler. Around 17 000 CRCs were identical but the rest wasn't.
In both cases it is the same project and the same database. I checked PROPATH in openedge-project.json file very carefully.
To investigate, I focused on just one procedure. CRC was the same if I compiled it in PDSOE , ant build using PCT and Progress editor. But different when compiled in VSCode. I really cannot find explanation why.
Hanna

[Hanna19]

I stopped VS Code, removed all r-code and started VS Code.
openedge-project.json starts with:
"name": "devslot2",
"version": "1.0",
"oeversion": "11.7",
"graphicalMode": false,
"charset": "ISO8859-1",
"extraParameters": "-cprcodeout ISO8859-1",

CRC remain the same, TEST.P.xref file shows :
iFast_iFastBaseRepo/mfs_base/fund/TEST.P iFast_iFastBaseRepo/mfs_base/fund/TEST.P 1 COMPILE TEST.P
iFast_iFastBaseRepo/mfs_base/fund/TEST.P iFast_iFastBaseRepo/mfs_base/fund/TEST.P 1 CPINTERNAL utf-8
iFast_iFastBaseRepo/mfs_base/fund/TEST.P iFast_iFastBaseRepo/mfs_base/fund/TEST.P 1 CPSTREAM iso8859-1

It looks as the cprcodeout parameter is not executed.

[gquerret]

Check that the _progres started by the LS has the right parameters. Check content of rcode at file offset 0xB7 (approximately), you should see the rcode codepage.

[Hanna19]

My openedge-project.json:

 "name": "devslot2",
  "version": "1.0",
  "oeversion": "11.7",
  "graphicalMode": false,
  "charset": "iso8859-1",
  "extraParameters": "-cprcodeout iso8859-1",

I ran a following programs in VS Code, using 'run with _progress':

put unformatted 
session:cpinternal "  " 
session:cpstream "    "
session:cprcodeout.
output close.
compile /slots/devslot2/iFast_iFastBaseRepo/mfs_base/fund/TEST.P save  xref TEST.P.xref . 

In hb.out there are the same session parameters as in openedge-project.json:
ISO8859-1 ISO8859-1 iso8859-1

And rcode CRC is the same as in PCT. This is the binary output:

But CRC is different when compiled by VS Code. And here is binary output of r-code created by VS Code:

I am not sure what you try to say by highlighting 1 2 5 2.

[gquerret]

1252 was the encoding of this rcode. I'm not sure about the file offset in 11.7, but you can perhaps check with Progress.
It's anyway not more than a codepage issue. You can contact me offline if you want to start a consulting engagement to have a look at this issue.

[Hanna19]

Thank you for all your insights. I was able to reconcile rode by changing CPINTERNAL to utf-8 for PCT.

[Hanna19]

We are using abl extension 1.16.0. It looks as it stopped compiling *.P (upper case) files. On our system files are named with both: upper and lower case (p,P). Is it the intentional change or just a mistake.

[gquerret]

That's in the release notes of 1.16, the patterns are now case-sensitive on Linux. The default include pattern only matches *.p.

[Hanna19]

Thank you.
I tried to change the default include pattern to include .P but I am not successful. I tried the ant style : "**/.P,/*.p,/*.cls" among the other few. None worked.

[Hanna19]

Can you comment, please, on my last message?
Our Unix based application consists out of around 25,000 *.P. They are also some *.p, but those have different purpose than *.P. The files' names are also mostly in upper case. We have many extensions for include files, some in upper case and some in lower case. We have been successfully using PCT compiler for many years without changing the file extensions. It would be very difficult to change all these extensions. At the moment, we reversed abl extension to v 1.14.1, so we can continue to work, and hope that all consecutive versions will compile both *.P and *.p files.

[gquerret]

Try 1.16.1

[Hanna19]

In 1.16.1, with
"includes": ".P,.cls"
the *.P and *.cls files are compiled. It works for us.
Thank you

[Hanna19]

In v 1.16.1 I see again the orphaned ABL LS processes.
We use the remote server configuration, Windows client- Linux server.
When I close a folder, the process won't be killed and when I open a folder, the new process will be created, eventually killing the server:
if992381 332784 1 18 08:38 ? 00:00:33 /home/if992381/.vscode-server/extensions/riversidesoftware.openedge-ab
if992381 333535 1 24 08:39 ? 00:00:35 /home/if992381/.vscode-server/extensions/riversidesoftware.openedge-ab
if992381 334288 1 32 08:39 ? 00:00:34 /home/if992381/.vscode-server/extensions/riversidesoftware.openedge-ab
if992381 335268 335018 99 08:41 ? 00:00:13 /home/if992381/.vscode-server/extensions/riversidesoftware.openedge-ab

This doesn't happen in v 1.14.1.

[gquerret]

Can't reproduce, and there are no changes related to the shutdown hook between 1.14.1 and 1.16.1

[Hanna19]

I observe the same in v 1.12.0 and 1.16.0.
I don't see it in version 1.14.1.