Questions about privacy-sensitive

How is it determined what is privacy-sensitive?
Is it a good idea to prompt users for exposing privacy-sensitive text fragments to the page? I think most users would not understand what is being asked, which makes me think it's a bad idea to prompt.

How is it determined what is privacy-sensitive?

The easiest solution is to simply maintain a well-known list of privacy-sensitive directives, pre-populated with the sole entry, text.

I think most users would not understand what is being asked, which makes me think it's a bad idea to prompt.

I don't think that users should be prompted either. I've left the option to prompt in this spec to better serve the needs of more privacy-conscious browser vendors.
A simpler option could be to not require a permission prompt but instead require secure origins for includeSensitive.
I understand that some PrivacyCG members would prefer if scroll-to-text text entries were protected. As it stands currently, there are no actual effective privacy boundaries in the scroll-to-text specification. If we can all agree that additional privacy boundaries are not necessary, I will change the includeSensitive part of the spec to require secure origins instead of a permission prompt.

OK. I think a secure context is not sufficient to expose the text directive, since we don't trust the page that has the text directive the honor the user's privacy, regardless of whether it's secure context or not. If text is always sensitive and we don't want to prompt, then this API just adds complexity with no benefit (until other directives are added, at least).
If anything, I think an opt in to reveal the text directive needs to be made by the page that created the link. (A possible workaround today would be to duplicate it in the query string, though may not be compatible for all sites.)
So then a search engine could use the text fragment feature without the "reveal" opt-in (as today), but other use cases (e.g. share link on social media) can use the opt in. But I'm not sure the extra complexity is worthwhile, and there's more risk that sites that really shouldn't opt in accidentally (or deliberately) do.

Note that the text directive is currently already exposed, available either via CSS tricks (e.g. temporarily use a huge font-size & measure scroll position) or through browser quirks with performance.getEntries().
A mechanism for the link creator to 'reveal' the search text sounds interesting, although I have no idea how that would look in terms of an API.
Personally, I am championing this spec primarily for the non-sensitive 'custom directives' use case and don't intend to use the 'custom scroll-to-text' use case myself. If push comes to shove, I can pare down the spec to only support the custom directives use case which shouldn't have any privacy concerns.

With scroll position you can get what the start of the match is but not the full text directive. Hopefully Chromium can fix the performance.getEntries() bug.

It's a bit difficult to reason about privacy of text directives, since hash fragments are an old feature and text-fragment et al are new, which means that browsers that don't support them would default to exposing them to the page.
Whether a directive is private or not is a great question, but perhaps it's not the browser's role to enforce it, but rather the referring site's ("the search engine" if we're talking about search terms)? To some extent, this is not very different from sending ?search_term= to the page. I would say the same about prompts etc, this should perhaps be part of the search engine's terms and conditions.
We could fix the performance.getEntries() quirk but I think the correct fix would be to expose the text directive to document.URL as we expose anything else after the '#'.

It's a bit difficult to reason about privacy of text directives, since hash fragments are an old feature and text-fragment et al are new, which means that browsers that don't support them would default to exposing them to the page. This is what's happening now and people are starting to depend on this feature for all sorts of things.

Right, but a search engine wanting to hide the search terms from the final page can feature-check for text fragment support before using it (assuming the text fragment is not exposed). If it's always exposed, search engines need to choose between using text fragments and hiding search terms.

Whether a directive is private or not is a great question, but perhaps it's not the browser's role to enforce it, but rather the referring site's ("the search engine" if we're talking about search terms)? To some extent, this is not very different from sending ?search_term= to the page.

Yes, indeed.

I would say the same about prompts etc, this should perhaps be part of the search engine's terms and conditions.
We could fix the performance.getEntries() quirk but I think the correct fix would be to expose the text directive to document.URL as we expose anything else after the '#'.

IIRC there was also a web compat reason for not exposing the fragment directive in existing APIs (some sites use the hash for client-side routing or other).

It's a bit difficult to reason about privacy of text directives, since hash fragments are an old feature and text-fragment et al are new, which means that browsers that don't support them would default to exposing them to the page. This is what's happening now and people are starting to depend on this feature for all sorts of things.

Right, but a search engine wanting to hide the search terms from the final page can feature-check for text fragment support before using it (assuming the text fragment is not exposed). If it's always exposed, search engines need to choose between using text fragments and hiding search terms.

OK this is a good model. So I think my answer to your original post would be:

It should be clear using feature detection whether a certain directive is going to be consumed & hidden by the browser.
If a directive is hidden, it should be consistently hidden across all APIs.
Given that information, it's up to the page to decide whether to send that directive in links or not.

Alternatively the opt-in can be to hide the text fragment, e.g.
#:~:text=Something&hide-text-fragment-from-script

(naming TBD)

Alternatively the opt-in can be to hide the text fragment, e.g.
#:~:text=Something&hide-text-fragment-from-script

(naming TBD)

Not sure about this, but either way feature-detection is the key here in terms of privacy (as it gives the power to the referring site, which is the one responsible), and if we add a new sub-directive, feature detection needs to handle it.

How would a search engine use text fragments and also hide the search terms with feature detection (for browsers that support text fragments)?

Either we fix navigation-timing and we make it so that feature-detecting text-fragments also means that they're hidden,
or we opt-in for hiding them in addition to the text fragment itself like you suggested, and feature-detect that.

IIRC there was also a web compat reason for not exposing the fragment directive in existing APIs (some sites use the hash for client-side routing or other).

We actually want that behavior (hiding the fragment directives from existing APIs), as Transcend Consent functions as a psuedo-UA layered on top of existing sites. Currently our customers rely on this behavior to test our consent manager without interfering with their site's routing.

I am confused by several things in this discussion:

Feature detection is assuming that the client where the link is generated is also the client consuming the link. But links get copied & pasted. How does this work?

Good point.

Indeed, it seems to me it's not fixable without disabling scrolling, which would regress the user experience of the feature. (Pages can opt out of scrolling of themselves, but the referring page can't.) I have assumed that the difference in fidelity (i.e. being able to tell where the match starts vs being able to access the full text directive directly) is significant enough to keep hiding the text directive (without some opt-in).

In order to reduce user confusion, we can have a spec-suggested prompt description for browser vendors that choose to prompt for includeSensitive: true.
Something like "[website] wants to access in-page scroll-to-text search data"

Permission prompts is usually a last resort and there's already a prompt fatigue. I don't think it would solve anything TBH. Given the previous discussion I'm back to my stance here. I don't think we should hide the text fragment directive. It doesn't do anything for privacy or for preventing website breakage.

