sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: angular
Issue: Angular Service Worker should prefetch assets in parallel
Labels: area: performance,area: service-worker,P4,feature: in backlog,bug

# 🚀 feature request

### Relevant Package

This feature request is for @angular/service-worker.

### Description

The Angular Service Worker currently prefetches a new version assets one by one, as mentioned in https://github.com/angular/angular/blob/dd0ba3f4abb5cf467e55bf660b70965ba7f2881e/packages/service-worker/worker/src/assets.ts#L510

> // Cache all known resources serially. As this reduce proceeds, each Promise waits
> // on the last before starting the fetch/cache operation for the next request. Any
> // errors cause fall-through to the final Promise which rejects.

Doing so with a medium/large application that heavily leverage code-splitting in inefficient: in our case we have ~340 assets to prefetch, for a total application size of only 3.0MB, yet upgrades a taking several minutes (sometimes above > 10 minutes) to be ready.

This leads to app upgrades being slower to propagate as they should be, as users have to stick around several minutes within the app for us to be able to switch to (or notify them about) the new version.

### Describe the solution you'd like

New versions assets should be prefetched by the Service Worker in parallel. 3MB only takes a second to download on the average broadband connection thanks for h2+ parallelism, and the Angular Service Worker should leverage that.

### Describe alternatives you've considered

I am unused if the current behavior was designed on purpose.
Repository: storybook
Issue: Storybook Theming: loading custom Roboto or Ciutadella font not loading
Labels: question / support,theming

