sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: terminal
Issue: Anti-Aliasing on profile icons.
Labels: Area-UserInterface,Product-Terminal,Issue-Task,Priority-3

<!-- 
🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨

I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING:
1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement.
2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement.
3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number).
4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement.
5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement.

All good? Then proceed!
-->

# Description of the new feature/enhancement
An option to add image filtering on profile icons to remove jagged edges from icons.
<!-- 
A clear and concise description of what the problem is that the new feature would solve.
Describe why and how a user would use this new functionality (if applicable).
-->
As it is right now, profile icons are shrunk using what appears to nearest neighbor scaling, adding an option to change the resize algorithm would make icons appear less weird.
# Proposed technical implementation details (optional)
Implement a resize filter such as bilinear or trilinear and let the user change that in the settings file.
<!-- 
A clear and concise description of what you want to happen.
-->
In a future version, add an option to apply a different resize filter to profile icon to remove strange image scaling results and make the icon more visible.
Repository: rust
Issue: Non-'static Lifetimes in Const Generics
Labels: C-enhancement,A-lifetimes,T-lang,A-const-generics

We currently don't correctly handle non-`'static` lifetimes in const generics. Until #74051 is merged we ICE when a non-`'static` lifetime is hit, as seen in #60814.

Many uses for const generics does not hit this limitation, but the following case has been brought up:
```rust
fn test<'a, const VALUE: std::mem::Discriminant<Enum<'a>>(v: Enum<'a>) -> bool {
     std::mem::discriminant(&v) == VALUE
}
```
as quoted from @lcnr on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/lifetime.20in.20const-generic/near/202866360)
> `mem::Discriminant` is invariant so `VALUE` has to be `mem::Discriminant` of `Enum<'a>` and can't use `Enum<'static>`.

@varkor @eddyb @nikomatsakis
Repository: godot
Issue: [Bullet] Area zero gravity with Bullet
Labels: bug,confirmed,topic:physics

**Godot version:**
Godot 3.2.2 Official, Standard 64bit (Windows)

**OS/device including version:**
Windows 10
GPU: Nvidia 1060m
Backend: GLES2

**Issue description:**
Short: RigidBody in Area with zero gravity override still has some initial (internal) force applied, while using Bullet but not Godot physics.  Expected results are zero forces applied and RigidBody remains still.  Potentially related to Issue #32776 or #35378.

**Steps to reproduce:**
- Ensure Bullet physics is in use (default?), no other global physics modifications.
- Create Scene with RigidBody entirely within an Area.  The Area should use Replace Space Override and set gravity to zero (both vector and magnitude).
- Run the scene.
- The expectation is that no force is applied to RigidBody as it has always been within the Area with no gravity.  Same results when creating an instance of the RigidBody after the scene is running (not in minimal project)
- Change physics back-end to Godot and run Scene; expected results achieved (no movement)

**Minimal reproduction project:**
[bzg.zip](https://github.com/godotengine/godot/files/4874428/bzg.zip)
Repository: PowerToys
Issue: Always open new windows in center
Labels: Idea-New PowerToy
Repository: youtube-dl
Issue: Add support for pops.vn
Labels: site-support-request

<!--

######################################################################
  WARNING!
  IGNORING THE FOLLOWING TEMPLATE WILL RESULT IN ISSUE CLOSED AS INCOMPLETE
######################################################################

-->


## Checklist

<!--
Carefully read and work through this checklist 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 versions will be REJECTED.
- Make sure that all provided video/audio/playlist URLs (if any) are alive and playable in a browser.
- Make sure that site you are requesting is not dedicated to copyright infringement, see https://yt-dl.org/copyright-infringement. youtube-dl does not support such sites. In order for site support request to be accepted all provided example URLs should not violate any copyrights.
- Search the bug tracker for similar site support 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 new site support request
- [x] I've verified that I'm running youtube-dl version **2020.06.16.1**
- [x] I've checked that all provided URLs are alive and playable in a browser
- [x] I've checked that none of the provided URLs violate any copyrights
- [x] I've searched the bug tracker for similar site support requests including closed ones


## Example URLs

<!--
Provide all kinds of example URLs support for which should be included. Replace the following example URLs by yours.
-->

- Single video: https://pops.vn/video/one-piece-s15-tap-517-ngay-tai-ngo-cua-bang-hai-tac-mu-rom-5ef97425f6e78e1592773b86
- A series: https://pops.vn/series/one-piece-dao-hai-tac-5e0afd7a08b95c003d0c39ed


## Description

<!--
Provide any additional information.
If work on your issue requires account credentials please provide them or explain how one can obtain them.
-->

A Vietnamese and Thai entertainment video streaming platform, including anime. Anime series are geo-restricted in all other countries and are fully licensed.
Repository: PowerToys
Issue: Preview word, ppt, excel files without Office
Labels: Idea-New PowerToy,Product-File Explorer

Many people may don't installed Office. It may be supported to preview  word, ppt, excel, pdf without other office software.
Repository: go
Issue: cmd/compile: type inference could be less strict when there are interface arguments
Labels: NeedsDecision,TypeInference

The [following program](https://go2goplay.golang.org/p/emZ6kZE6kT1) fails:

```
func Equal(type T comparable)(x, y T) bool {
	return x == y
} 

