Feature ASH language server features

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.
 

fredg1

Member
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).
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

Developer
Staff member
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.

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.
 

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.
 

fredg1

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.
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.
 

fredg1

Member
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.
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.
 

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.
 

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)
 

fredg1

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

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.
 

fredg1

Member
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
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.
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.
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

Developer
Staff member
open .ash files in the IDE

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.
 
Top