Hello, I am trying to customize the Storybook UI. Customization works, but my custom font won't seem to load. Am I forgetting something? I don't have a reproducible repo, but I followed the steps on [this page](https://storybook.js.org/docs/react/configure/theming). This is how my theming file looks:

`storybookCustomTheme.js`:

import { create } from "@storybook/theming/create";
import logo from "../assets/images/storybook-icon.png";

export default create({
    base: "light",
    colorPrimary: " #aa418c",
    colorSecondary: "#00526e",

    // UI
    appBg: "white",
    appContentBg: "white",
    appBorderColor: "grey",
    appBorderRadius: 4,

    // Typography
    fontBase: '"Roboto", sans-serif',
    fontCode: "monospace",

    // Text colors
    textColor: "black",
    textInverseColor: "white",

    // Toolbar default and active colors
    barTextColor: "#343434",
    barSelectedColor: "#377f95",
    barBg: "white",

    // Form colors
    inputBg: "white",
    inputBorder: "#00526e",
    inputTextColor: "black",
    inputBorderRadius: 4,

    brandTitle: "BrandTitle",
    brandUrl: "here's the brandurl",
    brandImage: logo,
});`

As you can see it falls back to Helvetica:

![afbeelding](https://user-images.githubusercontent.com/51741431/97586833-02d60c00-19fb-11eb-8f70-70811eec63c9.png)

Versions:

- @storybook/theming ^6.0.26
- @storybook/react ^6.0.16
Repository: godot
Issue: AtlasTexture breaks OptionButton popup list in editor
Labels: bug,topic:editor

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
<!-- Specify commit hash if using non-official build. -->
3.2.3

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
Wndows

**Issue description:**
<!-- What happened, and what was expected. -->
When adding an option for an OptionButton(possibly also ItemList and other similar nodes) that has an AtlasTexture as its icon, the TextureRegion tab overrides the button to open the list of options, making it impossible to edit

**Steps to reproduce:**
 - Create a scene coontaining an OptionButon
 - Open the list of options
 - Add an option and set the icon to an AtlasTexture
 - Click on the AtlasTexture to edit it


**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->

[AtlasTexture_bug.zip](https://github.com/godotengine/godot/files/5459251/AtlasTexture_bug.zip)
Repository: pytorch
Issue: [types] torch.utils.data.{Dataset, Sampler} are not Sized
Labels: triaged,enhancement,needs research,module: data

## 🐛 Bug

The base classes for `torch.utils.data.Dataset` and `torch.utils.data.Sampler` do not define a `__len__` method, which means that downstream code relying on PyTorch (with typehints) cannot assume that the class is supposed to have a `__len__` method (adhering to the "Sized" protocol).

There's a fairly lengthy comment about why this is the case:

https://github.com/pytorch/pytorch/blob/dfdc1dbee4809a7433fab5cb6880eb6396e9e59d/torch/utils/data/sampler.py#L27-L52

I admit that I'm not quite sure what this comment means -- in my small explorations, I didn't encounter either problem (e.g. subclass instances work just fine when returning a `NotImplemented`). That said, I'd like to offer two additional potential solutions:

- Make these classes `abc.ABC`s and make `__len__` an abstractmethod:
```python
@abc.abstractmethod
def __len__(self) -> int:
    ...
```
- Make the base classes inherit from `typing.Sized`.

cc @VitalyFedyunin @ejguan
Repository: scrcpy
Issue: Colors Washed out
Labels: color

Every time I run Scrcpy the colors on the screen seems to be washed out even my screen brightness is at the maximum. This screenshot is from the app itself. The box in the middle is supposed to be full white but it's kinda gray as if the brightness was low. Maybe it's something simple to fix but I couldn't find anything related on the issues page. Thanks!
![PRINT01](https://user-images.githubusercontent.com/64862877/97595608-9ea74e00-19e2-11eb-815a-0b706b2eda48.png)
Repository: terminal
Issue: Implement inheritance/layering behavior for settings lists/maps
Labels: Area-Settings,Product-Terminal,Issue-Task

# Description of the new feature/enhancement

TSM Inheritance (Spec #7876 + Impl #7923 ) enabled an object model representation of layering JSON. Some settings that are saved to arrays/maps (i.e. actions, color schemes) still experience a special form of layering that is not represented in the object model.

Today, the object model `std::move`s the list of actions/schemes down child-by-child, and directly modifies those values. We need to restructure this system to...
- track where an action/color scheme came from
- layer actions over other actions

This blocks the following work items:
- serialization for actions
- Settings UI implementation for actions
- serializing only _new_ color schemes (ones not from defaults.json)

This also is partially related to...
- #7175 Action IDs
Repository: go
Issue: unicode: does not document that ZERO WIDTH NO-BREAK SPACE (\uFEFF) is not considered whitespace
Labels: Documentation,NeedsDecision

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.15.3 darwin/amd64
</pre>

### Does this issue reproduce with the latest release?
Yes

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/sethvargo/Library/Caches/go-build"
GOENV="/Users/sethvargo/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/sethvargo/Development/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/sethvargo/Development/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/sethvargo/.homebrew/Cellar/go/1.15.3/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/sethvargo/.homebrew/Cellar/go/1.15.3/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/cs/jc9pj94x493gb8jr49ys7cnc00gy5b/T/go-build188500672=/tmp/go-build -gno-record-gcc-switches -fno-common"
</pre></details>

### What did you do?

https://play.golang.org/p/V3JHSB7kQX9

```go
package main

import (
	"fmt"
	"strings"
	"unicode"
)

func main() {
	s := "hi\uFEFF"
	fmt.Println(len(s))
	
	s = strings.TrimSpace(s)
	fmt.Println(len(s))
	
	fmt.Printf("%t", unicode.IsSpace('\uFEFF'))
}
```

### What did you expect to see?

```text
5
2
true
```

### What did you see instead?

```text
5
5
false
```
Repository: rust
Issue: Provide prebuilt std artifacts for sanitizers
Labels: C-enhancement,T-libs-api,A-sanitizers

[Based off of discussion in zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Prebuilt.20tsan.20artifacts.3F)

Rust currently has unstable support for sanitizers (#39699), but some sanitizers require (or prefer) std to be built with special instrumentation. The unstable [`cargo -Zbuild-std` feature](https://doc.rust-lang.org/cargo/reference/unstable.html#build-std) was introduced to address this issue, allowing you to ask cargo to rebuild std with your current RUSTFLAGS.

However, this is a bit messy to work with, and produces a lot of redundant work. Especially in the context of [CI with vendored environments](https://bugzilla.mozilla.org/show_bug.cgi?id=1671691). It would be nice if prebuilt stds were provided for some configurations. 

Sanitizers that merit consideration:
* [ ] ThreadSanitizer (tsan) -- requires an instrumented build to work right
* [ ] MemorySanitizer (msan) -- requires an instrumented built to work right
* [ ] AddressSanitizer (asan) -- can produce more accurate results with an instrumented built

For reference, Firefox is currently only using the -Zsanitizer flag for its "linux64" tsan builds, which I believe are currently debian8-amd64 machines. We have [asan tasks in many different configurations](https://searchfox.org/mozilla-central/search?q=-asan&path=&case=false&regexp=false), but evidently we haven't yet bothered to use -Zsanitizer for them (presumably because it's not required).

It has been suggested to provide builds for all the tier1 platforms, but I don't personally have an opinion on that.
Repository: vscode
Issue: Please add support engine version to api
Labels: api,under-discussion

Since February 2017, I've released an extended and non-stop update to this day.
Newer apis may now be used for each update, but I really don't know the minimum vscode engine version available for these apis.
So I can only write one and hope that after 'npm install' new api will appear, although this is not a big problem, but still want the document to be clearly identified.
Repository: go
Issue: net/http: StatusText(416) returns "Requested Range Not Satisfiable" should be "Range Not Satisfiable"
Labels: NeedsDecision

RFC 7233 defines 416 as "Range Not Satisfiable". This was previously "Requested Range Not Satisfiable" in RFC 2616, which is obsolete.
https://tools.ietf.org/html/rfc7233#section-4.4

But everywhere this occurs, whether it's user code calling `http.StatusText`, or `http.ServeFile` when a client requests a bad range, Go gives the client `416 Requested Range Not Satisfiable` when the canonical text is `416 Range Not Satisfiable`.

Obviously `http.StatusRequestedRangeNotSatisfiable` will have to stay to avoid breaking compatibility, but:
1. Should https://golang.org/src/net/http/status.go#L121 `statusText[StatusRequestedRangeNotSatisfiable]` be changed to `"Range Not Satisfiable"` ?
2. Should `http.StatusRangeNotSatisfiable` be added?
3. Should `http.StatusRequestedRangeNotSatisfiable` be removed in Go 2?

And yes, I realize this is the minorest of issues.

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.13 darwin/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes.

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/rbutts201/Library/Caches/go-build"
GOENV="/Users/rbutts201/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/rbutts201/lang/go/"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/vy/4dwjjyh96295zr995ny4wn400000gp/T/go-build975609211=/tmp/go-build 
-gno-record-gcc-switches -fno-common"
</pre></details>

### What did you do?
`http.StatusText(416)`
`http.StatusText(http.StatusRequestedRangeNotSatisfiable)`

### What did you expect to see?
"Range Not Satisfiable"

### What did you see instead?
"Requested Range Not Satisfiable"
Repository: godot
Issue: Get a error when resume() was called to close the coroutine
Labels: topic:gdscript

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
v3.2.3.stable.official


**OS/device including version:**
win7 64bit GLES2, 


**Issue description:**
I want to cancel the coroutine Then I found this example：
https://godotengine.org/qa/35584/how-to-break-out-of-a-function-that-has-an-in-progress-yield
```
extends Node2D

const CANCEL = true

var pending_yield

func _ready():

    pending_yield = do_stuff()

    # This what comes back out of the return from a yielded function.
    print(pending_yield)


func _on_Button_pressed():

    print(pending_yield.is_valid())

    if(pending_yield.is_valid()):

        # Resume can pass a value back.
        pending_yield.resume(CANCEL)


func do_stuff():

    var result = yield(get_tree().create_timer(5.0), "timeout")

    print(result)

    if(result and result == CANCEL):
        print("The yield was cancelled. Stopping the function.")
        return

    print("Waited 5 seconds... carrying on.")
```
It feels like this example should be right. And the program works as expected.
but I'm getting this error in the debugger:
```
E 0:00:08.447   resume: Condition "!function" is true. Returned: Variant()
  <C++ Source>      modules/gdscript/gdscript_function.cpp:1868 @ resume()
```
Here's a related problem that describes the same error, and his code logic is the same as above:
https://godotengine.org/qa/58682/resuming-coroutine-resume-condition-function-returned-variant

**Steps to reproduce:**
1.Create a new scene, and add a Node2D as it's root.
2.Paste the code above in the script,
3.Add a Button node as child of Node2D, and connect `pressed() ` signal 
4.run the scene and click the button in 5 seconds.
After waiting for a short time, you will see the error.


**Minimal reproduction project:**
All the code has been provided above.
Repository: rust
Issue: compiletest: Show real patches as diffs?
Labels: A-testsuite,C-enhancement,T-bootstrap,E-medium,A-contributor-roadblock,A-compiletest

Current compiletest diffs are not accepted by `patch` (at least when I've tried):

```
patch: **** Only garbage was found in the patch input.
```

Maybe we could change compiletest to output real patches, at least in CI, so that you can just copy-paste the diff and apply it locally if you are not able to run `./x.py test --bless`?

Cc https://github.com/rust-lang/rust/pull/78343#issuecomment-718949632
Repository: PowerToys
Issue: [Settings] Investigate use case of ActivationService and ActivationHandler classes
Labels: Idea-Enhancement,Product-Settings,Area-Quality

## Summary of the new feature/enhancement
While doing work on #7559, I came across the ActivationService and ActivationHandler classes in the Settings.UI project and wanted to validate threading behavior from changes I made on that PR. In my debugging attempts I was unable to trigger breakpoints and hit the code paths in these classes (both with VS debugging and print statement debugging). We should verify if these classes are actually used, or if they are dead code that can be removed.

## Proposed technical implementation details (optional)
The only documentation I can find on these classes (also linked in the source code) is [this](https://github.com/microsoft/WindowsTemplateStudio/blob/dev/docs/UWP/activation.md), which shows that it is in charge of activating a UWP application. However, to my understanding, the Settings app is primarily a WPF app which imports some UI controls and behaviors from UWP (a XAML island - see [this doc](https://github.com/microsoft/PowerToys/blob/6b4b0d1f24a1c72b71f836694113936191b4600e/doc/devdocs/settingsv2/ui-architecture.md)), so I'm not sure if this activation mechanism would apply here. If not, we should remove these classes and verify that no regressions occur.
Repository: go
Issue: x/crypto/acme: CreateOrderCert returning Order's status ('valid') is not acceptable for finalization
Labels: NeedsInvestigation

<!--
Please answer these questions before submitting your issue. Thanks!
For questions please use one of our forums: https://github.com/golang/go/wiki/Questions
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.15.2 linux/amd64
</pre>

### Does this issue reproduce with the latest release?
The build that is seeing the error is using:
```
golang.org/x/crypto (git) - 06a226f Use boolean tag (0x01) for boolean type.
```
and I don't see any fixes related to acme since that.


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/toaster/.cache/go-build"
GOENV="/home/toaster/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/opt/gopath/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/opt/gopath"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build034489393=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?
After calling `WaitOrder` for the order to be ready and authorizations to succeed, we call `CreateOrderCert` with the order's `FinalizeURL` and a freshly created CSR. We only call `CreateOrderCert` once.

### What did you expect to see?
I expect it to ignore this error when calling the finalize URL and continue to fetch the certificate since the order is Valid.

### What did you see instead?
 `CreateOrderCert` is returning:
```
403 urn:ietf:params:acme:error:orderNotReady: Order's status ('valid') is not acceptable for finalization
```

I imagine this is because of some retry logic that is not accounting for the fact that it's already valid. This just started happening today, I'm not sure if something changed on Let's Encrypt's end either.
Repository: rust
Issue: Type errors use 'expected' and 'found' in a confusing way
Labels: A-diagnostics,T-compiler,A-inference

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

Consider this snippet:

```rust
#[derive(Debug)]
struct SomeStuff {}

fn main() {
    let vec: Vec<SomeStuff> = vec![SomeStuff {}];

    vec.extend([
        SomeStuff {},
        SomeStuff {},
    ].into_iter());
}
```

This fails because `array.into_iter()` collapses to `(&array).into_iter()`, which provides a slice iterator that emits references, but `Vec::extend` wants values. This gives the following error:

```
error[E0271]: type mismatch resolving `<std::slice::Iter<'_, SomeStuff> as std::iter::IntoIterator>::Item == SomeStuff`
 --> src/main.rs:7:9
  |
7 |     vec.extend([
  |         ^^^^^^ expected reference, found struct `SomeStuff`
  |
  = note: expected reference `&SomeStuff`
                found struct `SomeStuff`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0271`.
error: could not compile `playground`.

To learn more, run the command again with --verbose.
```

This error, read naturally, seems to indicate that we *have* values but are *expecting* references. This confused a team member of mine today who didn't realize that arrays aren't iterable by-move. To quote:

> It seems to want a reference to the items but I can’t see why?
> ...
> Why would extend want a reference to the item? The vec needs ownership of the item at the end of the extend call.

From that perspective, the intuition is that the vec *wants* values, the array iterator is *providing* values, so why is the error message reporting that something is expecting a reference?

Additionally, while not strictly speaking part of the diagnostic, the first example in the docs (which is shown inline by rust-analyzer) looks like this:

![image](https://user-images.githubusercontent.com/1823405/97629122-05892f00-1a04-11eb-8451-0a7fce1fddc5.png)

This seems to show a slice being used without issue to extend something without explict copying or cloning. The disconnect is that `String: Extend<&char>`, but in this particular case it seemed to reinforce the idea that slices may be used to extend something by-move.

### Meta

This issue was originally reported in rust 1.46.0:

```
rustc 1.46.0 (04488afe3 2020-08-24)
binary: rustc
commit-hash: 04488afe34512aa4c33566eb16d8c912a3ae04f9
commit-date: 2020-08-24
host: x86_64-apple-darwin
release: 1.46.0
LLVM version: 10.0
```

However, I've also reproduced it in current stable:

```
rustc 1.47.0 (18bf6b4f0 2020-10-07)
binary: rustc
commit-hash: 18bf6b4f01a6feaf7259ba7cdae58031af1b7b39
commit-date: 2020-10-07
host: x86_64-apple-darwin
release: 1.47.0
LLVM version: 11.0
```

 and current nightly:

```
rustc 1.49.0-nightly (31530e5d1 2020-10-20)
binary: rustc
commit-hash: 31530e5d132ebcc3654baf2e5460599681520af0
commit-date: 2020-10-20
host: x86_64-apple-darwin
release: 1.49.0-nightly
LLVM version: 11.0
```
Repository: go
Issue: x/pkgsite: add copy option for pseudoversions
Labels: NeedsInvestigation,FeatureRequest,pkgsite,UX

<!--
Please answer these questions before submitting your issue. Thanks!
-->
 
### What is the URL of the page with the issue?
 
 Visited https://beta.pkg.go.dev/golang.org/x/tools
 
 
### Screenshot

![image](https://user-images.githubusercontent.com/5943521/97633883-2d2fc580-1a0b-11eb-95e9-01668e93c0d0.png)
 
 
### What did you expect to see?
 
 Ability to copy the full version string for golang.org/x/tools
 
### What did you see instead?

Typed "y" on the page to change the URL from https://beta.pkg.go.dev/golang.org/x/tools to https://beta.pkg.go.dev/golang.org/x/tools@v0.0.0-20201026223136-e84cfc6dd5ca, then copied full version string from my URL bar. 

It would be useful to have a copy option for the version string on the main page.