func main() {
	var x interface{} = 5
	var y = 5

	fmt.Println(Equal(x, y))
}
```

The error is:

```
prog.go2:15:23: type int of y does not match inferred type interface{} for T
```

Although it's true that the types don't match exactly, it seems to me that it might be nice
to allow the type argument to unify to `interface{}` in the same way that we allow
a concrete type to be passed to an interface type.
Repository: create-react-app
Issue: Erroneous CSS optimization
Labels: stale,issue: bug report

### Preface

First of all, I'd like to apologize if this issue is not related to `create-react-app` itself. Please redirect me to the proper package if it isn't. I am not particularly knowledgeable when it comes to packages and setup.

### Describe the bug

When creating an optimized build (`npm build`) I get erroneous CSS optimization (I assume "something" is optimizing incorrectly, but I have no idea what). This does not reproduce when simply running locally through `npm start`.

This is the CSS in question:

```CSS
.selector {
  border-width: var(--border-width);
  border-color: var(--border-color);
}
```

it gets optimized into:

```CSS
.selector {
  border: var(--border-width) solid var(--border-color);
}
```

which may seem correct at first, except `border-width` can be a set of values for the different "sides" of the border, and that does not work with the shorthand. (`border: 20px 0 30px 0 solid red` is not valid, for instance). So the properties should not be getting aggregated. At least as far as my understanding goes.

### Environment

  current version of create-react-app: 3.4.1

  System:
    OS: Windows 10 10.0.19041
    CPU: (8) x64 Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
  Binaries:
    Node: 8.16.0 - C:\Program Files\nodejs\node.EXE
    Yarn: Not Found
    npm: 6.4.1 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: 44.19041.1.0
    Internet Explorer: Not Found
  npmPackages:
    react: ^16.12.0 => 16.13.1
    react-dom: ^16.12.0 => 16.13.1
    react-scripts: 3.4.1 => 3.4.1
  npmGlobalPackages:
    create-react-app: Not Found

### Steps to reproduce

In "description". Essentially:

- Create a CSS class that contains variable `border-width` and `border-color`.
- Programmatically set `border-width` to represent multiple "sides" (`10px 20px 0 30px`).
- Run `npm start`. Observe correct CSS.
- Run `npm build`. Observe incorrect CSS.

For brevity, here's how to do step 2:
```JS
const rootStyle = document.documentElement.style;
rootStyle.setProperty("--border-width", "10px 20px 0 30px");
```

### Reproducible demo

You can find my published, erroneously optimized page here:
https://protos.now.sh

Inspect any "input" and you'll see the CSS is incorrect.
Repository: pytorch
Issue: Difference between allocated and reserved CUDA memory
Labels: module: memory usage,triaged

## ❓ Questions and Help

I've asked this [here](https://discuss.pytorch.org/t/difference-between-allocated-and-reserved-memory/87278) but got no response.

---

I imagined that that the difference between allocated and reserved memory is the following:

- **allocated** memory is the amount memory that is actually used by PyTorch.
- **reserved** is the allocated memory plus pre-cached memory.

If that is correct the following should hold:

- **reserved** memory >= **allocated** memory
- **reserved** memory == **allocated** memory after calling `torch.cuda.empty_cache()`

Is my understanding correct? 

---

I’m asking this since I have trouble determining the peak memory requirement for a piece of code. My setup is as follows:

```python
for param in params:
    torch.cuda.empty_cache()
    torch.cuda.reset_peak_memory_stats()

    try:
        test_function(param)
    except RuntimeError:
        break
    finally:
        print(torch.cuda.memory_summary())