This behavior was introduced to prevent site-compat issues (see https://github.com/WICG/scroll-to-text-fragment/issues/15) due to colliding usage of the hash. We were less worried about the privacy aspects at the time since the text snippet already appears on the incoming page and the page can infer what's highlighted via scroll position. However, since then, some security-minded folks I've discussed this with have noted that the increased fidelity of the actual text is significant (e.g. a page could infer the user's search term on the search engine if they have the exact snippet). So I think we should keep the text fragment entirely hidden.
I'm weary of re-introducing the exact scenario we invented the fragment directive for. i.e. different parties start using the fragment directive for their own purposes and then break if an unexpected thing appears there.
@eligrey - IIUC your use case is that the link can include some extra data that a third-party (w.r.t. the site itself) component (widget, extension, etc) can make use of - is that right? Rather than changing the behavior in URL parsing/stripping, what about introducing a new directive meant to carry third-party but non-UA data? e.g.
https://example.com#:~:text=foo&external(vendor,property=value)

This could be parsed and stripped from the URL but could be exposed via an API like the one proposed here. This has the advantage that it's structured and could be vendor scoped so would be less brittle. e.g.
document.fragmentDirective.items[0] //opaque text directive with value hidden to script
document.fragmentDirective.items[1] //"external" directive with readable values

@bokand Your suggestions work for the 'custom directives' use case, but I also want to support 'custom navigate-to-text' logic e.g. to enable deep links in unconventional webapps like 2d/3d/xr web games.

sorry if I missed it - do you have more details on that use case?
Guessing that you want to implement a :~:text search that works on non-DOM text - that would require the webapp to cooperate (by implementing the actual search) so in that case I'm not sure why you'd need a text fragment/fragmentDirective at all...why not just pack the search term into a query parameter or ordinary fragment? Text directives were added to make this kind of use case work without the cooperation of the destination page.

This behavior was introduced to prevent site-compat issues (see WICG/scroll-to-text-fragment#15) due to colliding usage of the hash. We were less worried about the privacy aspects at the time since the text snippet already appears on the incoming page and the page can infer what's highlighted via scroll position. However, since then, some security-minded folks I've discussed this with have noted that the increased fidelity of the actual text is significant (e.g. a page could infer the user's search term on the search engine if they have the exact snippet). So I think we should keep the text fragment entirely hidden.

@bokand Do you have an example for this increased fidelity? I understand the theoretical problem but I struggle to think of a practical use-case and I think it would be good for the discussion (and the spec) to have one.
That being said, this proposal has both a fragment API and we need to clarify if we think it is acceptable to expose the text fragment. Currently, it is supposed to be hidden.
However, this proposal also has custom directives. For which the situation seems more confusing. Since they are custom, the UA has no options for determining if they are privacy sensitive. They might contain search terms, they might contain the user's address (to show local results) or the user's religion.
On the other hand, (and I think that is what @bokand is also saying), I do not understand the benefit of standardizing custom directives, the link source and link target have to agree on their meaning, therefore that meaning would have to be standardized and not just "custom".

Re:

Guessing that you want to implement a :~:text search that works on non-DOM text - that would require the webapp to cooperate (by implementing the actual search) so in that case I'm not sure why you'd need a text fragment/fragmentDirective at all...why not just pack the search term into a query parameter or ordinary fragment?

and

Since they are custom, the UA has no options for determining if they are privacy sensitive. They might contain search terms, they might contain the user's address (to show local results) or the user's religion.

Custom handling for the text directive should ideally re-use the same syntax. The point is to allow websites that have non-DOM text to be able to provide deep links to users while providing some privacy protections in browsers that choose to gate includeSensitive: true with a prompt. If I navigate to a link with a text directive on a device that can only handle basic HTML, the site can provide HTML, but if the device supports XR, why should the site have to use a vendor-specific directive to support search? Exposing the text directive in this manner provides better compatibility and consistency for sites that choose to support non-DOM browsing mechanisms (e.g. canvas) and vary their content based on device capabilities.
Custom directives should not be used for privacy-sensitive commands. I'm using 'custom directives' here to mean vendor-specific, and it does requires cooperation. Vendor-specific fragment directives are used today to layer psuedo-UA command directives on top of existing websites without interfering with existing routing logic.
One example is Transcend Consent Management, which supports using vendor-specific fragment directives to provide configuration of select options and signals. This tool acts as a psuedo-user agent that is installed by website owners to control web traffic and trackers in accordance with user privacy preferences.

I think I do not fully understand what you are trying to achieve here.
If the data is vendor specific anyway, and requires cooperation, why not just encode it in the hash whichever way you want?

Let's separate custom directives from the standard ones. Let's assume custom ones can be encoded by the cooperating origins.
Re standard ones, I can see the benefit of accessing them in script and specifically text fragment, for allowing a web page to implement their own scroll-to-text. It's a valid use case but we don't have a proper privacy mitigations for it. A prompt to the user is almost never a proper privacy mitigation and definitely not in this case IMO.

I'd prefer to drop includeSensitive entirely and simply expose all directives, although I am waiting for feedback from Apple as their official stance[1] is that access to text directives is a "privacy vulnerability" when exposed in the Navigation Timing API.
Source:

It appears that the latest Safari allows access to all these directives via the Navigation Timing API without a reload by the way. I am unsure if this change was done in relation to my Apple security report.

Note that the latest Safari now allows access to all these directives via the Navigation Timing API without a reload by the way. I am unsure if this change was done in relation to my Apple security report.
I have requested that all directives continue to be exposed in such a manner to help enable polyfilling a better API until it ships. Most major browsers engines currently have access and we can experiment here

I spoke to the webkit folks about this a few days ago. From what I understand they coincidentally have the same bug as chromium. Since this is deemed to be a privacy issue, it's likely going to be fixed in both Chromium and WebKit.

btw I think what you're doing here is really innovative and it saddens me that the privacy tradeoffs might break it. Hopefully in the future the web platform can find a privacy-preserving way to enable custom UX on top of the text fragment.

@bokand Do you have an example for this increased fidelity?

Different text directive values can produce the same scroll offset so inferring the targeted text from scroll position is at least probabilistic. Exposing it directly means the destination page can more reliably infer something about the referring page. e.g. on a search engine, a specific search query might have a 1:1 mapping to a generated text directive - a page could then use the text directive to reveal the user's search terms. I'm neither a search nor security engineer so I can't say how serious the consequences are here but that's the kind of push-back I've heard to exposing text directives.

If the data is vendor specific anyway, and requires cooperation, why not just encode it in the hash whichever way you want?

I think the idea here is that the URL could be modified/used by a third-party library or extension in which case it might conflict with a site's usage of the hash for routing and other purposes. Using the fragment directive guarantees that it won't.
That said, I think usage of the hash like this is becoming fairly rare so I'm not sure how important this is to solve.

Custom handling for the text directive should ideally re-use the same syntax.

I can see the benefit of this. IMHO the privacy issue here is definitely use case specific - search engines being maybe the special case. In general, the page already knows its own text so it doesn't seem to me to be revealing anything.
Perhaps a second cleartext= directive which is identical to text except it is exposed to the page could be useful? e.g. search engines (and any other sensitive use case) could continue to use text which is completely hidden but the more general case of  "look at this part of the page" could use cleartext which could be exposed to the page.
e.g. in the "Copy link to text" feature in Chrome, there's no reason I can think of that the text should be hidden from the page. It could use cleartext=

If cleartext was used for the same purpose (scroll-to-text), then wouldn't that also be privacy-sensitive as well? I think we just need to be okay with websites knowing explicit scroll-to-text queries that they can self-handle the queries.
We should wait for Apple's response here in this issue to see their latest take on the privacy implications of exposing the text fragment directive. They are still 'investigating' my security report and I imagine that we will get a clearer picture soon.

If cleartext was used for the same purpose (scroll-to-text/navigate-to-text), then wouldn't that also be privacy-sensitive as well?

Yes - that's the idea here. In most cases I think the text directive isn't sensitive but in a few (search, maybe others?) it can be. So this will be application-specific and I think it would make sense to let applications decide whether it needs to be strictly hidden from the page.
Note: in both cases we'd still want to strip it from the URL to avoid compat issues on pages using the fragment for routing (https://github.com/WICG/scroll-to-text-fragment/issues/15). In the cleartext case it'd be ok to expose it to the page via an alternate API though.

I feel like hiding parts of navigational directives from navigation targets fundamentally pushes site owners to collude on a common readable key that isn't hidden (e.g. #text=... instead of #:~:text=...). I think that fragment directives should be wholly unrestricted, just like query parameters.
Once Apple responds or makes a public comment for us to consider, I may drop the privacy-sensitive restrictions entirely from this WICG proposal, or close it if Apple makes their own proposal.
I expect Apple to make a public comment about fragment directive access in a timeframe which is known to me. Apple has asked me not to share this timeframe.


fix: update npm dependencies

Result of running npm update. Hopefully we will do these using dependabot in  the future, with weekly or bi-monthly updates.

Why is it "fix"? Nothing's broken.


Doc index update

In light of the new splash page site (https://xarray.dev), this PR updates the documentation site's index page to simply provide pointers to key parts of Xarray's documentation.
TODOs:

[ ] Get feedback on the content and layout
[ ] Update the Icon SVGs (these along with the layout were borrowed, in part, from Pandas).

cc @andersy005, @rabernat

The website looks incredible; amazing work!

Looks great!


Add appveyor and Windows test

Travis doesn't like branches being renamed, I guess...

very nice, :+1:

:+1: yes very cool


Update README.rst: use build_batch instead of build for creating multiple objects

Fix command for building batch objects

Closing this. Already handled by PR #159


MVT Layer spec v2?

Hi, I am seeing this error when rendering carto vector tiles with MapboxGL v0.31.0:

Just wondering if there is any plan to update the vector tiles.  They don't seem to have any rendering errors, just this warning popping up in the JS console.  Thanks!!

Sorry, this is unrelated to your error, but were you able to display line features? through mvt?  i get some funny looking lines, polygons and point features are showing correctly.

Also, were you also able to display attributes as well? (send attribute information along with the vector data)

(i also got this warning myself)

We have only been using points and polygons. I actually did try to set up a line feature and got a lot of weird noise on the screen (lots of horizontal lines styled the way I wanted my line feature styled)

This should have been addressed with carto/node-mapnik 3.6.2-carto.8 (Windshaft 4.7.1):
[
  {
    "version": 2, <<<<<<<<<<<<<<<<<<<<<<<<<<<
    "name": "field_shapes",
    "extent": 4096,
    "features": [
      {
        "type": 1,
        "id": 1,
        "properties": {
          "cartodb_id": 1,
          "data": 0,
          "status2": false
        },
        "geometry": [
          9,
          682,
          8178
        ]
      },
      {
        "type": 1,
        "id": 2,
        "properties": {
          "cartodb_id": 2,
          "data": 0,
          "status2": false
        },
        "geometry": [
          9,
          4096,
          4096
        ]
      }
    ]
  }
]


add imageData hint parameter

Fixes #4

I think it's better not to calculate channels and bits inside the library, since it might not be an RGB image.
Better to just convert JavaScript objects to (iiibiiay).

Channels has only 2 possible values, either 4 for transparent image, or 3 otherwise. The hasAlpha property should cover that.
I don't quite understand what you mean by bit here. If what you mean is bits_per_sample then it needs to be hardcoded to 8 as per the spec. If what you mean is rowstride, honestly I don't know much about it, I got that formula after my research. If there's other formula for rowstride, please do tell me

Oh I just realized something, the image data needs to be RGB as per the spec

Formats
The "image-data" and "icon_data" hints should be a DBus structure of signature (iiibiiay). The components of this structure are as follows:
width (i): Width of image in pixels
height (i): Height of image in pixels
rowstride (i): Distance in bytes between row starts
has_alpha (b): Whether the image has an alpha channel
bits_per_sample (i): Must always be 8
channels (i): If has_alpha is TRUE, must be 4, otherwise 3
data (ay): The image data, in RGB byte order

@Hill-98 Ping! Can this be merged and released soon? I'd like to use it in my project

No problem, I'll merge and release a new version tomorrow.


Describe<EMAIL_ADDRESS>mailing list

Nice!
The webpage for the ML doesn’t seem to be up yet, as I’m getting a 404 when trying to access it.

I fixed the URL.  Thanks @s-perron
Keeping the LGTM.


stgit no longer available at gna.org

From stgit http://www.procode.org/stgit/

Unfortunately, the original project page hosted at gna.org is no longer available. An earlier snapshot is still accessible via the Wayback Machine. In the meantime, the project page is being migrated to GitHub and the StGit mailing list to Google Groups.

The new code is at https://github.com/ctmarinas/stgit
cc maintainer @the-kenny

Solved in fc03888

Cool, I solved my own issue without noticing. Thanks @c0bw3b for tracking it down.

/archive/ tarballs from github are generated AFAIK, so I'd fear the hash won't be stable.

Indeed @vcunat it's a pitfall that nixpkgs-update tool does not check. I'll open an issue on its repo.


Release Notes for 12/9 SDK Release

Docs Build status updates of commit a17cb86:
:warning: Validation status: warnings

File
Status
Preview URL
Details

microsoft-edge/hosting/webview2/ReleaseNotes.md
:warning:Warning

Details

microsoft-edge/hosting/webview2/ReleaseNotes.md

Line 25: [Warning] Invalid file link: 'reference/iwebview2webview5'.
Line 25: [Warning] Invalid file link: 'reference/iwebview2webview5'.
Line 25: [Warning] Invalid file link: 'reference/iwebview2webview5'.
Line 26: [Warning] Invalid file link: 'reference/iwebview2webview5'.
Line 26: [Warning] Cannot find bookmark '#iwebview2containsfullscreenelementchangedeventhandler' in 'hosting/webview2/reference/IWebView2ContainsFullScreenElementChangedEventHandler.md'
Line 36: [Warning] Invalid file link: 'reference/iwebview2webview4'.
Line 37: [Warning] Invalid file link: 'reference/iwebview2webview4'.
Line 38: [Warning] Invalid file link: 'reference/iwebview2settings2'.
Line 51: [Warning] Cannot find bookmark '#CreateWebView2EnvironmentWithDetails' in 'hosting/webview2/reference/webview2.idl.md'
Line 54: [Warning] Cannot find bookmark '#CreateWebView2EnvironmentWithDetails' in 'hosting/webview2/reference/webview2.idl.md'
Line 35: [Suggestion] Link 'https://docs.microsoft.com/en-us/microsoft-edge/hosting/webview2#debugging-webview2' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites. NOTE: This Suggestion will become a Warning on 12/20/2019.

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit e5f3ea4:
:warning: Validation status: warnings

File
Status
Preview URL
Details

microsoft-edge/hosting/webview2/ReleaseNotes.md
:warning:Warning

Details

microsoft-edge/hosting/webview2/ReleaseNotes.md

Line 25: [Warning] Invalid file link: 'reference/iwebview2webview5'.
Line 25: [Warning] Invalid file link: 'reference/iwebview2webview5'.
Line 25: [Warning] Invalid file link: 'reference/iwebview2webview5'.
Line 26: [Warning] Invalid file link: 'reference/iwebview2webview5'.
Line 26: [Warning] Cannot find bookmark '#iwebview2containsfullscreenelementchangedeventhandler' in 'hosting/webview2/reference/IWebView2ContainsFullScreenElementChangedEventHandler.md'
Line 36: [Warning] Invalid file link: 'reference/iwebview2webview4'.
Line 37: [Warning] Invalid file link: 'reference/iwebview2webview4'.
Line 38: [Warning] Invalid file link: 'reference/iwebview2settings2'.
Line 51: [Warning] Cannot find bookmark '#CreateWebView2EnvironmentWithDetails' in 'hosting/webview2/reference/webview2.idl.md'
Line 54: [Warning] Cannot find bookmark '#CreateWebView2EnvironmentWithDetails' in 'hosting/webview2/reference/webview2.idl.md'
Line 35: [Suggestion] Link 'https://docs.microsoft.com/en-us/microsoft-edge/hosting/webview2#debugging-webview2' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites. NOTE: This Suggestion will become a Warning on 12/20/2019.

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


package manager x lilypond version manager

I don't think it is a very good idea to have one tool manage both lilypond versions and lilypond code packages. I suggest following the Single Responsibility Principle and splitting lyp in two separate tools: a lilypond version manager allowing one to install several lilypond versions easily and switch between them, and a package manager, working simply with the lilypond currently in PATH. (Regardless of it being provided by the version manager or installed as a single system-wide lilypond instance.)

As for the lilypond version manager, there already is lilyvm

I disagree. The goal for lyp is to be a comprehensive tool for developing and sharing lilypond code ("packages"). In order to provide package loading functionality, lyp needs to wrap the lilypond executable.  Also, package developers need to be able to test their code on different versions of lilypond. Lyp already provides a command (lyp test) to run package tests using the currently selected version of lilypond, and an upcoming feature would be running package tests on multiple versions of lilypond, which can be a tremendous aid for people writing lilypond libraries (since things break quite often in Lilypond).
Yes, you can use lilyvm, but currently it only supports linux (not tested on Mac OSX), and it has quite limited testing. Also, the fact that is written in shell scripts means it will probably never support Windows, which is if I'm not mistaken quite popular among Lilypond users. Lyp, on the other hand, already supports Mac OSX and Linux, (with Windows support already being worked on, probably another couple of weeks), and is very well tested.
Besides, there's nothing stopping you from using lyp together with lilyvm, or any stock installation of lilypond. Lyp would recognize any version of lilypond on the user's $PATH.

 Well anyway I'm closing this as a won't fix.

Ok. I was just writing a follow-up, but if you don't want to discuss architecture, I won't bother you with any more musings on this topic.

If you have a response feel free to post it here or in another issue. There's no bother.

I understand that lyp is, as a lilypond version manager, supreme to lilyvm with regard to portability, functionality and reliability. Great.

Besides, there's nothing stopping you from using lyp together with lilyvm, or any stock installation of lilypond. Lyp would recognize any version of lilypond on the user's $PATH.

-- Even greater - that's a feature which I really appreciate.

The goal for lyp is to be a comprehensive tool for developing and sharing lilypond code ("packages"). In order to provide package loading functionality, lyp needs to wrap the lilypond executable. Also, package developers need to be able to test their code on different versions of lilypond.

-- As a preferable solution to address the described problem area I still see two separate layers (i.e. two separate executables, not necessarily two gems):

lilypond version manager
lilypond wrapper injecting packages

For testing of lilypond code across several lilypond versions either a third thin layer can be added or it can be solved by a general feature of the version manager (not knowing anything about the package code injector) "execute X across versions V1 ... Vn" where X can be invocation of the injector or anything else.
My ideological background is in the Art of Unix Programming, I.1, especially in the Rule of Modularity and Rule of Composition.
(And I am eventually willing to contribute not only ideology, but also code.)

As a preferable solution to address the described problem area I still see two separate layers (i.e. two separate executables, not necessarily two gems):

lilypond version manager
lilypond wrapper injecting packages

But how is this really different than the present situation (where you actually have two executables, lypand lilypond)? The only difference would be that you'll have a third executable, so instead of running lyp install lilypond@stable you'll run lvm install stable. Am I missing something?

For testing of lilypond code across several lilypond versions either a third thin layer can be added or it can be solved by a general feature of the version manager

Again, how does this improve the code quality or user experience?

(not knowing anything about the package code injector)

Please read the code before responding: resolver, wrapper, wrapper template, scheme interface

My ideological background is in the Art of Unix Programming, I.1, especially in the Rule of Modularity and Rule of Composition.

Don't take it personal but I find little use for ideology. Of course, if you have ideas on how to improve the functioning, user experience, or code quality please let me know. But frankly cutting up the code a bit different, I don't see how this improves things.

(And I am eventually willing to contribute not only ideology, but also code.)

Please do :-)


output folder was not created on installation

Hi, I am trying out your project.  I just installed it today to an EC2 server using your instructions on the main page.  Everything installed correctly without errors.  Good job!  One thing I noticed, is that the program wrote:
Log file generated: output/blackbird_log_20170608_135146.log
something like that, and I looked and the output folder was not even there.  I created it
mkdir output
, and re-ran the program
./blackbird (everything default, so demo=true).
and now I have the output log files.
So I don't know why the output folder wasn't created automatically, but it seems the program didn't have permissions to create it after installation.  just FYI, but really BRAVO on this project.

Bug fixed. Now the output folder is part of the repository


Linux dev built using docker fails to launch

I noticed this issue a while back, linux deb packaged using docker doesn't launch,
on clicking the icon of the app, the app shows up on dock and then vanishes,
this would get resolved when building linux deb natively on ubuntu,
with the recent commits I thought https://github.com/go-flutter-desktop/hover/commit/3446f3c8fb3f356f8482b182308bf419ce99bb4c would have solved the issue but looks like that isn't the case,
also, natively building linux deb doesn't work anymore too, it fails saying it needs makePkg but I think that is a slackware tool not present in debian based distributions, couldn't find any straightforward ways to install it on ubuntu or distributions based on it (I am using elementary OS Hera based on ubuntu 18.04).
Using flutter beta with latest master hover.

https://github.com/go-flutter-desktop/hover/commit/3446f3c8fb3f356f8482b182308bf419ce99bb4c does not have to do anything with linux-deb, but you are right https://github.com/go-flutter-desktop/hover/blob/0cbf66239dbe70262c0237f5b5c679ddc6ff01fa/cmd/packaging/linux-deb.go#L38 should say dpkg. Seems I copied some wrong things.

Please try https://github.com/go-flutter-desktop/hover/pull/187


Create AbstractStringToken..

..so there would be no need to implement delegation in all Tokens that rely on a String.
(The need came up in a concrete client api library.)

Just a note: would it make sense to create a lazy version, which only evaluations a let's say abstract String createValue() method when any of the CharSequence methods are called and then caches the value?

Yes a lazy + caching version would be good. Instead of having an abstract createValue method we could just pass a StringTokenFactory to the constructor, though ("Factory" is probably not the right term here). That might make it easier to recycle stuff, because you can decorate the factory but you can't decorate the createValue method once implemented (because the implementing class is supposed to be final).

Yes, sounds better with the factory. One more note: to be able to re-use for all CharSequence, not just Token, we could make this general, like AbstractStringCharSequence / AbstractLazyStringCharSequence.

I think this has become obsolete with AbstractBaseToken.

Yes, most probably, I close it.


Suppress RPC R3019 per discussion at https://github.com/Azure/azure-r…

…est-api-specs/pull/2258
This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.
PR information

[X] The title of the PR is clear and informative.
[X] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
[X] Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
[X] If applicable, the PR references the bug/issue that it fixes.
[X] Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

[X] I have read the contribution guidelines.
[X] My spec meets the review criteria:

[X] The spec conforms to the Swagger 2.0 specification.
[X] The spec follows the guidelines described in the Swagger checklist document.
[X] Validation tools were run on swagger spec(s) and have all been fixed in this PR.

Automation for azure-sdk-for-python

Swagger to SDK encountered a Subprocess error: (Azure/azure-sdk-for-go)
Command: profileBuilder -s preview -name preview
Finished with return code 127
and output:
/bin/sh: 1: profileBuilder: not found

@salameer, @ravbhatnagar  Can you guys help approve and merge?

Tagged @salameer @ravbhatnagar  as reviewers.

Ok to suppress as we discussed on the PR. It would still be good if we have granular suppression at API level since we still want to check for this rule for new resource types. @naveedaz  - I know this would still be a lot of APIs, anyhow that can be achieved? @lmazuel - thoughts on this? Can we suppress it at resource type or model level? anyhow we can make it easier for the author of the suppression but still ensure the rule gets applied for newer types?

@fearthecowboy @olydis Any idea for what suggests @ravbhatnagar in his last comment?

Suppression can be very fine-grained.
With most messages, you'll see something like
ERROR (BodyTopLevelProperties/R3006/RPCViolation): Top level properties should be one of name, type, id, location, properties, tags, plan, sku, etag, managedBy, identity, zones. Model definition 'TrafficManagerUserMetricsKeyModel' has extra properties ['key'].
    - file:///C:/tmp/hrk/specification/trafficmanager/resource-manager/Microsoft.Network/preview/2017-09-01-preview/trafficmanageranalytics.json:431:6 ($.definitions.TrafficManagerUserMetricsKeyModel.properties)

that last piece in parenthesis after the path can be specified to scope the suppression:
directive:
  # suppress just the one error
  - where: $.definitions.TrafficManagerUserMetricsKeyModel.properties
    suppress: R3006
    reason: It's an old API, will resolve in next API version
    approved-by: "@ravbhatnagar"

@fearthecowboy I think the question here is that doing it precisely will require a loooooooot of suppressions rule. It's why the PR is generic. But at the same time, the problem with generic rule is that this will be applied to all future Swagger :(
So is there a smart way to add a loooooooooot of suppression rules right now with precise granularity to replace the big one and allow future Swagger to be verified correctly?

Automation for azure-sdk-for-go

@fearthecowboy @olydis @ravbhatnagar @lmazuel
Let me know if the latest change addresses your concerns

Thanks @naveedaz . I think this address concerns from @ravbhatnagar on generic suppression. Merging!


Add Slack "Join our community" iframe to our community page

@mglukhovsky saw a good example of how to embed the "Join our slack" square on the Flintjs documentation, we should probably do something similar.

All the slack related links replaced to an invite link.


fix: Import of custom Superset assets

The custom Superset assets are all pushed into a single assets.yaml file, and need to be separated by --- lines. This fixes the ability to read multiple custom assets from the assets.yaml / superset-extra-assets patch.
Also allows the import_superset_zip command to serialize assets to other locations so that extensions can use it as well.

@pomegranited you'll need this fix to use custom assets. My tests for this are here: https://github.com/bmtcril/tutor-contrib-aspects-extension

@Ian2012 this could use a re-review whenever you have a min.


Error In finetuning layoutlmv3 object detection

I am using layoutlmv3 for Finetuning the Text , Title, Table, List, Figure from the pdf pages converted to Images.
I am using Label-studio to make the dataset and exported the dataset as coco-format, But when I tried to start the training I am getting this error
AttributeError: Cannot find field 'gt_masks' in the given Instances! .
Can anyone help ?
thank you

same problem.

I set the MASK_ON to False, and the code can run without error. But the model exhibits non-convergence and loss_box_reg_stage continues to rise with training, total_loss shows a fluctuating trend, which has been evident since the early stages of training.

I think this is because the Label-studio annotation does not contain any MASK information.

I think this is because the Label-studio annotation does not contain any MASK information.

hello, I meet the same problem when I train layoutlmv3 large model with set MASK_ON to False, but when I train layoutlmv3 base model with set MASK_ON to False everything is ok? do you have any idea of this problem?

I am using layoutlmv3 for Finetuning the Text , Title, Table, List, Figure from the pdf pages converted to Images. I am using Label-studio to make the dataset and exported the dataset as coco-format, But when I tried to start the training I am getting this error
AttributeError: Cannot find field 'gt_masks' in the given Instances! .
Can anyone help ? thank you

I am using layoutlmv3 for Finetuning the Text , Title, Table, List, Figure from the pdf pages converted to Images. I am using Label-studio to make the dataset and exported the dataset as coco-format, But when I tried to start the training I am getting this error
AttributeError: Cannot find field 'gt_masks' in the given Instances! .
Can anyone help ? thank you

You can include gt_masks in your coco json annotations by either getting actual segmentation masks or making rectangular segmentation masks using bbox info


bump versions of @tauri-apps/plugin-window for compatibility with latest release

Issue
Currently, tauri-controls doesn't work with the latest versions of @tauri-apps/plugin-window due to a refactor..
Links

feat(window): refactor and improvements
window v2.0.0-alpha.1

Solution
Bumping each package's version of @tauri-apps/plugin-window to 2.0.0-alpha.1, as well as modifying code to adjust for the refactor has fixed this issue.
Notes

The Solid and Vue packages have had their ref() and createSignal() function calls removed respectively, as they are no longer required.

Thanks for the PR. 🙏

Currently, tauri-controls doesn't work with the latest versions of @tauri-apps/plugin-window due to a refactor..

Yes, I was planning to work on it, but I was on vacation and just got back.

Thanks for the PR. 🙏

Currently, tauri-controls doesn't work with the latest versions of @tauri-apps/plugin-window due to a refactor..

Yes, I was planning to work on it, but I was on vacation and just got back.

All good! Hope you enjoyed your vacation!
Hope this PR helps!

I'll look into it, but I'm stuck on this issue on Windows. I can only move forward if this is fixed. :/
https://github.com/tauri-apps/tauri/issues/7784
https://discord.com/channels/616186924390023171/1149396631070982274

releated issues: #13


Issue with discontinuity hls on desktop.

The same video plays nicely on Android. Chrome and Firefox freeze, but play the stream for 6 seconds. Chrome shows no errors in the console, but I don't know if this log is quite normal (one file is downloaded two times):
XHR finished loading: GET "http://<IP_ADDRESS>/vod/3/d.m3u8?expires=2000000000&md5=D0DO62JT3n6CDprCKBZuHQ".

XHR finished loading: GET "http://<IP_ADDRESS>/vod/3/d.m3u8?expires=2000000000&md5=D0DO62JT3n6CDprCKBZuHQ".

XHR finished loading: GET "http://<IP_ADDRESS>/vod/3/playlist229.ts?expires=2000000000&md5=J1qT-1CPyx-LbJAdN3neUQ".

XHR finished loading: GET "http://<IP_ADDRESS>/vod/3/playlist219.ts?expires=2000000000&md5=g2LTqPEaRuAQoAD9lDVpVg".

XHR finished loading: GET "http://<IP_ADDRESS>/vod/3/playlist229.ts?expires=2000000000&md5=J1qT-1CPyx-LbJAdN3neUQ".

XHR finished loading: GET "http://<IP_ADDRESS>/vod/3/playlist219.ts?expires=2000000000&md5=g2LTqPEaRuAQoAD9lDVpVg".

Firefox's console:
mutating the [[Prototype]] of an object will cause your code to run very slowly; instead create the object with the correct initial [[Prototype]] value using Object.create clappr.js:2007:416

ReferenceError: event is not defined
 clappr.js:19149:16

Also I can skip this fragment and play video further (firefox wouldn't show the error too).
I'm on Ubuntu 14.04, clappr 0.2.31.

Found info about extra logging with Clappr.Log.setLevel(0). Here are the logs. I must admit that it seems like the playback stops on different fragments, this time chrome played the stream till 0:17.
chrome_firefox_logs.zip

@GeorgySerga maybe this is something related to your stream (the generation or other issue) , try this:

With this stream http://www.streambox.fr/playlists/x36xhzz/x36xhzz.m3u8 ?
At hls.js demo page ?
Did you try chrome on other platform? (like OS or Windows)
Using FlasHLS ? (a.k.a plugins: [Clappr.FlasHLS])

Well,

The http://www.streambox.fr/playlists/x36xhzz/x36xhzz.m3u8 is working.
I can't play my media right at the demo page (CORs thing), but I have cloned their repo and - my video freezes. Right at the same fragments. Chrome demo shows Frag Loop Loading Error,cannot recover, last media error recovery failed ... Firefox console has two errors at the end:

[error] > cannot recover fragLoopLoadingError error hls.js:6846:7
ReferenceError: event is not defined hls.js:692:15

I've tried this stream on my Android phone. It has some lags, but plays the stream from the start till the end.
It works with plugins: [Clappr.FlasHLS]. Though I must admit that the right click action doesn't show me the flash menu, console shows INFO:FlasHLS Clappr (version: 0.4.11 - flashls: <IP_ADDRESS>, id: o12). I'm confused a little.

Thank you.

@GeorgySerga if you still think this is not something related to your input stream and it's working under FlasHLS you might open an issue at hls.js passing all the details there( @mangui ).

Though I must admit that the right click action doesn't show me the flash menu, console shows

This happens because we cover the flash "stage" with an html div (a wrapper container).

if you still think this is not something related to your input stream
Well, at some point of course it's stream related, but I can play it with flashls, on my phone, in the vlc, etc, so it seems rather working )

Ok, thanks a lot for your help, one way or another, the issue is fixed with flashls. I'll open an issue at hls.js. Good luck!

@GeorgySerga please link the new issue at hls.js here too :)

@leandromoreira don't understand, the link to hls.js is right above your comment, in the reference. In case it isn't displayed: daylymotion/hls.js#205 . Or maybe you did want something else...

the same guy that did flashls did hls.js so this might be easy.

That was extremely easy :) You two answer super quickly!

my mistake, I didn't see the link. :) @mangui is an awesome person and amazing developer.


Roll back NumPy version (new pip finds conflict with TF)

Description
Type of change

[ ] Feature
[x] Fix
[ ] Release

Checklist

[ ] I have followed the CONTRIBUTING guidelines.
[ ] I have updated the CHANGELOG.

Tensorflow requires numpy<1.19 but we list 1.19.1.
It was probably just issuing a warning until now. Failure probably due to new pip version (as we do pip --upgrade we always have the last version)


Fix incorrect uses of loop variable

Pull Request Motivation
This fixes two instances where loop variables were being incorrectly
used:

using a loop variable in a closure passed to ginkgo.It() is
incorrect, as the capture happens by reference and only the last test
case will be executed (multiple times).
a similar issue happens in the context of a goroutine; specifically,
we need to create a copy of the runDurationFunc before calling it in
a goroutine as done by the controller's Run function.

With regards to the second issue, I believe it never came to the
surface because, in production code, only one runDurationFunc is
passed; tests don't exercise the multiple funcs path either.
Issues were automatically found with the loopvarcapture linter.
Kind
bug
Release Note
NONE

thank you for finding these bugs
/approve

@renatolabs could you provide some help/ guidance on where we can find this linter and how to add it to our tests?

/ok-to-test

/assign @jahrlin

Hey. How did you spot these? Did you use noloopclosure to spot it?

Hey. How did you spot these? Did you use noloopclosure to spot it?

In the description @renatolabs talks about loopvarcapture, but I'm not certain it's already widely used.

Hey. How did you spot these? Did you use noloopclosure to spot it?

In the description @renatolabs talks about loopvarcapture, but I'm not certain it's already widely used. cockroachdb/cockroach#80803 seems related

Indeed, this is a linter we have developed at Cockroach Labs. I ran it on a variety of open source projects to validate the issues it can find.
Unfortunately, it's not yet packaged in a way that can be easily consumed by 3rd parties. I do intend to do that in the near future, and I'll make sure to update this thread with more information once that's available.


[NEW ICON] GitKraken

Add New Icon(s)
Icon Details

Icon ID
Icon

gitkraken-dark

gitkraken-light

gitkraken-auto

Notes

GitKraken  is a graphical user interface (GUI) for Git with cross-platform support for Windows, Mac, and Linux

Closing
Closes tandpfun/skill-icons/issues/513
Checklist

[x] Added icon(s) to the appropriate directory
[x] Updated documentation with the new icon(s)
[x] Verified the icon(s) display correctly
[x] If the icon has light and dark, verified the auto switch works correctly

@LelouchFR
I wasn't entirely confident about how the -auto Icons functioned, which is why I did not add one. However, I'm more than willing to give it a shot if you could offer some guidance. My initial thought is to create a natural set of colors so that the outer square can dynamically change hues and fill accordingly. Does that sound about right?

to make the auto icon, you have to take from the example of your dark icon. Then you add the snippet underneath the svg opening tag and add at the end of the svg tag his id (which will there be gitkraken):
#gitkracken {
    rect {fill: #242938}

    @media (prefers-color-theme: light) {
        rect {fill: #F4F2ED}
    }
}

if you can, please change (for the auto) the path which creates the square with this line:
<rect width="256" height="256" rx="60" fill="#242938" />

after that, you just have to play with selector to change the color of the logo.
please also remove changes you made to the readme about the last section, thank you.

@LelouchFR
It should be good to go now, thanks for the assistance.
The readme was updated, It would seem my formatter modified it sorry about that.

You are right, sorry about that, should be fixed now.

Guys, just a question here, not to be annoying, but didn't you see that I pointed out the typo yesterday? I'm just asking to see if my comment is visible.

I did not see it until you just commented on it just now.

@LelouchFR @ItsJoshBrown, just a question here, not to be annoying, but didn't you see that I pointed out the typo yesterday? I'm just asking to see if my comment is visible.

That's weird, I thought the review would show everyone (since I don't own the repo) a new learning here haha, next time I'll comment in PR.

All good! It's my fault for not being more vigilant. I'm not used to doing anything with forks either so I didn't realize I was out of sync, but good to know for the future.

That's weird, I thought the review would show everyone (since I don't own the repo) a new learning here haha, next time I'll comment in PR.

