sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: Reliable way to identify RuntimeErrors (CUDA)
Labels: module: cuda,triaged,enhancement

## 🚀 Feature

Reliable way to check for CUDA out of memory (and CUDA Runtime errors in general). 

## Motivation

Currently there I see no way to reliably check for a cuda out of memory error except parsing the exception arg for 

``CUDA out of memory``.
 
(After a quick grep on the pytorch sources this seems to work **at the moment**)

As this text may change in future I do not feel comfortable with this work-around as it screams for breaking. 
In application code reliably detecting such an error seems crucial to me. 

If there is a way to do so and I did not find it, this issue may be a well place to document this? 

## Pitch

A solution would be quiet standard, e.g., RuntimeError subclasses or an attached error code. 

@soumith @albanD  How do you folks think about this? 

cc @ngimel
Repository: pytorch
Issue: [FR] F.pad support syntax sugars for specifying the padding amount
Labels: module: convolution,triaged,enhancement

Most of the times the same amount of padding is applied on both sides of all spatial dimensions. Instead of writing `F.pad(x, tuple_of_size_twice_spatial_ndim)`, I would be happy to see the two following syntax sugars:

1. `F.pad(x, p : int)` applies `p` amount of padding on both sides of all spatial dimensions in `x`.
2. `F.pad(x, t : Tuple[int])`, if `t` is a tuple of size equal to the number of spatial dimensions in `x`, each value of `t` is used as the padding amount on **both** sides for the corresponding dimension. This would be consistent with the Conv and Pooling layers too.

I'd submit a PR if this is reasonable.
Repository: go
Issue: cmd/dist: timeout hanging bootstrap
Labels: NeedsFix

Because of a runtime bug, Android builders hang in the bootstrap process:

https://farmer.golang.org/temporarylogs?name=android-arm-corellium&rev=99957b6930c76b683dbca1ff4bcdd56e59b1e035&st=0xc009856f20

This issue is about implementing some sort of timeout in cmd/dist to ensure forward progress even in the face of hangs. For quite some time I though the hangs were caused by a flaky Corellium network.
Repository: pytorch
Issue: CPU and CUDA error messages are divergent in type promotion
Labels: module: tests,triaged,module: type promotion

Discovered while writing #29417.

test_non_promoting_ops was not running on the CPU and CUDA. When I modified it to do so it began failing because the error message it's checking for is not the same across our native device types. I removed the check for the particular message as part of the PR. However, the error message should be the same on our native device types and should be checked for. 

@gchanan
Repository: pytorch
Issue: Provide a mechanism to set global state per test in thread-safe manner
Labels: module: tests,triaged,enhancement

Global state, like the default tensor dtype, is set by some tests. This is unsafe if tests are running concurrently or the test author forgets to reset the former dtype (which has happened before, and broke running pytest on test_jit.py). 

Ideally we would have a mechanism where we can set global state in a test that lets tests be run concurrently and safely. 

@gchanan
Repository: TypeScript
Issue: Warning or error when importing files from a project's own outDir
Labels: Suggestion,Awaiting More Feedback

## Search Terms

import, outDir, composit, TS5055

## Suggestion

Add a specific warning/error when trying to import something from the projects own outDir.

## Use Cases

Help track down files that are wrongly importing from it's own dist directory.
I don't know if there are valid use cases where you would want to do this but I can only think of (refactor) errors.

## Examples

In a big refactor I moved a class from a project to a shared directory (compiled with composite: true, imported into projects with "references").
I made the following change without thinking because it satisfied the compiler.
```diff
- import mongoose from "../../shared/dist/mongo";
+ import mongoose from "../dist/mongo";
```
Everything seemed to work fine (no error was shown in vscode on the import line itself, and the now shared class worked) until the next week I notice the following errors when compiling the shared dir:
```
error TS5055: Cannot write file '.../shared/dist/interfaces/branch.d.ts' because it would overwrite input file.
error TS5055: Cannot write ...
```
I did not notice these errors while doing the refactor itself because the `tsc -w` for the shared directory was running in a forgotten terminal tab. A warning or error on the import line itself when doing something like this would save a lot of debugging time.

