sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: Support streaming/partial image decoding
Labels: c: new feature,framework,engine,a: images,P3,team-engine,triaged-engine

A number of Skia codecs already support decoding from streams (single frame example: PNG; multiframe example: webp). With support in the engine, it also wouldn't be terribly difficult to support this in the [in-progress](https://github.com/flutter/engine/compare/master...bdero:bdero/apng-decoder) [APNG decoder](https://github.com/flutter/flutter/issues/37247).

A few thoughts about what's required for this:
1. `ImageDescriptor` returns basic header information to the framework synchronously at init time (width, height, blending mode, etc), and so it blocks the main thread while waiting for all of the decoders to resolve the initial dimensions. This must be made async, otherwise apps may freeze waiting for streams (e.g. network streams) to trickle.
1. `SingleFrameCodec`/`MultiFrameCodec` needs to recognize partial frame results from the ImageGenerator facade and expose status/progress info to the framework on request.
1. Decoding would become a polling operation which must occur repeatedly off the main thread rather than a one-shot task operation. Timeout management is necessary for this. On the engine-side, we may want to centrally keep track of images which are currently decoding and automatically adjust frequency/number of images decoded per-task for QoS purposes. This would allow us to handle sudden high volumes of streaming images without causing experience degradation via undue latency to other tasks.
1. Currently, `SingleFrameCodec`/`MultiFrameCodec` ultimately fetches a **host buffer** from the `ImageGenerator` and then blits it to a texture. This means that, without some kind of blit mask/diff extent, the entire frame's data will need to be synchronized host->device for each partial decode (which should otherwise be possible to do at a rapid rate, e.g. >20fps with low task congestion). It would be much simpler to refactor the `ImageGenerator` facade to just support supplying shared buffers (i.e. `SkImage`) directly and allow the `ImageGenerator` control over how the frame's buffer is updated/synchronized. We're already in the realm of operating with shared buffers within `ImageGenerator`s anyways -- for example, we can [avoid host copies in `AndroidImageGenerator`](https://github.com/flutter/engine/blob/223d8f906b7bfd745111030c0eac752ad8c4d08b/shell/platform/android/android_image_generator.cc#L69-L75) by using them.
Repository: rust
Issue: Tracking issue for `try_array_from_fn`
Labels: T-libs-api,C-tracking-issue,A-array

Provides the common use-case of creating custom fallible arrays in a reliable and unified way. Particularly useful for elements that don't implement Copy, Clone or Default.

### Public API

```rust
// Unstable
fn try_from_fn<E, F, T, const N: usize>(cb: F) -> Result<[T; N], E>
where
    F: FnMut(usize) -> Result<T, E>;
```

### Steps / History

