Add visibility to SymbolInformation

I propose an addition to SymbolInformation that allows an LS to report the visibility (private, protected, public) to the client:
interface SymbolInformation {
  visibility?: Visibility;
}
enum Visibility {
  Private = 1,
  Protected = 2,
  Public = 3
}

A client can choose how he uses that information:

it could display an icon that indicates a symbol is private
after getting a list of symbols, it could allow the user to hide/show only public symbols

The same property could get added to CompletionItem.
I think private, protected and public should cover all languages, or are there more modifiers in some languages?
The enum should be structured to allow something like
if (symbol.visibility >= Visibility.Protected) {
  // symbol is at least protected or public
}

I think private, protected and public should cover all languages, or are there more modifiers in some languages?

In Java there is package visibility, when there is no access modifier used.

@kaloyan-raev what do you think would be best to represent package visibility in the proposal?

Like this:
enum Visibility {
  Private = 1,
  Package = 2,
  Protected = 3,
  Public = 4
}

Better put "public" first, as it's the base case - all other a kinds of restricted.

Why does this have the 4.0 milestone? This is not a breaking change

@wiz public is the highest visibility, so it should be the highest number.

So, the visibility set is closed as no further levels can be added below "Private" and above "Public"? That would be unfortunate for non-Javy languages...

I'm confused, below private and after public is exactly where you could still add further levels. And you can add more levels in major protocol versions. We can also decide to leave more slots open in between. But if you have more visibilities in mind, the time to propose them is now :)

I'm confused, below private and after public is exactly where you could still add further levels.

That would ruin the pretty ordering we have here. Adding Whatnot = 5 would break that "public is the highest visibility" rule. Adding Something = -10 would add confusion to enum-styled constants.

But if you have more visibilities in mind, the time to propose them is now :)

I propose leaving some wiggle room for the future additions while keeping confusion to the minimum.

C# has 5 levels of accessibility: https://msdn.microsoft.com/en-us/library/wxh6fsc7.aspx, also in this case the accessibility lattice is not a sub lattice of the integer lattice so you can't do simple integer comparisons to check accessibility.

C# either has or is going to get a 6th level of accessibility, 'proternal', accessible only to things that derive from the type AND are in the same assembly. (compare with 'protected internal' which is accessible to things that either derive from the type OR are in the same assembly.)

One concern I have is to avoid clutter. Imagine you're writing in a language where almost everything is private, apart from the few methods that are explicitly annotated with the modifier export. What would an Outline view look like then? Would it include a 'private' glyph next to every single entry? Or would it leave the entries unadorned by default, and only stick a 'public glyph next to the ones that have the export modifier?

Up to the client to decide. It could grey it out if it's private, it could show an icon, it could just have checkboxes to filter like "only public". The protocol shouldn't make any UI decisions.

My point is, it probably shouldn't be up to the client to decide. Only the language knows what is the default (and hence which one should be shown with unadorned icons).
For instance: in Flow, if you write function foo() then it is private. If you adorn it with a keyword export function foo() then it it is public. I therefore expect my editor to show things unadorned by default, and only adorn them (with a glyph for public) when the developer has adorned their code with the export keyword.
In C# the accessibility of things is confusing and there are lots of common options, so I expect every single declaration in C# to have a glyph indicating accessibility.

I think @felixfbecker says it's up to the client to decide how to render once we know the visibility, and @ljw1004 says is that the default visibility is not desired. Both are fully compatible.
@ljw1004 In the example you give, then the foo symbol should have a private visibility flag when returned from LS. In general, if we go for it, the spec should mention that setting visibility is highly recommended and not allow a "default" visibility that doesn't mean much to the client as "default" is a language-specific concept.

I'm with @ljw1004 here. How would a generic client know that for language X, it should not decorate private modifiers, while for language Y it is the public ones? Only the LS knows.
I agree that the symbol information should contain all available data. I believe that the problem arises from conflating the symbol information with selecting a glyph - the "icon" value can't be computed reliably from the SymbolInformation, so an optional field should be provided by the server when needed.
The "icon" set can be more open than the "kind" one, so maybe this will address even https://github.com/Microsoft/language-server-protocol/issues/129.

This could be addressed more generically with #889. The discussion in microsoft/vscode#23927 indicates any modifier, including visibility/access, could be accommodated.

As discussed and concluded at microsoft/vscode#23927, a namespace SymbolTag was merged.
Though SymbolTag has ability to indicate modifiers, I don't know how to add language specific definitions.
https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/

