sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: [feature request] bincount along specified dimension(s)
Labels: triaged,module: numpy,module: sorting and selection,function request

## 🚀 Feature

`torch.bincount` along specified dimension(s).


cc @mruberry @rgommers @heitorschueroff
Repository: go
Issue: proposal: cmd/go: subcommands to add and remove modules from the module cache
Labels: Proposal,NeedsInvestigation,Proposal-Hold,modules

For a number of use-cases, it would be helpful to be able to upload modules to the module cache from source code (not just zip files!) in a local directory or repository.

Some examples:
* Testing changes involving cyclic module requirements (#27542, #27899).
* Bootstrapping a server to serve the module containing itself (#28029, but that can be worked around using `replace` directives).
* Storing and distributing private modules using version control systems that don't work well with zip files (related to #27618).

To support those use-cases, I propose the following subcommands:

* `go mod pack [MODULE[@VERSION]] DIR`: construct a module in the module cache from the module source code rooted at `DIR` (at version `VERSION`). If the `MODULE` is omitted, it is inferred from `DIR/go.mod`. If `@VERSION` is provided, it must be a valid semantic version, and `go mod pack` fails if that version already exists with different contents. If `@VERSION` is omitted, `DIR` must be within a supported version control repository, and `go mod pack` will attempt to infer the version from the repo state (commits and tags).

* `go mod unpack MODULE[@VERSION] DIR`: download the contents of `MODULE` to `DIR`. If `@VERSION` is omitted, use the active version from the main module (if any), or `latest` if no version is active. (In contrast to `go mod vendor`, `go mod unpack` would unpack the entire contents of the module — not just the packages in the import graph of the main module.)

* `go clean -m MODULE[@VERSION]`: remove `MODULE@VERSION` from the module cache. If run within a module, also remove the corresponding entry from its `go.sum` file. If `@VERSION` is omitted, remove all versions of `MODULE` from the module cache (and `go.sum` file).

CC @hyangah @jadekler @rsc @myitcv @thepudds @rasky @rogpeppe @FiloSottile
Repository: TypeScript
Issue: Provide a way to specify inheritance explicitly
Labels: Suggestion,Needs Proposal

**TypeScript Version:**  3.0.0-dev.201xxxxx

Its seems there's really no way currently to setup inheritance when working with complex mixins, and/or extending prototypes manually. While mixin support landed on TypeScript recently, it only addresses very simple cases. It's usefulness ends when you also want mixin that inherit from different classes on their own. To illustrate it with an example:

```js
export class Component extends HTMLElement implements ComponentCore {
    constructor() {
        super();
        ComponentCore.init(this);
    }
}
```

where the ComponentCore.init does mixin style implementation of ComponentCore. Tried the mixin approach documented, but that doesn't seem to work when you want to extend from HTMLElement here. 

Now, moving on a real-life example with a lot more context: https://github.com/prasannavl/icomponent/blob/v5.1.1/packages/icomponent/src/component.ts#L6

I had to jump through hoops and do something like 

```ts
ComponentCore.extend(ComponentImpl);
export interface IComponent extends ComponentImpl, ComponentStatics, ComponentCore, Constructor<IComponent> { }
export const Component: IComponent = ComponentImpl as any;
``` 

in order to even get inheritance working properly. This is further complicated, when you extend from these classes, since there's currently it's ` const Component`, and as such it is not always interpreted by the compiler as a class -- As as example - a few lines down in the same: https://github.com/prasannavl/icomponent/blob/v5.1.1/packages/icomponent/src/component.ts#L30

You can't pass `Component` into generics parameters, since it's no longer a class. 

**Possible solutions**:

- A simple and effective solution would be to just be even annotate the class and having different parents. 
// @ts-inherit: IComponentCore, HTMLElement, etc,
- Extend the `extends` syntax to inherit multiple classes with say "extends X, !Y, !Z` -- The exclamation is the indicator of these special classes
- Allow implements to inherit a class without actually implementing it, with the same as above syntax. This is probably the least intrusive way, but unlike `extends`, it forces you explicitly define interfaces to be able to do so.
Repository: pytorch
Issue: [sparse] add descriptions and examples for methods at torch.sparse doc page
Labels: module: sparse,triaged

- There is no descriptions / examples for the methods listed at at doc page
- It will be much easier for new comers to learn how to use sparse if we improve doc a little bit

cc @aocsa @nikitaved @pearu @mruberry @IvanYashchuk
Repository: godot
Issue: Editing dependencies and accidentally linking to the same dependency, will always update the other matching dependency
Labels: bug,topic:core,topic:editor,confirmed,usability

**Godot version:** 3.0

**OS/device including version:** Windows 10


**Issue description:**

For my project setup I have 3D characters composed of different interchangeable parts contained in separate scenes, that I swap out to create new characters, using the edit dependencies dialog.  On occasion sometimes I "corrupt" the scene by choosing a file that's already referenced in the dependencies.  By "corrupt" I mean I'm unable to undo my changes, and make the dependency unique, it will always update the other dependency to match.


**Steps to reproduce:**

Create 5 scenes, Scene A, Scene B, Scene C, Scene D, Scene E
Have Scene A, contain B and C.
Edit the dependency of B and C both to D
Now edit B OR C to E, this will update both B and C to E, when I expect one to only update

**Suggestion:**

If this is intended, I think a warning dialog should pop up.  Otherwise make scene dependencies have unique links.
Repository: godot
Issue: Directory inconsistency when opening an editor FileDialog
Labels: bug,topic:editor,confirmed

Godot 3.1 alpha2
Windows 10 64 bits

When setting up a different default directory for new projects, I found the location at which the File Dialog opens is inconsistent. It doesnt remember where it was, and also gets the drive letter wrong.

In Godot 3.0.6
------------------

I open a project, I go to Editor Settings, and this is the current directory:
![image](https://user-images.githubusercontent.com/1311555/48645206-e17de000-e9dc-11e8-8599-3af2428781e8.png)

If I open the file dialog to set a new path, it opens in the same directory as my project, with correct drive letter:
![image](https://user-images.githubusercontent.com/1311555/48645246-fce8eb00-e9dc-11e8-8aa4-285d5d6ff8da.png)

If I navigate elsewhere and close the dialog, it remembers where it was if I open it again.

In Godot 3.1 alpha2
-----------------------

I open a project, go to Editor Settings, it starts out the same:
![image](https://user-images.githubusercontent.com/1311555/48645351-56511a00-e9dd-11e8-82dc-178caca2d12d.png)

But, if I click on the directory icon to change it, it opens in the directory indicated by the property, which I guess was an intented change? If yes, that would also explain why the dialog no longer remember where it was when opening it again. But more importantly, you will also notice that the drive letter is wrong, which forces me to select `C:`, and then `D:` again to trigger the change and see the correct drive.
![image](https://user-images.githubusercontent.com/1311555/48645391-75e84280-e9dd-11e8-9b85-6206b7b86e9b.png)

Also, if I write just `D:` in the address bar instead of using the dropdown, it doesn't just go to `D:`, but instead warps straight into my project folder (Which is in `D:/some/where/in/a/folder`). This did not happen in 3.0.6.
Repository: pytorch
Issue: running caffe2 float16 tensors results in aten runtime error
Labels: caffe2

## 🐛 Bug

I am trying to create an FP16 tensor in caffe2, and I am following the method described in https://github.com/pytorch/pytorch/blob/master/caffe2/proto/caffe2.proto#L86  (set type to FLOAT16, store float16 as unsigned short in int32_data)

However, upon attempting to run the network using workspace.RunNet, I get:

    RuntimeError: storage_.IsType<T>() ASSERT FAILED at /home/nathan/pytorch/aten/src/ATen/core/TensorImpl.h:588, please report a bug to PyTorch. Tensor type mismatch, caller expects elements to be float, while tensor contains int. Error from operator: 
    input: "data" input: "scaled_datascale_w" output: "scaled_data" type: "Mul" arg { name: "axis" i: 1 } arg { name: "broadcast" i: 1 } arg { name: "float16_compute" i: 1 } 


## To Reproduce

This comes from converting an existing Float32 model into Float16. The model is loaded and the ops and blobs are copied.  To do the Float32->Float16 conversion of the tensors, 
I follow the comments at https://github.com/pytorch/pytorch/blob/master/caffe2/proto/caffe2.proto#L86:
    // Note about float16: in storage we will basically convert float16 byte-wise
    // to unsigned short and then store them in the int32_data field.
 
which gets done as follows:

    tensor.data_type = caffe2_pb2.TensorProto.FLOAT16
    float16_list = list(arr.flatten().astype(np.float16))  
    ushort_list = [ struct.unpack('H', struct.pack('e', f16))[0] for f16 in float16_list]  

so the tensor looks like:

	[dims: 32
	 dims: 32
	 dims: 3
	 dims: 3
	 data_type: FLOAT16
	 int32_data: 10967
	 int32_data: 10247
	 ... ]

For the initialization, since float16 data went in the int32 data, I use a GivenTensorIntFill like this:

            op = core.CreateOperator(
                "GivenTensorIntFill", [], [tensor.name],
                arg=[
                    MakeArgument("shape", list(tensor.dims)),
                    MakeArgument("values", tensor.int32_data)])
            init_net.op.extend([op]) 

RunNetOnce with the init net seems okay, but doing workspace.RunNet with the predict net gets the runtime error out of ATen

## Environment

PyTorch version: 1.0.0a0+5b15a50
Is debug build: No
CUDA used to build PyTorch: 8.0.61

OS: Ubuntu 16.04.5 LTS
GCC version: (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609
CMake version: version 3.5.1

Python version: 3.6
Is CUDA available: Yes
CUDA runtime version: 8.0.61
GPU models and configuration: 
GPU 0: GeForce GTX 1060 6GB
GPU 1: GeForce GTX 1080

Nvidia driver version: 410.48
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.6.0.21
/usr/lib/x86_64-linux-gnu/libcudnn.so.7.1.4
/usr/lib/x86_64-linux-gnu/libcudnn_static_v6.a
/usr/lib/x86_64-linux-gnu/libcudnn_static_v7.a
Repository: TypeScript
Issue: Type assertions using Exact, Subset, Superset
Labels: Suggestion,In Discussion

I have suffered several times with the limitations of casting like so:

```js
res.json(<Foo>{foo:'bar'});
```

the above cast/assertion will work even if the anonymous object does not have all the fields in type `Foo`.
For example, this question I had: https://stackoverflow.com/questions/53328459/prevent-compilation-unless-all-fields-exist

This feature request is for something like this:

```js
res.json(Exact<Foo>{foo:'bar'});
res.json(Subset<Foo>{foo:'bar'});
res.json(Superset<Foo>{foo:'bar'});
```

note this is similar to the existing construct `Partial`, as in `Partial<T>`, hopefully the above are self-explanatory. I am not sure if both `Subset<>` and `Superset<>` make sense, but one of them should.
Repository: opencv
Issue: connectedcomponentswithstats Is Not Thread-Safe
Labels: category: imgproc,incomplete,needs reproducer,needs investigation

##### System information (version)

- OpenCV =>3.3.1
- Operating System / Platform => Windows 10 - 64 Bit
- Compiler => Visual Studio 2015

##### Detailed description

connectedcomponentswithstats() is not thread-safe. It hangs sometimes (maybe 5% of the times). I'm guessing that it happens in the first few threads.


##### Steps to reproduce

This program should always return "5 5" (we have 5 threads) but sometimes it returns "5 4" (one hangs).
Something that can't be noticed easily when using the program because it triggers no errors.

```
// std::atomic<int> first = 0, last = 0;
ThreadPool pool(thread::hardware_concurrency()); // 2 threads
for (int i = 0; i < 5; i++) {
    pool.enqueue([i, binaryImg] { // Add the thread.
        // code ...
        first++;
        Mat labels, stats, centroids;
        int objCount = connectedComponentsWithStats(binaryImg, labels, stats, centroids, 8); // PROBLEM. Sometimes the following lines inside this block won't be executed.
        last++;
        // code ...
    });
}
pool.~ThreadPool(); // Join all the threads.
cout << first << ' ' << last << endl;

```
Repository: rust
Issue: rustdoc: "Implementations on Foreign Types" sidebar items should link to specific impls
Labels: T-rustdoc,C-bug,A-rustdoc-ui,S-needs-repro

Each of the impl sections in the "Implementations on Foreign Types" section has its own ID. Consider the [foreign impls](https://docs.rs/tokio/0.1.12/tokio/prelude/trait.Stream.html#foreign-impls) for the `Stream` trait from `tokio`. The first impl header is `#impl-Stream`, the second impl header is `#impl-Stream-1`, the third impl header is `#impl-Stream-2`, and so on.

But, the links in the sidebar do not jump to these specific IDs. Instead, they all link to `#impl-Stream`, or the first impl in the list. For a trait like `Stream`, which has many methods and many foreign implementors, this makes it difficult to get to a specific impl (to see the associated types, for example). You have to search the page, collapse the sections, or just scroll.

Since unique IDs are already generated for the impl sections, it would be great if the sidebar items used them to make navigation easier.
Repository: material-ui
Issue: [material-ui][docs] Add examples rendering in iframes, popups, and shadow DOM
Labels: docs,priority: important

<!--- Provide a general summary of the issue in the Title above -->
Material-UI Componentss not rendering properly when those are inside <iframe>, I have used many iframe react-comps but still Material UI is not working in any of them.
<!--
    Thank you very much for contributing to Material-UI by creating an issue! ❤️
    To avoid duplicate issues we ask you to check off the following list.
-->
There already closed threads without proper answers.
<!-- 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 and I haven't find any solution.

## Expected Behavior
It should render components in iframe as well
<!---
    Describe what should happen.
-->

## Current Behavior
<!---
    Describe what happens instead of the expected behavior.
-->
It is not rendering the components inside iframe, showing plain html elements without any styles
## Steps to Reproduce
<!---
    Provide a link to a live example (you can use codesandbox.io) and an unambiguous set of steps to reproduce this bug.
    Include code to reproduce, if relevant (which it most likely is).

    This codesandbox.io template _may_ be a good starting point:
    https://codesandbox.io/s/github/mui-org/material-ui/tree/master/examples/create-react-app

    If you're using typescript a better starting point would be
    https://codesandbox.io/s/github/mui-org/material-ui/tree/master/examples/create-react-app-with-typescript

    If YOU DO NOT take time to provide a codesandbox.io reproduction, should the COMMUNITY take time to help you?
<iframe src="https://codesandbox.io/embed/rjo0r3yooo" style="width:100%; height:500px; border:0; border-radius: 4px; overflow:hidden;" sandbox="allow-modals allow-forms allow-popups allow-scripts allow-same-origin"></iframe>
-->
Link: https://codesandbox.io/s/rjo0r3yooo

1. Please go to sandbox link provided in the above


## Context
<!---
    What are you trying to accomplish? How has this issue affected you?
    Providing context helps us come up with a solution that is most useful in the real world.
-->

## Your Environment
<!---
    Include as many relevant details about the environment with which you experienced the bug.
    If you encounter issues with typescript please include version and tsconfig.
-->

| Tech         | Version |
|--------------|---------|
| Material-UI  | v3.5.1  |
| React        |   v16.6.3      |
| Browser      |   chrome      |
Repository: godot
Issue: Nodes magically moves to bottom of tree hierarchy 
Labels: bug,topic:core,confirmed

 
**Godot version:**
0afdc5c559520204987544d30560745dbf29a390


**OS/device including version:**
Windows 10, 64-bit, GTX 960


**Issue description:**
With an instance scene and "editable children" selected, add a Particles2D node to the child of that instance scene, and place it somewhere in the hierarchy, press F6 to scene preview. Then, switch to a different scene, then switch back and you will notice that Particles2D node is at the bottom.
**This does not happen on 3.0.6**
Example:
![](https://i.gyazo.com/fa19498947ab068c01f0a9ad1dc18e66.gif)
Repository: rust
Issue: Support path prefix which refers to per-user DosDevices ("\??\C:\...")
Labels: O-windows,T-libs-api,A-io

`std::path::Prefix` does not support windows prefixes like `\??\C:\...`.

[See more about prefix which refers to per-user DosDevices](https://reverseengineering.stackexchange.com/questions/3798/c-question-marks-in-paths)

```rust
#![allow(unused)]
use std::path::{Component, Path, Prefix};
fn main() {
    let path = Path::new(r"\??\C:\Users\Rust\Pictures\Ferris");
    assert!(path.is_absolute());
}
```

([Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2015&gist=7e4c26dd016ce69c73fe076721f62b64))

Errors:

```
   Compiling playground v0.0.1 (/playground)
    Finished dev [unoptimized + debuginfo] target(s) in 0.61s
     Running `target/debug/playground`
thread 'main' panicked at 'assertion failed: path.is_absolute()', src/main.rs:7:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.

```
Repository: TypeScript
Issue: namespace containing only 'const enum' can be used as value -> causing runtime error
Labels: Bug

<!-- 🚨 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.
-->

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.2.0-dev.20181110

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** namespace const enum

**Code**

```ts
namespace foo {
    export const enum Foo {}
}
console.log(foo);
```

**Expected behavior:**
Error when using `foo` as a value. It's already an error to use a namespace that contains only types (and is therefore not emitted) as value.
The Symbol of the ModuleDeclaration actually contains `constEnumOnlyModule: true`, it just needs to be checked.

**Actual behavior:**

Doesn't emit the namespace in transpiled output, but it's still referenced by `console.log(foo);`

**Playground Link:** https://agentcooper.github.io/typescript-play/#code/HYQwtgpgzgDiDGEAEAzA9mpBvAUE-SEAHjGgE4AuS8awUVEwArmEgGIbYC+OPNdaADYQAdILQBzABTo0ASgDcQA

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
Repository: create-react-app
Issue: Create-react-app test debug not stopping at breakpoint
Labels: issue: bug,issue: needs investigation

I am really not sure what I am doing wrong here. I am trying to write unit tests and am using Enzyme and Jest (obviously). Here is what my package.json looks like


```
{
  "name": "balena-io-test",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
....
  },
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "test:debug": "react-scripts --inspect-brk test --runInBand",
    "eject": "react-scripts eject"
  },
  "eslintConfig": {
    "extends": "react-app"
  },
  "browserslist": [
    ">0.2%",
    "not dead",
    "not ie <= 11",
    "not op_mini all"
  ],
  "devDependencies": {
    "enzyme": "^3.7.0",
    "enzyme-adapter-react-16": "^1.7.0",
    "jest": "^23.6.0",
    "jest-mock": "^23.2.0",
    "react-scripts": "^2.1.1",
    "redux-mock-store": "^1.5.3"
  }
}
```
Now test are running just fine with npm test and I am trying to debug with npm run test:debug. 

Initially the react-script breaks at the first line which is what I would be expect but after that jest just runs without stopping at any debugger break points. I also cannot see any of the .test files in chrome. I am not sure if it is my environment which is to blame or something to do with create-react-app.

Here is a test I am trying to debug

```
describe('<LightingDevices>', ()=> {
  let wrapper;
  beforeAll(()=>{
    debugger;  <------ should stop here
    const updateDevice = jest.fn();
    const setUpAllLights = jest.fn();
    wrapper = shallow(<LightingDevices updateDevice={updateDevice} setUpAllLights={setUpAllLights}/>);

  });
....
```
Repository: rust
Issue: Lint: spurrious unused_parens on assignment of comparison
Labels: C-enhancement,A-lints,A-diagnostics,T-compiler,L-unused_parens

The following code triggers the `unused_parens` lint, but without the parens the equality operator can be (visually) confused with the assignment.
```rust
fn main()
{
    let bar = "";
    let _foo = (bar == "baz");
}
```
Repository: rust
Issue: 2018 idioms: rustc-internal crates linted to be removed when they can't
Labels: A-lints,E-needs-test,A-suggestion-diagnostics,A-edition-2018

Discovered in https://github.com/rust-lang/cargo/issues/6323

```rust
#![feature(extern_crate_item_prelude)]
#![feature(rustc_private)]
#![warn(rust_2018_idioms)]

extern crate syntax;

#[allow(unused_imports)]
use syntax::ast;

fn main() {}
```

yields:

```
warning: unused extern crate
 --> src/main.rs:5:1
  |
5 | extern crate syntax;
  | ^^^^^^^^^^^^^^^^^^^^ help: remove it
  |
note: lint level defined here
 --> src/main.rs:3:9
  |
3 | #![warn(rust_2018_idioms)]
  |         ^^^^^^^^^^^^^^^^
  = note: #[warn(unused_extern_crates)] implied by #[warn(rust_2018_idioms)]
```

This may be fixed by https://github.com/rust-lang/rust/pull/55884, but it's not clear to me at least
Repository: vue-element-admin
Issue: complex-table loading time
Labels: not vue-element-admin bug

complex-table is taking lot of time to load if records are  more  say 100000.
you can change the /mock/article.js  const count = 100000 to replicate this issue.