- [x] Implementation (https://github.com/rust-lang/rust/pull/75644)
- [ ] Final comment period
- [ ] Stabilization PR

### Unresolved Questions

* ~~Should the callback return indices (https://github.com/rust-lang/rust/pull/75644#discussion_r689066495) ?~~

* ~~`from_fn` and `try_from_fn` are very similar to `repeat_with` and `try_repeat_with` (#91613), just that they take unary instead of nullary functions. Anyone considering stabilizing these should think about those, and vice versa.~~
Repository: pytorch
Issue: torch.mul is not consistent with torch.multiply
Labels: module: numerical-stability,triaged,module: numpy

## 🐛 Bug

Hi，recently i read the torch docs and found torch.multiply is an alias of torch.mul, but I found some case: 

```python
import torch

x = torch.ones((3, 3), dtype=torch.float32, requires_grad=True)
out = torch.mul(2, x) # is Ok!
out = torch.multiply(2, x) # raise Error!
```
and the error is: 
```python
TypeError: multiply() received an invalid combination of arguments - got (int, Tensor), but expected one of:
 * (Tensor input, Tensor other, *, Tensor out)
 * (Tensor input, Number other)
      didn't match because some of the arguments have invalid types: (!int!, !Tensor!)

```

## Expected behavior

It should be consistent with torch.mul that torch.multiply support the first arg is Scalar and the second arg is Tensor. 

## Environment


 - PyTorch Version (e.g., 1.0): 1.9.1
 - OS (e.g., Linux): maxos
 - How you installed PyTorch (`conda`, `pip`, source): pip 
 - Python version: 3.9



cc @mruberry @rgommers
Repository: TypeScript
Issue: Inverted `Promise` should warn like it does without inverting
Labels: Suggestion,Help Wanted,Experience Enhancement,Fix Available

# Suggestion

## 🔍 Search Terms

> This condition will always return true since this 'Promise<string | undefined>' is always defined.(2801) Did you forget to use 'await'?

## ✅ Viability Checklist

<!--
   Suggestions that don't meet all these criteria are very, very unlikely to be accepted.
   We always recommend reviewing the TypeScript design goals before investing time writing
   a proposal for ideas outside the scope of the project.
-->
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, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).


## ⭐ Suggestion

When checking the inverted truthyness if something returned from an `async` function without calling `await`, it should warn you you forgot `await`. This works without inverting.

## 📃 Motivating Example

```ts
async function foo(): Promise<string | undefined> {
    return
}

const value = foo()
if (!value) { // <-- fails silently
    // ...
}

const awaitedValue = await foo()
if (awaitedValue) { // <-- Emits ts2801
    // ...
}
```

[Playground](https://www.typescriptlang.org/play?#code/IYZwngdgxgBAZgV2gFwJYHsL3egFASgC4YAFAJ3QFtUQBTAHhGTNQgHMYAfGJAE1ritavAHwwA3gCgYMmGVrIEZCJIC+kyVExMYAN2AAbBLRgBebHnyTUcGLgCE+o7XwTpsgPQeYAOj9rJIA)

## 💻 Use Cases

In my use, I had a function that returned a `User | undefined` and I was doing something if there wasn't a user returned. Later, I made the function async and forgot to update this since it was failing silently.
Repository: create-react-app
Issue: All TypeScript errors ignored throughout project if any .js file contains uniquely TypeScript syntax.
Labels: stale,needs triage,issue: bug report

### Describe the bug

If a file using uniquely TypeScript syntax (ex: `type bar = null;`) is named with a `.js` extension and then imported into your project you will no longer receive any TypeScript compiler errors. See **Steps to Reproduce & Demo** below for an example.

*Note: the bug may be narrower than described. But I did take some time to do a few experiments to try and narrow the scope of the bug further but couldn't. So this is my best understanding of the bug right now.*

### Did you try recovering your dependencies?

Yes (npm version 7.21.1). Further ensured it wasn't a setup problem by reproducing the bug with a fresh CRA project (created using the official typescript template).

### Which terms did you search for in User Guide?

Typescript. No relevant entries found.

### Environment

```
current version of create-react-app: 4.0.3
running from /Users/johnsullivan/.npm/_npx/c67e74de0542c87c/node_modules/create-react-app

System:
  OS: macOS 11.5.2
  CPU: (8) x64 Intel(R) Core(TM) i7-4960HQ CPU @ 2.60GHz
Binaries:
  Node: 16.9.1 - ~/.nvm/versions/node/v16.9.1/bin/node
  Yarn: Not Found
  npm: 7.21.1 - ~/.nvm/versions/node/v16.9.1/bin/npm
Browsers:
  Chrome: Not Found
  Edge: Not Found
  Firefox: Not Found
  Safari: Not Found
npmPackages:
  react: ^17.0.2 => 17.0.2 
  react-dom: ^17.0.2 => 17.0.2 
  react-scripts: 4.0.3 => 4.0.3 
npmGlobalPackages:
  create-react-app: Not Found
```

(This was run within the fresh CRA project I made to reproduce the issue)

### Steps to reproduce & Demo

I created a repository that was initialized with the official typescript template and made an initial commit. I then made a single commit that was sufficient to reproduce the bug: [commit](https://github.com/itsjohncs/cra-bug-report-reproduction/commit/main).

To test within your own project, I believe you can just change any of your TypeScript files from `.ts` to `.js`. You will then no longer receive any TypeScript errors during builds.

### Expected behavior

Speaking in the context of the demo project above: a compilation error from the TypeScript compiler should˙be output and the build should fail (error is in the `baz` function in `App.tsx`).

### Actual behavior

No error occurs in the `baz` function.
Repository: rust
Issue: Several trivial `Vec<T>` methods (deref, as_ref, etc) end up in compiled output when optimizing for size.
Labels: A-LLVM,T-compiler

Godbolt repro: https://rust.godbolt.org/z/caG4MEjsr

With `-Copt-level=s` and `-Copt-level=z` the functions `<Vec<T> as Deref>::deref` and `<Vec<T> as AsRef<[T]>>::as_ref` show up in the output pointlessly. Similarly for the mut versions (AsMut, DerefMut, etc), and a few similar methods I tried (Borrow::borrow for example).

There are probably some other similar issues too (it seems a lot of our library code is optimized for `-Copt-level=3` rather than with size optimizations...).

Note that this can end up with a lot of copies of these functions, since you get at least one for each `T` you use `Vec<T>::deref` with, which is basically one for each `T` you put in a `Vec`.

Also note that these get fully optimized away on both `-Copt-level=3` and `-Copt-level=2`.

One way to fix this is probably to make these `#[inline(always)]`, but it seems weird that these would show up at all, so perhaps there's a better way which can fix the issue more broadly.
Repository: godot
Issue: Huge blend shape overhead with multiple materials (GLES3)
Labels: topic:rendering,topic:3d,performance

### Godot version

3.2; 3.3.2; 3.4.beta 6a058cb

### System information

Windows 10; GLES3; Nvidia RTX 2080 Ti and Linux; GLES3; Nvidia GTX 1050 m

### Issue description

Godot 3.x stores vertices and blend shapes per surface. This means that the number of transform feedback passes on a model with blend shapes is multiplied by the number of surfaces.

The blend shape updates are also done per depth and color pass. From looking through renderdoc, it seems to be performing a prepass for some reason, so on a scene with a directional light with shadows, with my model that has 90 blend shapes, that makes 3 * 9 * 90 = 2500 draw calls for a single model.

Here is a GPU utilization graph showing Godot bringing my RTX card to its knees with a single model:
![image](https://user-images.githubusercontent.com/39946030/135393942-46aea480-cf70-4792-b897-2b36de829a0e.png)

We ran into this issue when debugging performance bottlenecks in a usecase for over 50 blend shapes using real-time face tracking data from iOS.
The original project is available here:
https://github.com/vss-project/vss
In the real-world application, we are not able to get above 20 fps on this model on Godot 3.x.

Here is a screenshot from RenderDoc showing all of the blendshape passes adding up to a total of 60000 events. (This is all for drawing a single animated character):
![RenderDoc showing 60000 events in the timeline](https://user-images.githubusercontent.com/39946030/135394285-93892357-a7ec-4640-94d3-afb1428be3ff.png)

We also tried GLES2, but the CPU skinning takes half a second per frame, so it's no good for this application.

The "one_material" model is the same model (same number of vertices), but with the materials merged into one surface using an external tool in Unity + UniGLTF.

One fix could be to store vertex buffers and blendshapes contiguously, and then the transform feedback pass can update all surfaces at the same time on each mesh.

Godot 4.0 is fast enough that I am not able to reproduce this issue without a more robust performance benchmark (e.g. 50 characters in the scene at once + FPS counter). But this usecase could come up in an application I am making.

### Steps to reproduce

Open the attached project.

For each of the three scenes:
many_active_blendshapes.tscn
many_active_blendshapes_one_material.tscn
no_active_blendshapes.tscn

1. Open the scene
2. Click AnimationPlayer in the tree
3. In the inspector, change [stop] to KeepUpdating
4. Watch the performance.


### Minimal reproduction project

[blendshape_performance.zip](https://github.com/godotengine/godot/files/7256975/blendshape_performance.zip)
Repository: flutter
Issue: `dart:ui.LineMetrics` should include the line boundaries 
Labels: a: text input,engine,a: typography,c: proposal,P3,team-engine,triaged-engine

The information is currently manually stripped when constructing a `LineMetrics`:
https://github.com/google/skia/blob/a92b268f7d78e0069b2a61b22cb7ce615d12a60e/modules/skparagraph/include/Metrics.h#L39-L93

It will be much easier to implement vertical caret movements for up/down arrow keys with the line boundary information included. This corresponds to a todo item in https://github.com/flutter/flutter/pull/90684 .
Repository: react
Issue: Bug: Submit events from a button inside a portal don't bubble up to a form in its React DOM Ancestry.
Labels: Component: DOM,Status: Unconfirmed,Type: Discussion

From the docs of [React Portal](https://reactjs.org/docs/portals.html#event-bubbling-through-portals)
>  An event fired from inside a portal will propagate to ancestors in the containing React tree, even if those elements are not ancestors in the DOM tree.

However this doesn't seem to be the case with `<form>`s when using a `<button type='submit'>` that is inside a `Portal`.
Clicking a submit button that is inside a portal-ed modal which is contained by the `form` does not trigger the form's `onSubmit` event. The only way to get it to do so, is to wrap the submit button in an additional `<form>` element that is inside the portal as well. When this is done, then event bubbles up to _both_ forms, and the original, outer form's `onSubmit` is triggered as desired.

React version: 16.14.0

## Steps To Reproduce

1. Write a simple form element that contains a React `Portal`, such as a modal. 
2. Inside the`Portal`, add a submit button, e.g. `<button type='submit'>submit</button>`.
3. Click the submit button inside the portal.

### Workaround
4. Inside the `Portal`, wrap the submit button you've made in an additional `form` element.
5. Click the submit button inside the portal.

Link to code example: https://codesandbox.io/s/new-dust-b6hoh?file=/src/App.tsx

## The current behavior
Clicking the button inside the portal does not result in the form being submitted.
Clicking the button inside the portal with an additional form element results in both forms being submitted.

## The expected behavior
The form outside of the portal is submitted by the portal's submit button (without including any additional form elements).
Repository: pytorch
Issue: `pad_packed_sequence` is not exactly the inverse of `pack_padded_sequence`
Labels: module: rnn,triaged

## 🐛 Bug

When a padded sequence is received from a batch it is possible that the last timesteps of all sequences are padded with zero. In that case packing und unpacking the sequences will drop the last timestep. Basically the packing/unpacking looses information.

## To Reproduce

Steps to reproduce the behavior:

```python
import torch
from torch.nn.utils.rnn import pack_padded_sequence, pad_packed_sequence

padded_batch = torch.LongTensor(
    [[1, 2, 3, 0],
     [5, 6, 0, 0],
     [7, 0, 0, 0]]
)

seqs_len = [3, 2, 1]

packed_batch = pack_padded_sequence(padded_batch, seqs_len, batch_first=True)
print(packed_batch)
# PackedSequence(data=tensor([1, 5, 7, 2, 6, 3]), batch_sizes=tensor([3, 2, 1]), sorted_indices=None, unsorted_indices=None)

padded_batch1, _ = pad_packed_sequence(packed_batch, batch_first=True, padding_value=0)
print(padded_batch1)
# note that the last paddings are dropped
# tensor([[1, 2, 3],
#         [5, 6, 0],
#         [7, 0, 0]])
```

This behaviour requires further handling in downstream components.
For example when doing sequence labeling it is required to adapt the label sequence before computing the loss:

```python
padded_batch_seq_len = padded_batch.shape[1]
padded_batch1_seq_len = padded_batch1.shape[1]

if padded_batch_seq_len != padded_batch1_seq_len:
    pass
    # shorten label sequence here
```

## Expected behavior

I would have expected the unpacked tensor to be the same as the original one.

## Environment

 - PyTorch Version (e.g., 1.9.1):
 - OS (e.g., Linux): Ubuntu 20.04.3 LTS
 - How you installed PyTorch (`conda`, `pip`, source): conda
 - Python version: 3.8.11
 - CUDA/cuDNN version: 10.2.89/7.6.5


cc @zou3519
Repository: ant-design
Issue: React Portals (Drawers,Modals) click with Apple Pencil doesn't work
Labels: help wanted,Inactive,improvement

- [x] I have searched the [issues](https://github.com/ant-design/ant-design/issues) of this repository and believe that this is not a duplicate.

### Reproduction link
[![Edit on CodeSandbox](https://codesandbox.io/static/img/play-codesandbox.svg)](https://codesandbox.io/s/optimistic-cloud-vi6r9)

### Steps to reproduce
- Open drawer
- Try to close it by clicking the "x" button with an Apple Pencil

### What is expected?
The Drawer or any other component implemented with Portals should close

### What is actually happening?
It doesn't close when using the Apple Pencil

| Environment | Info |
|---|---|
| antd | 4.16.13 |
| React | 17.0.1 |
| System | macOS Monterey |
| Browser | Google Chrome Canary |


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: vscode
Issue: Not showing pencil on left margin of settings.json
Labels: bug,settings-editor


Issue Type: <b>Bug</b>

Not showing pencil on left margin of `settings.json`.

![upload](https://user-images.githubusercontent.com/855297/135416543-7a639df2-e638-4360-96cf-ca1ed95a9f4d.gif)



VS Code version: Code 1.60.2 (7f6ab5485bbc008386c4386d08766667e155244e, 2021-09-22T12:01:43.795Z)
OS version: Linux x64 5.4.0-88-generic
Restricted Mode: No

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i5-8600K CPU @ 3.60GHz (6 x 4100)|
|GPU Status|2d_canvas: enabled<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>oop_rasterization: disabled_off<br>opengl: enabled_on<br>rasterization: disabled_software<br>skia_renderer: enabled_on<br>video_decode: disabled_software<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled|
|Load (avg)|2, 1, 1|
|Memory (System)|31.03GB (16.57GB free)|
|Process Argv|--unity-launch|
|Screen Reader|no|
|VM|0%|
|DESKTOP_SESSION|cinnamon|
|XDG_CURRENT_DESKTOP|X-Cinnamon|
|XDG_SESSION_DESKTOP|cinnamon|
|XDG_SESSION_TYPE|x11|
</details>Extensions: none<details>
<summary>A/B Experiments</summary>

```
vsliv368cf:30146710
vsreu685:30147344
python383cf:30185419
pythonvspyt602:30300191
vspor879:30202332
vspor708:30202333
vspor363:30204092
vswsl492cf:30256860
vstes627:30244334
pythonvspyt639:30300192
pythontb:30283811
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
pythondataviewer:30285071
pythonvsuse255:30340121
vscod805:30301674
pythonvspyt200:30340761
binariesv615:30325510
vsccppwt:30364497
pythonvssor306:30344512
bridge0708:30335490
pygetstartedt2:30371810
dockerwalkthru:30370836
bridge0723:30353136
pythonrunftest32:30373476
pythonf5test824:30373475
javagetstartedt:30364666
pythonvspyt187:30373474
pydsgst2:30361792
vsqsis200:30374795

```

</details>

<!-- generated by issue reporter -->
Repository: flutter
Issue: [flutter_markdown]: limit/restrict markdown functionality
Labels: c: new feature,package,c: proposal,team-ecosystem,P3,p: flutter_markdown,triaged-ecosystem

<!-- Thank you for using Flutter!

     If you are looking for support, please check out our documentation
     or consider asking a question on Stack Overflow:
      * https://flutter.dev/
      * https://api.flutter.dev/
      * https://stackoverflow.com/questions/tagged/flutter?sort=frequent

     If you have found a bug or if our documentation doesn't have an answer
     to what you're looking for, then fill out the template below. Please read
     our guide to filing a bug first: https://flutter.dev/docs/resources/bug-reports
-->

## Use case

I only want to use
#### emphasis
- This is ~strike_through~
- this is **bold**
- this is _italic_

#### list
- ordered
1. item1
2. item2
- unordered lists
-  item 4

#### Hyperlink
- [link](https://flutter.dev/)

## Proposal

Allow us to restrict functionalities to which we want to use.
Repository: pytorch
Issue: Deprecation: Remove nn.functional.sigmoid 
Labels: module: nn,triaged,module: deprecation

This operation is deprecated and warns whenever it's used, see it's implementation here:

https://github.com/pytorch/pytorch/blob/4666e3f19228ddb73294c3ce7eba01b1641c083a/torch/nn/functional.py#L1847

The deprecation warning also correctly points users to torch.sigmoid, for which nn.functional.sigmoid is an alias. We should finally remove this operator.

cc @albanD @mruberry @jbschlosser @walterddr
Repository: rust
Issue: Implement "intersection lifetimes" to improve diagnostics and accept rare impl trait cases
Labels: A-diagnostics,T-compiler,A-NLL

TLDR: The following does not compile but it should

```rust
trait Trait<'a, 'b> {}
impl<T> Trait<'_, '_> for T {}

struct Struct<'a>(&'a u8);

fn foo<'a, 'b>(a: Struct<'a>, b: Struct<'b>) -> impl Trait<'a, 'b> {
    if false { a } else { b }
}
```

The lifetime of the `if false { a } else { b }` is `'a` OR `'b`, but right now we can only express `'a` AND `'b` (as `'lifetime: 'a + 'b`).
Beyond diagnostics, only impl trait can actually encounter such lifetimes in a somewhat reasonable way.

So the plan is as follows:

1. add intersection lifetimes to mir borrowck, without actually creating them
2. specifically create them for member constraints that would otherwise be unresolvable
3. put a lot of effort into making the diagnostics comprehensible


Some details: https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/member.20constraints.20PR.20.2389056/near/255496552

Related (purely diagnostics) PR: https://github.com/rust-lang/rust/pull/89327