sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: Move collate_fn functionality / responsibility into Dataset object
Labels: module: dataloader,triaged

## 🚀 Feature
The `Dataset` `__getitem__` class should be expected to handle advanced indexing, as opposed to just single integer indexing, and batching functionality provided by DataLoader should then use this instead of collate_fn, i.e.

`batch = collate_fn([dataset[i] for i in indices])`

would become

`batch = dataset[indices]`

## Motivation

- The type of collation necessary for a dataset is more a property of the Dataset than the DataLoader.
- In particular, for `TensorDataset` objects, this will massively speed up batch creation. (Currently DataLoader is prohibitively slow, see #4959.)
- It also allows Datasets to be used more flexibly outside of a DataLoader.

## Pitch

I think it's quite natural to embed this collate functionality into the Dataset rather than the DataLoader. There are no downsides that I can see to changing this functionality. By default, you could simply pass it back through the current default_collate argument. For example, the class for Dataset could become

```python
class Dataset(object):
    def __getitem__(self, index):
        if type(index) is int:
            raise NotImplementedError
        else:
            requested_elements = [self[i] for i in index]
            return default_collate(requested_elements)
```

This isn't completely backwards-compatible with the current API, however it's a simple fix. Exising implementations which are working can just change their implementation of the `__getitem__` method to
```python
if type(index) is int:
    (... existing implementation...)
else:
    super().__getitem__(self, index)
```

I've made a quick-and-dirty change to this effect [in this fork](https://github.com/mboratko/pytorch/commit/e16804206c867201afbc283885e3a743ec486115). (I'm having trouble with CUDA versions blocking me setting up an actual build, and there's been no discussion yet, so I haven't set up a formal pull request.)


## Alternatives

An alternative workaround to #4959 is simply not to use a `DataLoader` for `TensorDatasets` (or any other datasets that support faster native advanced indexing) and instead write the batch functionality directly. This results in code duplication and also isn't possible for libraries that expect `DataLoader` objects (eg. fastai). The solution so far has been that I wrap `DataLoader` and `_DataLoaderIter` objects into new objects which make exactly the changes I am suggesting, however this obviously is less than desireable.

Obviously, there are also alternatives to my proposed implementation.

cc @SsnL @VitalyFedyunin @ejguan
Repository: flutter
Issue: Widget customizing
Labels: c: new feature,framework,P3,team-framework,triaged-framework

There are a lot of hardcoded widgets with their private parameters and instead devs to rewrite them with the custom code and copy-paste to have something different on enduser requests would be cool to provide provide some function that give inheristance of the desired widget and looks like
widget.copyof(baseclassname).with({changed_parameters_map})
Repository: pytorch
Issue: [feature request] ignore_index and size_average in nn.AdaptiveLogSoftMaxWithLoss
Labels: module: nn,triaged

**Feature request for nn.AdaptiveLogSoftMaxWithLoss**

Linked to https://github.com/pytorch/pytorch/pull/5287:

It would be nice if we could add these parameters to nn.AdaptiveLogSoftMaxWithLoss:

1) the "ignore_index" parameter, like in [F.cross_entropy](https://pytorch.org/docs/stable/nn.html?highlight=cross%20entropy#torch.nn.functional.cross_entropy), for batches with padding indexes
2) the `reduction` parameter

Thanks!
cc @albanD @mruberry @jbschlosser @SsnL @glample
Repository: flutter
Issue: Tree shaking and platform specific widgets
Labels: c: new feature,tool,engine,P3,team-engine,triaged-engine,:hourglass_flowing_sand:

There is a recurrent argument against Flutter in favor of React native:
React native allow reusable components that have the OS look&feel without having to test which platform we are on.

With flutter we have to manually switch over `defaultTargetPlatform`.
But there are two problems with this approach:

1. It requires a lot of boilerplate:

