How to implement quickfix via a language server - visual-studio-code

I've implemented a language server which provides some linting. The linter checks for required properties and issues 'missing property' errors. I would like to have corresponding 'insert missing property' quickfixes for these errors.
I think the general area of the LSP protocol meant for this is:
textDocument/codeAction
With this, the server could return a 'insert missing property' command for a 'missing property' diagnostic marker.
But how does the server implement the 'insert missing property' command itself?
Looking through the lsp spec, I can't find anything that lets the server register commands.
I did find some info about vscode apis for registering commands on the client side here: https://code.visualstudio.com/docs/extensionAPI/vscode-api
So I suppose I could register and implement the 'insert missing properties' on the client side, but...
The client side is only a 'dumb' wrapper delegating most work to the server. As such it doesn't really understand the document structure and isn't a very good place to implement transformations of the document that require understanding that structure.
It seems my best option is to add some 'custom' protocol to my language server so that I can implement the 'insert missing properties' command on the client side, but delegate the hard part of computing the edits for the quickfix back to the server.
Or... is there a better way?

Yes there is a better way which does not require any custom protocol extensions. These are roughly the steps:
First make sure that your vscode extension's package.json has an up-to-date language-server-client. Mine uses version 3.2.x. I also needed to update vscode engine version to 1.6.x. Here's an example package.json
Now we can use Version 3 (only a draft at the time of this writing, but already usable) of the language-server protocol. These are the interesting pieces:
textDocument/codeAction: implement this on the server-side to compute a list of commands that represent the quickfixes.
workspace/executeCommand: implement this in the server-side to execute the commands. It can make use of workspace/applyEdit to send a request to the client to perform changes to the documents in the workspace.
client/registerCapability: The server can call this with a ExecuteCommandRegistrationOptions object. This registers your server-side command(s) with the client, so that it knows to execute them via the workspace/executeCommand handler implemented in the previous step.
initialize: Alternatively to using client/registerCapability you can also register server-side commands by returning a WorkspaceCapabilities object with an appropriate setting for its executeCommandProvider attribute. This method is slightly less complex (but can only be used if you don't require registering/unregistering of commands dynamically).
See also this vscode issue ticket about the topic of implementing quickfixes.
Important note: Version 3.2.0 of the language-server client implementation has a bug, it uses the wrong name client/registerFeature instead of client/registerCapability so you may have to work around that until that bug is fixed. If you use the initialize method then you are not affected by this bug.

Related

How to disable wss4j timestamp cache

I need to update a javaEE application (still in java 1.7) that provides a SOAP web service. And I'd like to disable the TIMESTAMP_CACHE that wss4j (v2.0.2) uses to control reply attacks. It creates too many files and the OS reaches the maximum open files allowed, repeatedly. The files start to appear, one for each request that has been made and are named in the following way:
wss4j%002etimestamp%002ecache-e%0058ga%0058l%0058%004b%0057g%004ah%0050w==.data
The documentation states that the TIMESTAMP_CACHE can be changed (or so I understand):
ConfigurationConstants.ENABLE_TIMESTAMP_CACHE ("enableTimestampCache"): Whether to cache Timestamp Created Strings (these are only cached in conjunction with a message Signature). The default value is "true".
I've found many examples to change some of these ConfigurationConstants when a client application creates the Call object. See an example to change the PASSWORD_TYPE constant:
Service service = new Service();
Call call = (Call) service.createCall();
...
call.setProperty(UsernameToken.PASSWORD_TYPE, WSConstants.PASSWORD_TEXT);
call.setProperty(WSHandlerConstants.USER,"werner");
However, my application is not on the client side but on the server side and I haven't found so far the way to change the ENABLE_TIMESTAMP_CACHE constant.
Any idea?
I couldn't find a way to disable the timestamp cache. However, the wss4j behaviour described above happened to be a bug that not only resulted in lots of open files but in lots of open threads. It has already been fixed in version 2.0.9. Upgrading to the "newer" version did the trick.
You can find here the discussion in full that drove to the bug discovery and here the fix in wss4j's jira

Google Actions CLI 3.1.0 version and actions.intent.TEXT

I want to be able to talk with Google Assistant, but connect the Actions project directly to an NLP service I already have running on my server. In other words, NOT use dialogflow.
All the following examples show how to do this.
With Rasa
https://blog.rasa.com/going-beyond-hey-google-building-a-rasa-powered-google-assistant/
With LUIS
https://www.grokkingandroid.com/using-the-actions-sdk/
https://dzone.com/articles/using-the-actions-sdk-for-google-assistant-develop
With Watson
https://www.youtube.com/watch?v=no0R0bSkHXc
They use the actions.intent.MAIN as the invocation and actions.intent.TEXT for all other utterances from the talker.
This is what I need. I don’t want to create a load of intents, with utterance phrases, inside the Action because I just want all the phrases spoken by the talker to be passed to my server, and for my NLP service to deal with them.
So I set up a new Action project, install the Actions CLI and then spend 3 days trying all possible combinations without success, because all these examples are using gactions cli 2.1.3 and Google have now moved on to gactions cli 3.1.0.
Not only have the commands changed, but so too has the file formats and structure.
It appears there is also a new Google Actions Console, and actions.intent.TEXT is no longer available.
My Action is webhook connected to my server, but I cannot figure out how to get the action.intent.TEXT included and working.
Everything I find, even here
Publishing Actions on google without Dialogflow
is pre version update and follows the same pattern.
Can anyone point to an up-to-date, v3.1.0, discussion, tutorial or example about how to send all talker phrases through to an NLP that isn’t dialogflow, or has Google closed that avenue?
Is it possible to somehow go back and use the 2.1 CLI either with the new Console or revert the console back. (I have both CLI versions, I can see how different their commands are)
Is it possible to go back and use 2.1?
There is no way to go back to AoG 2. You probably also don't want to do so - newer features aren't available with v2 and are only available with v3.
Can I use my own NLP with v3?
Yes, although it isn't as obvious, and there are some changes in semantics.
As an overview, what you'll need to do is:
Create a Type that can accept "Free form text". I usually call this type "Any".
In the console, it looks something like this:
Create a Custom Intent that has a single parameter of this Any Type and at least one phrase that captures everything for this parameter. (So you should add one training phrase, highlight the entire phrase, and set it for the parameter. Sometimes I also add additional phrases that includes words that I don't want to capture.) I usually call the Intent "matchAny" and the parameter "any".
In the console, it could be something like this:
Finally, you'll have a Scene that you transition to from the Main invocation. When it matches the "matchAny" Intent, it should call your webhook with a handler name. Your webhook will be called with the "any" parameter set with the user utterance. (Note that the JSON has also changed.
Again, the console might have it looking something like this:
That seems like a lot of work. Isn't there just some way to do all that from the command line?
Yes. You can do all of that in the configuration files that the CLI accesses and then upload it. (You can then also use the console to review the configuration, if necessary, to make sure they're configured as you expect. You can shift back and forth between them as appropriate.)
Google also has a github repository that contains most of the files pre-configured for this sort of setup.
You will need to update the configuration from the repository to handle the webhook correctly (it includes code to illustrate what is happening using the inline code editor) and to add your project ID.

Include runtime type definitions using VSCode extension

I'm working on a library that lets users run Node processes from inside another application. The library is called "max-api"; functions for sending data to the host application are exposed through a Node module and are loaded in the expected way:
const maxAPI = require("max-api");
However, the user never interacts with this module directly. Rather, when the host application launches the Node process, it intercepts the call to require, checks if the name of the module is "max-api", and provides the module if so.
This works great, the only issue is we have no way to provide type definitions for this modules. So, the user doesn't get any autocomplete or validation for functions in the "max-api" module. I was thinking of writing a VSCode extension to provide these, but I'm not 100% sure how to get started. Thanks in advance for any advice.
You could write a TS typings file (see Definitely Typed). This would be installed in node_modules/#types and vscode will automatically pick it up to provide code completion for your module.

Create new work item type using VSTS Extension

Based on the documentation https://learn.microsoft.com/en-us/vsts/extend/overview?view=vsts#what-makes-up-an-extension, a VSTS extension can be used to extend the work item form.
However, I would like my extension to automatically create a new work item type once it is installed. Is this something that is possible? I can't find any documentation online that suggests how to do it.
Theoretically this is possible, the extension has a "first load" call which you can use to use the rest api to create a custom process or update the existing custom process. The REST Api to change processes isn't public yet, so you'll have to work from using fiddler to watch how the web ui does it.
Due to the way processes are linked to projects, all projects with that process will get the new work item type.
I could not find a lot of documentation online for this, but the VSS web extensions SDK(https://www.npmjs.com/package/vss-web-extension-sdk) has a REST client called 'ProcessDefinitionsRestClient' declared in the typings/tfs.d.ts file. This client has a createWorkItemType method available that looks like this:
createWorkItemType(workItemType: ProcessDefinitionsContracts.WorkItemTypeModel, processId: string): IPromise<ProcessDefinitionsContracts.WorkItemTypeModel>;.
The 'ProcessRestClient' client has methods to create a new/inherited process to which the new WIT can be added.
I have not tried it out yet, and these APIs are still in preview, but maybe they can get you started on the right path.

Advanced REST Client: adding query parameters

Advanced REST Client seems like a neat REST client implementation to try REST-APIs.
But, I can't find how I can add query parameters to the URI of the API, but without putting it up the with the URI itself.
for example, to generate some URL like
https://api.example.com/v2/users/?age=25&fanOf=lakers
i want to add parameters like "age"=25 and "fanOf"="lakers".
i know it's there somewhere but can't find it plainly on, otherwise intuitive interface, `Advanced REST client".
After a bit of failed exploration on Internet & SO of-course, got it from a tip of a co-worker.
The option opens up by clicking the down-arrow on the left-side of the url-box.
Screenshot with new version 12.1.4 of ARC client