Stream: t-compiler/wg-rls-2.0

Topic: Deployment and installation


std::Veetaha (Feb 07 2020 at 21:50, on Zulip):

Can anyone please also explain what is the logic behind these if statements?
https://github.com/rust-analyzer/rust-analyzer/blob/5397f05bfe7f3b18229a65040c6685e762b2f9a3/editors/code/src/config.ts#L90-L116

Jeremy Kolb (Feb 07 2020 at 21:55, on Zulip):

If we find cargo-watch.enablein the config then a field with the value and default to true?

std::Veetaha (Feb 07 2020 at 21:58, on Zulip):

But .has() already checks that the config value is present, that default would never be set then I guess ...

Emil Lauridsen (Feb 07 2020 at 22:13, on Zulip):

We leave it null if not in config, to use server default if I recall

std::Veetaha (Feb 07 2020 at 22:31, on Zulip):

Hmm, I see we have 3 sources of truth for default values.

  1. Default values in package.json
  2. Inline config member variables initializers
  3. Default values in config.get("path", value)

This is very confusing ...

matklad (Feb 09 2020 at 12:25, on Zulip):

Yes, the env var should override the config

matklad (Feb 09 2020 at 12:28, on Zulip):

Hmm, I see we have 3 sources of truth for default values.

Some of this is unfortunatelly inherent in the fact that there's no cross-editor way to handle configs...

Long-term, we should add a cargo xtask which would take rust struct as a source of truth and generate the relevant secion of package.json (or the relevant config for any other editor)

matklad (Feb 09 2020 at 12:28, on Zulip):

We also should integrate proper path-dependent and dynamic configs.

In short, the current configuration handling lacks design at all.

std::Veetaha (Feb 09 2020 at 13:06, on Zulip):

Yes, I was thinking about our class Config it definitely needs amount of rework, its design a bit obstructs the introduction of Download latest language server command. I decided to move this feature to new PR and not bother doing it now, because it is likely to add to many changes to code.

matklad (Feb 09 2020 at 13:10, on Zulip):

Should we merge the PR then?

matklad (Feb 09 2020 at 13:10, on Zulip):

I think all the important bits are already in place?

std::Veetaha (Feb 09 2020 at 13:16, on Zulip):

Hmm, I just have a question. I was wondering on how to add graceful termination when language server is not available.
But we just eat this error and continue execution like this was a nothing here

Shoud we throw an error from activate() call here instead?

matklad (Feb 09 2020 at 13:18, on Zulip):

I think if the user than chacnges the settings, we should be able to activate the server allright?

matklad (Feb 09 2020 at 13:18, on Zulip):

Ie, if we failed at startup, it doesn't mean that we've failed for good?

matklad (Feb 09 2020 at 13:18, on Zulip):

Not saying that the current handing is reasonable, just that throwing in the towel in activate might not be the right thing to do

std::Veetaha (Feb 09 2020 at 13:19, on Zulip):

Hmm, yes, didn't think about that

std::Veetaha (Feb 09 2020 at 13:19, on Zulip):

I am also a bit scared to merge this today, if we are making a release soon ;)

matklad (Feb 09 2020 at 13:20, on Zulip):

Isn't it exactly the point of the realease to figure out which stuff is broken? :)

std::Veetaha (Feb 09 2020 at 13:22, on Zulip):

Well, if you think of release this way, I won't argue...

std::Veetaha (Feb 09 2020 at 13:38, on Zulip):

@matklad I see we have no place to put images (to reference them in markdown doc) in our repo. What is you recommendation on this?

matklad (Feb 09 2020 at 13:40, on Zulip):

https://github.com/rust-analyzer/rust-analyzer/issues/567

std::Veetaha (Feb 09 2020 at 13:40, on Zulip):

ахаха

matklad (Feb 09 2020 at 13:40, on Zulip):

ога :-)

std::Veetaha (Feb 09 2020 at 14:43, on Zulip):

I am getting a random EBUSY error with this on windows, sometimes it appears, but other times not. This is very hard to debug... It happens when we already downloaded the binary, and run ./ra_lsp_server-windows.exe --version
Does anyone have any ideas?
https://user-images.githubusercontent.com/36276403/74103894-85125d80-4b58-11ea-8125-2a9c1dab34f5.png

matklad (Feb 09 2020 at 14:44, on Zulip):