```
Widget build(BuildContext context) {
  return defaultTargetPlatform === TargetPlatform.android
    ? RaisedButton(...)
    : CupertinoButton(...);
}
```


2. This switch breaks tree shaking.

`defaultTargetPlatform` is _not_ a constant, therefore when doing a release build tree shaking cannot decide which platform code to includes... And ultimately includes both

____

This causes discussions such as this medium talk: https://medium.com/flutter-io/do-flutter-apps-dream-of-platform-aware-widgets-7d7ed7b4624d

or this package: https://pub.dartlang.org/packages/flutter_platform_widgets

These solve the boilerplate problem but kills tree-shaking.


Another alternative is to have different `main` for each platform.
This allows for a fully working tree-shaking, but we lose the "write once run everywhere" as we basically have to write things twice.


____

Flutter should provide an easy way to deal with this situation without having tons of boilerplate or shipping both Material and Cupertino widgets at once.
Repository: flutter
Issue: Setup default project structure to create editable host apps and hidden "modules" for linking projects.
Labels: tool,a: existing-apps,P3,team-tool,triaged-tool

Setup default project structure to create editable host apps and hidden "modules" for linking projects.

This project structure should be equivalent to running the following 2 commands in the current tooling:

flutter create -t module my_app
cd my_app
flutter make-host-app-editable

Ensure that when making these changes that anyone who currently have a "module" project gets automatically migrated to this editable structure.  We don't want public support for "make-host-app-editable" at this point in time, so we want to force everyone out of the current "module" project structure.

Rename the hidden directories for clarity:
.android_module
.ios_module

Ensure that hidden directories are marked hidden on windows.
Repository: rust
Issue: Compiling hyper 0.12 on armv7-linux-androideabi with target-features=+neon fails with LLVM ERROR: ran out of registers during register allocation
Labels: A-LLVM,O-Arm,T-compiler,C-bug,A-target-feature

```
root@7f26157a3837:~/hyper# cargo rustc --release -v --target "armv7-linux-androideabi" -- -C target-feature=+neon                                             
     Running `rustc --crate-name hyper src/lib.rs --crate-type lib --emit=dep-info,link -C opt-level=3 -C codegen-units=1 -C target-feature=+neon --cfg 'feature="__internal_flaky_tests"' --cfg 'feature="default"' --cfg 'feature="futures-cpupool"' --cfg 'feature="net2"' --cfg 'feature="runtime"' --cfg 'feature="tokio"' --cfg 'feature="tokio-executor"' --cfg 'feature="tokio-reactor"' --cfg 'feature="tokio-tcp"' --cfg 'feature="tokio-timer"' -C metadata=5c7c44dab8eed49e -C extra-filename=-5c7c44dab8eed49e --out-dir /root/hyper/target/armv7-linux-androideabi/release/deps --target armv7-linux-androideabi -L dependency=/root/hyper/target/armv7-linux-androideabi/release/deps -L dependency=/root/hyper/target/release/deps --extern bytes=/root/hyper/target/armv7-linux-androideabi/release/deps/libbytes-ddc5925e1332c4e2.rlib --extern futures=/root/hyper/target/armv7-linux-androideabi/release/deps/libfutures-169e26de4e2e0883.rlib --extern futures_cpupool=/root/hyper/target/armv7-linux-androideabi/release/deps/libfutures_cpupool-a7ff7f77e82e2fd1.rlib --extern h2=/root/hyper/target/armv7-linux-androideabi/release/deps/libh2-a6ab8093d4aaef1e.rlib --extern http=/root/hyper/target/armv7-linux-androideabi/release/deps/libhttp-a998474d6086d0cc.rlib --extern httparse=/root/hyper/target/armv7-linux-androideabi/release/deps/libhttparse-fe59ea708b984d2c.rlib --extern iovec=/root/hyper/target/armv7-linux-androideabi/release/deps/libiovec-0fbee7688c5d5997.rlib --extern itoa=/root/hyper/target/armv7-linux-androideabi/release/deps/libitoa-6968692ba2ead4d2.rlib --extern log=/root/hyper/target/armv7-linux-androideabi/release/deps/liblog-982ca16cb4a51ba3.rlib --extern net2=/root/hyper/target/armv7-linux-androideabi/release/deps/libnet2-eca709a2543aac40.rlib --extern time=/root/hyper/target/armv7-linux-androideabi/release/deps/libtime-d2ab1c7a701d0c5c.rlib --extern tokio=/root/hyper/target/armv7-linux-androideabi/release/deps/libtokio-f318b1cbbd06c200.rlib --extern tokio_executor=/root/hyper/target/armv7-linux-androideabi/release/deps/libtokio_executor-a34c5d48733eb612.rlib --extern tokio_io=/root/hyper/target/armv7-linux-androideabi/release/deps/libtokio_io-615c1ba46c31b299.rlib --extern tokio_reactor=/root/hyper/target/armv7-linux-androideabi/release/deps/libtokio_reactor-5f33b571b5aa2433.rlib --extern tokio_tcp=/root/hyper/target/armv7-linux-androideabi/release/deps/libtokio_tcp-dcd0b854ed32b20c.rlib --extern tokio_timer=/root/hyper/target/armv7-linux-androideabi/release/deps/libtokio_timer-b8925bce2a2b5c77.rlib --extern want=/root/hyper/target/armv7-linux-androideabi/release/deps/libwant-c71f954f09dd620c.rlib`                                                                         
LLVM ERROR: ran out of registers during register allocation
error: Could not compile `hyper`.
```
Repository: pytorch
Issue: How can I build caffe2_gtest_main under pytorch/caffe2/test/ folder?
Labels: caffe2,triaged

