sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: three.js
Issue: FBXLoader: Load clips at t=0
Labels: Suggestion,Loaders

##### Description of the problem

I'd like the ability to choose whether or not to import FBX clips so that their start times are offset to begin at t=0. Sometimes several clips on a track aren't meant to be played one after the other. For example jump animations: If you have a hang time clip that is meant to loop in between a jump start and jump landing clips that hang time loop won't loop properly with the current setup and the jump landing animation will also be incorrect.

To visualize what I'm running into a bit better, if I have clips in a structure such as this:

![image](https://user-images.githubusercontent.com/10410125/45318904-4bc16280-b50c-11e8-8e8a-3da9f50583d7.png)

The 2nd clip begins playback at frame 1, but the clip's keyframes don't start until frame 31-- Resulting in 30 frames of pause every loop for the 2nd clip. 

I'm not suggesting that all FBXs should be imported this way, but it would be beneficial as an option when dealing with complex looping animations on a single track.

More discussion:
https://github.com/mrdoob/three.js/pull/13430#issuecomment-415985616

Example:

https://github.com/mrdoob/three.js/files/2322275/fbx-anim-tests.zip

##### Three.js version

- [ ] Dev
- [ ] r96
- [ ] ...

##### Browser

- [x] All of them
- [ ] Chrome
- [ ] Firefox
- [ ] Internet Explorer

##### OS

- [x] All of them
- [ ] Windows
- [ ] macOS
- [ ] Linux
- [ ] Android
- [ ] iOS

##### Hardware Requirements (graphics card, VR Device, ...)
Repository: TypeScript
Issue: No error for duplicate function in JavaScript
Labels: Bug,checkJs,Domain: JavaScript

**TypeScript Version:**  3.1.0-dev.20180907

**Code**

```js
function f() {}
function f() {}
```

**Expected behavior:**

`Duplicate function implementation.` error, exactly like in a `.ts` file.

**Actual behavior:**

No error.
Repository: TypeScript
Issue: Problem with inference for this['prop'] with conditional types
Labels: Bug,Domain: Conditional Types

**TypeScript Version:**  typescript@3.1.0-dev.20180907
**Search Terms:** this type, conditional type

**Code**

```ts
type Wrapped<T> = { ___secret: T };
type Unwrap<T> = T extends Wrapped<infer U> ? U : T;

declare function set<T, K extends keyof T>(obj: T, key: K, value: Unwrap<T[K]>);

class Foo {
    prop: Wrapped<string>;

    method() {
        set(this, 'prop', 'hi'); // <-- type error
    }
}

set(new Foo(), 'prop', 'hi'); // <-- typechecks
```

**Expected behavior:**
Both calls to `set` (the one in the method with `this` and the external one with `new Foo()`) pass typechecking.

**Actual behavior:**
The external call passes, but the one inside `method` fails with `Argument of type '"hi"' is not assignable to parameter of type 'Unwrap<this["prop"]>'.`.

If I explicitly annotate `this: Foo` in the method signature or set the type parameters `set<Foo, 'prop'>(...)`, everything passes.

We've run into this in the Ember type declarations, and have had to [weaken the types for the time being](https://github.com/typed-ember/ember-cli-typescript/issues/286#) to work around it.

**Playground Link:** [available here](https://www.typescriptlang.org/play/#src=type%20Wrapped%3CT%3E%20%3D%20%7B%20___secret%3A%20T%20%7D%3B%0D%0Atype%20Unwrap%3CT%3E%20%3D%20T%20extends%20Wrapped%3Cinfer%20U%3E%20%3F%20U%20%3A%20T%3B%0D%0A%0D%0Adeclare%20function%20set%3CT%2C%20K%20extends%20keyof%20T%3E(obj%3A%20T%2C%20key%3A%20K%2C%20value%3A%20Unwrap%3CT%5BK%5D%3E)%3B%0D%0A%0D%0Aclass%20Foo%20%7B%0D%0A%20%20%20%20prop%3A%20Wrapped%3Cstring%3E%3B%0D%0A%0D%0A%20%20%20%20method()%20%7B%0D%0A%20%20%20%20%20%20%20%20set(this%2C%20'prop'%2C%20'hi')%3B%0D%0A%20%20%20%20%7D%0D%0A%7D%0D%0A%0D%0Aset(new%20Foo()%2C%20'prop'%2C%20'hi')%3B)

**Related Issues:** I wasn't able to find anything that seemed related to this issue.
Repository: puppeteer
Issue: Giving permissions to all origins in browser context
Labels: feature,upstream,chromium

pptr v1.8.0 allows to set permissions per origin in browser context.

However, it'll come very handy to give permissions to all origins in browser context.

Proposal: special '*' value for origin.
```js
context.overridePermissions('*', ['geolocation']);
```
Repository: pytorch
Issue: Tests with "." in the name cannot be run standalone
Labels: module: tests,triaged

## Issue description

Tests with periods in their name can't be run standalone using `python <test_py_file> <test_module>.<test_name>`.

## Code example

 One example is: `TestNN.test_Normalize_1.5_cuda`. Running it as `python test_legacy_nn.py TestNN.test_Normalize_1.5_cuda` gives the stack trace:
```
/home/rocm-user/pytorch__ROCM__master__5/torch/backends/cudnn/__init__.py:89: UserWarning: PyTorch was compiled without cuDNN support. To use cuDNN, rebuild PyTorch making sure the library is visible to the build system.
  "PyTorch was compiled without cuDNN support. To use cuDNN, rebuild "
Traceback (most recent call last):
  File "test_legacy_nn.py", line 1376, in <module>
    run_tests()
  File "/home/rocm-user/pytorch__ROCM__master__5/test/common.py", line 53, in run_tests
    unittest.main(argv=argv)
  File "/usr/lib/python2.7/unittest/main.py", line 94, in __init__
    self.parseArgs(argv)
  File "/usr/lib/python2.7/unittest/main.py", line 149, in parseArgs
    self.createTests()
  File "/usr/lib/python2.7/unittest/main.py", line 158, in createTests
    self.module)
  File "/usr/lib/python2.7/unittest/loader.py", line 130, in loadTestsFromNames
    suites = [self.loadTestsFromName(name, module) for name in names]
  File "/usr/lib/python2.7/unittest/loader.py", line 100, in loadTestsFromName
    parent, obj = obj, getattr(obj, part)
AttributeError: 'function' object has no attribute '5_cuda'
```

## System Info

PyTorch version: 0.5.0a0+9853dbc (built fork https://github.com/ROCmSoftwarePlatform/pytorch)
Is debug build: Yes
CUDA (ROCm) used to build PyTorch: ROCm 1.8.2

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: 2.7
Is CUDA available: Yes
CUDA runtime version: N/A
GPU models and configuration: Vega 64 (gfx900) 2-gpu setup
Nvidia driver version: N/A
cuDNN version: N/A

Versions of relevant libraries:
[pip] 8.1.1
[conda] Not installed



cc @mruberry @VitalyFedyunin @walterddr
Repository: TypeScript
Issue: Conditional types don't work with Mapped types when you extend enum keys
Labels: Needs Investigation

<!-- 🚨 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.0.3, 3.1.0-dev.20180907

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**
mapped, conditional, enum, extends
**Code**

```ts
enum Commands {
  one = "one",
  two = "two",
  three = "three"
}

const SpecialCommandsObj = {
  [Commands.one]: Commands.one,
  [Commands.two]: Commands.two,
};

// a and b are correct
type a = Commands.one extends keyof typeof SpecialCommandsObj ? null : any; // null - ok
type b = Commands.three extends keyof typeof SpecialCommandsObj ? null : any; // any - ok

interface CommandAction {
  execute(element: any): any;
}

interface SpecialCommandAction {
  execute(element: null): any;
}

type CommandsActions = {
    [Key in keyof typeof Commands]:  Key extends keyof typeof SpecialCommandsObj ? SpecialCommandAction : CommandAction
};

const Actions: CommandsActions = {
  [Commands.one]: {
      // ERROR
    execute: (element) => {} // ELEMENT IS ANY, NOT NULL
  },
  [Commands.two]: {
      // ERROR
    execute: (element) => {} // ELEMENT IS ANY, NOT NULL
  },
  [Commands.three]: {
    execute: (element) => {}
  },
}

```

**Expected behavior:**
In the Actions object the argument of the execute method for Commands.one and Commands.two should be of type `null`, not `any`
**Actual behavior:**
`element` is always `any`,

type inference for type `a` and `b` are fine so it only occurs when you use mapped types

it works if you don't use enums as keys in SpecialCommandObj. Swap your SpecialCommandsObj with this one and it will start working

```
const SpecialCommandsObj = {
  "one": Commands.one,
  "two": Commands.two,
};
```
**Playground Link:** https://bit.ly/2QmdTIo
Repository: flutter
Issue: Allow plugins to depend on podspecs outside of CocoaPods specs repo
Labels: platform-ios,tool,d: stackoverflow,P3,a: plugins,team-ios,triaged-ios

I want to make a plugin that depends on the source which is outside of Specs
like this in **myplugin.podspec**: 

    s.dependency 'Hoge',  :git => 'https://github.com/hoge/fuga_specs.git'

However it looks it is not possible to do that in podspec. 
Reference:
https://stackoverflow.com/questions/22447062/how-do-i-create-a-cocoapods-podspec-that-has-a-dependency-that-exists-outside-of

Is there a way to solve the problem? 
Thank you in advance. 


<!-- Thank you for using Flutter!

     Please check out our documentation first:
      * https://flutter.io/
      * https://docs.flutter.io/

     If you can't find the answer there, please consider asking a question on
     the Stack Overflow Web site:
      * https://stackoverflow.com/questions/tagged/flutter?sort=frequent

     Please don't file a GitHub issue for support requests. GitHub issues are
     for tracking defects in the product. If you file a bug asking for help, we
     will consider this a request for a documentation update.

-->
Repository: TypeScript
Issue: Check property declarations in JS
Labels: Bug

Recently I found it's helpful to add JSDOC style comment to hint my IDE the variable's type.

For example, If I add comment to a variable:
```js
function fx(jsonAsset) {
   /** @type {import("a-dts-file-describes-the-type-of-the-json-object").Type} */
    const typedObject = jsonAsset.json;

    // IDE will give the member list of the type
    typedObject.
}
```
My IDE(Visual Studio Code Lastest) would correctly identify the type of ```typedObject```.
So that it give me a very nice intelligent prompt. Even when I  enable the type check through ```// @ts-check```, it will give the type errors.

This feature is helpful to me and my project. It's written in **Javascript**(although we will try to rewrite it using Typescript in future but not for now).

We are using Babel with a plugin called ```transform-class-properties```  means that we can declare class member in ES6 class just like Typescript does:
```js
class C {
    /* @types {HTMLCanvasElement} */
    @decorator(/* ... */)
    canvas = null;
}
```

But when I add similar comment to ```canvas``` declaration, it can not be recognized by IDE. The IDE seems like only decides the type through its initializer. Could you support this feature please?
Repository: pytorch
Issue: [feature request] - Allow sequences lengths to be 0 in PackSequence
Labels: module: nn,module: rnn,triaged,enhancement

Hi, 

### Context
I'm currently working on some NLP stuff which includes working on character-level encoding through RNNs. For this, I'm using pack_padded_sequence/pad_packed_sequence which does the job for word-level encoding, but starts to be a little bit more annoying for the chars. 

**_I'm using batch_first=True axis, but the same can be easily applied to batch_first=False_**

The character tensor's shape is [B, W, C, *], where B is the batch axis, W is the word axis and C is the character axis for each word  (In our case we flatten the first two axis B and W as each word is independent from each other, resulting in a forwarded tensor's shape: [B x W, C, *]).

Then, as W already contains some padded indexes, some C entries are then padded entries, thus having length = 0 which throw the following error when trying to use pack_padded_sequence : 

`ValueError: Length of all samples has to be greater than 0, but found an element in 'lengths' that is <= 0`

It seems that this behaviour comes from the following: https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/native/PackedSequence.cpp#L22

### Proposition

It would be interesting to relax the constraint on the sequence length to be >= 0 in PackSequence, and handling the "0-case" directly as it is currently done to generate each batch that will go to the RNN.

Thanks,
Morgan

cc @albanD @mruberry @jbschlosser @zou3519
Repository: go
Issue: cmd/go: add modvendor sub-command
Labels: NeedsDecision,modules

Creating this issue as a follow up to https://github.com/golang/go/issues/26366 (and others).

`go mod vendor` is documented as follows:

```
Vendor resets the main module's vendor directory to include all packages
needed to build and test all the main module's packages.
It does not include test code for vendored packages.
```

Much of the surprise in https://github.com/golang/go/issues/26366 comes about because people are expecting "other" files to also be included in `vendor`.

An alternative to the Go 1.5 `vendor` is to instead "vendor" the module download cache. A proof of concept of this approach is presented here:

https://github.com/myitcv/go-modules-by-example/blob/master/012_modvendor/README.md

Hence I propose `go mod modvendor`, which would be documented as follows:

```
Modvendor resets the main module's modvendor directory to include a 
copy of the module download cache required for the main module and its 
transitive dependencies.
```

Name and the documentation clearly not final.

### Benefits (WIP)

* Eliminates any potential confusion around what is in/not in `vendor`
* Easier to contribute patches/fixes to upstream module authors (via something like [`gohack`](https://github.com/rogpeppe/gohack)), because the entire module is available
* The modules included in `modvendor` are an _exact_ copy of the original modules. This makes it easier to check their fidelity at any point in time, with either the source or some other reference (e.g. Athens)
* Makes clear the source of modules, via the use of `GOPROXY=/path/to/modvendor`. No potential for confusion like "will the `modvendor` of my dependencies be used?"
* A single deliverable 
* Fully reproducible and high fidelity builds (modules in general gives us this, so just re-emphasising the point)
* ...

### Costs (WIP)

* The above steps are currently manual; tooling (the go tool?) can fix this
* Reviewing "vendored" dependencies is now more involved without further tooling. For example it's no longer possible to simply browse the source of a dependency via a GitHub PR when it is added. Again, tooling could help here. As could some central source of truth for trusted, reviewed modules (Athens? cc @bketelsen @arschles)
* ...

### Related discussion

Somewhat related to discussion in https://github.com/golang/go/issues/27227 (cc @rasky) where it is suggested the existence of `vendor` should imply the `-mod=vendor` flag. The same argument could be applied here, namely the existence of `modvendor` implying the setting of `GOPROXY=/path/to/modvendor`. This presupposes, however, that the idea of `modvendor` makes sense in the first place.

### Background discussion: 

https://twitter.com/_myitcv/status/1038885458950934528

cc @StabbyCutyou @fatih

cc @bcmills
Repository: rust
Issue: (Identical) function call with Generic arguments breaks compilation when called from within another function that has unrelated Generic arguments
Labels: C-enhancement,A-diagnostics,T-compiler

I searched and couldn't find a similar issue for now.

The following code shows an example of a function ```interpolate_linear``` that when called with identical (literal) arguments, causes a complier error in the function ```percentile``` (line 16), but no error in the function ```call_interpolate_linear``` (line 21). I haven't yet had time to try and narrow the issue yet, but nevertheless I think the code is valid. 

```
use std::convert::From;
use std::fmt::Debug;

pub fn percentile<T: Debug + Copy>(
    data_set: &Vec<T>,
    n: f64,
) -> f64
where
    f64: From<T>,
{
    let rank = n * (data_set.len() as f64 - 1f64);
    let below = rank.floor() as usize;
    let mut above = rank.floor() as usize + 1;
    if above == data_set.len() {
        above = data_set.len() - 1;
    }
    let lower_value = data_set[below];
    let higher_value = data_set[above];
    interpolate_linear(&1.0, &2.0, 0.5); // this line does not compile
    interpolate_linear(&lower_value, &higher_value, n)
}

pub fn call_interpolate_linear() {
    interpolate_linear(&1.0, &2.0, 0.5); // this line does compile
}

pub fn interpolate_linear<T: Copy>(
    a: &T,
    b: &T,
    how_far_from_a_to_b: f64,
) -> f64
where
    f64: From<T>,
{
    let a = f64::from(*a);
    let b = f64::from(*b);
    a + (how_far_from_a_to_b * (b - a))
}
fn main() {}
```

Here is the compiler error:

```
error[E0308]: mismatched types
  --> functions_issue.rs:16:24
   |
16 |     interpolate_linear(&1.0, &2.0, 0.5); // this line does not compile
   |                        ^^^^ expected type parameter, found floating-point variable
   |
   = note: expected type `&T`
              found type `&{float}`

error[E0308]: mismatched types
  --> functions_issue.rs:16:30
   |
16 |     interpolate_linear(&1.0, &2.0, 0.5); // this line does not compile
   |                              ^^^^ expected type parameter, found floating-point variable
   |
   = note: expected type `&T`
              found type `&{float}`

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0308`.
```
Repository: rust
Issue: NLL: document specs for (new) semantics in rust ref (incl. deviations from RFC)
Labels: A-lifetimes,P-medium,A-borrow-checker,T-compiler,A-NLL,NLL-reference

The [NLL RFC][] provided a specification for what we planned to implement. (Or at least it tried to do so.)

[NLL RFC]: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md

Since then, the NLL implementation made something that deviated in various ways from that specification.

This ticket is just noting that:
 1.  we did deviate in various ways, and
 2.  we should plan to document the actual semantics, in a manner suitable for the rust reference.

It would be good to link to here any PRs/issues where such deviations were implemented or discussed
Repository: electron
Issue: AppContainer Process Isolation on Windows 10
Labels: enhancement :sparkles:,platform/windows

Using tools like [`electron-windows-store`](https://github.com/felixrieseberg/electron-windows-store), Electron can be packaged as an `appx` app and run in the same environment as Windows Store apps, commonly known as UWP apps. They're still `exe` binaries, they're just running as part of a package and with a package identity attached.

While those applications are running within a scoped amount of virtualization (namely, filesystem and registry redirection), they're not actually running in a process isolation sandbox like their proper UWP siblings. Their capability is therefore `<rescap:Capability Name="runFullTrust"/>`.

With RS5 (October 2018 Update), Windows 10 introduces "partial trust" that'll allow applications running in the desktop bridge to make use of the same app container process isolation security proper UWP applications.

### Getting Electron ready for AppContainer
- [ ] **Get final appxmanifest.xml for partial trust applications from Microsoft**
- [ ] **Create a simple test harness to create and test partial trust Electron apps**
- [ ] **Verify which APIs need UWP additions to function within sandbox**
- [ ] **Extend non-functional APIs with UWP APIs**
We know, as an example, that `shell.*` APIs do not work. We'll need to augment those APIs to use UWP counterparts when [`isRunningInDesktopBridge()`](https://github.com/electron/electron/blob/163e2d35272a1269394add1b941ad961ad801c31/brightray/common/application_info_win.cc#L67-L107) returns `true`. We need to audit every single API and make sure that they either work fine or are documented as non-functional.
Repository: pytorch
Issue: at::Device makes it very easy to write buggy code
Labels: triaged,better-engineering

Imagine this method:
```cpp
Tensor Tensor::cuda(Device dev = at::Device(at::DeviceKind::CUDA)) {
  if (this->device() == dev) {
    return *this;
  }
  return ...; // do the transfer
}
```

Can you see the error? I didn't.

<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>

The problem lies in `operator==` of `at::Device`, which enforces strict equality of device kinds and indices. This would be fine if indices were always guaranteed to be valid, but they are in fact optional. On the other hand, the device objects returned from `this->device()` are always guaranteed to have a device set, and so they will always compare as not-equal to the default argument, *always forcing the tensor copy*.

It would be great if we could resolve this in some way. I have three proposals:

#### Create another device type

We want to allow people to specify a device type for their scripts, which often involves specifying the kind only and ignoring the index. This is what `at::Device` aims to do. On the other hand, internal library functions are almost always functional, and use the device to decide what to do *right now*. Those use cases pretty much always require us to have a device index bound to that object.

This proposal would be to add `at::FullDevice` (better name ideas welcome), which acts similarly to `at::Device`, but is guaranteed to have a device index set. We would need implicit conversions going in both ways because:
- `at::Device -> at::FullDevice` would be needed when users are calling into library functions (they would take `FullDevice` as arguments now). This conversion would be a no-op if the index is specified, and would retrieve the currently selected CUDA device otherwise.
- `at::FullDevice -> at::Device` this is a trivial conversion. `Tensor::device()` should now return `at::FullDevice`, but user code will always work with `at::Device`, which is why we need the conversion.

#### Do nothing. Add a warning maybe.

Plus a method like `ensure_has_index()`, which would set the index to currently selected device of this kind if it's missing.

#### Change `operator==` of `at::Device` to depend on `thread_local` state

This means that if we have a CUDA device with no index set, inside `operator==` we will assume that it has an index equal to the currently selected device. I don't like this one all that much, because it makes a supposedly simple operation quite complicated, and might break `operator==` invariants when someone e.g. uses a set of devices, and changes the thread local state during its lifetime.

---

cc @goldsborough