What's the return code/stderr after spawing?

std::Veetaha (Feb 09 2020 at 14:44, on Zulip):

null =)

std::Veetaha (Feb 09 2020 at 14:45, on Zulip):

The syscall failed and didn't spawn anything I guess

matklad (Feb 09 2020 at 14:51, on Zulip):

what's the value of .error?

matklad (Feb 09 2020 at 14:51, on Zulip):

https://nodejs.org/api/child_process.html#child_process_child_process_spawnsync_command_args_options

matklad (Feb 09 2020 at 14:52, on Zulip):

error <Error> The error object if the child process failed or timed out.

std::Veetaha (Feb 09 2020 at 14:53, on Zulip):

Its logged on the screenshot,

std::Veetaha (Feb 09 2020 at 14:53, on Zulip):

{ "code": "EBUSY", "errno": "EBUSY", "syscall": "spawnSync <path_to_binary>" }

Edwin Cheng (Feb 09 2020 at 14:54, on Zulip):

My wild guess: What if you disabled await fs.chmod(installationPath, 0o755); // Set (rwx, r_x, r_x) permissions ?

std::Veetaha (Feb 09 2020 at 14:54, on Zulip):

I see I cannot reproduce the error now...

std::Veetaha (Feb 09 2020 at 14:55, on Zulip):

I can try conditionally disabling chmod, though it is not reproducing now (

Edwin Cheng (Feb 09 2020 at 15:01, on Zulip):

Maybe cause by Windows Defender ? :thinking:

std::Veetaha (Feb 09 2020 at 15:01, on Zulip):

No, this is gone, it doesn't appear... ;(

std::Veetaha (Feb 09 2020 at 15:15, on Zulip):

Rebooted my laptop, reinstalled everything from scratch, and no more error... I guess if it was Windows Defender or any other thing it saved some state and doesn't try to prevent the binary from running anymore

std::Veetaha (Feb 09 2020 at 18:01, on Zulip):

@matklad I see we ship .vsix file via GitHub releases. While I am amending the docs, should I mention this in Installation from prebuilt binaries chapter?

std::Veetaha (Feb 13 2020 at 22:43, on Zulip):

@matklad , may I ask you to elaborate on the chosen versioning scheme? I am now working on versioning the installed prebuilt binary, so this is actual. Do we stick with YYYY-MM-DD?

matklad (Feb 13 2020 at 23:19, on Zulip):

Ideally, we should not care names and just pick the chronologically latest
release.

It might be prudent to filter out names with nightly though, for fwd compat

std::Veetaha (Feb 13 2020 at 23:23, on Zulip):

nightly as suffix or just as a substring at any position?

matklad (Feb 13 2020 at 23:24, on Zulip):

as a substring would be better I think

Jeremy Kolb (Feb 14 2020 at 03:52, on Zulip):

My only input here is that YYYY-MM-DD defeats the default of 0.1 from a source install so vscode automatically stomps cargo xtask install

matklad (Feb 14 2020 at 09:45, on Zulip):

@Jeremy Kolb do you now any docs about versions for VS Code?

matklad (Feb 14 2020 at 09:46, on Zulip):

let me just try this with -dev

matklad (Feb 14 2020 at 11:05, on Zulip):

Ok, even setting version to 0.2.0 doesn't not prevent VS Code from auto-updating. Quick googling hasn't revealed the proper solution here. I wonder if folks might know a workaround?

matklad (Feb 14 2020 at 11:06, on Zulip):

Also, a meta question: is there a Zulip / Discourse instance for developers of VS Code plugins? I feel I can make use of an area for shouting questions at people :)

bjorn3 (Feb 14 2020 at 11:10, on Zulip):

From the readme: https://gitter.im/Microsoft/vscode

bjorn3 (Feb 14 2020 at 11:11, on Zulip):

Not sure how relevant it is for ext authors though

std::Veetaha (Feb 14 2020 at 11:13, on Zulip):

But @Jeremy Kolb , you mentioned that turning off auto-updates fixes this...

matklad (Feb 14 2020 at 11:14, on Zulip):

Well, it's a bit like saying that not using VS Code fixes it :)

Or can you disable auto-update for a specifc extension?

std::Veetaha (Feb 14 2020 at 11:14, on Zulip):

I'm not surprised that vscode sees that the latest version doesn't match the installed one and tries to update