```

Here is the compressed output:

| `param` | failing | Allocated memory (Peak Usage) | GPU reserved memory (Peak Usage) |
| ------- | ------- | ----------------------------- | -------------------------------- |
| `1`     | `False` | 15006 MB                      | 16726 MB                         |
| `2`     | `False` | 17402 MB                      | 19354 MB                         |
| `3`     | `False` | 19961 MB                      | 22184 MB                         |
| `4`     | `True`  | 20609 MB                      | 22454 MB                         |

(Note that for `param==4` the memory report was generated after the error was raised and thus does not reflect the actual memory usage for the whole of `test_function`)

The memory requirement is growing approx. quadratic with `param`. A quick extrapolation for the failing `param` (`param==4`) gives 22683 MB of allocated memory and 25210 MB of reserved memory. I have 24189 MB available and no other processes are running. Thus, if my understanding about allocated and reserved memory is correct, the case should not fail, but it does.

Can someone explain why this is not the case?

## Environment

```
PyTorch version: 1.5.1+cu101
Is debug build: No
CUDA used to build PyTorch: 10.1

OS: Ubuntu 18.04.4 LTS
GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
CMake version: Could not collect

Python version: 3.6
Is CUDA available: Yes
CUDA runtime version: 10.1.243
GPU models and configuration: GPU 0: TITAN RTX
Nvidia driver version: 418.87.00
cuDNN version: /usr/lib/x86_64-linux-gnu/libcudnn.so.7.6.5

Versions of relevant libraries:
[pip3] numpy==1.19.0
[pip3] torch==1.5.1+cu101
[pip3] torchvision==0.6.1+cu101
[conda] Could not collect
```
Repository: rust
Issue: Inconsistent borrow check in async function
Labels: P-medium,A-borrow-checker,T-compiler,C-bug,NLL-polonius,fixed-by-polonius

I tried this code:

```rust
use std::collections::HashMap;

fn f1(map: &mut HashMap<i32, String>, k: i32) -> &String {
    if let Some(s) = map.get(&k) {
        return s;
    }
    map.insert(k, k.to_string());
    map.get(&k).unwrap()
}

async fn f2(map: &mut HashMap<i32, String>, k: i32) -> &String {
    if let Some(s) = map.get(&k) {
        return s;
    }
    map.insert(k, k.to_string());
    map.get(&k).unwrap()
}
```

`f2` seems to be correct but can not be compiled.

```
   Compiling playground v0.0.1 (/playground)
error[E0502]: cannot borrow `*map` as mutable because it is also borrowed as immutable
  --> src/lib.rs:15:5
   |
12 |     if let Some(s) = map.get(&k) {
   |                      --- immutable borrow occurs here
13 |         return s;
   |                - returning this value requires that `*map` is borrowed for `'1`
14 |     }
15 |     map.insert(k, k.to_string());
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ mutable borrow occurs here
16 |     map.get(&k).unwrap()
17 | }
   | - return type of generator is &'1 std::string::String

error: aborting due to previous error

For more information about this error, try `rustc --explain E0502`.
error: could not compile `playground`.

