sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: [folding] clicking on on line number of folded line should select full folding range
Labels: help wanted,feature-request,editor-folding

Issue Type: <b>Bug</b>
1. Fold an area (e.g. a block in JSON) to a line
2. Click the margin of the folded line
3. Try to drag the mouse to select the whole folded area

**Expected**:
Can select (only) the whole folded area

**Actual**:
It's either the first line of folded area, or the whole folded area **and** next line.

Other editors do not have this problem, but the solutions are different:
- Visual Studio: The whole folded area is selected when you click the margin
- Sublime Text: When you drag down, it expands the selection from first line to the whole folded area. If you keep dragging, it will expand the selection to include next line.

**Workaround**:
Click the beginning of the folded line, drag to the beginning of the next line. It works, but requires much more mouse precision than clicking/dragging in margin area.

**Suggestion**:
A simple question: how often do you want to select **only** the first line when you click the margin of **folded** area? I believe it's very rare, so Visual Studio's solution is desired.

VS Code version: Code 1.27.2 (f46c4c469d6e6d8c46f268d1553c5dc4b475840f, 2018-09-12T16:17:45.060Z)
OS version: Windows_NT x64 10.0.17134

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i7-8705G CPU @ 3.10GHz (8 x 3096)|
|GPU Status|2d_canvas: enabled<br>checker_imaging: disabled_off<br>flash_3d: enabled<br>flash_stage3d: enabled<br>flash_stage3d_baseline: enabled<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>native_gpu_memory_buffers: disabled_software<br>rasterization: enabled<br>video_decode: enabled<br>video_encode: enabled<br>webgl: enabled<br>webgl2: unavailable_off|
|Memory (System)|15.85GB (4.97GB free)|
|Process Argv|C:\Program Files\Microsoft VS Code\Code.exe D:\Repos\modern\NovaApi|
|Screen Reader|no|
|VM|0%|

</details>
<!-- generated by issue reporter -->
Repository: pytorch
Issue: [Feature] Support Adaptive Max Gradient Norm / Clipping
Labels: triaged,enhancement,module: norms and normalization

## 🚀 Feature
This feature is to use a moving windowed median or exponential moving average for gradient clipping and normalization. 

Additionally, it'd be nice to support batch skipping if the gradient norm is above a threshold which is usually an indication of an imminent gradient explosion.

## Motivation

The threshold for gradient clipping is a hyperparameter that needs to be set uniquely for each model. However, its supported by at least two important and well-written papers that I know of that this parameter can be set automatically:
- https://arxiv.org/abs/1212.0901 "The cutoff threshold for gradient clipping is set based on the average norm of the gradient over one pass on the data"
- https://arxiv.org/abs/1804.09849 "To further stabilize training, we also use adaptive gradient clipping. We discard a training step completely if an anomaly in the gradient norm value is detected, which is usually an indication of an imminent gradient explosion. More specifically, we keep track of a moving average and a moving standard deviation of the log of the gradient norm values, and we abort a step if the norm of the gradient exceeds four standard deviations of the moving average."

In addition, I've found in my own experiments in audio synthesis that setting the parameter automatically is helpful.

## Pitch

Implement a gradient clipping module that stores an internal state used for deciding the threshold for clipping.
Repository: javascript-algorithms
Issue: Add Persistent Vector?
Labels: enhancement

