Feature ASH language server features

H

heeheehee

Developer
Staff member
If we really wanted this to be a separate jar as a proof-of-concept, then yeah, I'm fine lifting the directory restrictions as well, since there's no risk of a malicious script author stealing creds or other data exfiltration.

I think we'll still want to be careful to limit external interactions even for this separate jar, but that's just standard security posture.
 
F

fredg1

Member
heeheehee said:
You don't need a range; you could just make sure there's nothing else listening to 60090 (or just insist that if you want to use this thing, you must have that port available).
Click to expand...
Here's the issue, though: if we keep the directory restrictions, it means that a single instance of the language server can only be used for a single project.

However, if someone wanted to use it for more than one at a time, hard-coding a single port means that they can't...
This is why I kept bringing up the issue of the "bridge" having to find out which port the server connected to: because they can be more than one at a time.

Remember: this project's goal was to allow language support for .ash files for IDEs.
It is meant to include things like git projects, which can't all be in a working mafia folder.

I can understand that we may want to "start" with only allowing one instance to be working at once, but please just remember that it's not the desired final outcome.
 
fronobulax

fronobulax

Developer
Staff member
fredg1 said:
I can understand that we may want to "start" with only allowing one instance to be working at once, but please just remember that it's not the desired final outcome.
Click to expand...

Nobody was suggesting one instance was the desired outcome. Merely that much could be learned from the one instance prototype running and actually getting into other people's hands.
 
H

heeheehee

Developer
Staff member
Why can't you have multiple git projects in a working mafia folder?

Nothing's stopping you from having subdirectories like, say,

scripts/diet-script/.git
scripts/ascension-script/.git
scripts/meat-farming/.git

Similarly, if I were developing a script, I'd like it to be directly runnable for various reasons. I don't like committing broken code, especially if that code can then be checked out by users.
 
F

fredg1

Member
heeheehee said:
Why can't you have multiple git projects in a working mafia folder?

Nothing's stopping you from having subdirectories like, say,

scripts/diet-script/.git
scripts/ascension-script/.git
scripts/meat-farming/.git

Similarly, if I were developing a script, I'd like it to be directly runnable for various reasons. I don't like committing broken code, especially if that code can then be checked out by users.
Click to expand...
Because we require users to submit repositories with a directory hierarchy disposed as if they were root.

This means the root of your repository CANNOT be located inside the scripts directory, as you are showing in your examples.
Instead, they must, themselves, contain a scripts, data, relay (etc) folder, meaning that they share their root, meaning, in turn, that they cannot in any way share a language server.
 
F

fredg1

Member
heeheehee said:
Similarly, if I were developing a script, I'd like it to be directly runnable for various reasons. I don't like committing broken code, especially if that code can then be checked out by users.
Click to expand...
That was, by the way, the reason why I wanted symbolic links to stay. It was the only way to make scripts under development runnable without having to constantly copy-paste.
 
H

heeheehee

Developer
Staff member
I don't see a conflict. There's nothing stopping you from having

scripts/diet-script/scripts/...

within your Mafia directory.
 
F

fredg1

Member
It doesn't work if you use more than one folder (by which I mean, if you're storing something in /images or /data)
 
F

fredg1

Member
Am I waiting for people to try the prototype, or am I meant to continue/start its formal integration into KoLmafia?
 
fronobulax

fronobulax

Developer
Staff member
I learned a new term - MVP for minimum viable product. Perhaps I should use it instead of "prototype"? I acknowledge your effort to get to this point but what you have presented for me is not a MVP, which is what I would love to see since it would make the conversation more concrete and less abstract. It might be a MVP but since (at the very least) I have to install software that is not currently on my system (VSCode or the Intellij LSP plugin, at least) it is not yet viable for me and my current environment It is also somewhat unclear to me what I then do next. At this moment this is "on my list" but is not rising to the top. That will change when I have more time to devote to this or when the "viability" for my environment (which may just be better instructions with an example of use) improves.
 
F

fredg1

Member
fronobulax said:
It might be a MVP but since (at the very least) I have to install software that is not currently on my system (VSCode or the Intellij LSP plugin, at least) it is not yet viable for me and my current environment
Click to expand...
There might be a misunderstanding regarding what this "is".

This is a language server.

The purpose of a language server is to connect to a language client (which are each hooked to a respective text editor, most notably IDEs).

While a portion of IDEs support the LSP natively, the majority of them still require a plugin to access it (even when the plugin is made by the same team who made the IDE).
(The plugin can range from containing the whole language client, to only containing the means of pointing to a language server)
Maybe it's to give users to possibility to make their own plugin/not force theirs onto the users. Maybe it's because a language client is just meant to be a plugin. I don't know, and that's not the point.

The point is:
  1. The language server is the minimum viable product (and yes, I made sure to look up the specific definition of "minimum viable product" beforehand)
    A language server adhering to the Language Server Protocol is nothing more than half of the equation. Going further than that beats the whole point.
  2. Language servers are nothing without a language client, which is a separate product.
    Since we're not supplying it (as that would mean supplying 3 different products: server + client + text editor to go with the client, and would also beat the purpose of the LSP as it would force the use of a specific text editor), accessing it requires users to use an existing text editor/IDE's language client.
  3. Most text editors/IDEs who support the LSP give access to their client via a plugin (even when they are the one who made both).
So in short, you seem to be expecting the server to be working as a standalone, which is literally impossible without going against its purpose.
fronobulax said:
It is also somewhat unclear to me what I then do next. [...] That will change when I have more time to devote to this or when the "viability" for my environment (which may just be better instructions with an example of use) improves.
Click to expand...
I'm not sure what you're expecting to be able to do next. You just... open .ash files in the IDE, and it points out errors in them (and any file they import, if any).

More features will be available later, but this is as far as the prototype goes...
 
fronobulax

fronobulax

Developer
Staff member
fredg1 said:
open .ash files in the IDE
Click to expand...

OK. If that was ever clearly stated recently then I forgot about it.

The MVP from an end user perspective is probably a properly configured IDE that supports language servers, will understand ash files are supported (which is just configuration unless it happens automagically) and the jar you created.
 
MCroft

MCroft

Developer
Staff member
Hey team, six months since the last comment, did we go any further than the prototype?

I'm asking because I was looking at dependency updates and 0.14.0 (current) breaks our code, which relies on 0.12.0 and that dependency is in the main codebase.
 
fronobulax

fronobulax

Developer
Staff member
The main proponent got mad at one of the devs (who can also moderate here) and disappeared. I never got the prototype to do anything I thought was useful but I understand my opinion of utility is not necessarily shared. @heeheehee seems to be the person likely to have the most informed opinion.

If there is no compelling reason to move from 0.12.0 other than 0.14.0 exists then put in a comment about the dependency, if you want, let it stay and move on. If there is some reason, besides new and shiny, to go to 0.14.0 then we should try and deal with the issues.
 
H

heeheehee

Developer
Staff member
I have not tried the prototype in action, in part because I am not actively developing ASH scripts or really playing KoL.

I'm surprised to hear that there are breaking API changes in just two versions, unless we were using a method that was already slated for deprecation.

From https://github.com/eclipse/lsp4j/blob/main/CHANGELOG.md:
Breaking Beta API changes:
  • Significant updates were made to the TypeHierarchy features to replace the non-standard implementation
Deprecated API changes:
  • SymbolInformation is deprecated in favor of DocumentSymbol or WorkspaceSymbol
Click to expand...

Oh right, beta features...

For now, I'm inclined to agree with frono's assessment of "comment why we need this specific version" and call it a day.
 
You must log in or register to reply here.
Top