## Checklist

My suggestion meets these guidelines: (this is my guess, don't know exactly what the change would entail)

* [ ] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).
Repository: pytorch
Issue: Slow (20-50x) RNN tutorial/example when torch is installed using pip comp. to conda installation
Labels: module: binaries,module: performance,module: rnn,triaged,module: mkl

## ❓ Questions and Help

The example https://pytorch.org/tutorials/intermediate/char_rnn_classification_tutorial.html 
runs slow on pytorch installations 1.[320].x[+cudaxxx ]
I first noticed that behavior on an really old version of torch, then updated. The example ran 50 times faster on a Colab notebook and on a windows machine then on my workstation. Then i tried different environments in docker and found that the behavior is observable for all environments with and without nvidia cuda and different distributions when using pip to install torch. 
Conda installations are running fine.

Did i do something wrong?

cc @ezyang @VitalyFedyunin @ngimel @mruberry @zou3519
Repository: godot
Issue: Tilemap not displaying correctly with vertex shader
Labels: bug,topic:rendering,confirmed,regression

**Godot version:**
3.2 beta
**OS/device including version:**
mac / android
**Issue description:**
I have a tilemap
![tilemap](https://user-images.githubusercontent.com/14961837/68766408-138d4680-061f-11ea-95fe-caf75acb6e0a.png)
the solid red area is initially off the screen and not visible. By using a vertex shader to apply a barrel distortion of sorts, the solid red area will ordinarily become visible.
![311](https://user-images.githubusercontent.com/14961837/68766586-6cf57580-061f-11ea-8f0d-8126527a6e57.png)
this is working ok for me in 3.1.1 on my mac and android devices with the default quadrant size of 16.

in 3.2beta 1 I am seeing this
![322Beta](https://user-images.githubusercontent.com/14961837/68766716-afb74d80-061f-11ea-9726-0068f82aae3c.png)
its always like that on my android devices but sometimes its ok on the mac until you resize the screen and then the left solid portion will flicker on and off. I have tried changing the quadrant size but was unable to get it working for me as it does in 3.1.1
**Steps to reproduce:**
run the attached project, if it looks okay try resizing the screen as well.
**Minimal reproduction project:**
[BARRELDIST.zip](https://github.com/godotengine/godot/files/3841259/BARRELDIST.zip)
Repository: rust
Issue: ICE: Adding `-C save-temps` to incremental compile causes rustc_codegen_ssa::back::write panic
Labels: I-ICE,E-needs-test,P-medium,T-compiler,A-incr-comp,C-bug,glacier

Steps to reproduce:

```
% mkdir temp
% cd temp
% touch lib.rs
% rustc +nightly lib.rs --crate-type=lib -C incremental=incr
% rustc +nightly lib.rs --crate-type=lib -C incremental=incr -C save-temps
thread '<unnamed>' panicked at 'assertion failed: `(left == right)`
  left: `false`,
 right: `true`', src/librustc_codegen_ssa/back/write.rs:872:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.40.0-nightly (50f8aadd7 2019-11-07) running on x86_64-unknown-linux-gnu

note: compiler flags: -C incremental -C save-temps --crate-type lib

thread '<unnamed>' panicked at 'src/librustc_codegen_ssa/back/write.rs:1488: worker thread panicked', src/librustc/util/bug.rs:37:26

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.40.0-nightly (50f8aadd7 2019-11-07) running on x86_64-unknown-linux-gnu

note: compiler flags: -C incremental -C save-temps --crate-type lib

thread 'rustc' panicked at 'src/librustc_codegen_ssa/back/write.rs:1758: panic during codegen/LLVM phase', src/librustc/util/bug.rs:\
37:26

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.40.0-nightly (50f8aadd7 2019-11-07) running on x86_64-unknown-linux-gnu

note: compiler flags: -C incremental -C save-temps --crate-type lib
```
Repository: TypeScript
Issue: Incremental type narrowing, enabling gradual object initialization
Labels: Suggestion,Awaiting More Feedback

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker.

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ, especially the "Common Feature Requests" section: https://github.com/Microsoft/TypeScript/wiki/FAQ

-->

## Search Terms

delayed initialization, gradual initialization

## Suggestion

<!-- A summary of what you'd like to see added or changed -->

What if, on every assignment to either a value or a property, that the type of that value is narrowed? It's probably easiest explained with an example:

## Use Cases

It means that this code for gradually initializing an object would just work:

```typescript
type Person = { firstName: string, surname: string }

function f() : Person {
    const p : Partial<Person> = {}

    p.firstName = ""
    p.surname = ""

    return p; // Error: Type 'Partial<Person>' is not assignable to type 'Person'
}
```

Currently this code does not type check because the compiler doesn't change the type of `p` after the assignments to its properties.

My thinking is that, for any value `x` of type `X : { a : unknown }`, 

```typescript
x.a = "some string"
```

would result in `x` having its type narrowed to:

```typescript
X & { a : string }
```

This means that the partial initialization example would work. If it works for variables as well as properties then so would this:

```typescript
function f(mode: "read" | "read/write") {
    // ... Code ...
}

let s: string;

s = "read"

f(s)
```

## Examples

<!-- Show how this would be used and what the behavior would be -->

## Checklist

My suggestion meets these guidelines:

* [X] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [X] This wouldn't change the runtime behavior of existing JavaScript code
* [X] This could be implemented without emitting different JS based on the types of the expressions
* [X] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [X] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).
Repository: go
Issue: cmd/compile: encoded pkg path shown in stack trace
Labels: NeedsInvestigation

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version devel +99957b6930 Tue Nov 12 05:35:33 2019 +0000 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/myitcv/.cache/go-build"
GOENV="/home/myitcv/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/myitcv/gostuff"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/myitcv/gos"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build670035236=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

Run the following [`testscript`](https://godoc.org/github.com/rogpeppe/go-internal/cmd/testscript) repro:

```
go run main.go

-- go.mod --
module mod.com

go 1.14

require (
        golang.org/x/net v0.0.0-20190620200207-3b0461eec859 // indirect
        gopkg.in/tomb.v2 v2.0.0-20161208151619-d5d1b5820637
)
-- main.go --
package main

import "gopkg.in/tomb.v2"

func main() {
	done := make(chan struct{})
	var t tomb.Tomb
	t.Go(func() error {
		panic("here")
		close(done)
		return nil
	})
	<-done
}
```


### What did you expect to see?

```
panic: here

goroutine 18 [running]:
main.main.func1(0x0, 0x0)
        /home/myitcv/gostuff/src/github.com/myitcv/playground/main.go:9 +0x39
gopkg.in/tomb.v2.(*Tomb).run(0xc00018e000, 0xc00018a060)
        /home/myitcv/gostuff/pkg/mod/gopkg.in/tomb.v2@v2.0.0-20161208151619-d5d1b5820637/tomb.go:163 +0x38
created by gopkg.in/tomb.v2.(*Tomb).Go
        /home/myitcv/gostuff/pkg/mod/gopkg.in/tomb.v2@v2.0.0-20161208151619-d5d1b5820637/tomb.go:159 +0xba
exit status 2
```


### What did you see instead?

```
panic: here

goroutine 18 [running]:
main.main.func1(0x0, 0x0)
        /home/myitcv/gostuff/src/github.com/myitcv/playground/main.go:9 +0x39
gopkg.in/tomb%2ev2.(*Tomb).run(0xc00018e000, 0xc00018a060)
        /home/myitcv/gostuff/pkg/mod/gopkg.in/tomb.v2@v2.0.0-20161208151619-d5d1b5820637/tomb.go:163 +0x38
created by gopkg.in/tomb%2ev2.(*Tomb).Go
        /home/myitcv/gostuff/pkg/mod/gopkg.in/tomb.v2@v2.0.0-20161208151619-d5d1b5820637/tomb.go:159 +0xba
exit status 2
```

Note the `%2e` in the stack trace.

cc @bcmills @randall77 @jayconrod
Repository: java-design-patterns
Issue: Microkernel architecture
Labels: info: help wanted,epic: pattern,epic: architecture,type: feature

## Description
The Microkernel Architecture design pattern, also known as the plug-in architecture, is ideal for product-based applications that need to extend their core functionalities through plug-ins. This pattern is characterized by a minimal core system that contains the essential functionality of the application, and additional features or customizations are provided through independent plug-in modules. This approach promotes extensibility, flexibility, and maintainability of the software by isolating the core system from the custom processing logic.

### Main Elements:
1. **Core System**: The foundational part of the application containing the minimal functionality required to run the system.
2. **Plug-in Modules**: Independent components that add specialized processing or additional features to the core system. They should remain isolated from each other to avoid dependencies.
3. **Plug-in Registry**: A system that manages the available plug-in modules, providing information such as their names, data contracts, and access protocols.

## References
1. Priyal Walpita's article on Microkernel Architecture: [Software Architecture Patterns: Microkernel Architecture](https://priyalwalpita.medium.com/software-architecture-patterns-microkernel-architecture-97cee200264e)
2. ["Software Architecture Patterns" by Mark Richards: Chapter 3 (Microkernel Architecture)](https://github.com/iluwatar/java-design-patterns/files/3841915/Software-Architecture-Patterns.pdf)

## Acceptance Criteria
1. **Core System Implementation**: Develop a core system with essential functionalities and a mechanism to interact with plug-in modules.
2. **Plug-in Module Integration**: Create at least two plug-in modules that demonstrate the extensibility of the core system by providing additional features.
3. **Plug-in Registry**: Implement a plug-in registry to manage the available plug-in modules, ensuring they can be dynamically discovered and loaded by the core system.
Repository: java-design-patterns
Issue: Space-based architecture
Labels: info: help wanted,epic: pattern,epic: architecture,type: feature

## Description
The Space-Based Architecture design pattern is aimed at addressing scalability and concurrency issues by minimizing factors that limit application scaling. This pattern is ideal for applications with high user load and variable concurrent user volumes. The key components include processing units and virtualized middleware, with the primary aim of distributing and replicating data in-memory across processing units, eliminating the traditional database bottleneck.

### Main Elements of the Pattern
1. **Processing Units**: These contain application components, in-memory data grids, optional asynchronous persistent stores for failover, and a data replication engine. They can be dynamically started or stopped based on user load.
2. **Virtualized Middleware**: This component includes:
   - **Messaging Grid**: Manages request routing to available processing units.
   - **Data Grid**: Manages data replication across processing units.
   - **Processing Grid** (optional): Manages distributed request processing across different processing units.
   - **Deployment Manager**: Monitors load conditions to dynamically scale processing units up or down.

## References
- [Space-Based Architecture](https://en.wikipedia.org/wiki/Space-based_architecture)
- [Richards, Mark. "Software Architecture Patterns". O’Reilly Media, 2015.](https://github.com/iluwatar/java-design-patterns/files/3841915/Software-Architecture-Patterns.pdf)

## Acceptance Criteria
1. **Implementation of Processing Units**: Develop processing units that include application modules, in-memory data grids, and data replication engines.
2. **Middleware Components**: Implement virtualized middleware components such as messaging grid, data grid, and deployment manager to manage request routing, data replication, and dynamic scaling.
3. **Scalability and Performance Testing**: Conduct extensive testing to ensure the system can handle high concurrency and variable loads, achieving near-infinite scalability and high performance.
Repository: svelte
Issue: Examples need documentation
Labels: stale-bot,temp-stale,documentation

Some of the examples on the Svelte website are straightforward/intuitive but others need some explanation/documentation.  For example, the "Deferred transitions" example is excellent but there are a lot of things going on and it's difficult to understand.  In particular, what is the essential lesson of the example vs. understanding all the code needed to demonstrate it.  

Therefore, I recommend:

- Review of each example
- Adding a README file to each example.  Perhaps a README.svelte file could be added to each example.
- Adding more comments to each example.

e.g.

**App.svelte**

```
<script>
	import README from './README.svelte';

	let name = 'world';
</script>


<README />

<h1>Hello {name}!</h1>
```

**README.svelte**

```
<hr>
<h1>
	README - Hello world
</h1>

This example shows how a variable in the script section can be used in a HTML template.

```

![image](https://user-images.githubusercontent.com/1135694/68781628-10399100-0606-11ea-8c45-647dec3f936e.png)
Repository: react
Issue: "Should not already be working" in Firefox after a breakpoint/alert
Labels: Type: Bug,Difficulty: medium,Type: Needs Investigation,good first issue

**Do you want to request a *feature* or report a *bug*?**
Bug

**What is the current behavior?**
I'm seeing "Error: Should not already be working" after upgrading to React 16.11

**Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?**

This is exclusively happening on an older version of Chrome, 68.0.3440 on Windows 7

I was unable to reproduce this in a VM environment but our Sentry is getting littered with these errors. 

I know it's a long shot, but I wasn't able to find any information about this error anywhere, just a reference in the error codes file in react, so thought it would be a good idea to report this just in case. Curious if anyone has seen this.
Repository: go
Issue: net: better docs for PreferGo in Resolver
Labels: Documentation,help wanted,NeedsInvestigation

Guys, how are you?

I have a suggestion to improve doc about parameter `PreferGo` on struct Resolver based on a comment in another issue. https://github.com/golang/go/issues/19268#issuecomment-345384876

Suggestion adds more a small text:
```
When you use the variable PreferGo set to true you will be 
able to use your dial, If you use PreferGo set to false it will ignore 
your dial and use directly "/etc/resolv.conf "
```


Reference Doc:
https://github.com/golang/go/blob/a38a917aee626a9b9d5ce2b93964f586bf759ea0/src/net/lookup.go#L120
Repository: pytorch
Issue: Tensor.nbytes() returns itemsize * numel for sparse tensors
Labels: module: sparse,module: autograd,triaged,actionable,fixathon

scipy sparse tensors don't have an "nbytes".  I guess you could argue for this or doing nnz * itemsize, but it seems best to just error in this case.

cc @ezyang @SsnL @albanD @zou3519 @gqchen @vincentqb
Repository: pytorch
Issue: [build] gcc 7.4 needs CMAKE_CXX_FLAGS="-std=gnu++11"
Labels: module: dependency bug,module: build,triaged

## 🐛 Bug
Since I can't use conda gcc 7.3 (https://github.com/pytorch/pytorch/issues/29093), I tried to build master with system gcc `7.4` and met 
```
CMake Error at third_party/fbgemm/third_party/asmjit/CMakeLists.txt:100 (target_compile_features):
  target_compile_features no known features for CXX compiler

  "GNU"

  version 7.4.0.
Call Stack (most recent call first):
  third_party/fbgemm/third_party/asmjit/CMakeLists.txt:332 (asmjit_add_target)
```

I was able to fix it by explicitly adding stdlib11, i.e., adding 
```
CMAKE_CXX_FLAGS="-std=gnu++11",
```
to https://github.com/pytorch/pytorch/blob/f0dd7517f2c71a1ae566e75d935d6aefd651ff72/tools/setup_helpers/cmake.py#L289

Maybe I should submit this issue to `asmjit` repo?