sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: three.js
Issue: Render to Unwrapped Texture (for baking)
Labels: Enhancement

It is possible to modify the main ThreeJS shaders so that we can enable rendering a final color to an unwrapped texture target.  This involves using the world position for lighting, but the desired UV coordinate when writing the final results.

This should be implemented in a fairly flexible fashion to Three.JS.

(There may be an additional pass required after the main render pass to do extrapolation around each rendered component.)
Repository: three.js
Issue: Adding a Baking Workflow to Three.JS
Labels: Enhancement

This ties into the previous meta task that describes the progressive global illumination workflow.  Basically once you can calculate global illumination, you likely want to bake it into the meshes for reuse.  This would also be useful for ambient occlusion and shadow baking as well.

There are two aspects to a baking workflow.

UV Unwrapping via Mesh Color Textures
https://github.com/mrdoob/three.js/issues/14053

Render to Unwrapped Texture
https://github.com/mrdoob/three.js/issues/14054
Repository: TypeScript
Issue: Generic enumerated type parameter narrowing (conditional types)
Labels: Suggestion,Needs Proposal

## Search Terms
conditional type inference enum enumerated narrowing branching generic parameter type guard

## Suggestion
Improve inference / narrowing for a generic type parameter and a related conditional type. 
I saw another closed-wontfix issue requesting generic parameter type guards, but a type guard should not be necessary for this case, since the possible values for the generic are enumerated. 

## Use Cases
(Names have been changed and simplified)
I have a method that takes a KeyType (enumerated) and a KeyValue with type conditionally based on the enumerated KeyType.  
Depending on the KeyType value, the code calls method(s) specific to that type. 

The TS compiler is unable to tell that after I have checked the enumerated KeyType, the type of the KeyValue (string, number, etc) is known and should be able to be passed to a function that only accepts that specific KeyValue type.

## Examples

```
const enum TypeEnum {
	String = "string",
	Number = "number",
	Tuple = "tuple"
}
// The issue also occurs with
// type TypeEnum = "string" | "number" | "tuple"

interface KeyTuple { key1: string; key2: number; }

type KeyForTypeEnum<T extends TypeEnum> 
	= T extends TypeEnum.String ? string
	: T extends TypeEnum.Number ? number
	: T extends TypeEnum.Tuple ? KeyTuple
	: never;


class DoSomethingWithKeys {	
	doSomethingSwitch<TType extends TypeEnum>(type: TType, key: KeyForTypeEnum<TType>) {
		switch (type) {
			case TypeEnum.String: {
				this.doSomethingWithString(key);
				break;
			}
			case TypeEnum.Number: {
				this.doSomethingWithNumber(key);
				break;
			}
			case TypeEnum.Tuple: {
				this.doSomethingWithTuple(key);
				break;
			}
		}
	}

	doSomethingIf<TType extends TypeEnum>(type: TType, key: KeyForTypeEnum<TType>) {
		if (type === TypeEnum.String) {
			this.doSomethingWithString(key);
		}
		else if (type === TypeEnum.Number) {
			this.doSomethingWithNumber(key);
		}
		else if (type === TypeEnum.Tuple) {
			this.doSomethingWithTuple(key);
		}
	}	

	private doSomethingWithString(key: string) {

	}

	private doSomethingWithNumber(key: number) {

	}

	private doSomethingWithTuple(key: KeyTuple) {

	}
}
```
This should compile without errors if TS was able to tell that the switch statements or equality checks limited the possible type of the other property.  

I lose a lot of the benefits of TS if I have to cast the value to something else. especially if I have to cast `as any as KeyForTypeEnum<TType>` as has happened in my current codebase.

If I'm doing something wrong or if there's already a way to handle this, please let me know. 
## 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. new expression-level syntax)
Repository: rust
Issue: Error messages about modules are confusing to beginners
Labels: C-enhancement,A-diagnostics,T-compiler,D-newcomer-roadblock

When a beginner [0] first tries to use modules, they are likely to do it wrong. The error message printed is misleading because it only mentions `extern crate foo` and never mentions 

## Example

Consider the following project:

src/main.rs:
```rust
use foo::say_hello;

fn main() {
    say_hello();
}
```

src/foo.rs:
```rust
pub fn say_hello() {
    println!("Hello, world!");
}
```

Running `cargo run` results in the following error message:

