sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: Issues leading to rebuilding more of the RenderObject and Layer trees than necessary
Labels: framework,c: performance,perf: speed,P2,team-framework,triaged-framework

Flutter consists of a number of levels of trees (as described in the [Mahogany Staircase talk](https://www.youtube.com/watch?v=dkyY9WCGMi0)). When a change is made to the Widget tree, those changes must be propagated into the Element, RenderObject, and Layer trees. Each level has code that attempts to reuse parts of the lower level trees on each pass to minimize the work. Unfortunately, there is still a lot of rebuilding going on for some simple changes to a tree, and a fair bit of developer involvement in minimizing the effect in their apps. In particular:

- One of the few tools at the disposal of the developer for minimizing the scope of rebuilds is the RepaintBoundary which acts as a wall between parts of the tree to keep a change inside its children from causing a rebuild of any of the widgets outside of it (and vice versa).
- Animating widgets don't protect their children or ancestors by default, but require the developer to insert a RepaintBoundary to keep their constant rebuilds from affecting the rest of the tree.
- One of the most common inter-dependencies between RenderObjects is the sharing of paint commands being dealt to a single shared Picture object. The Picture object will be shared from the first RenderObject that issues a paint command all the way until the end of the tree or until the first RenderObject that requires an engine layer to be pushed to do its work. The Picture can be shared outside of the scope of the first RenderObject that initiated it as it is shared across any subset of the flattened tree traversal with no regard to scope. If any of these RenderObjects needs to change what it painted then all of them must repaint. If there is a RepaintBoundary somewhere in the list, then that will break the Picture into multiple Picture objects and reduce the scope of sharing and repainting, but this requires detection by the app developer and a change to their Widget hierarchy.

These are some of the issues discovered while attempting to minimize repaints at the engine level (see https://github.com/flutter/flutter/issues/33939) and represent areas where we could achieve better efficiency both for minimizing the work done at the framework level when a widget changes and, by extension, the work needed to repaint the scene.
Repository: TypeScript
Issue: Enumerating an enum: Wrong thing is allowed and right thing is not with with noImplicityAny
Labels: Suggestion,Needs Proposal

Consider this code:

enum Test1 {
  One = 1,
  Two = 2
}
enum Test2 {
  One = "one",
  Two = 2
}
enum Test3 {
  One = "one",
  Two = "two"
}
for (const key **in** Test1) {
  const aValue = Test1[key];
  console.log(aValue);
}

This code compiles but because in an enum a reverse value->key map is also set up **for numeric values**, the outcome is not what one would expect: 1, 2. It's: One, Two, 1, 2 instead. Similarly, replacing Test1 with Test2 in the for..in loop compiles but gives unexpected result: "Two", "one", 2. However, with Test3, for which the result would've been correct: "one", "two", there's a compile error with the noImplicitAny compiler option:

Element implicitly has an 'any' type because expression of type 'string' can't be used to index type 'typeof Test3'.
  No index signature with a parameter of type 'string' was found on type 'typeof Test3'.

This seems backwards of what the behavior should be: With Test1 and Test2, the compile should fail and it should succeed with Test3. If not that, the compile should either fail or succeed with all 3. FYI, the reason I noticed this was because converting an all numeric enum to all string enum caused compile failure for some other code that was using "for..in" which originally had a logical flaw which the compiler didn't catch but it's flagging it now when the logical flaw has (inadvertently) been fixed.

It seems like there are at least a couple of independent problems here.

1. With enums that have at least one numeric member (Test1 and Test2), the inferred type of loop variable (key) should ideally be the union of all keys and **numeric** values or at least string | number, not just string.

2. Indexing enums by a string (that cannot be narrowed down specific literals representing keys of an enum) should consistently  return any. It may acceptable to return union type of all possible values: number for Test1, string|number for Test2 and string for Test3 and not string for Test1 and Test2 and any for Test3.

3. In addition to the issues above, a for..in over an enum should somehow be flagged and fail to compile regardless of noImplicitAny flag because it only yields the expected result in the enum has all string values but even with all string-enums, that would be fragile as adding a single numeric value to the enum will cause compile failures at that point. It should just not be allowed at least by default.

Issue #18409 seems related but not quite the same.
Repository: pytorch
Issue: Implement LSH Optimizations for Enhanced CPU-Only Performance
Labels: module: performance,feature,module: cpu,triaged,needs research

I am writing to inquire if the PyTorch team has any interest or plans for implementing locality sensitive hashing based optimizations for enhanced CPU only performance and reduced overall computational resource consumption as detailed in this paper?

https://www.cs.rice.edu/~as143/Papers/SLIDE_MLSys.pdf

It would appear that these techniques have reached a level maturity to consider implementation and that this would be a great benefit to reducing the GPU barrier of entry for developers, reduce complexity and expense for both training and deploying large deep learning models, and also reduce waste in terms of not only hardware expense but also energy usage and ecological impact.


cc @VitalyFedyunin @ngimel
Repository: go
Issue: x/tools/gopls: consider disambiguating same-score completion candidates using candidate length
Labels: gopls,Tools

Currently completion candidates are sorted by score, and then secondarily sorted lexicographically to provide a predictable order. I propose we instead do a secondary sort by candidate length, preferring shorter candidates. My intuition is that shorter names are used more frequently than longer names, so it is a somewhat better heuristic to put shorter items first, all else being equal.

Edit: Note that this proposal only comes in to play when candidates have identical scores. Currently the tie-break sorting is alphabetical; I'm proposing we switch to a potentially better heuristic. This will have a very small impact in general.

Contrived example:

```go
package main

type myStr struct {
	s string
}

func (m myStr) Get() string {
	return m.s
}

type foo struct {
	ID         myStr
	AardvarkID myStr
}

func main() {
	var f foo
	var _ string = f      // want "f.ID.s" but got "f.AardvarkID.s"
	var _ string = fidget // want "f.ID.Get()" but got "f.AardvarkID.Get()"
}
```

/cc @heschik because you had an opinion in slack
Repository: excalidraw
Issue: sentry doesn't map source for console.error events
Labels: bug

Stack traces coming from `console.error` logged to sentry aren't using source maps for some reason.
Repository: pytorch
Issue: momentum in BatchNorm
Labels: module: docs,module: nn,triaged,needs research

# 📚 Documentation

## PyTorch docs

What's going on with `momentum` in BatchNorm? `0.9` of momentum means I keep `0.9` of the old stuff and add `0.1` of the new one. Why is it reversed here? `momentum` equal `0` means I'm running with no memory of the past.

Also, the default value is way off! It should be `0.99`, not `0.9`.

![image](https://user-images.githubusercontent.com/2119355/87723066-34e29b80-c787-11ea-86c1-1eea693fd377.png)
![image](https://user-images.githubusercontent.com/2119355/87722818-c43b7f00-c786-11ea-9452-d8b1d503a2cc.png)

## Keras docs

A more sensible approach.

![image](https://user-images.githubusercontent.com/2119355/87723043-298f7000-c787-11ea-84fe-3a5f09f5c2c8.png)


cc @jlin27 @albanD @mruberry
Repository: pytorch
Issue: [RPC] Should we support users _not_ calling rpc.shutdown()?
Labels: triaged,module: rpc

In https://github.com/pytorch/pytorch/issues/41474 we saw that due to global static variables being destroyed in a certain order, not calling `rpc.shutdown()` explicitly before terminating a program could cause a SIGABRT. The problem comes from a event loop thread of TensorPipe trying to acquire a glog mutex that may be already gone. Avoiding this might be complicated, so before we attempt it, let's clarify whether this is even a supported scenario or whether we require users to always shut down explicitly.

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @rohan-varma @xush6528 @jjlilley @osalpekar @jiayisuse
Repository: flutter
Issue: Run clang tidy on more targets
Labels: c: new feature,team,engine,P3,team-engine,triaged-engine

Today, we run clang-tidy on the host sources only on Linux.

This means we miss the following variants:

- [ ] macOS desktop
- [x] iOS embedding
- [x] Android embedding
- [ ] Fuchsia
- [ ] Windows desktop

It would be great to enable it for these variants.
Repository: flutter
Issue: Filter MacStadium bots from analytics
Labels: c: new feature,team,tool,P3,team-tool,triaged-tool

Since June 1, there has been a disproportionate spike in analytics events coming from Atlanta, GA. The events report themselves to be from Mac devices, which indicates that they are probably CI bots in the MacStadium datacenter there. We need to filter these out in the Flutter tool's bot detector.
Repository: flutter
Issue: `flutter channel` output channels that can't be used later
Labels: tool,P2,team-tool,triaged-tool

For example, `flutter channel` prints:

```
  flutter-0.0-candidate.1
  flutter-1.19-candidate.2
  flutter-1.19-candidate.3
  flutter-1.19-candidate.4
  flutter-1.19-candidate.5
  flutter-1.20-candidate.0
  flutter-1.20-candidate.1
  flutter-1.20-candidate.2
  flutter-1.20-candidate.3
  flutter-1.20-candidate.3.renyou_experiment
  flutter-1.20-candidate.4
  flutter-1.20-candidate.5
  flutter-1.20-candidate.6
  flutter-1.20-candidate.7
....
```

However, `flutter channel   flutter-1.20-candidate.7` outputs:

```
Switching to flutter channel 'flutter-1.20-candidate.7'...
This is not an official channel. For a list of available channels, try "flutter channel".
git: fatal: 'origin/flutter-1.20-candidate.7' is not a commit and a branch 'flutter-1.20-candidate.7' cannot be created from it
Switching channels failed with error code 128.
```
Repository: deno
Issue: Dynamically generating import maps
Labels: cli,suggestion

There’s a pattern emerging for creating cross-platform ESM modules using the `exports` property in `package.json`. To be perfectly honest, I wish there were a conditional import syntax for this use case instead, but there isn’t so this is what we’ve got.

Rollup, webpack, and of course Node.js, all now support this property.

This means that internally in the module, and in the module’s tests, you can’t use relative imports but instead have to use the package name because relative imports skip the export map loader. And of course, tests all have to do the same. 

The nice part of authoring this way is that my modules and all the tests can be run and loaded in the browser and Node.js without a compiler, and the module works as expected when people consume it **with** a compiler.

When I run tests in the browser I generate an export map and stick it in the page before loading my tests.

Similarly, I can generate an import map for Deno and pass it as a command line flag.

The thing is though, I have my test runner **running in Deno natively**. I’d like to generate an import map from package.json **in Deno** and then load it, rather than passing as a command line flag because that would require another subprocess launch and additional permissions.

There are security concerns here. The browser doesn’t allow dynamic import map loading, it requires that it’s in the page you load from the origin. Perhaps something similar could be done with Deno by passing a `.js` or `.ts` file instead of `.json` file as the importMap argument? There could be an API in `Deno` to set the import map and it would only be accessible to that module, creating a similar security pattern to what the browser uses. Or the default export of that file could be the import map?

Thoughts?
Repository: rust
Issue: Spotlight shows traits with generic impls that do not apply to the specific type
Labels: T-rustdoc

In both these cases, the mutability or the generic parameter is not dealt with when showing spotlight impls:


![image](https://user-images.githubusercontent.com/1617736/87731617-d36afe80-c77f-11ea-99e9-b372c64735c6.png)
![image](https://user-images.githubusercontent.com/1617736/87731628-d534c200-c77f-11ea-86c4-420b6d1dbe15.png)


https://github.com/rust-lang/rust/pull/74370#discussion_r455233545

We should do something similar to what we do for  auto traits and blanket impls.
Repository: neovim
Issue: :terminal scrolls if scrollback is full
Labels: enhancement,terminal,has:workaround

<!-- Before reporting: search existing issues and check the FAQ. -->

- `:ver`:
```
NVIM v0.4.3
Build type: Release
LuaJIT 2.0.5
Compilation: /usr/bin/cc -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -O2 -DNDEBUG -DMIN_LOG_LEVEL=3 -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fdiagnostics-color=always -DINCLUDE_GE
NERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -I/build/neovim/src/build/config -I/build/neovim/src/neovim-0.4.3/src -I/usr/include -I/build/neovim/src/build/src/nvim/auto -I/build/neovim/src/build/include
Compiled by builduser

Features: +acl +iconv +tui
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/share/nvim"
```
- `vim -u DEFAULTS` (version: 8.2) behaves differently?

Yes, vim pauses rendering new lines of input in its terminal buffers when you go into normal mode, but I assume this is because it has a very different implementation than Neovim.

- Operating system/version: Arch Linux
- Terminal name/version: mintty (wsltty)
- `$TERM`: xterm-256color

### Steps to reproduce using `nvim -u NORC`

```
nvim -u NORC
:terminal
seq 100000
# then very quickly afterwards,
<C-\><C-n>
<C-b><C-b><C-b>
```

### Actual behaviour

Cursor should stay on the same number.

### Expected behaviour

The cursor is scrolled downwards as lines past 10000 are dropped.
Repository: pytorch
Issue: torch.cuda.BoolTensor uses 8 bits per element, not 1 bit as reported by element_size()
Labels: module: docs,triaged

## 🐛 Bug

I could not find this in the documentation, but it seems like `torch.cuda.BoolTensor` actually uses a byte for each element instead of a bit.

## To Reproduce

Steps to reproduce the behavior:

```python
import torch
x = torch.empty([], device="cuda") # load something on GPU to get a baseline
# running nvidia-smi, I see the GPU has 715 MiB of RAM in use
# let's create a tensor which should take 10 MiB:
x = torch.empty(10*8*1024**2, dtype=torch.bool, device="cuda")
assert x.element_size() == 1
# running nvidia-smi, the GPU has 795 MiB of RAM used, or ~ 80 MiB additional (instead of the 10 MiB expected)
```

Checking repeatedly with different sizes of tensors indicated that a `torch.cuda.BoolTensor` takes 8 bits per element on GPU.

## Expected behavior

Either `torch.cuda.BoolTensor` should only take 1 bit per element (not sure if there is a GPU limitation here) or `x.element_size()` should return 8

## Environment

PyTorch version: 1.5.1
Is debug build: No
CUDA used to build PyTorch: 10.1

OS: CentOS Linux release 7.6.1810 (Core)
GCC version: (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)
CMake version: version 2.8.12.2

Python version: 3.7
Is CUDA available: Yes
CUDA runtime version: 10.1.168
GPU models and configuration:
GPU 0: GeForce RTX 2080 Ti

Nvidia driver version: 418.87.00
cuDNN version: Could not collect

Versions of relevant libraries:
[pip3] numpy==1.18.5
[pip3] pytorch-utils==0.1
[pip3] torch==1.5.1
[conda] blas                      1.0                         mkl
[conda] cudatoolkit               10.1.243             h6bb024c_0
[conda] mkl                       2020.1                      217
[conda] mkl-service               2.3.0            py37he904b0f_0
[conda] mkl_fft                   1.1.0            py37h23d657b_0
[conda] mkl_random                1.1.1            py37h0573a6f_0
[conda] numpy                     1.18.5           py37ha1c710e_0
[conda] numpy-base                1.18.5           py37hde5b4d6_0
[conda] pytorch                   1.5.1           py3.7_cuda10.1.243_cudnn7.6.3_0    pytorch
[conda] pytorch-utils             0.1                       dev_0    <develop>

cc @jlin27
Repository: youtube-dl
Issue: Get formats and thumbnails and title in one call
Labels: question

## Checklist
- [x] I'm asking a question
- [x] I've looked through the README and FAQ for similar questions
- [x] I've searched the bugtracker for similar questions including closed ones


## Question
e.g:  youtube-dl.exe --get-title --list-thumbnails --list-formats URL
It seems if I combine these options, I get "No info from page"
This means I need to call 3 times and combine all output
Repository: youtube-dl
Issue: Option to write number of audio channels into filename
Labels: request

<!--

######################################################################
  WARNING!
  IGNORING THE FOLLOWING TEMPLATE WILL RESULT IN ISSUE CLOSED AS INCOMPLETE
######################################################################

-->


## Checklist

<!--
Carefully read and work through this check list in order to prevent the most common mistakes and misuse of youtube-dl:
- First of, make sure you are using the latest version of youtube-dl. Run `youtube-dl --version` and ensure your version is 2020.06.16.1. If it's not, see https://yt-dl.org/update on how to update. Issues with outdated version will be REJECTED.
- Search the bugtracker for similar feature requests: http://yt-dl.org/search-issues. DO NOT post duplicates.
- Finally, put x into all relevant boxes (like this [x])
-->

- [x] I'm reporting a feature request
- [x] I've verified that I'm running youtube-dl version **2020.06.16.1**
- [x] I've searched the bugtracker for similar feature requests including closed ones


## Description

<!--
Provide an explanation of your issue in an arbitrary form. Please make sure the description is worded well enough to be understood, see https://github.com/ytdl-org/youtube-dl#is-the-description-of-the-issue-itself-sufficient. Provide any additional information, suggested solution and as much context and examples as possible.
-->

WRITE DESCRIPTION HERE

Please add the ability for the program to automatically put the number of audio channels into the filename when downloading videos from YouTube. Some videos are 1 channel and some are 2 channels.
Repository: storybook
Issue: Generating source maps slow the build significantly, should they be opt-in?
Labels: performance issue,build-storybook

**Is your feature request related to a problem? Please describe.**
I'm looking to optimise the time taken by `build-storybook`. Simply setting the `devtool` webpack option to `undefined` reduces my build times by half.

**Describe the solution you'd like**
I'd argue the average storybook user would benefit more from faster builds than they would from source maps. Therefore, I think source maps should be an opt-in feature due to the performance gains in not generating them. Obviously this might be controversial, so I'd love to hear any thoughts on this.

**Describe alternatives you've considered**
N/A

**Are you able to assist bring the feature to reality?**
Sure!
Repository: rust
Issue: Consider changing "mono item" terminology
Labels: C-cleanup,A-codegen,T-compiler,-Zpolymorphize

Requested by @eddyb in [this comment](https://github.com/rust-lang/rust/pull/69749#discussion_r455909581). After polymorphisation (#69749) lands, mono items may not actually be monomorphic and so it might be worth changing the terminology here, e.g. "codegen item".
Repository: TypeScript
Issue: Suggestion: noInferredAny
Labels: Suggestion,Needs Proposal

####  Search Terms

noImplicitAny inference any noInferredAny

## Suggestion

Symbols typed as `any` reduce the type safety of a program. That's fair if the programmer intended to use `any`. However it's relatively easy to end up with symbols typed `any` through type inference chains that are not obvious:

* 3rd party libraries might return `any`
* complex type expressions might infer to any
* some `.d.ts` types default generic arguments to `any` (e.g. `Set`)

In all these situations, a programmer might write `const foo = something();` and expect `foo` to have a reasonable inferred type. `foo` being inferred to `any` is easy to miss in such code, both while editing and while reviewing code.

Proposal: add a compiler option `noInferredAny` that flags symbols whose type is any and that do not have an explicit type annotation.

## Use Cases

* better type safety for programs
* detect weak typings in your dependencies
* more 

## Examples

```ts
const foo1 = returnsAny();  // error
const foo2: any = returnsAny(); // ok
const foo3: string = returnsAny(); // probably ok, programmer gave an explicit type? could also require an explicit cast.
const foo4 = returnsAny() as string;  // ok

const {foo5}: {foo5: string} = returnsAny(); // ok
```

## Checklist

My suggestion meets these guidelines:

* [ ] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).