sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Add alternative to `extends` that performs shallow excess property checking
Labels: Suggestion,Awaiting More Feedback

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker.

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ, especially the "Common Feature Requests" section: https://github.com/Microsoft/TypeScript/wiki/FAQ

-->

## Search Terms

<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

excess property check exact strict extends
## Suggestion

<!-- A summary of what you'd like to see added or changed -->
I'm proposing an `extends!` operator that does excess property checking.


## Use Cases

I specifically would like this for [testing types](https://humeris.org/espresso-shot). It would be helpful for having a check like 
`expectTypeOf<{a: 1, b: 1}>().toBeAssignableTo<{a?: 1}>();`

Also for type-checking props of React components, TypeScript uses excess property checking:
```tsx
<Component propExists propDoesntExist />
                      ^^^^^^^^^^^^^^^
```
so it's not enough to just check `Props extends React.ComponentProps<Component> ? true : false` to determine TypeScript would give a type error in this scenario.


I'm currently approximating this by doing something similar to:
```ts
Props extends React.ComponentProps<Component>
  ? keyof Props extends keyof React.ComponentProps<Component>
    ? true
    : false
  : false;
```

<!--
What do you want to use this for?
What shortcomings exist with current approaches?
-->


## Examples

```ts
// `true`
type Example1 = {a: 1, b: 1} extends {a?: 1} ? true : false;

// `false`
type Example2 = {a: 1, b: 1} extends! {a?: 1} ? true : false;

// `true`
type Example3 = {a: 1} extends! {a?: 1} ? true : false;
```

```ts
// Type 'keyof T' cannot be used to index type 'U'.(2536)
type Example1<T, U> = T extends U ? U[keyof T] : never;
                                      ^^^^^^^
// Okay
type Example2<T, U> = T extends! U ? U[keyof T] : never;
```

<!-- Show how this would be used and what the behavior would be -->

## Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).
Repository: pytorch
Issue: ModuleDict does not preserve order of initializing dictionary
Labels: module: nn,triaged

## 🐛 Bug

<!-- A clear and concise description of what the bug is. -->

## To Reproduce
```
>>> torch.nn.ModuleDict({'b': torch.nn.Linear(10, 10), 'a': torch.nn.Linear(20, 20)})
ModuleDict(
  (a): Linear(in_features=20, out_features=20, bias=True)
  (b): Linear(in_features=10, out_features=10, bias=True)
)
```

<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->

## Expected behavior
```
>>> torch.nn.ModuleDict({'b': torch.nn.Linear(10, 10), 'a': torch.nn.Linear(20, 20)})
ModuleDict(
  (b): Linear(in_features=10, out_features=10, bias=True)
  (a): Linear(in_features=20, out_features=20, bias=True)
)
```
<!-- A clear and concise description of what you expected to happen. -->

## Environment
```
PyTorch version: 1.6.0
Is debug build: False
CUDA used to build PyTorch: 10.2

OS: Microsoft Windows 10 Home
GCC version: Could not collect
Clang version: Could not collect
CMake version: Could not collect

Python version: 3.8 (64-bit runtime)
Is CUDA available: True
CUDA runtime version: Could not collect
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.0\bin\cudnn_ops_train64_8.dll

Versions of relevant libraries:
[pip3] numpy==1.18.3
[pip3] pytorch-lightning==0.9.0rc12
[pip3] torch==1.6.0
[pip3] torchvision==0.7.0
[conda] Could not collect
```

## Additional context
Python dictionary preserve order of dictionary literals, so that order is naturally expected to be respected by `ModuleDict`.
<!-- Add any other context about the problem here. -->


cc @albanD @mruberry
Repository: PowerToys
Issue: Provide an SVG WIC codec to enable the use of SVG in many applications
Labels: Idea-New PowerToy

SVG is a great format but most applications cannot use it directly, forcing people to export their vector graphics to PNG images before using them in most apps.
To improve the use of SVG in Windows, a WIC (Windows Imaging Component) decoder (input codec part only) could be provided. Any application that uses WIC to allow inserting or importing an image would then automatically support SVG files.

Windows 10 already added such WIC codec support for .heif/.heic, .webp and camera raw image files. Similarly, adding SVG would improve the platform and many apps running on Windows.
The codec would support rendering the SVG at any pixel size requested by the consuming application, keeping the vector quality.

I submitted this through the Feedback Hub as well: https://aka.ms/AA9c5e8
But I suspect building it as a PowerToy extension and maybe submitting it later for inclusion in Windows or as a standalone Store codec extension, has much more chances of being done.
Also, since PowerToys already include an SVG renderer for its Explorer icon and preview handlers, I suspect wrapping the same code in a WIC codec would be easier than starting from scratch.

If you'd like to see this feature implemented, add a 👍 reaction to this post.
Repository: terminal
Issue: Pane opening animation should not flash the default pane backdrop
Labels: Help Wanted,Area-UserInterface,Product-Terminal,Issue-Task,Priority-3

##### follow up to #7364

When we open a new pane there's a brief time when you can see the pane background color as the new pane slides in. This is because we _immediately_ create the Row/Col definitions, so even if we animate the first pane getting smaller, the first pane only has half the parent grid to render into. 

A solution we could do is use the background brush from the first child as the background of the parent pane, until the animation is finished. Then revert back to transparent. This will make the backgroud behind the pane sliding in look like it's the same as the first pane. This won't _really_ help for background images, but I think this is a reasonable compromise.
Repository: go
Issue: mailing lists: build a permanent archive at ml.golang.org
Labels: NeedsInvestigation,Community

As of recently, it looks like a Google account is required to access Google Groups.

For example, loading this security release announcement on mobile or in an incognito tab leads to a login page:
https://groups.google.com/g/golang-announce/c/NyPIaucMgXo/m/GdsyQP6QAAAJ

This is plainly unacceptable for announcements, especially for security ones, and needs to be resolved ASAP. It's also a problem for community involvement, because there seems to be no way for users to discover how to sign up for the mailing lists without a Google account. Finally, we regularly share designs for review on the mailing lists, and following those discussions should not require an account.

If this is something we can turn off, we should. Otherwise, we might have to at least run a public mirror like public-inbox.org, with instruction for signing up and posting via email without an account, assuming that still works.

It's sad that moving away from Google Groups would be too much of a mess, or I would recommend considering that.

/cc @golang/osp-team
Repository: material-ui
Issue: [Popper] Leverage ResizeObserver
Labels: new feature,component: Popper

https://codesandbox.io/s/practical-kalam-jz2ew?file=/src/Demo.js

open the popper by clicking on the button

1. When scrolling (fast) it does not remain in position but jiggles around
2. When using "keepMounted" open the popper, close it -> additional white space at bottom of page
3. When the height of the content inside the popper increases (i.e. because of a form interaction) the position of the popper is not updated until scrolling. After scrolling it jumps up to accommodate for the new height.
Repository: godot
Issue: Extended Resource's resource_name not shown over remote scene view
Labels: bug,topic:editor,confirmed

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
3.2 branch commit 9bf5a0b791faf8e960bdb07009b5fe8003206e4f


**OS/device including version:**
Arch Linux


**Issue description:**
And extended `Resource` object like the following:

```
tool
extends Resource
class_name AnAwesomeResource

func _init():
    resource_name = "AnAwesomeResourceName"

func _to_string() -> String:
       return "[" + get_name() + " ID: " + str(get_instance_id()) + "]"
```

Shows correctly in Inspector but not when inspecting nodes through the remote scene view.

**Steps to reproduce:**
1. Open the attached project.
2. On the Scene tab click the only node on the scene.
3. Checkout the exported `looks_good` variable in Inspector -- it shows the resource name `AnAwesomeResourceName` correctly.
4. Press F6 to run the scene.
5. Click on "Remote" under the Scene tab to see the remote scene.
6. Click on the `Node2D` node.
7. Look at Inspector -- the `looks_good` variable still has the correct resource name, however if an array or dictionary contain an instance of `AnAwesomeResource` it won't show in the Inspector. Click on the `cant_see_name` array -- the only object there is an instance of `AnAwesomeResource` and the `_to_string` override is getting ignored. 

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
[RemoteResourceView.zip](https://github.com/godotengine/godot/files/5110423/RemoteResourceView.zip)
Repository: flutter
Issue: [flutter_driver] Remove timeout parameters, which cause flakiness/incorrect tests
Labels: tool,t: flutter driver,a: quality,c: proposal,P3,team-tool,triaged-tool

The timeout parameter for `waitFor` commands only affect the host-side Future. The serialized command sent to client continues to execute on every frame. If the condition is never met, it affects the performance measurements significantly.
Repository: godot
Issue: WorldEnvironment Scene Instances Irresponsive to Property Changes
Labels: bug,topic:core

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
<!-- Specify commit hash if using non-official build. -->
3.2.2 Stable

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
macOS
Intel UHD Graphics 630 1536 MB
GLES2

**Issue description:**
<!-- What happened, and what was expected. -->
It occurs when you save a WorldEnvironment as a scene and then try and change properties in its instance. The WorldEnv ignores any local changes when you run the game. It shows it working in the editor viewport, but NOT at runtime. It only works if you go into the WorldEnv scene and change settings there.

**Steps to reproduce:**
1. Add a WorldEnvironment node to a scene
2. Save that node as a scene
3. Any changes to the instance of the node will no longer be reflected at runtime

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
Repository: pytorch
Issue: Switch C10_EXPORT_CAFFE2_OP_TO_C10 to new operator registration API
Labels: caffe2,module: bootcamp

caffe2/core/export_caffe2_op_to_c10.h is still using the old API. Among other problems, @jackm321 ran into trouble because these were all having aliasing inferred conservatively when actually most of these functions are pure. Let's switch it to the new API.

1Change the macros to use the new operator API (c.f. https://pytorch.org/tutorials/advanced/dispatcher.html). For the most part, you should be able to do this directly in the macro definitions themselves, but for the `C10_EXPORT_CAFFE2_OP_TO_C10_SCHEMA_ONLY` call, you will have to use `TORCH_LIBRARY_FRAGMENT_THIS_API_IS_FOR_PER_OP_REGISTRATION_ONLY` to relax the restriction that all definitions are made in one place.

One fly in the ointment is the use of `TORCH_LIBRARY_FRAGMENT_THIS_API_IS_FOR_PER_OP_REGISTRATION_ONLY`.  When we designed TORCH_LIBRARY, we added the constraint that all operators for a namespace had to be declared in one place. However, the Caffe2 operators are pretty decentralized, and live in both fb/ and non-fb folders. This is making me wonder if we should keep caffe2 as a special namespace which is allowed to be registered anywhere you want (in keeping with Caffe2's historical nature). Otherwise, we will have to go on a renamespacing spree for all fb/ folder caffe2 operators, which seems like a lot of work for not much gain.
Repository: flutter
Issue: Add integration test for platform view gestures on iOS 
Labels: a: tests,platform-ios,engine,a: platform-views,P2,team-ios,triaged-ios

For example, we could add an iOS implementation to the [existing integration test](https://github.com/flutter/flutter/tree/master/dev/integration_tests/hybrid_android_views), or create a new app just for iOS. 

This test verifies that tap gestures are forwarded to a child view.

cc @cyanglaz
Repository: pytorch
Issue: Add support of random state generator objects to nn.init module
Labels: module: nn,triaged,enhancement,module: initialization

## 🚀 Feature
Most of init functions xavier_uniform_/ xavier_normal_ under the hood use torch.uniform_ and torch.normal_ which support generator objects however these init functions don't.

## Motivation
Code reproducibility. If not using global manual_seeds it becomes increasingly tough to keep track without generator objects,


## Pitch

For instance in the current xavier_uniform_ the function under the hood returns a uniform distribution which supports random state generator object but while using xavier_uniform_ it can't be passed as an argument. 



cc @albanD @mruberry
Repository: PowerToys
Issue: Virtual Desktop Continuous Looper
Labels: Idea-New PowerToy,Product-Virtual Desktop

## 📝 Allows user to loop through virtual desktop continuously from either direction 

_What is the expected behavior of the proposed feature?  What is the scenario this would be used?_
While holding down Ctrl+Windows, and tapping on Left or Right key, it allows user to loop through all the available virtual desktops and once it reaches the end, it will automatically start from the beginning.
Currently, assuming you have 4 virtual desktops, if you are under Desktop 1, you have to loop 1, 2, 3, 4, and once you are in Desktop 4, if you want to go back to Desktop 4, you'd have to have loop 4, 3, 2, 1.. 
Ideally, if you are currently under Desktop 4, it would be real useful if you hold down Ctrl+Windows and tap Right key, you automatically go from Desktop 4 to Desktop 1. Similarly, if you are on Desktop 1, you can hold down Ctrl+Windows and tap Left key, and you switch to Desktop 4. 
Other people may propose an even better way where you can jump to a specific virtual desktop with a specific combination of hot key, but I am merely proposing a loop instead.

---

If you'd like to see this feature implemented, add a 👍 reaction to this post.
Repository: godot
Issue: Usage of EditorNode singleton in CanvasItemEditor plugin
Labels: discussion,topic:core,topic:editor

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
<!-- Specify commit hash if using non-official build. -->
8c4f556

**Issue description:**
<!-- What happened, and what was expected. -->
So I noticed that CanvasItemEditorPlugin has a variable `editor` of type EditorNode. This is obviously a reference to the main Editor Node, but there's `EditorNode::get_singleton()` all over the place in that file. Maybe all singleton references should be changed to use the editor variable?
Also this might apply to other editors too.
Repository: pytorch
Issue: Inference performance regression caused by hacky_wrapper_for_legacy_signatures
Labels: module: performance,module: internals,triaged,module: dispatch

Not exactly a bug, more of a status check + data point for prioritization of a known issue.

In internal CI, @xwang233 observed https://github.com/pytorch/pytorch/commit/0494e0ad707b8cc266c81b723f622a76e4b64dc4 caused extensive inference performance regressions (between 5 and 17%, depending on model, batch size, and precision).  Apparently the gymnastics to pack `TensorOptions` in `hacky_wrapper_for_legacy_signatures` and unpack `TensorOptions` into blessed tensor-construction-axis types in the autogenned `at::*` functions incurs substantial CPU overhead (possible pain point:  unpacking in autogenned `at::*` [uses  the notorious `typeMetaToScalarType`](https://github.com/pytorch/pytorch/blob/aa53b2d4279cac379d8ac327501b8bed1d25dac5/aten/src/ATen/function_wrapper.py#L910)).  Does this make sense?

Afaict boxable functions are still registered with `hacky_wrapper_for_legacy_signatures` by default in [current master](https://github.com/pytorch/pytorch/blob/3d76f7065eb97aa81e2147d39dae973cb11bdf94/aten/src/ATen/function_wrapper.py#L112-L115).  I realize this is a temporary state of affairs, but do we have an idea when `hacky_wrapper_for_legacy_signatures` can die?

cc @ezyang @bhosmer @smessmer @ljk53 @VitalyFedyunin @ngimel @ptrblck
Repository: godot
Issue: Default .csproj template: Error CS0012:...You must add a reference to assembly ‘netstandard.
Labels: discussion,documentation,topic:dotnet

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:** 3.2.3-rc4 Mono
<!-- Specify commit hash if using non-official build. -->


**OS/device including version:** Windows 10
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->


**Issue description:**
<!-- What happened, and what was expected.  -->

A fresh mono projects fails to build with `Error CS0012: The type ‘Object’ is defined in an assembly that is not referenced. You must add a reference to assembly ‘netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=...`

By default <project_name>.csproj now contains:
````
<Project Sdk="Godot.NET.Sdk/3.2.3">
  <PropertyGroup>
    <TargetFramework>net472</TargetFramework>
  </PropertyGroup>
</Project>
````
Chaining it to seems to fix the issue for me
```
<Project Sdk="Godot.NET.Sdk/3.2.3">
  <PropertyGroup>
    <TargetFramework>net472</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <Reference Include="netstandard" />
  </ItemGroup>
</Project>

```
**Steps to reproduce:**
- Create new mono project 
- Project -> Tools -> Mono -> Create C# Solution...
- FileSystem -> Right click -> New Script -> Language: C# -> Create
- Build
This results in `new_script.cs(4,27): error CS0012: The type 'Object' is defined in an assembly that is not referenced. You must add a reference to assembly 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=...`

As mentioned before editing .csproj and adding `<Reference Include="netstandard" />` seems to fix it for me.

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
Repository: godot
Issue: Remote scene tree: Unable to see internal Objects of extended Resource unless it's under an array
Labels: bug,topic:editor,confirmed

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
3.2 branch at commit 9bf5a0b791faf8e960bdb07009b5fe8003206e4f


**OS/device including version:**
Arch Linux


**Issue description:**
Internal `Object` of an extended `Resource` is not visible on remote view unless the remote Resource object is inside an array or a dictionary as far as I can tell.


**Steps to reproduce:**
Consider the following class:

```gdscript
tool
extends Resource
class_name AnAwesomeResource

var unseen_resource_in_inspector : Reference

func _init():
    resource_name = "AnAwesomeResourceName"
	unseen_resource_in_inpsector = Reference.new()

func _to_string() -> String:
       return "[" + get_name() + " ID: " + str(get_instance_id()) + "]"
```

1. Open the attached project.
2. On the Scene tab click the only node on the scene.
3. Checkout the exported `looks_good` variable in Inspector -- it's of type `AnAwesomeResource` and we can't see the `unseen_resource_in_inspector` through Inspector variable which is fine.
4. Press F6 to run the scene.
5. Click on "Remote" under the Scene tab to see the remote scene.
6. Click on the Node2D node.
7. Look at Inspector -- the `looks_good` variable still has the correct resource name, however its internal member variables can't be seen on the Inspector.
8. Click on `can_see_internal_member` array, and double click the only `Object` it contains --- the `unseen_resource_in_inspector` can now be seen because `AnAwesomeResource` lives inside an `Array`.

**Minimal reproduction project:**
[RemoteResourceView.zip](https://github.com/godotengine/godot/files/5111892/RemoteResourceView.zip)


**Additional Notes**
Related: 
#41427
 #40758
Repository: PowerToys
Issue: [FancyZones] Allow Alt-Tab to drag into zone.
Labels: Idea-Enhancement,Product-FancyZones

## 📝 Provide a description of the new feature

Add an alternative Alt Tab.  Have it work like Ctrl-Alt-Tab (but just using Alt-Tab), and allow the mouse to drag an app from it to a zone

---

If you'd like to see this feature implemented, add a 👍 reaction to this post.
Repository: pytorch
Issue: Training Large Neural Networks with Constant Memory using a New Execution Algorithm
Labels: module: nn,module: memory usage,triaged,needs research

## 🚀 Feature
Training Large Neural Networks with Constant Memory using a New Execution Algorithm
https://arxiv.org/abs/2002.05645
Request to implement this in pytorch training.  
L2L is also able to fit models up to 50 Billion parameters on a machine with a single 16GB V100 and 512GB CPU memory and without requiring any model partitioning. L2L scales to arbitrary depth allowing researchers to develop on affordable devices which is a big step toward democratizing AI.

## Motivation
Many researchers are currently not able to experiment on bigger AI model.  This will strongly impact pytorch adoption in the research and DS community. 

## Pitch
Implement such layer to layer training algorithm alternative in pytorch.

## Alternatives

<!-- A clear and concise description of any alternative solutions or features you've considered, if any. -->

## Additional context

<!-- Add any other context or screenshots about the feature request here. -->


cc @albanD @mruberry