To learn more, run the command again with --verbose.
```

### Meta

According to the playground, the problem exists on `1.44.1` and `1.46.0-nightly (2020-07-04 0cd7ff7ddfb75a38dca8)`.

Other versions may be the same.
Repository: transformers
Issue: Tabert
Labels: New model,Feature request

# 🌟 New model addition

## Model description
a pre-trained language model for learning joint representations of natural language utterances and (semi-)structured tables for semantic parsing. TaBERT is pre-trained on a massive corpus of 26M Web tables and their associated natural language context, and could be used as a drop-in replacement of a semantic parsers original encoder to compute representations for utterances and table schemas (columns).
<!-- Important information -->

## Open source status

* [X] the model implementation is available: (give details)
https://github.com/facebookresearch/TaBERT
* [X] the model weights are available: (give details)
https://github.com/facebookresearch/TaBERT
* [ ] who are the authors: (mention them, if possible by @gh-username)
Repository: PowerToys
Issue: [Run] Skin / theme / customization / size / transparency / opacity  / overlay
Labels: Idea-Enhancement,Product-PowerToys Run,Area-User Interface

Since I frequently use PT Run, I found that it is a bit dull to use only color theme to decorate RUN. 
Can you add a "add skin"function?

**Anticipated effect**
allowing users to set a background picture for their PT Run.
Repository: PowerToys
Issue: Combine Windows Snap with FancyZone? Add more border targets to the screen and link them to zones? Combined window resizing like in Snap?
Labels: Idea-Enhancement,FancyZones-Dragging&UI,Product-FancyZones

Windows snap (move window to top screen for full screen, to the left for 50% etc.) is a fantastic feature with a great UX and actually even faster to use than FancyZones. I use both in combination.

The only limitation in Snap since it was introduces are too few targets. 50% left/right and full screen is not enough. You have now also this 25% zone when you drag a window in the screen corner. But I don't find this too useful and a bit limited on larger screens. I often want something like 1/3 or 2/3. Or something centred with free space to the left and right. This is easy to do with FancyZones. 

But the Snap UX feels so great and even faster than FancyZones. I like FancyZone to access more complicated zones possibilities. But using Snap for your most common zones would be great and for me even more efficient.

My idea is to add more targets to the screen for window Snap, and give the possibility to map these targets to zones defined in FancyZone.

For example: 
- Left corner is not 25% resize, but re-mapped to FancyZone e.g. zone 1. 
- Think also about to add additional Snap zones on the screen border. Like moving a window at the top at 0-20% left is an own target that could be used for something different than full screen. Full screen would be top/left 20%-80% for example. 

In addition. When you Snap two windows 50% 50% and resize one window, you resize both windows at the same time in Windows 10. This is also a great feature. It would be great when this would be the same for directly touching zones in FancyZone too. You need to resize only one windows instead of two this way. 

This is just a rough idea. Especially if and how to setup additional Snap targets needs some additional thoughts. But this would feel like the ultimate solution for me.
Repository: godot
Issue: Mesh and materials clear on imported obj at runtime and on project load
Labels: bug,topic:core

**Godot version:**
3.2.1


**OS/device including version:**
Windows 10 Pro Education

**Issue description:**
Materials seem to be being cleared at runtime and the mesh property of the MeshInstance is cleared during project load

**Steps to reproduce:**
- Open ViewportContainer3D and assign the ShapeA mesh to it
- Run the ViewportContainer3D and see that the material is reset to the original material (in this case null)
- Open the Remote tab and Try to assign a material to the MeshInstance's mesh during runtime
- See that it's set to the original material before you can view it
- Close Project and Reopen it
- See that the mesh is cleared

**Minimal reproduction project:**
[AstroWars3D.zip](https://github.com/godotengine/godot/files/4876321/AstroWars3D.zip)
Repository: storybook
Issue: Controls: JSX support
Labels: feature request,react,addon: contexts

Currently React nodes, such as `children`, show a JSON object editor by default. They should show a text editor instead that supports full JSX editing.
Repository: storybook
Issue: Controls: React text node support
Labels: feature request,react,has workaround,addon: controls

Currently React nodes, such as `children`, show a JSON object editor by default. They should show a text editor instead, in the short term. Long term, we should support JSX #11428
Repository: pytorch
Issue: Is this a bug? The values calculated according to the document isn't equal to the values calculated by framework
Labels: module: optimizer,triaged

Torch 1.5.0 CPU, Linux

Bug API: `torch.optim.lr_scheduler.CosineAnnealingLR(optimizer, T_max, eta_min=0, last_epoch=-1)`

<!-- A clear and concise description of what content in https://pytorch.org/docs is an issue. If this has to do with the general https://pytorch.org website, please file an issue at https://github.com/pytorch/pytorch.github.io/issues/new/choose instead. If this has to do with https://pytorch.org/tutorials, please file an issue at https://github.com/pytorch/tutorials/issues/new -->

https://github.com/pytorch/pytorch/blob/master/torch/optim/lr_scheduler.py#L448


If set T_max =5, initial learning_rate of optimizer are 0.5, eta_min=0:

The value calculated by framework are as flow :
![image](https://user-images.githubusercontent.com/52485244/86489498-16e46680-bd97-11ea-9a10-622d48d4cf3e.png)

But the value calculated by formula in the document are as flow：
https://pytorch.org/docs/stable/optim.html?highlight=cosineannealinglr#torch.optim.lr_scheduler.CosineAnnealingLR
![image](https://user-images.githubusercontent.com/52485244/86489333-a2112c80-bd96-11ea-8e01-19fa5ae1227a.png)

These Two doesn't match, in epoch 5. one is 0, but the other is 0.0954915028125. I want to know which one is right, and is this a bug?

thank you very much!

cc @vincentqb
Repository: rust
Issue: using inner tool attributes in crate root induces compiler error on intra-crate macro use
Labels: A-attributes,A-resolve,A-macros,T-compiler,C-bug

Take a crate that has the following `foo.rs`, that contains a macro, `foomacro()!`:

```rust
#[macro_export]
macro_rules! foomacro {
    ($f:expr) => ({
        println!("foomacro: {}", $f);
    });
}
```

This macro is used in `bar.rs`:

```rust
use crate::foomacro;

