sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: react-native
Issue: TouchableOpacity setOpacityTo is not a function
Labels: Issue: Author Provided Repro,Component: TouchableOpacity

Originally reported in expo/expo#9026, I ran into the same problem so I'm re-reporting this here

## Description

The `setOpacityTo` on TouchableOpacity is no longer available.

## React Native version:

0.62.2

```
  Expo CLI 3.20.3 environment info:
    System:
      OS: macOS Mojave 10.14.6
      Shell: 5.3 - /bin/zsh
    Binaries:
      Node: 10.20.1 - /var/folders/qt/10542x9d2wbg0x93mmh1xsw00000gn/T/yarn--1593777562592-0.5909086070884821/node
      Yarn: 1.22.4 - /var/folders/qt/10542x9d2wbg0x93mmh1xsw00000gn/T/yarn--1593777562592-0.5909086070884821/yarn
      npm: 6.14.4 - ~/.asdf/installs/nodejs/10.20.1/bin/npm
      Watchman: 4.9.0 - /usr/local/bin/watchman
    IDEs:
      Android Studio: 3.5 AI-191.8026.42.35.5791312
      Xcode: 11.0/11A420a - /usr/bin/xcodebuild
    npmPackages:
      expo: ^38.0.0 => 38.0.4
      react: 16.11.0 => 16.11.0
      react-dom: 16.11.0 => 16.11.0
      react-native: https://github.com/expo/react-native/archive/sdk-38.0.0.tar.gz => 0.62.2
      react-native-web: ^0.12.0 => 0.12.3
      react-navigation: ^4 => 4.3.9

```

## Steps To Reproduce
Provide a detailed list of steps that reproduce the issue.

1. Create a reference to `TouchableOpacity`
2. Try calling `setOpacityTo`

## Expected Results

Opacity of the element is changed

## Actual Results

Fatal crash due to missing method

## Snack, code example, screenshot, or link to a repository:

https://snack.expo.io/@zanona/3cb338
Repository: go
Issue: cmd/go: go test -json splits log records
Labels: NeedsInvestigation,GoCommand