## ❓ Questions and Help
I am trying to build the caffe2_gtest_main in caffe2/test/. So I uncommented add_subdirectory(test) in caffe2/CMakeLists.txt. But it seems that there is no CMakeList.txt in caffe2/test/ folder. I tried to write a CMakeLists.txt. But I am not sure about its dependencies and target_link_libraries. Can anyone help me to enable the gtest build? Thanks. 

### Please note that this issue tracker is not a help form and this issue will be closed.

We have a set of [listed resources available on the website](https://pytorch.org/resources). Our primary means of support is our discussion forum:

- [Discussion Forum](https://discuss.pytorch.org/)
Repository: go
Issue: x/build/cmd/gopherbot: consider any comment accompanied by a reopening to be “more info”
Labels: Builders,NeedsInvestigation

Suggestion by @bcmills, split out from https://github.com/golang/go/issues/24834#issuecomment-381267439, lest it get lost:

> For the WaitingForInfo case, perhaps we should consider any comment accompanied by a reopening to be “more info”: we should only re-close the issue if it was reopened without comment.

cc @dmitshur @FiloSottile
Repository: go
Issue: x/build/cmd/gopherbot: reply when a command is not understood
Labels: Builders

Broken out from some other recent issue (https://github.com/golang/go/issues/27961#issuecomment-427112448), a suggestion from @bradfitz: if @gopherbot doesn't understand a request (e.g. because a human substituted a synonym for one of the magic commands), it should reply and say so.

cc @FiloSottile @dmitshur
Repository: go
Issue: x/build/maintner: reports inconsistent world state (e.g., issue state vs issue events) during short windows of time
Labels: Builders

### Problem

A program that fetches a `maintner` corpus and tries to use its data to make decisions may make a mistake, because the world view is inconsistent during short windows of time. Even though the windows are short, it's guaranteed to happen for any daemon that loops over doing corpus updates and making decisions immediately after.

The most visible high-level example of this is #21312.

### Cause

This happens because there are effectively two GitHub data sources that are not synchronized:

1. changes to GitHub state (e.g., issue N now has labels X, Y, Z)
2. GitHub-generated events (e.g., issue N has had an "unlabeled" event)

To give a concrete example of an inconsistent state that `maintner` can report, consider when an issue has just been unlabeled. The first mutation received and processed by a `corpus.Update` call will be that the issue no longer has that label.

The mutation reporting that there has been an unlabeled _event_ on the same issue may come in a few seconds later. Until it does, it will appear that the issue does not have said label and it has never been unlabeled (e.g., `!gi.HasLabel("Documentation") && !gi.HasEvent("unlabeled")` will be true). Which is not the reality (if one considers the reality to be one where the unlabeled event and its effect to happen simultaneously).

#### Details

These are two distinct mutations received and processed by `corpus.Update` method:

```
received mutation at time t0:
github_issue: <
  owner: "golang"
  repo: "go"
  number: 28103
  updated: <
    seconds: 1539629204
  >
  remove_label: 223401461
>

... (short window during which the issue doesn't have a label,
     but the accompanying "unlabeled" event hasn't been received yet;
     aka an inconsistent world state)

received mutation at time t1:
github_issue: <
  owner: "golang"
  repo: "go"
  number: 28103
  event: <
    id: 1904921842
    event_type: "unlabeled"
    actor_id: 1924134
    created: <
      seconds: 1539629204
    >
    label: <
      name: "Builders"
    >
  >
  event: <
    id: 1904921913
    event_type: "labeled"
    actor_id: 8566911
    created: <
      seconds: 1539629206
    >
    label: <
      name: "Builders"
    >
  >
  event_status: <
    server_date: <
      seconds: 1539629209
    >
  >
>
```

There is more relevant information in https://github.com/golang/go/issues/21312#issuecomment-430051456.

/cc @bradfitz
Repository: godot
Issue: Collision signals don't work on static and rigid RigidBody2D but do work between rigid and kinematic RigidBody2D
Labels: bug,confirmed,topic:physics

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
--> I tried. Sorry if dupe

**Godot version:**
<!-- Specify commit hash if non-official. -->
v3.0.6.stable.official.8314054

**OS/device including version:**
<!-- Specify GPU model and drivers if graphics-related. -->
arch linux (godot package v:aur/godot-bin 3.0.6-1)

**Issue description:**
<!-- What happened, and what was expected. -->
collision reporting doesn't work when a RigidBBody2d mode is static but does when its set to kinematic.
**Steps to reproduce:**
create two rigid bodies and set one to static collision reporting wont work when properly set up

**Minimal reproduction project:**
<!-- Recommended as it greatly speeds up debugging. Drag and drop a zip archive to upload it. -->

[godotBug.zip](https://github.com/godotengine/godot/files/2481047/godotBug.zip)
The 2 folders in the zip are snapshots of my git repo. Full history is retained in both dirs. project is located at godotQWOPProj/project.godot in both dirs and the script where i set up the signals is located at  godotQWOPProj/groundLineStaticBody2D.gd though its attached to a RigidBody2d.
Repository: kubernetes
Issue: CSI: `readOnly` field is not passed to CSI NodePublish RPC call
Labels: kind/bug,priority/important-soon,sig/storage,lifecycle/frozen

<!-- This form is for bug reports and feature requests ONLY!

If you're looking for help check [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) and the [troubleshooting guide](https://kubernetes.io/docs/tasks/debug-application-cluster/troubleshooting/).

If the matter is security related, please disclose it privately via https://kubernetes.io/security/.
-->

**Is this a BUG REPORT or FEATURE REQUEST?**:

> Uncomment only one, leave it on its own line:
>
 /kind bug
> /kind feature


**What happened**:

As per the CSI spec, `readOnly`is passed to ControllerPublishVolumeRequest that should be passed to NodePublish as well..

Ref: https://github.com/container-storage-interface/spec/blob/master/lib/go/csi/v0/csi.pb.go#L1761

For CSI driver that do not support Controller Publish/Unpublish, the `readOnly` flag is missing from the nodePublish RPC request.

**What you expected to happen**:

`readOnly` flag is passed to both, ControllerPublish and NodePublish calls.

**How to reproduce it (as minimally and precisely as possible)**:

CSI driver that doesn't support ControllerPublish call should be able to validate from NodePublish call that the `readOnly` flag is not passed to the driver.

**Anything else we need to know?**:

**Environment**: 
- Kubernetes version (use `kubectl version`): 1.11
- Cloud provider or hardware configuration:
- OS (e.g. from /etc/os-release):
- Kernel (e.g. `uname -a`):
- Install tools:
- Others:
Repository: node
Issue: remote debugger unable to convert path correctly in different operating system
Labels: help wanted,inspector

<!--
Thank you for reporting a possible bug in Node.js.

Please fill in as much of the template below as you can.

Version: output of `node -v`
Platform: output of `uname -a` (UNIX), or version and 32 or 64-bit (Windows)
Subsystem: if known, please specify the affected core module name

If possible, please provide code that demonstrates the problem, keeping it as
simple and free of external dependencies as you can.
-->

* **Version**:v10.9.0
* **Platform**:Linux s97712 4.18.10-arch1-1-ARCH #1 SMP PREEMPT Wed Sep 26 09:48:22 UTC 2018 x86_64 GNU/Linux
* **Subsystem**:remote debugger

<!-- Please provide more details below this comment. -->

I debugger node on window, but my node server on linux. 
When I set the breakpoint through chrome devtools, like the below:
![image](https://user-images.githubusercontent.com/13390001/46996696-32858480-d150-11e8-9bbc-58700f95721e.png)
It doesn't work, nothing happend when reach breakpoint.

I inspect the devtools through `chrome://inspect/#pages`
![image](https://user-images.githubusercontent.com/13390001/46997256-d9b6eb80-d151-11e8-96b5-7f62efb1525e.png)

the devtools check the operating system with `Host.isWin()` , but it check the local operating system, not remote 
![image](https://user-images.githubusercontent.com/13390001/46998172-62cf2200-d154-11e8-9e97-540cb7950cea.png)

![image](https://user-images.githubusercontent.com/13390001/46997677-e12ac480-d152-11e8-94b6-d53498a1fd0a.png)
Repository: godot
Issue: ImmediateGeometry Node does not color the points 
Labels: bug,platform:macos,topic:rendering,topic:3d

**Godot version:**
3.1 master from the last few days


**OS/device including version:**
Intel HD 5000 (macbook air)


**Issue description:**
I'm using ImmediateGeometry to draw a list of points. I believe I can set the colour of the point similar to an opengl call by using IM.set_color inside the IM.begin call.

However, the points render black in the game. I think it could be one of several problems:
1. my misunderstanding the use of set_color
2. I'm using gles2 as it's an older laptop and perhaps it's not supported
3. There's a bug where ambient light does not affect the points
4. There's a bug where no lights affect the points (I added an omnilight to no effect)

I think this is related to #10024 which describes a similar problem on godot 2.

**Steps to reproduce:**
```
var point_size = 5
var im = ImmediateGeometry.new()
add_child(im)
var m = SpatialMaterial.new()
m.flags_use_point_size = true
m.params_point_size = point_size
im.set_material_override(m)
im.clear()
im.begin(Mesh.PRIMITIVE_POINTS, null)
im.set_color(Color(0,1,1))
for p in pts: #list of Vector3s
    im.add_vertex(p)
im.end()
```
Repository: rust
Issue: Documentation of std::mem::size_of confusingly only details the `#[repr(C)]` case
Labels: C-enhancement,P-medium,A-docs,A-repr

The [Size of Structs][1] paragraph bases its explanation of struct sizes on the idea that field are "ordered by declaration order", which is no longer the case since #37429 got merged. This might prompt a user to pointlessly manually order fields to optimize for size.

Instead, the documentation should mention the issue of field alignments, and explain that the compiler will reorder fields to minimize padding. The exact algorithm might be a bit too complex and/or subject to change, so I don't think that it needs to be described completely. It's probably enough to say something like "the compiler reorders fields for optimisation, don't expect a particular order unless using one of the `repr` specifier".

[1]:https://doc.rust-lang.org/core/mem/fn.size_of.html#size-of-structs
Repository: vue-element-admin
Issue: How to install into an  existing vue.js project?
Labels: feature

How to install into an  existing vue.js project?
Repository: rust
Issue: staticlib libgcc_s dependency requirement since 1.21.0 (nightly-2017-08-24)
Labels: A-linkage,T-compiler

Hi Rust team!

Since Rust 1.21.0 and nightly-2017-08-24 a new dependency, `libgcc_s`, is needed for static libraries we're building for `gnu`, `musl` and `freebsd` targets.

This requirement slipped past us during a recent upgrade because the build process did not inform us of this new requirement. (I see this is an option `--print=native-static-libs` in the latest nightly (`nightly-2018-10-10`) and unreleased 1.22.0.)

The change was only visible to us upon linking to an Elixir app as a NIF during a two stage build process where on the second stage this particular library was absent. The error we see is:

```
Error loading shared library libgcc_s.so.1: No such file or directory (needed by /app/lib/elixir_package-0.0.1/priv/elixir_package_extension.so)
```

From what I can tell [this commit](https://github.com/rust-lang/rust/commit/c9645678e86861f670ce8b422c2e565c1a232916) and its parent PR (https://github.com/rust-lang/rust/pull/40113) seem related to this issue. According to the commit and PR the `libgcc_s` link requirement gets added for the musl target/to support dynamically-linked musl targets.

However, we see this requirement listed on the latest nightly for the gnu and freebsd targets as well.

Was this libgcc_s link requirement intended for the gnu and freebsd targets as well? Or was this an unintended change?

## Reproducible example project

To track the issue down I created an example project with a reproducible state. It allows building an example Rust staticlib for musl and link it to Elixir as a NIF. Instructions can be found in the README. I'm adding this to add context and show a scenario to show how this requirement breaks between versions.

https://github.com/tombruijn/rust-elixir-linking-issue-example-project
Repository: go
Issue: x/tools/go/packages: clarify error invariants
Labels: NeedsInvestigation,Tools

```
$ ./gopackages -mode=allsyntax "" "nonesuch"
Go package "_/home/adonovan/got/src/golang.org/x/tools": (has errors)
        has complete exported type info
        -: no Go files in /home/adonovan/got/src/golang.org/x/tools

Go package "nonesuch": (has errors)
        has complete exported type info
        -: cannot find package "nonesuch" in any of:
        /home/adonovan/goroot/src/nonesuch (from $GOROOT)
        /home/adonovan/go/src/nonesuch (from $GOPATH)
```

packages.Load("nonesuch") and Load("") both return a Package, presumably just as a place to hold errors. The package Name field is empty, which is a good clue that the package doesn't exist, and the Errors slice is non-empty. However, the Types field is non-nil and Complete(), which causes the gopackages diagnostic/example tool to report "has complete exported type info" for a package that doesn't exist.

The task of this issue is to clarify which fields can be relied upon in each error scenario and to improve the output and logic of the gopackages tool to reflect this.
Repository: rust
Issue: Arms permitted when matching on uninhabited types
Labels: A-lints,T-compiler,C-bug,A-exhaustiveness-checking

There seem to be two issues here:
```rust
pub enum Void {}

pub fn foo(x: Void) {
  match x {
    _ => {} // This arm shouldn't be permitted.
  };
  let _ = (); // This should be warned as unreachable, but isn't.
}
```
On the other hand, the following code *does* warn:
```rust
match () {
	() => {} // okay
	_ => {} // unreachable pattern
}
```