Well, it was the same bug than the last time I was talking you about something, now I get it sicne I've not seen it too there xD

Well, it was the same bug than the last time I was talking you about something, now I get it sicne I've not seen it too there xD

Yeaaah, that's true haha, now I get you.

goodness, it's just not my week apparently. Okay, everything should be fine now I triple-checked it.


Fix a minor typo

Fixes a word in the docs where I think you mean existing communication "channel", not "change"

@aareet Thank you for sending this fix. Unfortunately I had to revert it because we need you to accept our CLA before I can merge this fix. Could you please take a few minutes and accept our CLA:

[ ] Accept the Ockam Contributor License Agreement by adding your Git/Github details in a row at the end of the CONTRIBUTORS.csv file in a separate pull request to the build-trust/ockam-contributors repository.

The easiest way to do this is to edit the CONTRIBUTORS.csv file in the github web UI and create a PR, this will make the commit as verified.
After you accept, I'll merge the same commit again. Thank you.

No problem, added in https://github.com/build-trust/ockam-contributors/pull/200


Polish explorer tooltip rendering

Fixes #173236
Polishes tooltip rendering to match more what windows does

@Tyriar It sounds like there's two concerns here.

It blocks items (which I don't see on my Mac personally, but the screenshots do show it).
It provides little actual value to many due to them already knowing the full path which they have open. Breadcrumbs also provides this info.

It provides little actual value to many due to them already knowing the full path which they have open

It can provide value though, adding a setting to disable it outright feels like a cop-out. Will making it less intrusive solve the problem most of the way so we can avoid the extra setting?
Users could have problems with all sorts of hovers across the product, we shouldn't be adding individual settings to disable the hovers (I'm guilty of this too with terminal.integrated.showLinkHover which I somewhat regret adding).