matklad (Feb 14 2020 at 11:15, on Zulip):

But how it determines "the latest"? Like, I've build extension today, with a higher version number, and it still isn't considered the latest

std::Veetaha (Feb 14 2020 at 11:21, on Zulip):

I think only Stackoverflow is to the rescue here...

std::Veetaha (Feb 14 2020 at 12:52, on Zulip):

FYI: regarding the stream.pipeline(). My report to nodejs team brought some fruits. It is confirmed to be a bug in filesystem core module

matklad (Feb 14 2020 at 13:07, on Zulip):

And this actually boggles my mind. Like, how is it possible that a piece of core infrastructure fails to properly close the file before signalling that the file is closed?

std::Veetaha (Feb 14 2020 at 13:15, on Zulip):

It's piece of cake. One lecturer in our university, who is very into NodeJS community told us that the nodejs core is very convoluted and messy. There are a cases when people write some core module, but then leave the project and noone knows how that code functions thereafter, even new PR to that codebase may dangle for a long while because people just can't review them properly.

Jeremy Kolb (Feb 14 2020 at 13:18, on Zulip):

@matklad I did some digging yesterday and didn't turn anything up. I half expect it's something weird like injecting "enableProposedApi: "true" in the json file.

matklad (Feb 14 2020 at 13:28, on Zulip):

I think the reason is much simpler

matklad (Feb 14 2020 at 13:28, on Zulip):

xtask install is hard-coded to install file named rust-analyzer-0.1.0.vsix

Jeremy Kolb (Feb 14 2020 at 13:29, on Zulip):

that would make more sense

Mr Smeet (Feb 14 2020 at 13:47, on Zulip):

I try fix it. https://code.visualstudio.com/docs/editor/extension-gallery#_extension-autoupdate

matklad (Feb 14 2020 at 16:34, on Zulip):

matklad said:

xtask install is hard-coded to install file named rust-analyzer-0.1.0.vsix

fixed that

std::Veetaha (Feb 14 2020 at 16:39, on Zulip):

I'd suggest to also describe why the version in package.json must be bigger in the comment

matklad (Feb 14 2020 at 16:43, on Zulip):

https://github.com/rust-analyzer/rust-analyzer/blob/master/editors/code/package.json#L8

matklad (Feb 14 2020 at 16:44, on Zulip):

the exact why is in the commit message, which is reachable via git blame.

std::Veetaha (Feb 14 2020 at 16:51, on Zulip):

Yeah, not a fan of git blaming tho

matklad (Feb 14 2020 at 16:53, on Zulip):

I actually think that comments in commits are more valuable than comments directly in code, as they don't bit rot as badly. See also https://mislav.net/2014/02/hidden-documentation/

Jeremy Kolb (Feb 14 2020 at 17:04, on Zulip):

@matklad That version change fixed my issue!

Mr Smeet (Feb 14 2020 at 17:22, on Zulip):

matklad said:

I actually think that comments in commits are more valuable than comments directly in code, as they don't bit rot as badly. See also https://mislav.net/2014/02/hidden-documentation/

crutches =)

matklad (Feb 14 2020 at 17:25, on Zulip):

@Mr Smeet I would refrain from making comments which contain purely value judgment, without any substance of actual discussion: significant number of people participate in this zulip, and such comment spend time of some number of those people, and also risk provoking unproductive discussions.

Mr Smeet (Feb 14 2020 at 17:29, on Zulip):

matklad said:

Mr Smeet I would refrain from making comments which contain purely value judgment, without any substance of actual discussion: significant number of people participate in this zulip, and such comment spend time of some number of those people, and also risk provoking unproductive discussions.

Ok, sorry.

std::Veetaha (Feb 14 2020 at 18:05, on Zulip):

Wow

matklad (Feb 14 2020 at 18:11, on Zulip):

Sorry if I am to abrasive here, I should have expressed that in a friendlier way :(

I just think that's it's important to try to keep discussion on topic, and to minimize pings and notifications; one2many amplification is a significant issue, imo

std::Veetaha (Feb 14 2020 at 18:11, on Zulip):

That's a good wow, thank you for keeping the propper atmosphere in discussions

matklad (Feb 14 2020 at 18:12, on Zulip):

yeah, it's just that it is exactly a "value judgement without actual content for discussion", which pings me ;)

Last update: Jun 07 2020 at 09:40UTC