It seems the LSP spec proposes a SymbolTag  for DocumentSymbol details like deprecation, visibility and more. Shouldn't the spec contain more SymbolTag  values than just deprecated? I thought of values like visibility tags common for most languages (private, package-private, protected, public,...) and maybe even more pre-defined tags (e.g. synchronized, volatile, transient).
My original request comes from a requirement on LSP4E, CDT LSP, and clangd discussed here.

I've prepared a proposal for additional SymbolTag values in PR #2003. Could someone please do a review?


Shifted sorting Algos in correct folder

This PR aims at solving #360. Moving sorting Algos to Sorting folder.

Please star this repository to show your support, in the meantime I am reviewing your code.

@amritansh22 Did it!


CycloneDX .json Version 1.5 error

I ran the following on a CycloneDx 1.5 json file:
from lib4sbom.parser import SBOMParser
sbom_parser = SBOMParser()
sbom_parser.parse_file("...")
print (f"SBOM type {sbom_parser.get_type()}")
sbom_packages = sbom_parser.get_packages()
sbom_relationships = sbom_parser.get_relationships()
It seems like the parser can't properly detect the format type and thus, the parser just returns empty lists. When I ran the same code on a CycloneDx 1.4 json file for the same project, the parser was working. I've attached the files I used below. There is no difference between the files besides the lifecycles section in metadata and specVersion at the very top. I also ran the same code on a  CycloneDx 1.5 xml file for the same project and that worked fine (though GitHub doesn't let us upload xml files).
If this issue is a case of user error, please let me know lol. I used the maven plugin to generate these sboms from the project's pom.xml file.
bom_1.4.json
bom_1.5.json

@howellx I have seen this before and is normally to do with the metadata processing. I have fixed some issues in the latest version (which will become version 0.7.2) but will check that your SBOMs validate.

@howellx The 1.5 version is using a deprecated Tools specification in the metadata. I have improved the checking so both 1.4 and 1.5 files should now parse correctly.


Feature Request: Handling white-spaces as first class citizen in textOnlyMode

Description:
I recently started to use Ractive as a template engine in a project to generate the necessary C header and source files regarding to user supplied data.
Ractive might not be the intended tool for that purpose, that's okay. However, I would love to use Ractive for this type of tasks in the future as it's both familiar to me and already the part of the rest of the system. I guess there is no harm to open a feature request for this one.
Versions affected:
All?
Platforms affected:
All?
Reproduction:
Here is the reproduction for my intention.
Template
#define hello there
{{#if hey}}
    #define hi 5
{{/if}}

{{#each myObj}}
    {{#with myObj[@key] as val}}
        #define {{val.x}} {{val.y}}
    {{/with}}
{{/each}}

Expected
#define hello there
#define hi 5

#define foo bar
#define baz qux

Observed
#define hello there
    #define hi 5

        #define foo bar

        #define baz qux

Except for the whitespace on empty lines, about which I'm not sure, the indentation on lines with text matches exactly what's in the template (think white-space: pre). If you wanted to only preserve line breaks but no indentation (like white-space: pre-line, it would only make sense with a separate config option.

Applying a white-space: pre-line style resolves the prefixed whitespaces, but absolutely interferes with indentation-sensitive parts. Here is what I mean: playground
Template
#define hello there
{{#if hey}}
    #define hi 5
{{/if}}

{{#each myObj}}
    {{#with myObj[@key] as val}}
        #define {{val.x}} {{val.y}}
    {{/with}}
{{/each}}

# This section is Python-code
if foo:
    bar = baz
    {{#each myObj}}
        {{#with myObj[@key] as val}}
            hey{{@key}} = {{val.x}}/{{val.y}}
        {{/with}}
    {{/each}}

Expected
#define hello there
#define hi 5

#define foo bar
#define baz qux

# This section is Python-code
if foo:
    bar = baz
    heya1 = foo/bar
    heya2 = baz/qux

Observed
#define hello there
#define hi 5

#define foo bar

#define baz qux

# This section is Python-code
if foo:
bar = baz

heya1 = foo/bar

heya2 = baz/qux

Proposal
What I propose is:

Ractive will have a indent:  option for user defined indentation.
Any block ({{#if}}, {{#each}}, {{#with}}, ...) will subtract that configured number of whitespaces for its child nodes.
Blocks ({{#if}}, ...) will not introduce a newline.

@evs-chris is it a wontfix?

I don't think it's a wontfix, as I think it definitely makes sense to allow more control over whitespace. I won't be able to implement it for a while though, unfortunately.

@evs-chris Ping?

I was kinda thinking something more along the lines of https://shopify.github.io/liquid/basics/whitespace/, but it would probably make sense to have a mode that just strips out the lines with only block tags. I'll poke at the parser a bit and see what that would take.

That'd be very nice. By the way, I saw another project, modm.io, that uses Jinja as the initial templating stage, which IMHO proves that this "using a full-blown template engine in front of a regular compiler" approach has a valid rationale.

I've added some experimental support for something along these lines on edge. It's a sort of extension of preserveWhitespace, which is required because otherwise consecutive whitespace is collapsed in the template (where allowed i.e. almost everywhere), since HTML doesn't really care in most cases. It gives you manual control of collapsing the line contains section tags by adding a - before the end of the tag e.g. {{#if foo -}}. Alternate blocks (else, elseif, etc) are also handled based on the flag on the opening tag.
It's not particularly easy to describe, but this example in playground will hopefully make it clear. There's also a test case.
This doesn't cover automatic handling of indentation, and I don't think it reasonably could. That leaves you nesting the sections with whatever indentation but leaving the content where it should appear on its own line. Let me know what you think.

Well, this example outputs what's expected. Awesome!

This doesn't cover automatic handling of indentation,

Thinking again, not handling indentation (leaving it as is) is kind of a "feature". I like it more. We can easily determine the resulting indentation of a "code" without tracing its surrounding blocks. Now I vote for "leave indentation handling as is".
However, the - character... Is it too hard to remove that dependency? It seems annoying. We could perfectly use it, okay, but removing the need for - sign would be awesome.


2 ➡ 3 (as of 2020 03 27)

This pull request was originally opened at BitBucket but it couldn't be merged in time.
The main issue it has was that it was taking a long time to compile, which is solved by https://github.com/ignitionrobotics/ign-physics/pull/41, so I think we should wait for that pull request to be merged and released before merging this one.

This seems to be missing the AxisAlignedBox component, which was merged into ign-gazebo2 here.
Should there be an AxisAlignedBox in this PR?

This PR is not a complete 2->3 port. I'm breaking it into parts because there's a lot to migrate. Currently we're blocked by the ign-physics PR.


SDK Access

The link to the Philips open pathology portal seems to be dead, and if one goes to the Philips knowledge centre to download  the SDK, one finds it can no longer be downloaded on Ubuntu (or probably any linux flavour) or mac os (even though this used to be possible). I guess this means people in these camps can no longer use this package?
Is it possible to include the SDK in this repo, or for someone to get in touch with Philips and request the website is fixed? It has been like this for (at least) several months.
I would be super-grateful if the SDK becomes available again, or if someone could advise, so we can use the code in this very useful repo.
Thank you!

As much as we would like to offer the Philips SDK for download its licensing terms explicitly forbid redistribution. Through some of our partners we have been in active dialogue with Philips for some time trying to get the current scenario resolved; unfortunately it is out of our hands. I would recommend that you contact Philips directly with your concerns..
See also #33.

Contact details and the full Philips SDK site maintenance bulletin:

The Philips Open Pathology Portal website is undergoing maintenance.
Meanwhile customers can download the Philips Software Development Kit and Pathology Image File Viewer from Incenter (https://philips.mizecx.com/login.html), using the Guest User Login to access the links to the software.
For support please send an email to "Customer Services"<EMAIL_ADDRESS>with the subject 'I need support / have a question'
Please include the following details to help us respond efficiently to your query:
Your Name:
Email address: (customer contact if reporting on behalf of one)
Contact telephone number (optional):
Product (Software Development Kit/Pathology Image File Viewer/Other):
Brief Description:


Agario socket error

server.js:75
        blob.x = data.x;
               ^

TypeError: Cannot set property 'x' of undefined

I'm getting this error on the agario socket challenge.

Okay, I had a look at this and this can only happen in a few situations:

The socket's update event occurs prior to the start event. As far as I know, this should never happen.
The socket's blob object is removed at some point. This cannot happen in the current code as there is no removal of blobs.

The current code in the repo appears to work fine for me.
Did you make any changes to the code at all?


TUNE 228: Search and language for homepage

@projectmushroom please review
Search and languages is only on the homepage