And if it indeed does not provide value, should we remove the hover outright? We could then explore doing something like this on hover to help with truncated items:

And if it indeed does not provide value, should we remove the hover outright? We could then explore doing something like this on hover to help with truncated items:

This seems like the best future, but quite complicated. Maybe as a stop gap we switch to custom hovers that always render outside the explorer view?

修复 #173236
我null在这里明显缺乏价值来最小化差异，但这可能会在使用nullvs时造成混乱，因为它不再像现在这样简单。如果您认为我应该添加一个明确的选项来禁用工具提示，请告诉我。undefined``!value

Two simple solutions, add an option to disable all hovers, or set a shortcut key for all hovers, both are acceptable for me

Fixes #173236
I utilized null as an explicit lack of value here to minimize the diff, but that may create confusion surrounding when null vs undefined is used as it's not as simple as just doing !value anymore. Let me know if you think I should instead add an explicit option for disabling the tooltip.

Two simple solutions, add an option to disable all hovers, or set a shortcut key for all hovers, both are acceptable for me.

And if it indeed does not provide value, should we remove the hover outright? We could then explore doing something like this on hover to help with truncated items:

This seems like the best future, but quite complicated. Maybe as a stop gap we switch to custom hovers that always render outside the explorer view?

It is easier to customize whether to enable all hovers than to delete all hovers. In addition, we can use this method to achieve custom effects, increasing the upper limit of the hover delay to a few minutes, or even an hour.