I maintain a test runner tool (https://github.com/grasparv/testie). 

Here is my problem:

```
$ go version
go version go1.14 linux/amd64
$ cat hello_test.go
package hello

import (
        "testing"
)

func TestSomething(t *testing.T) {
        t.Logf("first item\nsecond item")
        t.Logf("third item")
}
$ go test -v -json
{"Time":"2020-07-03T15:08:12.426294755+02:00","Action":"run","Package":"example","Test":"TestSomething"}
{"Time":"2020-07-03T15:08:12.426393632+02:00","Action":"output","Package":"example","Test":"TestSomething","Output":"=== RUN   TestSomething\n"}
{"Time":"2020-07-03T15:08:12.426403571+02:00","Action":"output","Package":"example","Test":"TestSomething","Output":"    TestSomething: hello_test.go:8: first item\n"}
{"Time":"2020-07-03T15:08:12.426407445+02:00","Action":"output","Package":"example","Test":"TestSomething","Output":"        second item\n"}
{"Time":"2020-07-03T15:08:12.426411074+02:00","Action":"output","Package":"example","Test":"TestSomething","Output":"    TestSomething: hello_test.go:9: third item\n"}
{"Time":"2020-07-03T15:08:12.426415993+02:00","Action":"output","Package":"example","Test":"TestSomething","Output":"--- PASS: TestSomething (0.00s)\n"}
{"Time":"2020-07-03T15:08:12.426419389+02:00","Action":"pass","Package":"example","Test":"TestSomething","Elapsed":0}
{"Time":"2020-07-03T15:08:12.426423735+02:00","Action":"output","Package":"example","Output":"PASS\n"}
{"Time":"2020-07-03T15:08:12.4264854+02:00","Action":"output","Package":"example","Output":"ok  \texample\t0.001s\n"}
{"Time":"2020-07-03T15:08:12.42649666+02:00","Action":"pass","Package":"example","Elapsed":0.001}
```
I expected seeing first and second item reported as a single entry (instead second entry gets its own log event). The above is an issue since it destroys information by breaking lines. For instance, my test runner tool might want to change indentation on some messages, but here it is impossible to see which log lines that actually belong together.
Repository: material-ui
Issue: [Autocomplete] Jumps between being expanded to the top/bottom
Labels: bug 🐛,component: autocomplete,design

- [x] The issue is present in the latest release.
- [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.

## Current Behavior 😯

When having not that much space below the bottom of the input field the Autocomplete opens to the top.
By entering text into the input field the Autocomplete field gets shorter and jumps to the bottom.
<!-- Describe what happens instead of the expected behavior. -->

## Expected Behavior 🤔

After opening the Autocomplete ist should stay at the same position as the switch to the bottom is not expected and the user has to re-orientate to find the list of suggestions.

## Steps to Reproduce 🕹

CodeSandbox used for reproduction: https://codesandbox.io/s/naughty-hermann-24rmn

Steps:

1. The input field
![image](https://user-images.githubusercontent.com/2699280/86476744-6438e780-bd47-11ea-9bce-c9a210bc9b47.png)
2. Ensure that there is not much space to the bottom
3. After clicking into the field, the Autocomplete opens to the top (as expected ✔️)
![image](https://user-images.githubusercontent.com/2699280/86476689-4e2b2700-bd47-11ea-9d02-c96f9bb44e8a.png)
4. After typing an "a", the Autocomplete jumps to the bottom (not expected, should stay ❌)
![image](https://user-images.githubusercontent.com/2699280/86476766-731f9a00-bd47-11ea-8a5d-86ab21f5f5c2.png)

## Your Environment 🌎

| Tech        | Version   |
| ----------- | --------- |
| Material-UI | v4.11.0   |
| React       | v16.13.1  |
| Browser     | Chrome 83 |
Repository: rust
Issue: SpecForElem for i16/u16 and other digits
Labels: I-slow,C-enhancement,A-collections,A-specialization,T-libs

We have specialization for `SpecForElem` for `i8` and `u8` (which provides a small performance win over plain extend for vec) but we could look into using specialization for that involves duplicating more digits with `rep stosw` (or `d` or `q`). It may need benchmarking to ensure that it's actually faster as mentioned by @joshtriplett 

I am not sure how to reproduce the assembly `rep stosw`, someone that know could take up this issue.

Previous discussion: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/SpecForElem.20for.20other.20integers
Repository: pytorch
Issue: Inconsistent behaviour when parameter appears multiple times in parameter list
Labels: module: docs,module: optimizer,triaged

## 🐛 Bug

When we pass a list of parameters or parameter groups to an optimizer, and one parameter appears multiple times we get different behaviours, and it is not clear whether this is intended that way:

* If the parameter appears twice within one parameter group, everything works. That parameter will get updated *twice* though.
* If the parameter appears in distinct parameter groups, then we get an error.

## To Reproduce

```
import torch
x = torch.zeros((1,), requires_grad=True)
# uncomment one of the following three lines for each of the cases:
# a = torch.optim.SGD(params=[dict(params=[x])], lr=0.1) # baseline
# a = torch.optim.SGD(params=[dict(params=[x, x])], lr=0.1)  # apparently acceptable (?); x is updated twice
# a = torch.optim.SGD(params=[dict(params=x), dict(params=x)], lr=0.1)  # apparently not acceptable
x.sum().backward()
a.step()
print(x)
```

## Expected behavior

I would expect that no matter in what way a parameter apperas multiple times, we get the same behaviour in both situations: Either we get errors in both situations, or both situations are deemed acceptable.

## Environment

 - PyTorch Version (e.g., 1.0): 1.5
 - OS (e.g., Linux): Win/Linux
 - How you installed PyTorch: conda
 - Python version: 3.7



cc @jlin27 @vincentqb
Repository: excalidraw
Issue: Feature request: See myself in the user list
Labels: enhancement

In collaborative edition, I only see others in the list of users on the top right. Since a color is automatically assigned to my user avatar, I regularly use a similar color to write content, so everybody can track who wrote what. Currently, I can't see myself in the list so I need to ask others which color I am.

I would like to see myself in the list. Any reason not to?
Repository: pytorch
Issue: Regarding graphs page on site
Labels: module: docs,triaged

## 🚀 Feature
<!-- A clear and concise description of the feature proposal -->
A graphs page on site, to track the evolution of PyTorch, along with the time required to train neural networks, along with the data available.
## Motivation

<!-- Please outline the motivation for the proposal. Is your feature request related to a problem? e.g., I'm always frustrated when [...]. If this is related to another GitHub issue, please link here too -->
Without graph it become difficult to see, where things are headed.
## Pitch

<!-- A clear and concise description of what you want to happen. -->
I suggest a few graphs, a few more could be added,
1) Evolution of PyTorch
2) Evolution of time required to train neural network, since the beginning of PyTorch
3) Evolution of data available since the beginning of PyTorch in terms of size
4) Evolution of number of parameters in neural network
5) Evolution of FLOPS