pub fn bar() {
    foomacro!("bar");
}
```

Finally, here is the root of the crate and `main.rs`:

```rust
#![feature(custom_inner_attributes)]

// Setting any inner tool attribute here causes a compiler error on bar's use of
// foomacro!():
//
//   error: macro-expanded `macro_export` macros from the current crate cannot
//   be referred to by absolute paths
//
// To see this, uncomment either of the following lines:
//
// #![clippy::cyclomatic_complexity = "100"]
// #![rustfmt::skip]

mod foo;
mod bar;

fn main() {
    foomacro!("foo");
    bar::bar();
}
```

As the comment there indicates, as written, this compiles and runs as expected:

```
$ cargo run
   Compiling modmac v0.1.0 (/home/bmc/modmac)
    Finished dev [unoptimized + debuginfo] target(s) in 0.18s
     Running `target/debug/modmac`
foomacro: foo
foomacro: bar
```

If, however, either of the inner tool attributes is uncommented, the code fails on compiling `bar.rs`, complaining about its use of `foomacro()!`

```
$ cargo run
   Compiling modmac v0.1.0 (/home/bmc/modmac)
error: macro-expanded `macro_export` macros from the current crate cannot be referred to by absolute paths
 --> src/bar.rs:2:5
  |
2 | use crate::foomacro;
  |     ^^^^^^^^^^^^^^^
  |
  = note: `#[deny(macro_expanded_macro_exports_accessed_by_absolute_paths)]` on by default
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #52234 <https://github.com/rust-lang/rust/issues/52234>
note: the macro is defined here
 --> src/foo.rs:2:1
  |
2 | / macro_rules! foomacro {
3 | |     ($f:expr) => ({
4 | |         println!("foomacro: {}", $f);
5 | |     });
6 | | }
  | |_^

error: aborting due to previous error

error: could not compile `modmac`.

```

This behavior seems surprising, especially because tool attributes are generally thought to only be relevant to the specified tool:

> When a tool is not in use, the tool's attributes are accepted without a warning. When the tool is in use, the tool is responsible for processing and interpretation of its attributes.

Thanks in advance for any consideration of this issue -- and apologies if this is an elaborate form of pilot error!