Two simple solutions, add an option to disable all hovers, or set a shortcut key for all hovers, both are acceptable for me.

Both of these are unfortunately not as easy as you might expect. At least until we move all hovers onto the custom hovers (as opposed to our current mix of title attribute and custom hovers)

I don't know how to make a screenshot of it, but the "Contains emphasized items" tooltip is so large that it interferes with mouse context menu operations. It is not fixed. Please consider a setting to disable these.

@gregdelozier That will be fixed for insiders and this tooltip will not go out in stable as there is still some polish to be done here.

I'd like to add that this is super annoying, I can't even fast-scroll through the files, because the scroll gesture gets caught by the hover and it stops scrolling, I have to look for some empty space in the explorer so I can continue scrolling. Sometimes I wish for a tooltip, if I need to see the full filename and if it is too long, but I would expect for the tooltip to work the same way tooltips work anywhere else, by staying on the item for a few seconds.
I would rather turn this off and have no tooltips than to be interrupted in my work because of the tooltip. Is there a way to turn this feature off until it is fixed?

I never noticed the original tooltip issue, until this supposed fix made me notice it in a worse way. Now I can't scroll quickly and pulling up the context menu becomes troublesome.

I'd like to add that this is super annoying, I can't even fast-scroll through the files, because the scroll gesture gets caught by the hover and it stops scrolling, I have to look for some empty space in the explorer so I can continue scrolling. Sometimes I wish for a tooltip, if I need to see the full filename and if it is too long, but I would expect for the tooltip to work the same way tooltips work anywhere else, by staying on the item for a few seconds.
I would rather turn this off and have no tooltips than to be interrupted in my work because of the tooltip. Is there a way to turn this feature off until it is fixed?

This should be off now, still working on improving it before looking to ship this.


fix(secure-storage): only trim by the aws secret manager global prefix to get the resulting key

Description

This follows up on
https://github.com/bf2fc6cc711aee1a0c2a/kas-fleet-manager/pull/1638/commits/64d56dd8ccb7899eca2c888f5e7b01286a89d702
which introduce an unintended bug of returning wrong keys as expected by certmagic since prefix was removed.
For example:
If the storage.secretPrefix is "kas-fleet-manager"
When we call Store(ctx, "example/secret-one") then the resulting secret name in the storage backend is going to be "kas-fleet-manager/example/secret-one". When we call List(ctx, "example", true) then the returned list of keys should be ["example/secret-one"] and not /secret-one as it is current is. This was because we trimmed by the filterValue, an exising bug from the first version. We should only trim by the "kas-fleet-manager/" prefix.
Verification Steps

Checklist (Definition of Done)

[ ] All acceptance criteria specified in JIRA have been completed
[ ] Unit and integration tests added that prove the fix is effective or the feature works (tested against emulated and non-emulated OCM environment)
[ ] Documentation added for the feature
[ ] CI and all relevant tests are passing
[ ] Code Review completed
[ ] Verified independently by reviewer
[ ] All PR comments are resolved either by addressing them or creating follow up tasks
[ ] Required metrics/dashboards/alerts have been added (or PR created).
[ ] Required Standard Operating Procedure (SOP) is added.
[ ] JIRA has been created for changes required on the client side