cc @jlin27
Repository: excalidraw
Issue: Feature request: Automatically change the color when joining a live-collaboration session
Labels: enhancement

Following #1868, it would be nice to auto-change the default color to the color of avatar, e.g. if I enter a live-collaboration session and I'm assign a red avatar, my default color would be red and all I'd type would be red instead of black. It wouldn't prevent me from changing the color.

I'm not sure this is a behavior we would always want. It could be a toggle when creating a session. My use case is team retrospectives, where we write and draw stuff one by one.
Repository: godot
Issue: SkeletonIK Targets cause bones to deform
Labels: bug,topic:core,confirmed

**Godot version:**
3.2.2.stable.official

**OS/device including version:**
Windows 10 Pro - GLES3

**Issue description:**
Godot deforms a skeleton's bones instead of rotating it. This seems to be related to, or a regression of #34415
![image](https://user-images.githubusercontent.com/18017673/86487673-01534a80-bd5f-11ea-9dbc-18dd1a622f1d.png)

This happens regardless of whether I use magnets or not

**Steps to reproduce:**
Create a chain of bones longer than 2-3 bones, and set an IK target for the tip.

**Minimal reproduction project:**
[.escn file containing the model + rig](https://github.com/moonwards1/Moonwards-Virtual-Moon/blob/7c00c0e0fdbbf92609512b0d656fab24a6b5d486/Assets/MoonTown/Models/Athlete_Rover/AtheleteRover_Rigged.escn)

[Commit](https://github.com/moonwards1/Moonwards-Virtual-Moon/blob/7c00c0e0fdbbf92609512b0d656fab24a6b5d486l)

[blend file](https://github.com/moonwards1/Moonwards-Assets/blob/master/Models/AtheleteRover_Rigged.blend)

Credits to [Neurotremolo](https://github.com/Neurotremolo) for finding this one
Repository: pytorch
Issue: The values calculated according to the document isn't equal to the values calculated by framework
Labels: module: docs,module: optimizer,triaged

## 📚 Documentation
Torch 1.5.0 CPU, Linux
<!-- 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

Bug API: `torch.optim.lr_scheduler.CosineAnnealingLR(optimizer, T_max, eta_min=0, last_epoch=-1)`

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, thank you very much!

cc @jlin27 @vincentqb
Repository: scrcpy
Issue: A simple thank you
Labels: wontfix

Hello!
I just wanted to say thank you for your great work. I have used your software and i am really happy with it. Thank you so much for your effort and hard work!
Repository: pytorch
Issue: len of dataloader when using iterable dataset does not reflect batch size
Labels: module: nn,module: dataloader,triaged

## 🐛 Bug

If I construct an iterable dataset of length 100, and want to then use that in a dataloader with batch_size=4, one would expect the length of the dataloader to be 25, but instead it is 100. This is because it is implemented as
```
        if self._dataset_kind == _DatasetKind.Iterable:
            length = self._IterableDataset_len_called = len(self.dataset)
            return length
```

## To Reproduce

Steps to reproduce the behavior:

```
from torch.utils.data import DataLoader, IterableDataset, Dataset
test_items = list(range(100))
class TestDataset(Dataset):
    
    def __init__(self, test_items):
        self.x = test_items

    def __getitem__(self, item):
        return self.x[item]

    def __len__(self) -> int:
        return len(self.x)

class TestIterableDataset(IterableDataset):
    
    def __init__(self, test_items):
        self.x = test_items

    def __iter__(self):
        return iter(self.x)

    def __len__(self) -> int:
        return len(self.x)

print(len(TestIterableDataset(test_items)))
print(len(TestDataset(test_items)))
print(len(DataLoader(TestIterableDataset(test_items), batch_size=4)))
print(len(DataLoader(TestDataset(test_items), batch_size=4)))
```
this prints:
```
100
100
100
25
```

## Expected behavior

I would expect this to print:
```
100
100
25
25
```
## Environment

Please copy and paste the output from our
torch '1.5.1'

## Additional context

If people agree this should be fixed, I would love to put out a PR for it! Seems manageable and I've been wanting to contribute for a while now :)


cc @SsnL @albanD @mruberry
Repository: rust
Issue: Naming an associated type can cause a compile failure
Labels: A-lifetimes,A-associated-items,T-compiler,C-bug

<!--
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 have found two different pieces of code that should be equivalent, but one compiles and the other does not.

This code  compiles successfully: ([Playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=907f7fefa2a2f9d02f4a6a178a4f55ed))

```rust
struct Lazy<Ptr>(Ptr) where Ptr: Deref, Ptr::Target: Record;

impl<Ptr:Deref> Record for Lazy<Ptr> where Ptr::Target: Record {
    fn try_field_ref<F:Field>(&self)->Option<&F> {
        self.0.try_field_ref()
    }
}
```

But this code fails to compile: ([Playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=f9d0dca192e5702b1528ab19d3e5bba5))

```rust
struct Lazy<Ptr>(Ptr) where Ptr: Deref, Ptr::Target: Record;

impl<R:Record, Ptr:Deref<Target=R>> Record for Lazy<Ptr> {
    fn try_field_ref<F:Field>(&self)->Option<&F> {
        self.0.try_field_ref()
    }
}
```

Error Message:
```

   Compiling playground v0.0.1 (/playground)
error[E0311]: the parameter type `R` may not live long enough
  --> src/lib.rs:14:9
   |
14 |         self.0.try_field_ref()
   |         ^^^^^^
   |
   = help: consider adding an explicit lifetime bound for `R`
note: the parameter type `R` must be valid for the anonymous lifetime #1 defined on the method body at 13:5...
  --> src/lib.rs:13:5
   |
13 | /     fn try_field_ref<F:Field>(&self)->Option<&F> {
14 | |         self.0.try_field_ref()
15 | |     }
   | |_____^
note: ...so that the type `R` is not borrowed for too long
  --> src/lib.rs:14:9
   |
14 |         self.0.try_field_ref()
   |         ^^^^^^

error[E0311]: the parameter type `R` may not live long enough
  --> src/lib.rs:14:16
   |
14 |         self.0.try_field_ref()
   |                ^^^^^^^^^^^^^
   |
   = help: consider adding an explicit lifetime bound for `R`
note: the parameter type `R` must be valid for the anonymous lifetime #1 defined on the method body at 13:5...
  --> src/lib.rs:13:5
   |
13 | /     fn try_field_ref<F:Field>(&self)->Option<&F> {
14 | |         self.0.try_field_ref()
15 | |     }
   | |_____^
note: ...so that the reference type `&R` does not outlive the data it points at
  --> src/lib.rs:14:16
   |
14 |         self.0.try_field_ref()
   |                ^^^^^^^^^^^^^

error: aborting due to 2 previous errors

error: could not compile `playground`.

```
Repository: terminal
Issue: Support fonts and fonts attributes through inline escape sequences like mintty and vte52
Labels: Help Wanted,Area-VT,Area-Fonts,Product-Terminal,Issue-Task

# Escape sequences to set fonts and their attributes are ignored, instead they are displayed as raw 

Terminals support escape sequences to alter the fonts. Windows Terminal at the moment only support basic colors and reverse colors

This is linked to #109 #2916 #5461 #5462 #6703 and #6205 as currently most of the VTE52 font attributes are not supported.

Full support can be tested with:
https://github.com/csdvrx/sixel-testsuite/ansi-vte52.sh 

Expected output:
https://github.com/csdvrx/sixel-testsuite/blob/master/test-passed-part1.jpg

It would be desirable to support all mintty font attributes, including support for alternative fonts, using ECMA-48 SGR codes. This would be linked to #1163 for usecases like CJK.

Mintty patch implementing this is on https://github.com/mintty/mintty/commit/1250829806d3da2f05b3207183b190747d2cc127

This allows sequences like:

echo "\e[12mVery thin font\e[0m"

![image](https://user-images.githubusercontent.com/49044530/86496775-6f3e4880-bd44-11ea-817d-0d58f632ac1f.png)
Repository: godot
Issue: get_property_list() differs between build configurations
Labels: bug,topic:dotnet

**Godot version:**
3.2.2 stable.mono

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
Windows 10 x64

**Issue description:**
<!-- What happened, and what was expected. -->
I've been pulling my hair out trying to get my project to behave properly after upgrading to 3.2.2;  The build configurations needed to be updated to compile and debug again, and after pointing everything to the new locations, everything seemed to get along just fine.  However, a rather insidious problem that even confused the debugger when it popped up originally under an incorrect build configuration popped up for me again when attempting to export either a release or debug build.

When attempting to access and assign a c# node's property from a separate gdscript file, it becomes unreachable in exported builds.  The property in question wraps a generics class, which may be related to the issue, but I'm more inclined to believe something broke between godot versions in terms of export template implementation.  I've created and attached a minimal example project using some of the same code from my larger project.  The relevant files are pretty much all in the root, including `Test.cs` which is the sample implementation of the C# node that other GDScripts would be fetching data from.

**Steps to reproduce:**
Run attached project in editor.  Text box will be filled with information fetched from the test node's c# property `Ksr`.  Pressing F12 will assign dummy data to Ksr.  If successful, a series of alert boxes will appear.  (These will continue to appear because of the way input is hooked until the project is killed, sorry.)  The relevant code to pop the alert box is located in `FMCore/RTable.cs`, lines 188 and 196.  (testing to validate a Set actually changed the value to something sane.)

Perform the same steps as above, only instead of running from the editor, build a debug release and run it instead.  Console will display the message `ResponseCurve: Can't find the target property 'Ksr' to send the table to."`.  This is triggered in line 43 of `Node2D.gd` for failing to find the relevant property in the object property list.


**Minimal reproduction project:**
[CSharpPropertyUnreachable.zip](https://github.com/godotengine/godot/files/4871942/CSharpPropertyUnreachable.zip)
Repository: flutter
Issue: macOS Edit menu doesn't auto-enable text-related menu items
Labels: a: text input,framework,platform-mac,a: desktop,P2,fyi-text-input,team-macos,triaged-macos

## Details

```dart
SelectableText(
  'You have pushed the button this many times:',
  toolbarOptions: ToolbarOptions(
    selectAll: true,
    copy: true,
  ),
),
```

![image](https://user-images.githubusercontent.com/7928961/86502372-081ca480-bdd5-11ea-9a37-fcca18a8acb7.png)

**Target Platform:** macOS
**Target OS version/browser:** macOS 10.15
**Devices:** MacBook Pro (16-inch, 2019)

## Logs

flutter analyze

```
C02CN0H4MD6V:selectable_tour sunbreak$ flutter analyze
Analyzing selectable_tour...                                            
No issues found! (ran in 2.2s)
```

flutter doctor -v

```
C02CN0H4MD6V:selectable_tour sunbreak$ flutter doctor -v
[✓] Flutter (Channel master, 1.19.0-4.1.pre, on Mac OS X 10.15.4 19E287, locale en-CN)
    • Flutter version 1.19.0-4.1.pre at /Users/sunbreak/flutter/flutter-1.19.0-4.1.pre
    • Framework revision f994b76974 (3 weeks ago), 2020-06-09 15:53:13 -0700
    • Engine revision 9a28c3bcf4
    • Dart version 2.9.0 (build 2.9.0-14.1.beta)
    • Pub download mirror https://pub.flutter-io.cn
    • Flutter download mirror https://storage.flutter-io.cn

 
[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.3)
    • Android SDK at /Users/sunbreak/Library/Android/sdk
    • Platform android-29, build-tools 29.0.3
    • Java binary at: /Users/sunbreak/Library/Application Support/JetBrains/Toolbox/apps/AndroidStudio/ch-0/192.6392135/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_212-release-1586-b4-5784211)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 11.5)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 11.5, Build version 11E608c
    • CocoaPods version 1.9.2

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 3.6)
    • Android Studio at /Users/sunbreak/Library/Application Support/JetBrains/Toolbox/apps/AndroidStudio/ch-0/192.6392135/Android Studio.app/Contents
    • Flutter plugin version 46.0.1
    • Dart plugin version 192.8052
    • Java version OpenJDK Runtime Environment (build 1.8.0_212-release-1586-b4-5784211)

[✓] IntelliJ IDEA Ultimate Edition (version 2020.1.2)
    • IntelliJ at /Users/sunbreak/Applications/JetBrains Toolbox/IntelliJ IDEA Ultimate.app
    • Flutter plugin version 47.1.3
    • Dart plugin version 201.7846.93

[✓] VS Code (version 1.46.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.11.0

[✓] Connected device (3 available)
    • macOS      • macOS      • darwin-x64     • Mac OS X 10.15.4 19E287
    • Web Server • web-server • web-javascript • Flutter Tools
    • Chrome     • chrome     • web-javascript • Google Chrome 78.0.3904.108

• No issues found!
```
Repository: pytorch
Issue: Add a launching script for RPC
Labels: feature,triaged,module: rpc

See forum discussion: https://discuss.pytorch.org/t/distributed-model-parallel-using-distributed-rpc/87875/3

This might be helpful to provide launching script for RPC as we did for DDP. 

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @rohan-varma @xush6528 @jjlilley @osalpekar @jiayisuse