LSPDocument needs to be in a scide_vscode folder.
hjh
Yes, obviously one of the essential features of lsp is to be “live”. I didn’t question it.
But wouldn’t it be possible to have two sclang processes? (I didn’t mean to suggest using another language for lsp). That’s what I thought when writing the first message.
@jamshark70
@semiquaver
Thanks!
I saw the file “Document.sc” in the “scide_vscode” folder after installing Quark in vscode by running “SuperCollider: Update LanguageServer.quark”. I mistakenly thought this file was “LSPDocument.sc”.
After removing the path to this quark in the SC-IDE preferences and its folder using “Files”, I reinstalled it by running “SuperCollider: Update LanguageServer.quark”. Now the folder “scide_vscode” does not exist.
This is strange because I did not change the Quark folder after each installation!
The first time it seems to install the master version of LanguageServer.quark; the second time it seems to install the development version of LanguageServer.quark.
I see… I just had a try.
There are two possible fixes (which I just noted in github as well):
- Move the LSPDocument class definition into scide_vscode.
- Or, guard the
implementingClass_call:Document.tryPerform(\implementingClass_, LSPDocument);. (EDIT: This could turn out to be problematic though, after the proposed refactoring.)
Easy fix…
Also prko is correct that, currently, “update language server quark” is fetching the development branch, which doesn’t have scide_vscode/. Manually doing git checkout master resolves this (though, eventually, users shouldn’t have to do this by hand).
hjh
1 Like
Trying to install via virtual machines on the same machine confused me.
I tested on Ubuntu, MacOS and Windows with SC3.14.0_dev. Some problems have been solved, but some problems remain. On Windows, the results I reported with images are the same.
Yes, the fix is relatively simple! Thanks!
I now also think that the vscode-sc extension could replace the SC-IDE if some minor issues are fixed. I appreciate @scztt and I am sorry that I am just using what you have made for us and asking for more features without helping you solve these problems. What you are doing is beyond my capabilities, unfortunately…
1 Like
Yes, definitely there could be two. Right now, since the “active” process owns basically all the data we need, a second process wouldn’t be doing anything other than basically proving a proxy for the active process. Splitting it in two wouldn’t even get you more stability in case of e.g. a crash or compile error (at least not without work), since the Language Server sclang process would have the same disconnection problems as vscode has now. Probably the time to make the split is when we can get the full parse tree and a symbols database as data, rather than just having to introspect it from the running sclang itself.
What it might give you, though, is a response to introspection requests that wouldn’t interfere with musical timing in the primary sclang process. Since the sclang interpreter isn’t preemptive, requests from vscode could conceivably block musical threads in the interpreter, which is undesirable. The blockage is likely to be short and probably would never be noticed – but it could be eliminated if requests go to a second process. OSC messaging could sync Pdef etc types of keys.
hjh
Until you can perform SOME meaningful amount of non-trivial work in the language server sclang instance, two processes is just pushing the problem around. There are some expensive calculations that COULD be pushed to a second process now, but there are two things holding me back:
- The language server still has reliability issues that affect everyday usability. Another process increases the potential for issues here, so I’m hesitant to introduce until reliability is improved enough so that things work seamlessly for a “normal” SC user, in “normal” usage scenarios.
- 95% of the performance cost of the LSP can be fixed by caching to avoid duplicate work. This has to be done regardless of whether we have a second process or not, so this is where I’ll focus energy for now.
- I have no performance metrics whatsoever, so I have no idea whether LSP stuff is even remotely slow enough to affect musical timing. My first priority is to add some performance metrics to the language server, to get a picture of which operations are expensive enough to look at optimizing.
FWIW, the language server has a VERY loosely organized LSPDatabase class. This is an early attempt to factor out requests for data that (a) have the potential to be cached, and (b) could be performed against a serialized data set rather than the active sclang process (e.g. things like searching the list of methods). As it evolves, I would envision a setup where all of the LSP runs out of process, and LSPDatabase is an abstraction for a connection to both an “active” sclang process, and any other sources of data required for the LSP (e.g. a parse tree).
1 Like
FWIW I fully agree that a second process for the language server is, now, the sort of premature optimization that Knuth called “the root of evil.”
In principle, time-critical applications should avoid time-unbounded operations in high priority threads. In sclang, the concern is orders of magnitude less severe than in scsynth – server messaging latency can absorb interpreter jitter up to a couple hundred ms in typical use (though we don’t know how many users are running with significantly lower s.latency) while scsynth has hard targets on the order of 10 ms (or less, for live fx use). So it’s probably not a big deal in sclang, and the vscode-sclang environment is currently experimental, so it’s way too early to consider a big architectural change like a second process.
The one that gives me a little pause is the document formatter: synchronously passing large (unbounded) strings to the sclang-format process, and synchronously reading them back (where sclang-format is probably very fast, but sclang is blocking for the reply, so it needs to be very very very fast). One suggestion you had made to me is to enable “format on type” in vscode – which, from a user interaction perspective, is fine – but does vscode then invoke the formatter for every character typed? I’d hope that vscode would wait for a pause, but I don’t know if it does or not. If so, then I’d take it upon myself to do those benchmarks since that seems potentially heavy.
But that investigation would be some ways down the road (and FWIW I haven’t even been able to build sclang-format yet). To be clear, I’m not arguing that this is a fatal flaw – I’m just considering potential risk areas, to check carefully later.
hjh
Note that this is only applies to sequencing. When playing a live MIDI instrument, you really don’t want sclang to block for dozens or hundreds of milliseconds. Now, in most cases you wouldn’t type code while playing an instrument. However, I can think of cases where you’d want to live code while another musician is playing a MIDI instrument.
So we should indeed be careful about blocking the sclang interpreter for possibly unbounded durations.
I’ve got a local branch of sclang that’s doing non-blocking IO to interact with the formatter - so this is at least in theory solveable (getting this code into SuperCollider develop will be a journey, as it probably should be part of a larger refactoring of pipe code). In practice, it may be better to have vscode invoke the formatter directly - I view. the sclang wrapper around the formatter as more of a fallback for LSP clients that aren’t set up to connect to the formatter directly.
Cool, yes, I agree that 1/ it’s better not to involve sclang in the code formatter and 2/ a non-blocking Pipe would be a very very welcome feature!
hjh
BTW: Here are a couple of color customizations that make VSCode less unpleasant to look at (“workbench: color customizations” settings, and add into settings.json):
"workbench.colorCustomizations": {
"editorBracketMatch.border": "#233843",
"editorBracketMatch.background": "#434e20",
"editor.lineHighlightBackground": "#1B2B34"
}
VSCode’s default preference for outlines highlighting the current line, and matching brackets, I found to be visually noisy and a major turnoff. Took a bit of searching to find how to change that.
"editorBracketMatch.background" is a tough one to tune: too dark and you can’t see it; too light and it obliterates the bracket itself. This color is maybe OK but I’ll probably tweak it later.
hjh
Yes. But, for example, the same words that are highlighted, so you can edit them all at the same time, if applicable. I also find it a bit annoying sometimes.
speaking of colo[u]rs: I’ve commented on a bug, but I’m not certain it is not a meatware issue of yours truly… when I cmd-shift-d a Ugen to get its ref, it always works, sometimes the browser’s background it dark grey, sometimes white. That I can live with although I’d like to understand why.
another much bigger issue. As I click a link in a helpfile, very frequently the page loading is white and empty.
In both cases, is it me the problem? if so any pointer is welcome
Just a little overview of color related bugs, both in Documentation and otherwise:
- Syntax highlighting colors are determined by the
supercollider.tmLanguage.jsonfile. - You can see WHY something in the editor is colored the way it is by running the
Developer: Inspect Tokens and Scopescommand, and then moving the cursor to the code in question. Thetextmate scopesvalue should correspond to something in thetmLanguagefile, and the foreground color is from your theme (you can see the details of this by runningDeveloper: Color Theme From Current Settings). - Compare SuperCollider highlighting in your theme to that of another language, e.g. Python or Javascript. If something in sclang is being highlighted in a way that seems inconsistent or weird, see if there’s a better TextMate scope to use (this is easy-ish to change in the tmLanguage file). If you feel at all hacker-y, changing the tmLanguage file to find a better TM scope is easy, and making a pull request for a positive fix would be very helpful!
- If the highlighting is simply misunderstanding the sclang code (e.g. it’s highlighting isn’t just a wrong color, it’s understanding symbols incorrectly), it’s probably a problem the regex strings in the tmLanguage. Fixing these is a fun hacky evening project, but also tbh very annoying - I’m happy to take PR’s on this but I don’t blame you if you get frustrated.
- Documentation color is a pain in the ass… The
frontend.cssfile maps css selectors for the SuperCollider documentation to colors in the VSCode theme, so the docs match the theme. The vscode colors (things like--vscode-sideBarSectionHeader-foreground) correspond to the colors in your theme (again,Developer: Color Theme From Current Settingswill show these). They’re all prefixed by--vscodeand dots are converted to-. - I’ve spend VERY little time mapping sclang documentation colors to theme colors. If you see parts of the documentation that don’t match your theme very well, I would love it if you can experiment with the
frontend.csscolors to see if you can find a better option. TheOpen Webview Developer Toolscommand can be helpful here, as it gives you a dev panel for the documentation, which should let you live-edit the CSS. Please try this with a few different themes to make sure the change is legible in a general way. - Code that is displayed in the sc documentation is even worse - SCDoc uses a javascript code component that has it’s OWN syntax highlighting. Ideally, I would set the highlighting of this code panel to something that matches your vscode theme, but I haven’t gotten around to this. If someone figures out a good way to do this, it would be very helpful. I don’t think it’s hard, probably just digging in the documentation a bit.
1 Like
Probably this is not a you problem. Let me know a few specific links in the documentation that result in a white page? Or, if you want to try debugging the vscode plugin yourself - the documentation is literally running on a locally hosted web server, specified in help.ts in the launchServer function. A breakpoint on line 231 should let you see what the HTTP request from the documentation is, and maybe get a clue why it’s failing and resulting in a blank page.
I figured out why this is the case (at least for a couple of cases I am having), though I don’t know the solution. It seems it is because the html file for the help doesn’t exist and the VS Code version of SC doesn’t automake it for you. Weird.
I was making a help file this morning. The help didn’t work - white screen as described by @tremblap above. I opened SCIDE, looked up the help, and it worked. Went back to VSCode and it worked. I had been having the same issue with FluidLabelSet in VSCode. Went into IDE, opened the help, now it is all good in VS Code. In both cases the HTML file didn’t exist in the Help directory until loading in the IDE. What might be the easy fix for this in VSCode? Is there a function that isn’t being run properly?
Sam
just a quick note that I see this in SCNvim when using the String:help method - I get a “file does not exist” or some such error. Completely intermittent, not sure why it works sometimes.