@pb82 @miguelsorianod this builds on top of https://github.com/bf2fc6cc711aee1a0c2a/kas-fleet-manager/pull/1638 to enhance the List implementation. Can you have a look please?

I'll work on adding unit test for the whole storage implementation on a separate PR tomorrow.

Is the unit testing done? if so, it looks good to me

Is the unit testing done? if so, it looks good to me

Thanks for the review @miguelsorianod @pb82 just pushed an update to address https://github.com/bf2fc6cc711aee1a0c2a/kas-fleet-manager/pull/1642#discussion_r1139933930 wording issue


[PE-D][Tester C] Over-restrictive input validation for the address field

Quoted from the UG:

Address has a max length of 50 characters, and it should not be empty upon adding.

It is extremely common for addresses to have a length of more than 50 characters. Such data will be unable to be inputted into the app.

Labels: type.FeatureFlaw severity.Medium
original: benson1029/ped#5

Fix:
Clarify in the user guide that we know that addresses might have a length of more than 50 characters but currently do not support. Also encourage the user to use shortforms such as b123 instead of block 123.

Fix in #166


Redefined param in child Parameterized class inherits the 'bounds' of the parameter in the parent class

ALL software version info
v2.0.0a3
Description of expected behavior and the observed behavior
Say I have a child Parametrized class which inherits from a parent Parameterized class and redefines one of its parameters from a param.Integer to a param.List. If the param.Integer had a bounds defined, the param.List in the child class seems to inherit those bounds, which doesn't really make sense (the bounds of an integer enforce a range on the number, but the bounds of a list enforce a range on the length of the list).
Complete, minimal, self-contained example code that reproduces the issue
import param

class parent(param.Parameterized):
    p = param.Integer(None, bounds=(1, None))

class child(parent):
    p = param.List([])

p = parent()
c = child()

The above code fails with ValueError: List parameter 'child.p' length must be at least 1, not 0.
I expect p = param.List([]) to completely override p = param.Integer(None, bounds=(1, None)), and a default value of [] to be valid.

I see. Thanks for the detailed explanation.

We could improve the error message here. The error happens while creating the child class when it detects that the type of a Parameter has changed. In that case we could catch the validation error (a mix of ValueError, TypeError OSError) and enhance it with some more context.


[Design Doc] In Doc Search UI

Initial design doc for In Doc UI.
I implemented the edge-ngrams in my local and have tested the search with that. I will be testing it more and more to see the effectiveness of it.
Also, I will be implementing the Completion Suggester also to see its result and then the comparison will tell us that which is better and efficient to implement.
Closes #5699