```
   Compiling confusion v0.1.0 (file:///home/jeremy/tmp/confusion)
error[E0432]: unresolved import `foo`
 --> src/main.rs:1:5
  |
1 | use foo::say_hello;
  |     ^^^ Maybe a missing `extern crate foo;`?

error: aborting due to previous error

For more information about this error, try `rustc --explain E0432`.
error: Could not compile `confusion`.

To learn more, run the command again with --verbose.
```

Naturally, one might try adding `extern crate foo;` to the top of main.rs. This changes the error message to:

```
   Compiling confusion v0.1.0 (file:///home/jeremy/tmp/confusion)
error[E0463]: can't find crate for `foo`
 --> src/main.rs:1:1
  |
1 | extern crate foo;
  | ^^^^^^^^^^^^^^^^^ can't find crate

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.
error: Could not compile `confusion`.

To learn more, run the command again with --verbose.
```

If a user reads the output of `rustc --explain E0432`, they might instead try changing main.rs to start with `use self::foo::say_hello;`, though this does not change the error message.

Another common thing to try is adding `mod foo;` or `pub mod foo;` to the top of `foo.rs`. It is very unlikely that a user will stumble upon an actual solution (such as adding `mod foo;` to the top of `main.rs`).

## Suggestion

The error message should also mention how to refer to local modules, not just external crates.

If there is a file that matches the module name the user is trying to import, it would be especially helpful if the error message discussed how to correctly use that module from `main.rs`.

## Meta

```
$ rustc --version
rustc 1.26.0 (a77568041 2018-05-07)
```
[0] or myself, after having not touched Rust in over a year
Repository: godot
Issue: GIProbe indirect lighting on GridMaps not working
Labels: bug,topic:rendering,confirmed,topic:3d

Godot 3.0.2
Win 7 64 bits GeForce 960

Hi there,

I made a scene with an emissive material and Global Illumination, but lighting only throw  on floor, but walls don't receive any bounces lighting.

https://github.com/DevMagicLord/Godot3/blob/master/bugs/Giprobeissue.jpg

While materials without normal map and roughness map receives all indirect lighting.

https://github.com/DevMagicLord/Godot3/blob/master/bugs/giprobeissue2.jpg

Materials with normal map and roughness, metallic maps, needs to receive lighting bounces.
Repository: three.js
Issue: Texture preservation for mesh simplification(LOD)
Labels: Enhancement

##### Texture preservation for mesh simplifier

Here's a model reduced to 40% of original vertex count with textures preserved. With this you can generate LOD instead of baking it.

This modification of SimplifyModifier adds texturing support and is replacing face UVs on removed vertex to UV coordinates of remaining vertex. More or less works. I can make a PR unless you want to improve this first.

https://codesandbox.io/s/5018onxy1p

Update:

Details:
Added a check if percentage of texture coordinates change is disproportionately higher than vertex shift distance(percentage of distance to diameter of bounding sphere) then no UV change will be applied on face at removed vertex position.

https://codesandbox.io/s/jvy6x7r3my

This seems to improve the end result and strange texture stretching but I don't think it's fixing the root cause of the problem.

##### Three.js version

- [ x] Dev
- [ x] r92

##### Browser

- [x] All of them
- [ ] Chrome
- [ ] Firefox
- [ ] Internet Explorer

##### OS

- [x] All of them
- [ ] Windows
- [ ] macOS
- [ ] Linux
- [ ] Android
- [ ] iOS
Repository: pytorch
Issue: [feature request] Global GPU Flag
Labels: feature,module: cuda,triaged

