sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: Consolidate TextEditingValues in RenderEditable
Labels: a: text input,framework,c: proposal,P2,team-framework,triaged-framework

Currently, EditableTextState has several aliases of the same value, and I propose that they should be consolidated into one name.  All of the aliases are:

  1. [textEditingValue](https://github.com/flutter/flutter/blob/01dc9694be6461eb15bce4854c0253ef0362b1fb/packages/flutter/lib/src/widgets/editable_text.dart#L2524), which comes from the TextSelectionDelegateMixin [here](https://github.com/flutter/flutter/blob/01dc9694be6461eb15bce4854c0253ef0362b1fb/packages/flutter/lib/src/services/text_input.dart#L818).
  2. [currentTextEditingValue](https://github.com/flutter/flutter/blob/01dc9694be6461eb15bce4854c0253ef0362b1fb/packages/flutter/lib/src/widgets/editable_text.dart#L1730), which comes from the TextInputClient abstract class [here](https://github.com/flutter/flutter/blob/01dc9694be6461eb15bce4854c0253ef0362b1fb/packages/flutter/lib/src/services/text_input.dart#L880).
  3. [_value](https://github.com/flutter/flutter/blob/01dc9694be6461eb15bce4854c0253ef0362b1fb/packages/flutter/lib/src/widgets/editable_text.dart#L1992), which is local to EditableTextState.

All of these values one way or another point to `widget.controller.value`.  Let's consolidate them all, maybe to `textEditingValue`.  That may be a breaking change.
Repository: go
Issue: cmd/internal/obj/riscv: riscv64 compressed instructions
Labels: NeedsInvestigation,arch-riscv

The RISC-V architecture has support for compressed instructions - these are effectively a subset of the standard 4 byte long instructions, which fit in 2 bytes. These compressed instructions have limited functionality, however require half the code size.

Adding support to the assembler is relatively straight forward and from a code generation perspective, things work as expected and the binary runs. However, I keep hitting problems relating to the `pcdatavalue` tables while building toolchain3 - this is in the form of deadlock loops while generating tracebacks for inline functions, "runtime: invalid pc-encoded table" from symtab.go while handling async pre-empt, etc.

These all seems to suggest that the various PCDATA tables are wrong/broken, however as far as I can tell `p.Pc` is being set correctly in `cmd/internal/obj/riscv`. I would also expect that we handle variable instruction sizes (and variable `p.Pc` steps), given CISC architectures like x86.

Overall it seems like I'm missing something obvious - should things work if `p.Pc` is set correctly on a per `*obj.Prog` basis (even with multiple machine instructions with various widths being generated)?

Any suggestions regarding what else I should check?

(will mail out the work in progress code shortly)
Repository: rust
Issue: Unstable rustc internal attribute to disable optimizations on a module/function basis
Labels: C-enhancement,T-compiler,F-rustc_attrs

Occasionally, it would be nice to use a debugger with rustc. However, currently the options generally available are to either compile with optimizations enabled which makes debugging difficult but the compiler performs reasonably or to disable optimizations which greatly increases the debugability but makes rustc unbearably slow in many situations. 

It would be nice if we had the ability to to selectively disable optimizations at the function or module level via an attribute like `#[rustc_optnone]`. This would allow building most all of rustc with optimizations (thus retaining reasonable speed) while still allowing them to be disabled on a very small scale for the purpose of increased debugability.

Other compilers offer similar functionality:

- clang: `[[clang::optnone]]`
- gcc: `__attribute__((optimize("O0")))`
- msvc: `#pragma optimize( "", off )`

For the LLVM backend, we would just need to adjust the functions' attributes to [include `optnone`](https://llvm.org/docs/LangRef.html#function-attributes).
Repository: youtube-dl
Issue: Add script path to -v argument info.
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 2021.06.06. 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 **2021.06.06**
- [x] I've searched the bugtracker for similar feature requests including closed ones


## Description

If I want to get more info about youtube-dl I run `youtube-dl -v` which prints me all kinds of useful info. Would it be possible to add code there that prints out youtube-dl path on disk? For example  I installed it with  `pip install --upgrade youtube_dl` but I have hard time figuring out where the youtube-dl is located because the real life seems to be different from internet tutorials. 

solution would be to print `__file__` if it runs from script or `sys.executable` if it is compiled exe.
Repository: node
Issue: build: provide pre-built nodejs/node images or cache 
Labels: build

<!--
Thank you for suggesting an idea to make Node.js better.

Please fill in as much of the template below as you're able.
-->

**Is your feature request related to a problem? Please describe.**
Presently, making a small contribution to node.js core is particularly challenging. There are a number of contributing factors, but a primary one is simply having to build Node.js from scratch. For someone unfamiliar/new to Node.js, this can be particularly challenging compared to basically anything else in the JavaScript ecosystem.

**Describe the solution you'd like**
It would be a nice contributor experience enhancement to provide a pre-built image (containerd or Docker?) or some kind of cache that would help alleviate the pain of needing to build *completely* from scratch every single time.

One theoretical manifestation of how this _could_ work:

* Nightly, build a Docker container.
* This Docker container includes all necessary tools / nice-to-haves for building Node.js.
* This Docker container builds Node.js.

Containers provide some nice benefits: 

* We'd potentially be able to enhance *many* contributors' workflows.
* We'd enable a better experience through cloud-hosted developer environments like Codespaces that have the option to build from a container. 
* We could include [node-core-utils](https://github.com/nodejs/node-core-utils) and potentially enhance it further with something like a contributing checklist to ease first-time-contributor or early-contributor burden, effectively automating what's codified in the [PR guidance](https://github.com/nodejs/node/blob/master/doc/guides/contributing/pull-requests.md#setting-up-your-local-environment).

Or, we could do something in the vein of a cloud cache (in the vein of [goma](https://chromium.googlesource.com/infra/goma/client/)). While these require immense work, they are extremely useful and don't require you to run Docker. If there's more interest in this, I'm happy to see what resources I can pull from Microsoft (including potentially open sourcing some things) to enable it.

Either way, this is a build feature that seems to go in a positive direction that helps both new and existing contributors. Would love thoughts, if there are any.

**Describe alternatives you've considered**

Doing nothing: I mean this works but also retains an unnecessary bad experience.
Repository: electron
Issue: [Feature Request]: set up mockDbus for linux keyring tests
Labels: enhancement :sparkles:

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/master/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/master/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a feature request that matches the one I want to file, without success.

### Problem Description


Surfaced in #30020

* Currently many of our Linux CI tests - such as powerMonitor - depend on a mock dbus to mock out calls for tests. 
* However, using this mock dbus breaks the new Linux tests for safeStorage, because the mock dbus does not contain the mocked method that we need to access the keystorage needed to run encryption tests. 
* Present functionality limits our availability to create a KeyStorage when calling chromium's `os_crypt.CreateKeyStorage` API- specifically, our CI is unable to[ get the cached config
](https://source.chromium.org/chromium/chromium/src/+/main:components/os_crypt/os_crypt_linux.cc;l=74?q=os_crypt_&ss=chromium%2Fchromium%2Fsrc)


### Proposed Solution

To address this, we need to:
* Determine what method the dbus needs to access keystorage on Linux
* Mock the method in the mock dbus
* Determine how to access the keystorage in a reliable way on Linux using the mock (likely with the basic-string encryption option)


note: investigating the mocking of [networkManager](https://github.com/lucasdemarchi/python-dbusmock/blob/master/dbusmock/templates/networkmanager.py) may be a good place to start.

### Alternatives Considered

The linux tests currently pass locally when run on an actual Linux machine with a keystorage solution already set up. 

As an alternative, we could continue to manually test on maintainer machines. However, getting CI working would be a better long-term alternative

### Additional Information

The failure and limitations are further described [here](https://github.com/electron/electron/pull/30020/files#diff-01bf7d8e14c819304671f86818b2bade8ad00fde0d54f79b65fc6b0fb303cba2R9-R14)

To reproduce the issue regarding retrieving the cached config on linux, you can run the  tests in the above linked file on a linux distro

run these tests using `e test --runners=main -g safeStorage`
Repository: rust
Issue: Typecheck fails when providing explicit types instead of GAT
Labels: GATs-triaged,S-bug-has-test,A-GATs

<!--
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.
-->

I tried to compile this code:

```rust
#![feature(generic_associated_types)]

trait Scanner {
    type Input<'a>;
    type Token<'a>;
    
    fn scan<'a>(&mut self, i : Self::Input<'a>) -> Self::Token<'a>;
}

struct IdScanner();

impl Scanner for IdScanner {
    type Input<'a> = &'a str;
    type Token<'a> = &'a str;
    
    fn scan<'a>(&mut self, s : &'a str) -> &'a str {
        s
    }
}
```

I expected to see this happen:
The code compile successfully

Instead, this happened:
Rust could not match the lifetimes.
```
error[E0195]: lifetime parameters or bounds on method `scan` do not match the trait declaration
  --> src/lib.rs:16:12
   |
7  |     fn scan<'a>(&mut self, i : Self::Input<'a>) -> Self::Token<'a>;
   |            ---- lifetimes in impl do not match this method in trait
...
16 |     fn scan<'a>(&mut self, s : &'a str) -> &'a str {
   |            ^^^^ lifetimes do not match method in trait

For more information about this error, try `rustc --explain E0195`.
```

Changing the `impl` method to:
```rust
fn scan<'a>(&mut self, s : Self::Input<'a>) -> Self::Token<'a> {
```
Does compile successfully.

This seems somewhat related to #79207 and possibly in scope of #85499

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->
I tried this on nightly as well as with the latest code from #85499 [this commit](https://github.com/jackh726/rust/commit/1e59cf69f4967bd94d5a4b868e948d9bdc7839c4)
nightly:
```
rustc 1.56.0-nightly (492723897 2021-07-29)                                           
binary: rustc                                                                         
commit-hash: 492723897e9b4db6701b3a75b72618d08a7d5319                                 
commit-date: 2021-07-29                                                               
host: x86_64-apple-darwin                                                             
release: 1.56.0-nightly                                                               
LLVM version: 12.0.1
```

from jackh726:
```
rustc 1.55.0-dev                                                                      
binary: rustc                                                                         
commit-hash: unknown                                                                  
commit-date: unknown                                                                  
host: x86_64-apple-darwin                                                             
release: 1.55.0-dev                                                                   
LLVM version: 12.0.1
```
Repository: youtube-dl
Issue: Is it possible to Authorize a user as the owner of the channel or not without Youtube Data API
Labels: question

<!--

######################################################################
  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:
- Look through the README (http://yt-dl.org/readme) and FAQ (http://yt-dl.org/faq) for similar questions
- Search the bugtracker for similar questions: http://yt-dl.org/search-issues
- Finally, put x into all relevant boxes (like this [x])
-->

- [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

<!--
Ask your question in an arbitrary form. Please make sure it's worded well enough to be understood, see https://github.com/ytdl-org/youtube-dl#is-the-description-of-the-issue-itself-sufficient.
-->

I'm writing an application that does something related to archive work or more specifically video backups but in general any person could fetch/dump the whole channel and reupload to the backup service that's not quite suitable for my scenario

Is it possible to retrieve the channel ID from logged-in cookie file or any other way?
Repository: flutter
Issue: VisualDensity is inverted
Labels: framework,f: material design,c: proposal,team-design,triaged-design

From the description at [`ThemeData.visualDensity`](https://api.flutter.dev/flutter/material/ThemeData/visualDensity.html): 

> Density, in the context of a UI, is the vertical and horizontal "compactness" of the elements in the UI.

> ...negative values indicate a denser, more compact, UI, and positive values indicate a less dense, more expanded, UI.

> A larger value translates to a spacing increase (less dense), and a smaller value translates to a spacing decrease (more dense).

Is this not inconsistent? How can you say that "a larger value [of `visualDensity`] translates to a spacing increase (less dense)" and vice versa? A higher value for a variable called "density" should _increase_ density! I don't know how many Flutter widgets use this property already, but this should probably be fixed sooner rather than later. 

I noticed that [material.io](https://material.io/design/layout/applying-density.html#components) gets this wrong too (emphasis mine):
> The density scale allows you to control the density of individual components when needed.
> 
> The density scale is numbered, starting at 0 for a component’s default density. The scale moves to negative numbers (-1, -2, -3) as space decreases, creating higher density. **_Each increment represents a decrease in the height of a component by 4dps._** 

Seems like both pages are really describing _spacing_, not density. 

## Proposal

Invert the definition of density such that higher values actually correlate to a higher density. 

~Should I file an issue at https://github.com/material-components/material-components as well?~
**EDIT**: I opened an issue there, see https://github.com/material-components/material-components/issues/100
Repository: pytorch
Issue: allow specification of variadic arguments in native_functions.yaml
Labels: module: internals,triaged

## 🚀 Feature
Variadic arguments are quite Pythonic and feature in a few of our operators, e.g. `broadcast_tensors`, `broadcast_shapes`, `einsum`, `meshgrid`, `cartesian_prod`, etc. They should be expressible in native_functions.yaml.

## Motivation
We have a few wrappers in the `torch.functional` module that are not documented. These would be unnecessary if native_functions.yaml could handle the job.

## Pitch

Add support for variadic arguments in native functions. It need not generate c++ functions that take variadic arguments, the dispatcher could still send a `TensorList` or `std::vector` down to the implementation. This is akin to how we support keyword arguments, but don't try to generate keyword arguments in C++ (which is definitely not a C++ feature, but could be hacked poorly).

## Alternatives
preserve status quo: add wrappers as needed

It is likely we will continue to support variadic args if we intend to maintain numpy compatibility.

## Additional context

#62844 (filed by me) requests improved implementation comments explaining this.


cc @ezyang @bhosmer @smessmer @ljk53 @bdhirsh
Repository: deno
Issue: repl: parse error: Unexpected token `<eof>` (unfinished math expression)
Labels: repl,suggestion

## Reproduce
1. In Deno REPL, issue: `> 1 %`
2. See parse error.

<details>
<summary>Error description</summary>

```
parse error: Unexpected token 'eof'. Expected this, import, async, function, [ for array literal, { for object literal, @ for decorator, function, class, null, true, false, number, bigint, string, regexp, ` for template literal, (, or an identifier at 1:2
```
</details>

![grafik](https://user-images.githubusercontent.com/23178554/128422313-6b76729b-7bb0-4b21-9511-984c967f7bb8.png)

I would expect a new line, just like node does:
![grafik](https://user-images.githubusercontent.com/23178554/128422649-fe1baeed-a1fa-4617-a894-2b4f16379749.png)

Is this working as expected? Would this be eligible as enhancement for REPL?

- deno 1.12.2 (release, x86_64-unknown-linux-gnu)
- v8 9.2.230.14
- typescript 4.3.5
Repository: pytorch
Issue: slice_embed, select_embed like diag_embed
Labels: module: autograd,triaged,module: viewing and reshaping

## 🚀 Feature

We should add `slice_embed` and `select_embed` like `diag_embed`. Furthermore, we should make all three of these operators primitives w.r.t. autograd.

## Motivation

vmap has problems with `slice_backward` and `select_backward` because they decompose into some vmap-incompatible code that involves copy: https://github.com/pytorch/pytorch/blob/e62189ad698303dfd5d577ee437437182ae77918/aten/src/ATen/native/TensorShape.cpp#L1299-L1303. We should turn these into operators and give them backward formulas.

## Pitch

Add the following APIs:
```
Tensor slice_embed(const Tensor& slice, IntArrayRef size, int64_t dim, int64_t start, int64_t end, int64_t step);
Tensor select_embed(const Tensor& selection, IntArrayRef size, int64_t dim, int64_t index);
```
`select_embed` embeds the `selection` tensor in a new zeros Tensor of size `size`

Furthermore, write a backward formula for `slice_embed`, `select_embed`, and `diag_embed`.

## Alternatives

We could just write a backward formula for `slice_backward` and `select_backward` since those are already operators.


cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7
Repository: youtube-dl
Issue: Not downloading at 320 kBit/s bitrate
Labels: question

<!--

######################################################################
  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:
- Look through the README (http://yt-dl.org/readme) and FAQ (http://yt-dl.org/faq) for similar questions
- Search the bugtracker for similar questions: http://yt-dl.org/search-issues
- Finally, put x into all relevant boxes (like this [x])
-->

- [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

<!--
Ask your question in an arbitrary form. Please make sure it's worded well enough to be understood, see https://github.com/ytdl-org/youtube-dl#is-the-description-of-the-issue-itself-sufficient.
-->

WRITE QUESTION HERE
Is anyone having the same issue?
I tried to download songs as mp3 files with the best audio (320 kBit/s in the case of YouTube) and eventought i tried parameters like "--audio-quality 0", "-f bestaudio", I couldn't get any mp3 file at 320 kBit/s. They were usually around 256kBit/s and some even really low. Eventhough i always used "--audio-format mp3" it also gave me other formats sometimes. So I dont know if it is an issue on my end or if something is broken. The website i used before it got shut down, used to give me 320 kBit/s so it is supported by YouTube.
Repository: flutter
Issue: InkWell.borderRadius should support BorderRadiusGeometry
Labels: framework,f: material design,a: internationalization,a: quality,P3,team-design,triaged-design