@rtfd/core
I have implemented a short demo.
Here is something our search-as-you-type feature may look and work like.
(The quality of gif got reduced after the conversion from mp4 file.

(Implemented using edge-ngrams)
Should I include this is design docs?

Thanks for the design doc. I think we need a hybrid solution here which is mixed of edge-ngrams, completing suggestor as well as Simple Query String. Moreover, I think we should show search suggestion like search engines like google by using the suggestor.

@safwanrahman
I am having some problems setting up the completion suggester, so I haven't tested the results of it yet.
https://discuss.elastic.co/t/problem-with-completion-suggester/181695
It would be great if you could help me out with this.
Also, some problems might be associated with completion suggester + edge_ngrams
My settings:
PUT test-completion
{
  "settings": {
    "analysis": {
      "filter": {
        "ngram_filter": {
          "type": "edge_ngram",
          "min_gram": 1,
          "max_gram": 30
        }
      },
      "analyzer": {
        "ngram_analyzer": {
          "type": "custom",
          "tokenizer": "whitespace",
          "filter": [
            "lowercase",
            "ngram_filter"
          ]
        }
      }
    }
  },
  "mappings": {
    "doc": {
      "properties": {
        "content": {
          "type": "text",
          "fields": {
            "autocomplete": {
              "type": "completion",
              "analyzer": "ngram_analyzer",
              "search_analyzer": "whitespace",
              "contexts": [
                {
                  "name": "project",
                  "type": "category",
                  "path": "project"
                },
                {
                  "name": "version",
                  "type": "category",
                  "path": "version"
                }
              ]
            }
          }
        },
        "title": {
          "type": "text",
          "fields": {
            "autocomplete": {
              "type": "completion",
              "analyzer": "ngram_analyzer",
              "search_analyzer": "whitespace"
            }
          }
        },
        "headers": {
          "type": "text"
        },
        "commit": {
          "type": "text"
        },
        "path": {
          "type": "text"
        },
        "project": {
          "type": "keyword"
        },
        "version": {
          "type": "keyword"
        }
      }
    }
  }
}

Edge ngrams itself requires large disk space and using it with completion suggester (with the above settings) took 564.1 MB which was originally 4.7 MB. This might be because I used edge_ngrams in filter. I am not sure about this.

We also have to use contexts with the completion suggester, according to the docs

Adding context mappings increases the index size for completion field. The completion index is entirely heap resident, you can monitor the completion field index size using Indices Stats.

We have to use atleast 2 contexts (for filtering based on project and version), but when multiple contexts are used, those are OR-ed and not AND-ed. For that, there is a little hacky workaround which involves making a pseudo-context (#26407 (comment)). This adds to the size of the index.

As per this comment - #504 (comment), we might not be able to support completion suggester as it keeps everything in-memory.

Firstly, that short demo looks very cool.
This design doc jumps right into specific implementations of how this will work in Elastic Search and while that's pretty important I think we are missing a few higher level things. For example, there's two parts of the in-doc search UI -- the normal search results page and a new search as you type instant-answer overlay. Are you planning to tackle any improvements to the normal Sphinx search page or exclusively tackling the overlay? Also, how customizable do we want to make this?

The normal Sphinx search page (eg. this page for the RTD docs). This is the page that Sphinx provides out of the box with its built-in implementation. It's pretty impressive for what can be done without a server backend but there is a lot of room for improvement. Read the Docs overrides the search API to hit its own backend and this is where @safwanrahman's improvements were made. There's lots of additional things this could do such as:

Searching subprojects and maybe eventually related projects. To give an example, I'm thinking of finding results for the requests-toolbelt while searching the requests docs.
Should any UI improvements be done to the search results page? This might be hard to do in a theme-agnostic way.
Currently, our custom search doesn't integrate with MkDocs at all.
Should we expose any facets in this search implementation (I'm thinking of how github issue search exposes facets like is:closed)?
Projects should probably have a way to disable any modifications we make to the search page or even just have a way to just use the Sphinx defaults. There's currently a way to do this but it isn't particularly well-documented or explained (see #4570).

A search as you type JavaScript overlay. This currently doesn't exist at all unless document authors have added third-party tools like how the requests docs have added Algolia. There's a lot to think about here:

How will the front-end work in a theme agnostic way?
Will project maintainers be able to opt-out of this or customize it in any way (either styles or something different)? For example, if the requests docs want to continue to use Algolia, they probably don't need our implementation.
How will we roll this out to users? For example, we probably want to turn it on for docs.readthedocs.io before anyone else. Maybe we make it opt-in for a beta period.
I would like to start thinking about some example searches we could think of on specific projects and what the results should be. That way we can ensure that our search as you type implementation is returning desired results.

I went through a lot of things here and we don't need to do all of these things for GSoC! There probably isn't enough time. I probably missed some things too! However, I want to get thinking about how this will fit into the codeline, how we'll roll it out, and how project maintainers will be able to customize things. I don't want to focus exclusively on implementation details.

@davidfischer

Firstly, that short demo looks very cool.

Thank you.

Are you planning to tackle any improvements to the normal Sphinx search page or exclusively tackling the overlay?

Currently, I don't have any thoughts on improving the Sphinx search page, perhaps we may have to make changes to it if the suggested results and actual results don't match.

how customizable do we want to make this?

According to your comment above, we should atleast give the maintainers an option to opt-in/out to our search improvements. Also, I think maintainers should be able to change some UI parts like the colors. They might want to do this if the theme colors doesn't match with the search suggesstions colors.

Should any UI improvements be done to the search results page? This might be hard to do in a theme-agnostic way.

Does search results page need any improvements? Do you have anything in your mind?

Currently, our custom search doesn't integrate with MkDocs at all.

I am aware of this and I believe that we won't be able to support the search as you type feature for documentations built with MkDocs as of now. We can, once we have MkDocs integration with search.

Should we expose any facets in this search implementation (I'm thinking of how github issue search exposes facets like is:closed)?

How we will be using facets for our searches?

Projects should probably have a way to disable any modifications we make to the search page or even just have a way to just use the Sphinx defaults.

I agree with you here. We have to find a way to support this. I will research on this more. Do you anything in your mind?

How will the front-end work in a theme agnostic way?

I think, this is one of the biggest challenge for us. I faced this issue when making the short demo of this feature. I will research more on this.

Will project maintainers be able to opt-out of this or customize it in any way (either styles or something different)?

Yes, I think some customisations must be there for project maintainers as mentioned in Point 2 above.

How will we roll this out to users? For example, we probably want to turn it on for docs.readthedocs.io before anyone else. Maybe we make it opt-in for a beta period.

We can have something like #4570 for this.

I would like to start thinking about some example searches we could think of on specific projects and what the results should be. That way we can ensure that our search as you type implementation is returning desired results.

I did compared the suggested results (with the short demo) with the algolia's result. The results were pretty good. I wouldn't say that all the results were same but most of them were.

Linking some PRs on Algolia integration with the docs:

https://github.com/kennethreitz/requests/pull/5066
https://github.com/realpython/python-guide/pull/997

Thanks @davidfischer for the points. Those were some important ones which i didn't consider in the first place. I am updating the Design Docs to include those.

@davidfischer
I found this way to enable project maintainers to opt-in/out of our search-as-you-type feature.
For opt-in/out, we basically need a javascript bool type variable and from that we can wrap our code in if block to control it.
To enable search-as-you-type, project maintainers set it in their conf.py like
# conf.py
...
RTD_AUTOCOMPLETE = True
...

Then we can make changes in our readthedocs-sphinx-ext to check for this variable and if this is true, set a javasciript variable in the template to true, like
var RTD_AUTCOMPLETE = true;

This can be done in this way - https://github.com/thewtex/sphinx-contrib/blob/master/googleanalytics/sphinxcontrib/googleanalytics.py
and we got our variable which is globally available and we can use it to control this feature.
Thus, project maintainers have to do very little work to opt-in/out of this.
And for the styles, they can have a custom css file embed in their docs (which can be configured from conf.py) like this (tested with short demo) - https://github.com/rtfd/readthedocs.org/blob/f12f5fd4adae415959caf56323ed0eeb77103ae7/docs/conf.py#L107-L108
Also for rolling out this feature, after testing this with our docs, can we ask some other project maintainers who are currently using RTD to enable this in their project and provide some feedback on this?

Does search results page need any improvements? Do you have anything in your mind?

I think if we add the ability to disable our search (falling back to Sphinx's built-in search) or to search subprojects, we should probably add some messaging like "search provided by Read the Docs". We could even have a link to click to get the built-in search results. We also need a way in the UI to show if a search result came from a subproject or something like that.

How we will be using facets for our searches?

We don't currently. However, I could see some useful ones like excluding subprojects, looking for certain terms in titles only vs anywhere in the body, or something like that.

I agree with you here. We have to find a way to support this. I will research on this more. Do you anything in your mind?

One way that would involve a significant refactor would be to expose all the functionality we do on in-doc pages via a JavaScript global variable READTHEDOCS. This variable could have methods on it that handle things like in-doc search (eg. READTHEDOCS.handle_indoc_search). The defaults for these methods are in some file we include on the generated docs pages. The user could override these methods to change functionality.
This could be used for:

disabling overriding the built-in Sphinx search
disabling or modifying how the autocomplete/search overlay work

Thoughts?

@davidfischer

I think if we add the ability to disable our search (falling back to Sphinx's built-in search) or to search subprojects, we should probably add some messaging like "search provided by Read the Docs". We could even have a link to click to get the built-in search results. We also need a way in the UI to show if a search result came from a subproject or something like that.

I am +1 on the message. But, how will showing the built in results benefit?
Also, by UI, did you mean UI around search suggestions or actual results page? On the actual results page, we did have a UI to tell the users that a result is from a subproject. And we need to show something on the search suggestions for the results from subprojects.

We don't currently. However, I could see some useful ones like excluding subprojects, looking for certain terms in titles only vs anywhere in the body, or something like that.

It is great idea. We should consider this. This will increase the complexity though.

One way that would involve a significant refactor would be to expose all the functionality we do on in-doc pages via a JavaScript global variable READTHEDOCS.

We can do this. I don't know if it's going to increase the complexity or not. Also, I would like to know your thoughts on my comment above.
One thing that we can also provide is the search analytics to the project maintainers (who are using our search)? I don't know if it is required or not. But it will be a great feature. They can just go to the admin dashboard and see the analytics.
I think we are tracking many things here and we should prioritize them before starting the work. Like, search analytics, if agreed upon, might me the last on our to-do list.

I think we are tracking many things here and we should prioritize them before starting the work. Like, search analytics, if agreed upon, might me the last on our to-do list.

Agreed. I want to focus this a bit more than the current discussion. My first question is:

Can we implement the front-end "search as you type" with the existing search API? Do we need to re-build the backend first, or can we simply update the existing search to make it better? The demo you showed looked like a great improvement to me.

Once we answer that question, we can break the work down into pieces. My goal is to focus mostly on the front-end here, at least to start, since that's the area where we historically have needed more work. Once we get a really good UX around search, then we can work on improving indexing and other backend related things to make the front-end function better.

Can we implement the front-end "search as you type" with the existing search API? Do we need to re-build the backend first, or can we simply update the existing search to make it better?

I think, we can, not sure though. I will try this with the demo tomorrow and update it here. If this works, we can start working on frontend with minimal setup of backend.
@davidfischer do you have anything in mind before starting work on frontend?

The demo you showed looked like a great improvement to me.

Thank you. We will make sure that the final product is much better than that.

Once we get a really good UX around search, then we can work on improving indexing and other backend related things to make the front-end function better.

+1 on this. We must do it this way.

I think, we can, not sure though. I will try this with the demo tomorrow and update it here. If this works, we can start working on frontend with minimal setup of backend.

Great, this sounds like a good path forward. We should define a bit more what we're going to do on the front-end in terms of technology. Either in a new GitHub Issue or in this document. 👍

(Sorry, didn't mean to close it, wrong button! :)

@ericholscher
I tried with the existing search backend. It is not effective as that of first demo but I think we can start working on frontend with it. :tada:

One problem I faced is how to include CSS file for this. I was trying to include it in the same way as we include readthedocs-doc-embed.js for all our docs but the grep wasn't able to tell me that how we are doing it.

We should define a bit more what we're going to do on the front-end in terms of technology.

What do you mean 'technology' here?
cc: @davidfischer

Wow, the demo is really good.
Just a comment here, since I suppose that the UI has not been discussed yet, but to consider in that case. If we are going to show these kind of results as you type, I'd suggest to open a modal once the user clicks on the "Search" box input, as Slack does.

It takes control of the screen over the page that you are seeing it suggest you things, but if you don't find what you are looking for from the suggested ones, you hit enter and you get more specific results in the same modal

So, this way we can differentiate our own search from the default search provided by Sphinx and both can live together.

@humitos
I think that's really a nice idea. Although the UI will be more complex though.
We have two options now. What do you think? @ericholscher @davidfischer

@humitos
It may look like this.

This is just a demo and it will much better than this. Like backdrop and other things.

@ericholscher
@davidfischer
I am thinking to start the work. What are your thoughts?

Once we answer that question, we can break the work down into pieces. My goal is to focus mostly on the front-end here, at least to start, since that's the area where we historically have needed more work. Once we get a really good UX around search, then we can work on improving indexing and other backend related things to make the front-end function better.

I'm good focusing on in-doc modal search. That means that we are mostly ignoring the built-in Sphinx search page for the purpose of GSoC. I'm fine 👍 with that.
Basically, that limits the scope to:

JavaScript in-doc search as you type
Any API changes needed to enable in-doc search as you type

I think that's probably a good idea to scope this down for the purpose of GSoC. We have a clear, somewhat self-contained project. There's already enough complexity here.

What do you mean 'technology' here?

I think he means like any libraries we will need to do this. For example, we try to support all the way down to IE11 with our docs theme and Read the Docs generally and I think we want to support that here. For example, that means you can't use the JavaScript fetch API to make Ajax requests. Having a library might make this easier. Sphinx docs already rely on jquery which has an Ajax API but will that be sufficient for everything I'm not 100% sure.

One problem I faced is how to include CSS file for this.

Currently, the CSS included for in-doc search is here: https://github.com/rtfd/readthedocs.org/blob/master/media/css/readthedocs-doc-embed.css
Currently, we inject our CSS and JS into the Sphinx build process here: https://github.com/rtfd/readthedocs-sphinx-ext/blob/50e43731311006cb51a530bc34df89386de8bcf6/readthedocs_ext/readthedocs.py#L53
You have a few options.

You could add your CSS into readthedocs-doc-embed.css and your JS into readthedocs-doc-embed.js and it will get included.
We could package the in-doc search into it's own self-contained CSS and JS files and include them in a similar manner to readthedocs-doc-embed.*.
It might be possible to package up the in-doc CSS/JS as a sphinx extension. This might be nice because then it's easy to enable it on a per-project basis. When we are ready to roll it out to a wider audience, we can make a decision to just turn it on for everybody (put it in here) or we could enable it as an opt-in feature like the 404 extension.

With respect to @humitos comments around a modal window versus an overlay, I don't have a particularly strong opinion. I do hope that we can change the UI relatively easily and I don't want to have to make the decision between modal and overlay quite yet. It might be nice to roll it out to a subset of users and begin to get some real user feedback.

With respect to concrete feedback on the document in this PR, I think there's a few bits that need to be moved around and a few bits that need to be added.
A few things that we should probably add:

Intro - You have a small intro and that's good but I think there could be a bit more. I think it's worth taking one of the animated gifs in the comments of this PR and putting it in there. A picture is worth a 1000 words sometimes. It's ok if the final implementation won't exactly match the image. We can always update it. I think it's also worth mentioning that this was a GSoC project. This section only needs to be a few sentences, I think.

Goals and non-goals - This should probably be a short section near the top. I think that we should highlight all the goals required to make this a successful project. The goals should be really high level but it should include things like:

Support a search-as-you-type/autocomplete interface backed by the existing Read the Docs search backend.
Support across all (or virtually all) Sphinx themes. We should also mention that we are targeting Sphinx only for the initial release since we don't index MkDocs.
Support for the JS user experience down to IE11 or graceful degradation where we can't support it
Maintainers should have a way to opt-in/opt-out of this feature. Changing styles would be nice but isn't as important.

Milestones - This section should be near the bottom. You alluded to this in the "Shipping" section that you have but I think we should be more explicit. Most of these milestones will be dependent on the milestones before them so the order is important (although things can move around a bit). While you don't have to commit to dates, it might also help you coordinate the milestones. We do have specific evaluation dates for GSoC although they don't have to match exactly. I can envision some milestones like:

A local implementation (this seems like what you have in the gifs)
In-doc search on a test project hosted on Read the Docs using the RTD Search API
In-doc search on docs.readthedocs.io
Friendly user trial where users can add this on their own docs
Additional UX testing on the top-10 Sphinx themes
Finalize the UI

Open questions - It is ok that we don't have all the answers up-front. For example, should we rely on jquery, another library, or go 100% vanilla JS? I don't think we quite know the answer to this and we might not until we start on the project. However, we can discuss the trade-offs of these. For example, having as few dependencies as possible is good especially when we want to include this on lots of docs. However, if we have to reimplement the wheel of Ajax, it's probably worth it to use something. This should probably be near the bottom. I think there's a few other open questions like:

Is our existing Search API is sufficient?
Will we search subprojects?

Here's a short guide on writing design documents if that's helpful.
Headings
Looking at just the headings of the doc in this PR, I think we could have something like this:

Intro
Goals and non-goals
Existing search implementation
Proposed architecture for in-doc search

Front-end - this could have subsections
Back-end - you could highlight possibilities like the N-Gram Tokenizer here if you want but I'd keep it a little shorter than what's there now

Milestones
Open Questions
References (maybe)

@davidfischer
I really liked the idea of having separate sphinx extension for it. I think we should do it that way.

Is our existing Search API is sufficient?

I don't think so, I tried that with the demo #2 and the results were not very good. We get the suggestion after typing the whole word. Like.. It will not give any result for elasticse, but would give results for elasticsearch.
We have to make changes in our elasticsearch index to get the results similar to demo #1.
Also, Thanks for a great advice on the design docs. I have restructured the whole docs according to it.

I was trying via sphinx-extension method. The main problem is that we can't use rtd-data.js and our custom js file (search_ext.js) gets included just below the readthedocs-embed.js

The problem it poses is that search_ext.js will be missing some parameters - project and version (and language) which are required for making query. This is because that readthedocs-data.js gets included a little below the search_ext.js and we won't be having object READTHEDOCS_DATA in search_ext.js. I think to solve this problem we might have to get a little hacky (like taking the current url, parsing the url to get project, version and language and then sending them via the query params to search_ext.js).
I think we might not want to that much hack around it (or we want?).
I don't know that the hacky way that I have mentioned will work or not. If we go in this direction, we need to find a way for this.
Or else we can use options 1 or 2 from the comment above.

We can use DOMContentLoaded event (I totallly forget about this) and can have access to READTHEDOCS_DATA global object.

This is what you want! Support is good for all the browsers we care about.

Will there be a new repo

I'd start with a new repo and we can change that later if necessary.

@davidfischer
I have applied and pushed the changes you suggested.
I will make a new repo for the sphinx extension.
Should I move it under rtfd now or should I make @ericholscher and you as the maintainer for now ??

Merging this, we can make any updates to this doc in an additional PR.


Coding Badly - Mason Egger

A few things here,
The repo: user/repo is case sensitive so if your github username is JoeNash you'll need to update the deploy.template.yaml
Also, be sure to run and build the wasm files on your repo too as I updated the links
This was a lot of fun!
Please squash and merge so there isn't 17 commits :lolsob:

Ok, so there's one issue I just discovered. So do you want the button to be for anyone to come to the page to be able to deploy? With the GitHub tag in the app spec auth is required so it won't be available to everyone, however, the deploy on commit is only available via github and not git.  Which I don't think that's to big of an issue. I'm leaning to changing it back to git and having people just manually deploy. Or fork it and have them deploy it through the UI, which uses the github part in the spec and allows deploy on commit

I think the latter works fine! Thanks Mason!


Support Different Number of Max Children

Add support for setting child max, for platforms that define a different maximum number of supported children.
If the maximum number of children is higher than expected, the cert test fails because all children are able to join.

Current coverage is 73.24% (diff: 83.33%)

Merging #872 into master will decrease coverage by 0.48%

@@             master       #872   diff @@
==========================================
  Files           112        111     -1
  Lines         16407      16410     +3
  Methods        2255       2253     -2
  Messages          0          0
  Branches       1981       1982     +1
==========================================
- Hits          12097      12019    -78
- Misses         3651       3726    +75
- Partials        659        665     +6

Powered by Codecov. Last update a291d8d...63eb67b


Lesserwrong links should redirect to lesswrong

Since the domain migration lesserwrong.com links don't resolve to lesswrong. This breaks links people have posted around the web.
Suggestion: Set up 301 redirects from lesserwrong to lesswrong.

I think I may have just successfully fixed this – let me know if you're running into more issues with it.

AFAICT this is now working. Closing, but let me know if there are furher issues.


getThreadList not flagging pending group chats properly when added by non-friend

When the user gets kicked from a group chat, then it gets added by a non-friend, it is a pending message request, but whilst using getThreadList (3rd argument is 'pending', also tried 'archived'), the thread is basically not there.
Whilst looking at inbox messages, the thread is there, but there's no way to determine if the thread is pending.
I need to receive messages from everywhere, so I want to use handleMessageRequest, but I can't determine which threads need to be handled. Attaching an event handler does kinda work, but it will simply won't work when the bot isn't running.

What does the browser do to retrieve these threads?

Is anyone else running into this issue or was it some transient bug on facebook's end?

It's pretty hard to diagnose these bugs without more data and we've changed a lot since september so hopefully this works better now!  I'm going to close it but we can definitely reopen if you're still having problems 😄


Add zalando to adopters list

Hey, I just made a Pull Request!
Added Zalando to adopters list
:heavy_check_mark: Checklist

[ ] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[ ] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)

@roflc0pter we love you, but prettier does not. Could you run prettier on the file :shrug:

@roflc0pter we love you, but prettier does not. Could you run prettier on the file

I think prettier caught some feelings :)


Add clarification around public key format mints should use

This PR is a small addition to the definition of the keyset type, stating that the public keys must be serialized using the compressed public key format used everywhere in bitcoin when building keysets.
This is not unique to bitcoin so I couldn't find a BIP to link to for further information on the format, but information about it is basically found everywhere, including many questions and answers on Stack Overflow and a section of Mastering Bitcoin by Antonopoulos. I chose an article from learnmeabitcoin.com for the link.
Note that this is also the approach used in one of the BIPs defining SegWit, where only compressed keys are accepted, standardizing the length required to share them as well as making them shorter in general.

Thank you for clarifying this and sorry for the delay!


Library Sync issue : Exception: TypeError

Bug report
Your Environment

Netflix add-on version: 1.4.0
Operating system version/name: Windows 10
Device model:  NA

Used Operating system:

[ ] Android
[ ] iOS
[ ] Linux
[ ] OSX
[ ] Raspberry-Pi
[x] Windows

Describe the bug

I just installed the addon and wanted to export items to my library.
This is how my UI appears

When I click on perform full sync I receive a Exception: TypeError error.
Below a link to my log.
Expected behavior

Able to sync my list with kodi
Actual behavior

Error - As described above
Steps to reproduce the behavior

Click on "Perform full sync now"

Possible fix

Dunno
Debug log

The debug log can be found from this link:
https://gofile.io/d/XtXLBP

hi,
please update and let me know:
plugin.video.netflix_1.4.0_20200603_t1.zip

The issue is gone (tested on both windows pc and nvidia shiedl box).

I wanted to reopen this because I'm getting the same error while doing the same thing on 1.40.


GPII-3592: Fix zonal only get-credentials

Fixes issue with Tiller in our CI/CD, which is actually caused by zonal-only support for getting credential and hardcoded zone.
Related to recent move to regional cluster this stopped working and will manifest mainly on CI, as CI does not keep docker volumes with credentials around (can be reproduced locally by running rake clobber).
This PR read the actual zone (gcp uses zone and region somewhat interchangeable in get-credentials command and output of clusters list, so this will work both for zonal and regional clusters).

LGTM!


[False-Positive] Uncaught exception YCX_OBJECT_NOT_PROCESSED

It is being forward to the caller:

Run: https://github.com/SAP/code-pal-for-abap/pull/304/checks?check_run_id=2289307670

thanks, I'm not really sure what causes this in abaplint, so I suggest disabling the rule for now

it currently traverses the statement structure without the include, and the spaghetti syntax is with the include

@lucasborin try again

Fine:

https://github.com/SAP/code-pal-for-abap/pull/405/checks?check_run_id=2685557650
https://github.com/SAP/code-pal-for-abap/pull/405/checks?check_run_id=2685560392


Magic number typo about stack allocating in virt.lds

In virt.lds, we should allocate 0x80000 bytes for the kernel stack instead of 0x8000:
  /*
     Our kernel stack starts at the end of the bss segment (_bss_end). However, we're allocating
	 0x80000 bytes (524 KiB) to our kernel stack. This should be PLENTY of space. The reason
	 we add the memory is because the stack grows from higher memory to lower memory (bottom to top).
	 Therefore we set the stack at the very bottom of its allocated slot.
	 When we go to allocate from the stack, we'll subtract the number of bytes we need.
  */
  PROVIDE(_stack_start = _bss_end);
  PROVIDE(_stack_end = _stack_start + 0x8000); /* should be 0x80000 */
  PROVIDE(_memory_end = ORIGIN(ram) + LENGTH(ram));

So when we divide up the stack for parked harts in boot.S, the multiplier of dividing up the stack for parked harts will be too large:
# We divide up the stack so the harts aren't clobbering one another.
	la		sp, _stack_end
	li		t0, 0x10000 # Too large, MAX = 0x2000
	csrr		a0, mhartid
	mul		t0, t0, a0
	sub		sp, sp, t0

which may cause parked harts to corrupt other sections of the kernel later. For example, in Ch4, this bug would cause the program to hang on my computer.

It was my mistake to actually not just park non-zero harts, but I wanted to show how it would work in the future. I have corrected virt.lds. Funny enough, the documentation comment actually states 0x80000, but the number itself is 0x8000. Thanks!

Thanks for your reply 😃. But it seems that linker files in the chapters directory are still not fixed.

And the comment said 0x80000 bytes equals 524KiB is not perfect,  0x80000 is 8 = 2^3, four zero in hexadecimal means 2^(4*4)=2*16 (since each zero indicates 4bit in binary),  so, it just be 2^(3+16)=2^(19). We know 2^10 is actual kilo: 1024 on computer, approximately equals 10^3=1000, so 2^19=2^(20-1)=(2^10/2)*(2^10)=(1024/2) * (2^10)=512KiB
In a word, 524KiB is 1000-k, and 512Kib is 1024-k, the later is better to understand for computer programmar.