The [PyTorch 0.4 Migration Guide](https://pytorch.org/2018/04/22/0_4_0-migration-guide.html), simplifies writing device-agnostic code as follows:

```python
# at beginning of the script
device = torch.device("cuda:0" if torch.cuda.is_available() else "cpu")

...

# then whenever you get a new Tensor or Module
# this won't copy if they are already on the desired device
input = data.to(device)
model = MyModule(...).to(device)
```

However, this is still not clean.

Ideally, we would like PyTorch to move everything over to the GPU, if it's available...
much like TensorFlow.

I tried setting the global tensor type to a cuda tensor using the ```torch.set_default_tensor_type()``` method.

However, there are some fundamental problems with setting the default tensor type.

* Dataloaders give normal (non-cuda) tensors by default. They have to be manually cast using the `Tensor.to()` method.

* Many methods are simply not implemented for `torch.cuda.*Tensor`. Thus, setting the global tensor type to cuda fails.

* Conversions to numpy using the `numpy()` method aren’t available for cuda tensors. One has to go `x.cpu().numpy()`.
Although this chain is agnostic, it defeats the purpose.

<hr>

I find that I use methods like `.to(device)` and `.cpu()` far too often in my projects.

In my view, _it makes the code more verbose than it needs to be_ and makes it just a little harder to read.

**I think that there is room for a global `use_gpu` flag that can enable developers to run the entire subsequent code in the GPU, where required.**

Specifically, my request is the following:

#### 1. Abolish need for the `.to(device)` suffix:
Circumvent it by letting the developer set the device using a global method like `torch.set_default_device()` or a convinience method/flag like `use_gpu`

Then, whenever, an error is encountered because a CUDA tensor is expected in place of a regular tensor or vice-versa, automatically cast the tensor to the expected device.

Additionally,
a. Move `nn.Module` automatically to the default device.
b. Move the yield of `DataLoader`s to the default device.

Prevent the need to manually cast to the default device.

#### 2. Add the numpy() method to cuda tensors:
The existing way is to move the tensor to cpu first.
Thus, we have `x.cpu().numpy()`, which is agnostic but redundant.

#### 3. Use GPU by default if available:
PyTorch is built from the ground up with the Deep Learning community in mind.

With most Deep Learning done on GPUs, they be considered as the default device automatically.

_Let PyTorch give first preference to the GPU._
Repository: rust
Issue: Unhelpful error with "overlapping" never applicable impls
Labels: A-trait-system,T-lang,C-bug

These two implementations are overlapping (it's allowed to write `where for<'a> M: B<'a>` even when `M` doesn't implent `B<'a>`) but the error doesn't say this.
```rust
trait A { /* ... */ }
trait B<'a> {}

struct M;

impl A for M where for<'a> M: B<'a> { /* ... */ }
impl A for M where for<'a> M: B<'a> { /* ... */ }

fn main() {}
```

Compiler output:

<details>

```text
   Compiling playground v0.0.1 (file:///playground)
error[E0283]: type annotations required: cannot resolve `M: A`
 --> src/main.rs:8:6
  |
8 | impl A for M where for<'a> M: B<'a> {}
  |      ^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0283`.
error: Could not compile `playground`.

To learn more, run the command again with --verbose.
```

</details>

cc #48214 which will make this issue easier to come across.
Repository: TypeScript
Issue: strictNullChecks false positives in case clause
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:**  2.9.0-dev.20180512

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** 

**Code**

```ts
// @strictNullChecks: true

function test1(param?: {prop: string}) {
  switch (param && param.prop) {
    case 'foo':
      return param.prop; // error: 'param' is possibly undefined
  }
}

function test2(param: {prop?: string}) {
  switch (param && param.prop) {
    case 'foo':
      return param.prop.charAt(0); // error: 'param.prop' is possibly undefined
  }
}
```

**Expected behavior:**

Compiles without error.

**Actual behavior:**

strictNullChecks errors as described in the comments above.

**Playground Link:** https://agentcooper.github.io/typescript-play/?noImplicitReturns=false#code/GYVwdgxgLglg9mABFApgZygRgBQAcCGATvgLYD8AXIgN66Fy5UaExgDmAvgJQ0BQiiNAHcYUCAAtEeIqUQAyOYgLESAOjoMe1fgMQR8aFIgDkwOHGMUduxIRRQQhJMtLr6uANyIA9N8QpCekIqYxcSY0QYNCU4NDQYACMAGwBPRHAAExRgVhQMnQ5eQt5QSFgEZHQoACZpFSpad0pBKBZ2bj4BYVEJKTD5RTC3TU7dfUMTMwsrGwE7ByclGTUNXFUJIgBBKGwABi4vX39AuGCTIdWIqJi4xNT0sCycsDyCoqA

**Related Issues:**
#23818
Repository: rust
Issue: Confusing error message when trying to cast usize to fat pointer
Labels: C-enhancement,A-diagnostics,T-compiler

Trying to cast a `usize` to a fat pointer (in this case `*const T` where `T: ?Sized`) gives a confusing error message (in that it's not immediately obvious that it's invalid because it's a fat pointer):
```
error[E0606]: casting `usize` as `*const T` is invalid
   |
38 |         self.0 as *const T
   |         ^^^^^^^^^^^^^^^^
```

If you try to cast to a thin pointer, then to a fat pointer, it gives a better error:
```
error[E0607]: cannot cast thin pointer `*const core::alloc::Opaque` to fat pointer `*const T`
   |
38 |         self.0 as *const Opaque as *const T
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```

It would be more obvious if doing the former gave a message like `cannot cast usize to fat pointer`, maybe
Repository: flutter
Issue: On Android 5 (API 21) Appbar is shown behind the header on recent apps list
Labels: platform-android,framework,f: material design,a: fidelity,e: OS-version specific,has reproducible steps,P2,found in release: 3.3,found in release: 3.7,team-android,triaged-android

On Android when recent apps list is shown, appbar is still visible under the header.

Can be observed more easily when `AppBar` `backgroundColor` is given explicitly

```dart
return new Scaffold(
      appBar: new AppBar(
        // Here we take the value from the MyHomePage object that was created by
        // the App.build method, and use it to set our appbar title.
        title: new Text(widget.title),
        backgroundColor: Colors.green,
      ),
      body: new Center(
```

![screen shot 2018-05-14 at 01 17 26](https://user-images.githubusercontent.com/5124597/39972284-9ad500b2-5714-11e8-9d00-808aea13b96c.png)
Repository: rust
Issue: #[derive] fails to detect associated type when qualified path is used
Labels: A-macros,A-associated-items,T-compiler,C-bug,T-types

The deriving code scans the field types in order to generate bounds on associated types, if they happen to be used as a field type (this isn't foolproof but it catches a lot of cases).

https://github.com/rust-lang/rust/blob/9fae1537462bb10fd17d07816efc17cfe4786806/src/libsyntax_ext/deriving/generic/mod.rs#L350-L352

The comment in this code implies that `field: T::Assoc` and `field: <T as Trait>::Assoc` would both work. However, the second one is missed and the required bound is not generated, resulting in a type error:

```rust
#[derive(Debug)]
struct Foo<T: FromStr> {
    field: <T as FromStr>::Err
}
```

```
error[E0277]: `<T as std::str::FromStr>::Err` doesn't implement `std::fmt::Debug`
  --> expr.rs:18:77
   |
18 |     field: <T as FromStr>::Err
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^ `<T as std::str::FromStr>::Err` cannot be formatted using `{:?}` because it doesn't implement `std::fmt::Debug`
   |
   = help: the trait `std::fmt::Debug` is not implemented for `<T as std::str::FromStr>::Err`
   = help: consider adding a `where <T as std::str::FromStr>::Err: std::fmt::Debug` bound
   = note: required because of the requirements on the impl of `std::fmt::Debug` for `&<T as std::str::FromStr>::Err`
   = note: required for the cast to the object type `std::fmt::Debug`
```

cc #26925.
Repository: pytorch
Issue: [Caffe2] Build broken on macOS High Sierra: can't find sys headers in /usr/local/include.
Labels: caffe2

Information about what failed when building from HEAD (see error logs.)

/Applications/Xcode.app/Contents/Developer/usr/bin/make -f CMakeFiles/cmTC_8a5ea.dir/build.make CMakeFiles/cmTC_8a5ea.dir/build
Building CXX object CMakeFiles/cmTC_8a5ea.dir/src.cxx.o
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -DCAFFE2_NEED_TO_TURN_OFF_DEPRECATION_WARNING -std=c++11 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -mmacosx-version-min=10.9 -o CMakeFiles/cmTC_8a5ea.dir/src.cxx.o -c /usr/local/anaconda3/conda-bld/caffe2_1526270409265/work/build/CMakeFiles/CMakeTmp/src.cxx
/usr/local/anaconda3/conda-bld/caffe2_1526270409265/work/build/CMakeFiles/CMakeTmp/src.cxx:1:10: fatal error: 'glog/stl_logging.h' file not found
#include <glog/stl_logging.h>
^~~~~~~~~~~~~~~~~~~~
1 error generated.
make[1]: *** [CMakeFiles/cmTC_8a5ea.dir/src.cxx.o] Error 1
make: *** [cmTC_8a5ea/fast] Error 2

Source file was:
#include <glog/stl_logging.h>
int main(int argc, char** argv) {
return 0;
}

I ran "brew install glog" successfully. After install, the file is there:

$ ls /usr/local/include/glog/stl_logging.h
/usr/local/include/glog/stl_logging.h

But the error still persists as you can see from the output above that '/usr/local/include' is not on the system headers path search? Shouldn't this path be added to CMake? Default on latest OS points to the SDK headers and seems to cause this sort of issues when package is installed with homebrew.
Repository: flutter
Issue: Provide a Backdrop Widget
Labels: c: new feature,framework,f: material design,P3,team-design,triaged-design

Please provide a backdrop widget in flutter library
Repository: opencv
Issue: MSER different results in transition from 2.4 to 3 version
Labels: category: imgproc,incomplete,needs reproducer

Due to the facts that default parameters value have not changed in transition from opencv2.4 to 3 we expect to not get different regions with our previous parameters setting but we get absolutely different and wrong regions with those parameters (exactly the same, except the mask which is not an argument for mser anymore) in opencv3 version and finding the reason and new parameter setting wasn't straight forward at all.
As I reviewed logs of changes in these transition, I found that there were some bug fixes so we expect to get better results in version 3 but it was vice versa.
I realized that there are huge modifications in updateTree function as it use the delta parameter in a different way. The question is how should we change the parameters to get exact results as 2.4 function and why the description of delta in opencv docs has no changes?

System information (version)

    OpenCV => 3.1 3.3 2.4
    Operating System / Platform => Ubuntu, Embedded linux
Repository: material-ui
Issue: [Table] Improve mobile display / responsive stacking
Labels: new feature,waiting for 👍,component: table,mobile

# Feature Request

Can you guys make the table responsive to break into pieces with its Heading while right now we have to scroll left/right in mobile devices?

## Expected Behavior
![image](https://user-images.githubusercontent.com/25475456/39991642-ea7b312e-578f-11e8-8aed-a2c380c87a0c.png)

**Example** : 

- https://codepen.io/zavoloklom/pen/yLmZeQ
- https://css-tricks.com/examples/ResponsiveTables/responsive.php
- https://semantic-ui.com/collections/table.html

## Current Behavior
![image](https://user-images.githubusercontent.com/25475456/39991560-b45557a0-578f-11e8-94d6-8ea2d8d5c390.png)
Repository: javascript
Issue: Shown Example Is Not Appropriate for arrays--callback-return
Labels: needs followup,editorial

[4.6 in Readme](https://github.com/airbnb/javascript#arrays--callback-return)
last example is shown as
   ```
    inbox.filter((msg) => {
      const { subject, author } = msg;
      if (subject === 'Mockingbird') {
        return author === 'Harper Lee';
      }
      return false;
    });
```

 but its not a example of `arrays--callback-return`, its illustrate `avoid of else`, when using return statement.
Repository: flutter
Issue: add2app: flutter run --use-application-binary should launch by Intent
Labels: platform-android,tool,engine,a: existing-apps,P2,team-android,triaged-android

In add2app scenarios, a single Android package may have multiple launchable Activities, only one of which should be the default one. Parsing `aapt` output doesn't seem to be able to tell us which one is default, whereas launching by specific intent does the correct thing:
```
shell am start -a android.intent.action.MAIN -c android.intent.category.LAUNCHER <package_name>
```
@devoncarew Would you be concerned about extracting only the package name from `aapt` output instead of also the Activity name as currently done in https://github.com/flutter/flutter/pull/5307?
Repository: godot
Issue: Editor randomly freezes computer
Labels: bug,topic:editor,confirmed

**Godot version:** 3.0.2 Stable
**OS:** Windows 8.1 laptop
_edit: more specs_
**CPU:** Intel Core i3-5005U
**Graphics:** IntelHD 5500

I've been using Godot for around a week or so, but I've been getting a very serious problem: in random instances, my *whole computer* freezes, including the cursor. I have to hard reset it.

It doesn't happen often enough that I can reproduce the issue (it really feels random), but it happens often enough that I already got this three times in the span of a week. If I had to guess what triggers it, i noticed it seems to happen more often during script editing, but I don't intend to try and reproduce this bug, hard-resetting is obviously something I want to avoid.

I'm liking the experience with Godot for now, so I'd love to get that fixed, as I can't use an editor that will bring my PC to a halt. Any ideas?