I would like to contribute to adding [persistent vector](http://www.hypirion.com/musings/understanding-persistent-vector-pt-1), it's a cool immutable data structure. Thumbs up if it interests you.
Repository: go
Issue: x/net/http2: Ability to set initial flow control in transport.
Labels: NeedsInvestigation,FeatureRequest

### What version of Go are you using (`go version`)?
Go 1.11

### Does this issue reproduce with the latest release?
Yes

### What operating system and processor architecture are you using (`go env`)?
linux + darwin on amd64 and android on arm.

### What did you do?
Made an http2 request.

### What did you expect to see?
This is a feature request.

### What did you see instead?
Configurable values such as in the Server but for thetransport would be great :D
As the latency gets higher this has a sizable effect.
Currently it is at some huge value for connection and 4MB for stream. In a server that does lots of calls out that might want to be reduced, and in known high latency cases it may go up.
Repository: opencv
Issue: Allow contributors to request reviews
Labels: category: infrastructure

I believe there is no harm to allow contributors to request a review after creating a PR.
Repository: rust
Issue: Borrow checker extends borrow range in code with early return
Labels: A-borrow-checker,T-compiler,A-NLL,C-bug,fixed-by-polonius

Borrow checker seems to extend mutable borrow of variable to the end of the function in case of an early return of value dependent on the borrow:
```rust
fn foo(x: &mut u8) -> Option<&u8> {
    if let Some(y) = bar(x) {
        return Some(y) // comment this out to calm compiler
    }
    bar(x)
}

fn bar(x: &mut u8) -> Option<&u8> { Some(x) }
```
Gives:
```
error[E0499]: cannot borrow `*x` as mutable more than once at a time
 --> src/main.rs:7:9
  |
4 |     if let Some(y) = bar(x) {
  |                          - first mutable borrow occurs here
...
7 |     bar(x)
  |         ^ second mutable borrow occurs here
8 | }
  | - first borrow ends here
```
Compilation fails on stable, nightly and nightly with NLL, works on nightly with polonius.
[Try it on Playground](https://play.rust-lang.org/?gist=166bc56651e9f52726237066d06624df)
Repository: rust
Issue: Incorrect information attached to slice::from_ref
Labels: T-rustdoc

Head over on the official documentation of [slice::from_ref](https://doc.rust-lang.org/std/slice/fn.from_ref.html). There’s a small information bubble that will trigger the following, confusing information:

![img_092918_180315](https://user-images.githubusercontent.com/506592/46247886-2c826a80-c412-11e8-9360-9e37438f9f8e.png)

I think other functions from the `std` have this problem as well and this might be due to some macro or code generation.

Cheers! :beers:
Repository: material-ui
Issue: [colorManipulator][docs] Document the color helpers
Labels: new feature,docs,package: system

<!-- Checked checkbox should look like this: [x] -->
- [x] This is not a v0.x issue. <!-- (v0.x is no longer maintained) -->
- [x] I have searched the [issues](https://github.com/mui-org/material-ui/issues) of this repository and believe that this is not a duplicate.

## Expected Behavior

I've done a comparison of various JS color utility libraries. I found that `@material-ui/core/es/styles/colorManipulator.js` offers the smallest bundle size of all options I could find. Here's a comparison to other libraries (all numbers are minified; second number is minified + gzipped):

- colorManipulator.js // 3.02kb, 1.25 gzipped
- [kewler](https://github.com/adriantoine/kewler) // 7.24kb, 2.7kb gzipped
- [spectra](https://github.com/avp/spectra) // 10.5kb, 3.38kb gzipped
- [tinycolor2](https://github.com/bgrins/TinyColor) // 15.2kb, 5.28kb gzipped
- [color](https://github.com/Qix-/color) // 23.1kb, 7.83kb gzipped
- [chroma-js](https://github.com/gka/chroma.js/) // 39.8, 15.9kb gzipped

## Current Behavior

@oliviertassinari has stated that the color manipulator is a [private API](https://github.com/mui-org/material-ui/issues/10789#issuecomment-375892148). He also openly asked if there were better open-source alternatives to the private implementation. In my view, there is no better alternative. colorManipulator.js offers basically identical functionality to all of the other libraries, and does it in the fewest amount of bytes.

## Context

Color Manipulation is a very generic problem, this library has the best solution, but it is a private API. I think it could be easily publishable as a separate entity within the mono-repo structure. It's already fully unit tested, so there could be no disagreement that it would be in a good state to make publicly accessible.
Repository: create-react-app
Issue: Write high performance webpack loader worker
Labels: contributions: up for grabs!,tag: enhancement,difficulty: complex

x-ref: #5170

It'd be nice to write a high performance webpack worker that uses shared memory instead of IPC, automatic caching with customizable cache identifier, and anything else to make it really robust.
Repository: vscode
Issue: [scss] No autocomplete for built-in functions inside maps
Labels: feature-request,css-less-scss

Issue Type: <b>Bug</b>

```sass
$something: #fff;
$map: (
    key: transparentize($something, 0.4),
);
```
There is no autocomplete for `transparentize` and some other functions (`mix`, `lighten`, `darken`, `red`, `rgb`, `saturate` ...)  inside the map definition.

---
VS Code version: Code - Insiders 1.28.0-insider (caaa5369cb4d22b7481e6ff97252cf92937709eb, 2018-09-28T05:18:20.266Z)
OS version: Windows_NT x64 10.0.17134


<!-- generated by issue reporter -->
Repository: rust
Issue: No warning given when mutability unnecessary in match arm pattern with mutable reference
Labels: A-lints

The compiler doesn't notice and/or warn that a mutable reference in a match arm pattern doesn't need to be mutable.

I tried this code:

```rust
fn main() {
    let mut option = Some(Box::new(0));
    match option {
        Some(ref mut v) => println!("{}", v),
        None => (),
    };
}
```

I expected to see this happen: The compiler would give a warning, saying that `mut` is unnecessary in the first match arm.

Instead, this happened: The compiler gives no warnings.

## Meta

`rustc --version --verbose`:
```
rustc 1.27.0 (3eda71b00 2018-06-19)
binary: rustc
commit-hash: 3eda71b00ad48d7bf4eef4c443e7f611fd061418
commit-date: 2018-06-19
host: x86_64-apple-darwin
release: 1.27.0
LLVM version: 6.0
```
Repository: TypeScript
Issue: Inconsistent error messages with circular base type argument
Labels: Suggestion,In Discussion

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

I noticed [here](https://stackoverflow.com/a/52573647) that a type argument to a base class can reference property types in the same class, so I wondered what would happen if I tried to reference an inherited property type that itself depends on the type argument.  To its credit, the compiler didn't crash, but the errors I got didn't make much sense.

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  master (e1a4c2779f93c8389d1589e543920a61771e97ec)

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** circular self referential base extends type argument property same class lookup type

**Code**
```ts
class Super<T> {
  foo!: T;
}
class Sub extends Super<Sub["bar"]> {
  bar!: Sub["foo"];  // Actual: Error: "Property 'foo' does not exist on type 'Sub'."
  baz!: Sub["foo"];  // Actual: No error
}
```

**Expected behavior:** An error that indicates that circular type annotations are involved.

**Actual behavior:** As marked.

**Playground Link:** [link](https://www.typescriptlang.org/play/#src=class%20Super%3CT%3E%20%7B%0A%20%20foo!%3A%20T%3B%0A%7D%0Aclass%20Sub%20extends%20Super%3CSub%5B%22bar%22%5D%3E%20%7B%0A%20%20bar!%3A%20Sub%5B%22foo%22%5D%3B%20%20%2F%2F%20Actual%3A%20Error%3A%20%22Property%20'foo'%20does%20not%20exist%20on%20type%20'Sub'.%22%0A%20%20baz!%3A%20Sub%5B%22foo%22%5D%3B%20%20%2F%2F%20Actual%3A%20No%20error%0A%7D%0A)

**Related Issues:** None found, but this is hard to search for.
Repository: opencv
Issue: Support for INTER_LINEAR_EXACT for cv::remap
Labels: feature,category: imgproc

So, I learned the hard way that INTER_LINEAR does not just do bilinear interpolation in cv::remap, but fixpoints the maps first and then does bilinear interpolation. In the documentation of interpolation modes, there is INTER_LINEAR_EXACT, claiming to be a bitexact variant. Unfortunately (4.0.0-alpha), this is not supported for cv::remap (it is for resize, but I need it for remap). I have not found a way around this, I had to write my own variant of remap not doing the fixpointing (which is way less effective, but gives the right result).

I suggest INTER_LINEAR_EXACT should be implemented for cv::remap.
Repository: opencv
Issue: No way to get the properties of a video when using cuda::videoreader.
Labels: wontfix,category: gpu/cuda (contrib)


- OpenCV => 3.4.3

##### Detailed description
The videocapture class provides with several methods to get the properties of a video.
https://docs.opencv.org/2.4/modules/highgui/doc/reading_and_writing_images_and_video.html#videocapture-get

They seem to be missing in the videoreader class. This should be supported IMO.
##### Steps to reproduce
Repository: flutter
Issue: How to know a specific widget in listview scrolling out of screen?
Labels: c: new feature,framework,f: scrolling,P3,team-framework,triaged-framework

Is there a callback or event can handle this?
Repository: create-react-app
Issue: Add notes about runtime chunk being inlined and implications
Labels: tag: documentation,difficulty: starter,contributions: claimed

https://github.com/facebook/create-react-app/issues/5144#event-1875612638

Has implications for CSP.
Repository: create-react-app
Issue: Documentation follow-up
Labels: tag: documentation

Copied from #5141:

- [ ] Update React's "Add React to Website" JSX section
- [ ] Prepare blog post
- [ ] Touch up migration guide from 1.x
- [ ] Make a decent migration guide from 2.x betas
  - [ ] Monorepo migration (https://github.com/facebook/create-react-app/issues/5100)
- [ ] Check and document Apollo (https://github.com/facebook/create-react-app/issues/5126) and Relay support
- [ ] MDX https://github.com/facebook/create-react-app/issues/5149
Repository: puppeteer
Issue: [Feature Request] Provide way to access stack trace on ConsoleMessage
Labels: feature,chromium

In devtools we can get the stack trace of warning/error messages like so:

![screenshot from 2018-10-01 16-33-57](https://user-images.githubusercontent.com/8518303/46268619-e8b96d80-c597-11e8-9418-45d525aadc24.png)

It would be useful if `ConsoleMessage` exposed a way of getting those stack traces.
Repository: vue
Issue: Binding the bind directive and change events to the <input/> tag doesn‘t work
Labels: has workaround

### Version
2.5.17

### Reproduction link
[https://jsfiddle.net/MoriGirl/50wL7mdz/755097/](https://jsfiddle.net/MoriGirl/50wL7mdz/755097/)





### Steps to reproduce
Enter two numbers less than 10(etc, 7 , 8) in succession twice, observe page display and console output.

### What is expected?
I originally expected the page and console to display 10 after each input.

### What is actually happening?
When I input numbers less than 10 for two consecutive times, such as ( 7, 8 ), it was observed that after the first input, the page and console display 10 at the same time, but after the second input, the page displays 8 and the console displays 10.

---
## reluctant solution
1. Get the native input element and modify its value

   *  use ref   
```
<input  :value='num' @change='handleChange' ref='inputnumber' />
...
handleChange(event){
   this.num=this.check(event.target.value);
   this.$refs.inputnumber.value=this.num;
}
``` 
   *  use event  

```
handleChange(event){
    this.num=this.check(event.target.value);
    event.target.value=this.num;
}
```
but if I replace the input element with a custom component, this may not work.
2.  use both v-model and watch
```
<input  v-model.lazy='num' />  //.lazy: Data synchronization using the change event
...
watch:{
    num:function(v){
      	this.num=this.check(v);
    }
},
```

I want to know why such  outputs appear and if there is a better solution.
Thank you！

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: vue
Issue: Functional component not rendering named slot (following #8871)
Labels: has workaround

### Version
2.5.17

### Reproduction link
[https://codesandbox.io/s/p9mx85qpz0](https://codesandbox.io/s/p9mx85qpz0)





### Steps to reproduce
nothing in particular.

### What is expected?
It should display `Hello World`  

### What is actually happening?
It displays `Hello`

---
Following https://github.com/vuejs/vue/issues/8871 I made App.vue non-functional: 

If you make Child.vue non-functional it works: https://codesandbox.io/s/pw5lzx2w90

If you use default (not named) slots it works: https://codesandbox.io/s/04jrp3y4ln

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: godot
Issue: When removing a TileMap node (or its parent), remove_child method sometimes causes a crash.
Labels: bug,topic:core,confirmed,crash

**Edit:**
This comment is outdated / misleading. The core issue is TileMaps and physics processing - see below.

**Issue:**
I have a situation where I need to switch a node between being "active" and "inactive" - so that when inactive (or disabled) its script and processes etc. stop running. However, using `remove_child()` will (almost always) cause the whole game/engine to crash (at least on Win10) - tried using `call_deferred`, `set_process_internal(false)` and waiting some idle_frames too. Using `queue_free()`, there will not be a crash but the node cannot be added back to the tree (because it's not in memory anymore).

**Workaround hacks:**
1. My workaround now is to hold the original node in memory, and when I want to insert it, I duplicate the node and insert that duplicate - upon "disabling" the node, I call queue_free() on the duplicate. As is clear, this is not optimal in any sense (especially if a very complex node with a lot of kids), and it also brings other problems (eg. with AnimationPlayers inside the duplicated node - at least autoplay won't trigger, didn't check what the problem exactly is yet).
2. I know one other kind of workaround is to save the original node as a PackedScene and then just load and instance it again, but it is not the same as remove_child + add_child (which holds all the node's properties in memory). More importantly, this method also adds other complications - such as instead of saving some scene (eg. some place in a world) should make a "export mini scenes" functionality (eg. a dock tool), and handle all its special cases (tried it initially), as well as keeping book of all the miniscenes after renaming the main scene etc.

**Suggestion:**
I think either of the below two suggestions would fix this "problem":
1. A `queue_remove_child()` or similar method - would function like `queue_free()` but only removes from the tree, not from memory.
2. A `disable_node()` method, which would stop the scripts and processes etc. from running - or at least so, that remove_child could be called without crash after this. ... Or maybe a `call_queued()` method..? (I know "disabling node" has been discussed - but didn't found a solution in the discussions that would work in my case.)
Repository: create-react-app
Issue: Slow compilation time with large project SASS (migrated from 1.x to 2.x)
Labels: issue: needs investigation

I've recently migrated to v2 since I needed the node_module compilation.

I like the auto-magic sass support, but the app takes a minute or two to compile now.

Any suggestions?

Platform: OSX, Node 8, running build/dev via yarn
Repository: create-react-app
Issue: Re-enable `react/no-deprecated` rule after its been adjusted
Labels: tag: underlying tools

Right now `react/no-deprecated` warns multiple times over on deprecated lifecycle methods.

This behavior isn't very optimal -- we should file an issue with ESLint and ask them to remove it once a formal warning is added to React.
Repository: rust
Issue: Tracking issue for the `quote!` macro in `proc_macro`
Labels: A-macros,T-lang,T-libs-api,B-unstable,C-tracking-issue,Libs-Tracked,S-tracking-needs-summary

I'm splitting this off https://github.com/rust-lang/rust/issues/38356 to track the `quote!` macro specifically contained in `proc_macro`. This macro has different syntax than the [`quote` crate](https://crates.io/crates/quote) on crates.io but I believe similar functionality. At this time it's not clear (to me at least) what the status of this macro is in terms of how much we actually want to stabilize it or what would block its stabilization. Others are welcome to fill this in though!

## Steps / History

- [x] RFC: https://rust-lang.github.io/rfcs/1566-proc-macros.html
- [x] Implementation: https://github.com/rust-lang/rust/pull/40939
- [ ] Stabilization:

## Unresolved questions

- Should this use `$` to match other macros or `#` to drop in with `quote::quote`? https://github.com/rust-lang/rust/issues/54722#issuecomment-2302411103
- Which spans should be used? https://github.com/rust-lang/rust/issues/54722#issuecomment-2291168064

From https://github.com/rust-lang/rust/issues/54722#issuecomment-2290103770:
- Do we want our own version of `quote::ToTokens` rather than relying on `From`?
- Should we add repetition before stabilization?
Repository: rust
Issue: Tracking issue for `Span::def_site()`
Labels: E-needs-test,A-macros,T-lang,T-libs-api,B-unstable,A-macros-2.0,C-tracking-issue,A-proc-macros,Libs-Tracked,S-tracking-needs-summary

This is a tracking issue for the `Span::def_site()` API. The feature for this is `proc_maro_def_site`. The `def_site` span primarily relates to hygiene today in that it's *not* copy-paste hygiene.

This is likely blocked on larger hygiene reform and more thorny Macros 2.0 issues. I'm not personally clear on what the blockers are at this time, but I wanted to make sure we had a dedicated tracking issue!

cc https://github.com/rust-lang/rust/issues/45934