sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: 'replicate' padding in convolution is 77 times slower on cpu than 'zeros'
Labels: module: performance,module: nn,triaged,module: padding

## 🐛 Bug

When using a 2D convolution, 'replicate' padding is 77 times slower than 'zeros' padding on cpu.
I observe only a 30% difference on gpu. I would not have expected a so big difference on cpu.

```
import torch
import time

print(torch.__version__)

###
nb_trials = 10
kernel_size = 3
dilation = 2**8
nb_chs = 64
batch_size = 16
data_length = 28

devices = ['cpu','cuda:0']

dims = {
    '1d':{
        'tensor' : torch.rand(batch_size,nb_chs,data_length),
        'conv' : torch.nn.Conv1d,
    },
    '2d':{
        'tensor' : torch.rand(batch_size,nb_chs,data_length,data_length),
        'conv' : torch.nn.Conv2d,
    },
}

def get_time_perfs(nb_trials, verbose=True):
    for device in devices:
        for dim in dims.keys():

            a = dims[dim]['tensor']
            a = a.to(device)

            for pad in ['zeros', 'replicate']:

                conv = dims[dim]['conv'](nb_chs,nb_chs, kernel_size=kernel_size, padding_mode=pad,
                    padding=dilation*(kernel_size-1)//2, dilation=dilation)
                conv.to(device)

                if 'cuda' in device:
                    torch.cuda.synchronize(device=device)
                time_start = time.time()
                for _ in range(nb_trials):
                    b = conv(a)
                    b = b.detach().cpu()
                if 'cuda' in device:
                    torch.cuda.synchronize(device=device)
                time_end = time.time()


                if verbose:
                    print(f"{device}, {dim}, {pad} took {1000*(time_end-time_start)/nb_trials} ms")

    return

get_time_perfs(2, verbose=False)
get_time_perfs(nb_trials)
```

result:
```
1.10.0+cu102

cpu, 1d, zeros took 3.5540103912353516 ms
cpu, 1d, replicate took 8.845877647399902 ms

cpu, 2d, zeros took 4.4013261795043945 ms
cpu, 2d, replicate took 581.4733505249023 ms

cuda:0, 1d, zeros took 1.3633012771606445 ms
cuda:0, 1d, replicate took 1.03912353515625 ms

cuda:0, 2d, zeros took 0.7899761199951172 ms
cuda:0, 2d, replicate took 18.916916847229004 ms

```

[edit-1] Correct benchmark with gpu synchroniation


cc @VitalyFedyunin @ngimel @albanD @mruberry @jbschlosser @walterddr
Repository: create-react-app
Issue: eslint ^8 version incompatible
Labels: stale,needs triage

i was creating a eslint plugin,and i used create-react-app cli to created a react project inner eslint plugin，but it turn's out an error: 
```
The react-scripts package provided by Create React App requires a dependency:

  "eslint": "^7.11.0"

Don't try to install it manually: your package manager does it automatically.
However, a different version of eslint was detected higher up in the tree:

  /Users/vb/openSource/tools/eslint-plugin-authority-import/node_modules/eslint (version: 8.2.0) 

Manually installing incompatible versions is known to cause hard-to-debug issues.

If you would prefer to ignore this check, add SKIP_PREFLIGHT_CHECK=true to an .env file in your project.
That will permanently disable this message but you might encounter other issues.

To fix the dependency tree, try following the steps below in the exact order:

  1. Delete package-lock.json (not package.json!) and/or yarn.lock in your project folder.
  2. Delete node_modules in your project folder.
  3. Remove "eslint" from dependencies and/or devDependencies in the package.json file in your project folder.
  4. Run npm install or yarn, depending on the package manager you use.

In most cases, this should be enough to fix the problem.
If this has not helped, there are a few other things you can try:

  5. If you used npm, install yarn (http://yarnpkg.com/) and repeat the above steps with it instead.
     This may help because npm has known issues with package hoisting which may get resolved in future versions.

  6. Check if /Users/vb/openSource/tools/eslint-plugin-authority-import/node_modules/eslint is outside your project directory.
     For example, you might have accidentally installed something in your home folder.

  7. Try running npm ls eslint in your project folder.
     This will tell you which other package (apart from the expected react-scripts) installed eslint.

If nothing else helps, add SKIP_PREFLIGHT_CHECK=true to an .env file in your project.
That would permanently disable this preflight check in case you want to proceed anyway.

P.S. We know this message is long but please read the steps above :-) We hope you find them helpful!
```

i can create an .env file to fixed it. but i was wondering why this happen? i try to used `yarn list eslint`:
```
yarn list v1.22.10
warning Filtering by arguments is deprecated. Please use the pattern option instead.
└─ eslint@7.32.0
```
my home folder dependencies in  eslint@^8, but this react project should used the closest node_modules, why still invalid? thank you
Repository: TypeScript
Issue: `ThisType` should use the `intrinsic` keyword
Labels: Suggestion,In Discussion

# Suggestion

<!--
  Please fill in each section completely. Thank you!
-->

## 🔍 Search Terms

<!--
  💡 Did you know? TypeScript has over 2,000 open suggestions!
  🔎 Please search thoroughly before logging new feature requests as most common ideas already have a proposal in progress.
  The "Common Feature Requests" section of the FAQ lists many popular requests: https://github.com/Microsoft/TypeScript/wiki/FAQ#common-feature-requests

  Replace the text below:
-->

thistype intrinsic

## ✅ 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

[`ThisType`](https://www.typescriptlang.org/docs/handbook/utility-types.html#thistypetype) is quite confusing in that it appears to do nothing when you go to its definition:

```ts
interface ThisType<T> { }
```
but it actually has secret intrinsic functionality? so imo it should use the `intrinsic` keyword:

```ts
type ThisType<T> = intrinsic
```

or better yet, why not implement it in the language? 
```ts
type ThisType<OldThis, NewThis> = {
    [K in keyof OldThis]: OldThis[K] extends (...args: never[]) => unknown
        ? (this: NewThis, ...args: Parameters<OldThis[K]>) => ReturnType<OldThis[K]>
        : OldThis[K]
}
```
(though that would probably break existing code)

## motivation

it's misleading in a language when a symbol has a "fake" implementation you can look at, but its behavior is actually defined intrinsically somewhere else. for example, the `NoReturn` type in python:
```py
NoReturn = Union[None]
```
this is as non-sensical as its typescript equivalent:
```ts
type never = undefined
```
`Union[None]` has nothing to do with `NoReturn`. its behavior is actually intrinsically defined in type checkers such as mypy. if `never` had a fake definition like this, it would be extremely confusing and it would blur the lines between what's intrinsic and what isn't.
Repository: pytorch
Issue: Add common regularizations to PyTorch.
Labels: feature,module: nn,triaged,needs research,module: norms and normalization

## 🚀 Feature
I propose including L1/L2 regularization and perhaps stochastic depth to the PyTorch library.

## Motivation

PyTorch does not currently support L1 regularization natively despite its once being a very popular method.
Indeed, the decline of L1 may in part be due to the lack of a native PyTorch implementation.
Also, the L2 regularization offered by PyTorch is specified in the optimizer and cannot change in value.
Finally, stochastic depth, despite being a standard technique in training residual neural networks, must be implemented by users, making it impossible to use pre-trained models directly.

## Pitch

I propose adding the L1 and L2 regularizations as backward hooks, hopefully with the option of changing the regularization terms during training.
Stochastic depth may be included as a layer. I do not know how it could be implemented as a hook.

These proposals have already been implemented by TorchLayers, though L1 and L2 are layers instead of pure hooks.
https://github.com/szymonmaszke/torchlayers/blob/master/torchlayers/regularization.py

 
## Alternatives

Perhaps the optimizer could automatically perform regularization of either L1 or L2 or a combination of the two.
The fact that the regularization values cannot be changed is very frustrating because the loss generally declines while the weights generally increase during training.

## Additional context

L1 and L2 regularization have declined in popularity in recent years despite their initial widespread use. This may be due to the inconvenience of re-implementing them in PyTorch, whereas they are available natively in Keras.
Also, despite the near universality of learning-rate scheduling, there is very little research into regularization scheduling, even though they both operate on the ease of learning.
Stochastic depth is also made more difficult than necessary.
I believe that adding these simple regularizations will be immensely helpful to the research community at large.

cc @albanD @mruberry @jbschlosser @walterddr
Repository: pytorch
Issue: [ux] [feature request] Arguments to modules(), named_modules(), children(), named_children() to filter modules of specific types
Labels: module: nn,triaged,enhancement,needs research

This is a very frequent pattern (e.g. when doing weight initialization), so being able to specify parent module type or parent module types (e.g. nn.Linear) would make the code more concise, clear and have less boiler plate. These methods already accept some filtering options, so adding type-based ones should be okay

cc @albanD @mruberry @jbschlosser @walterddr
Repository: ant-design
Issue: [Bug] message组件style传zIndex无效
Labels: Inactive

### 重现链接

所有message都会重现

### antd 版本

4.17.1

### 重现步骤

  message.error({
    content: "test",
    style: {
      zIndex: 1500
    }
  });

ant-message这个class下的div写死z-index:1010了，内部设置的zindex没有意义

### 期望的结果是什么？

期望ant-message这个class被加上z-index

### 实际的结果是什么？

zindex被加到了ant-message下面的div

### 浏览器

Chrome

### 浏览器版本

90.0.4430.212

### 操作系统

MacOS

### 其他

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: material-ui
Issue: Allow emmet CSS shorthands in the `sx` prop
Labels: new feature,waiting for 👍,package: system

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Summary 💡

The `sx` prop already allows us to use `m`, `my`, `mx`, `mt`, `mb`, `ml`, `mr`, `p`, `py`, `px`, `pt`, `pb`, `pl`, `pr` as shorthands for margin and padding.  

Being able to use other [emmet CSS shorthands](https://docs.emmet.io/cheat-sheet/) would be great.

### Examples 🌈

```
<Box sx={{ d: 'inline' c: 'red', pos: 'fixed', fz: 12  }}>
```

Would be similar to: 

```
<Box sx={{
  didplay: 'inline'
  color: 'red',
  position: 'fixed',
  fontSize: 12
}}>
```

### Motivation 🔦

I've been using emmet since I started coding, seeing the same kind of feature for margin of padding in MUI reminded me of how time saving it is, and could be here too if it's implemented.  

I'd be happy to provide a PR for this if someone guides me to where the modifications should be made.
Repository: react-native
Issue: KeyboardAvoidingView Android white area when keyboard open/close 
Labels: Platform: Android,Component: KeyboardAvoidingView,API: Keyboard,Needs: Triage :mag:

### Description

When using KeyboardAvoidingView on android, whatever the configuration I use for the `behavior` or the `keyboardVerticalOffset` I always have a white area when the keyboard is opening or closing while on iOS everything is moving smoothly.

https://user-images.githubusercontent.com/21194324/142198993-243f9d37-07ae-4b10-bc7d-2357867629fb.mp4

In the video, we can see that when the keyboard opens there is a big white area and when closing sometimes a small white rectangle with some flickering. I'm wondering if this is normal behavior because on iOS it transitions smoothly 

I tried modifying android manifest with  `android:windowSoftInputMode="adjustResize"` or `android:windowSoftInputMode="adjustPan"` but the problem is still there with both config. 

It would actually be ok if we could change this color from white to something else like the background color of the content (red in my example). But I couldn't find a way.

### Version

0.66	

### Output of `react-native info`

It happens from the documentation snack so I guess this section is not necessary 

### Steps to reproduce

Take the example from the KeyboardAvoidingView of react-native documentation and modify the background color of the container from white to red in order to see the white area when opening/closing the keyboard.

### Snack, code example, screenshot, or link to a repository

https://snack.expo.dev/@flowwwww/keyboardavoidingview
Repository: ant-design
Issue: [Feature Request] [Table] Support pass custom porps to wrapper component 
Labels: Inactive

- [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.

### What problem does this feature solve?
Currently the `components.body.wrapper` component [can't recevie](https://github.com/react-component/table/blob/2d0d403642263fdfe41e0dae3cda8d16f665eb35/src/Body/index.tsx#L111) any prop, but `components.body.row` can by the `onRow` prop.

### What does the proposed API look like?
I would suggest support a new prop like `onContainer` or `onWrapper`, and then the logic is same as `onRow`.


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: flutter
Issue: [Video_Player] Proposal to set custom buffering values
Labels: c: new feature,p: video_player,package,c: proposal,team-ecosystem,P3,triaged-ecosystem

## Use case

I am displaying videos in ```ListView.builder``` widgets in my app or ```PageView.builder```. 
I am using a CDN to load and play very quickly files from network (small videos 1-5 seconds).
They are all buffering 1-3 seconds before starting. 
I am not sure how the buffer is working in ```video_player```, but it seems that this is causing the issue in my app as my videos are not played directly and leads to bad user experience. 

I am almost certain this comes from the ```video_player``` buffer or native iOS player because if i open the video URLs in a browser it plays instantly.

I have not tested it yet on Android, once i have i will update here. 

## Proposal

Simply let the user be able to set a custom buffering configuration for the player. 
The ```VideoPlayerController``` class could have a setter like : 
```
_videoPlayerController.setBufferDurations(Duration minBuffer, Duration maxBufferMs, Duration bufferForPlayackMS, Duration bufferForPlaybackAfterRebufferMs)
```

I am not an iOS developer, but i know that on Android the ```ExoPlayer``` allows this kind of [customization](https://stackoverflow.com/questions/54073206/android-exoplayer-start-playing-as-soon-as-possible-without-too-much-buffering).
Repository: godot
Issue: This artifact significantly increases the size of APK(s) downloaded by users
Labels: bug,platform:android,topic:porting,topic:thirdparty

### Godot version

3.4

### System information

Android Google Play Console

### Issue description

With 3.4 (I did not get this with 3.3.4) I now get the following warning when creating a new release for my game:
> This artifact significantly increases the size of APK(s) downloaded by users. Larger apps see lower installation and update success rates and take up device storage on user's devices.

There have been no significant changes to the game (aside from upgrading Godot to 3.4) and the file sizes reported by the Google Play Console are approximately the same:
**Current release asset sizes**
File | Download Size
-- | --
Original file | 54.8 MB
Signed, universal APK | 48.9 MB
ReTrace mapping file | -
Native debug symbols | 6.26 MB

**Previous release asset sizes**
File | Download Size
-- | --
Original file | 53.6 MB
Signed, universal APK | 47.3 MB
ReTrace mapping file | -
Native debug symbols | 6.26 MB


### Steps to reproduce

- Upgrade Godot to v3.4.
- Export to Android AAB.
- Upload the AAB to the Google Play Console.
- Create a new release from the new AAB.
- Review the release and check the warnings before starting the rollout. 

### Minimal reproduction project

_No response_
Repository: go
Issue: x/sys/windows/namedpipe: new package
Labels: OS-Windows,Proposal,Proposal-Accepted

**Update, Dec 8 2021**: Proposed API is in https://github.com/golang/go/issues/49650#issuecomment-976797686 -rsc

- - - 

https://go-review.googlesource.com/c/sys/+/299009 is a CL to add a new "namedpipe" package to x/sys/windows/namedpipe.

This is an accompanying proposal for its API addition.

From that CL's commit message:

> It is based on WireGuard's namedpipe library, which in turn is based on
> parts of Microsoft's go-winio library.

The proposed API can more be seen here, which already exists outside of x/:

https://pkg.go.dev/golang.zx2c4.com/wireguard/ipc/namedpipe

It's basically a Unix socket dia/listen API but over Windows named pipes.

/cc @zx2c4 @jstarks
Repository: go
Issue: x/tools/go/analysis/passes/shadow: is confused by newtypes
Labels: NeedsInvestigation,Tools,Analysis

##  Reproducer

```go
package main

import "fmt"

type x int

type y int

func main() {
	as := []int{1, 2, 3}
	bs := []int{10, 20, 30}

	for _, a := range as {
		v := x(a)

		for _, b := range bs {
			v := y(b)
			fmt.Println(v)
		}

		fmt.Println(v)
	}
}
```

<https://play.golang.org/p/Xx4xqdtocit>

##  Expected

```none
$ shadow --strict ./main.go
.../main.go:17:4: declaration of "v" shadows declaration at line 14
$
```

##  Got

```none
$ shadow --strict ./main.go 
$
```

##  Details

If I remove the type conversions, the result is as expected.

##  OS, Versions, And So On

<details><summary>Formalities</summary>

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.17.3 linux/amd64
$ shadow -V
shadow: unsupported flag value: -V=true
$ strings $( which shadow ) | grep -F -e '0.1.8' | grep -F -e 'shadow'
/home/ainar/go/pkg/mod/golang.org/x/tools@v0.1.8-0.20211117171249-771dabf43312/go/analysis/passes/shadow/shadow.go
/home/ainar/go/pkg/mod/golang.org/x/tools@v0.1.8-0.20211117171249-771dabf43312/go/analysis/passes/shadow/cmd/shadow/main.go
</pre>

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/ainar/.cache/go-build"
GOENV="/home/ainar/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/ainar/go/pkg/mod"
GONOPROXY="REMOVED"
GONOSUMDB="REMOVED"
GOOS="linux"
GOPATH="/home/ainar/go"
GOPRIVATE="REMOVED"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/ainar/go/go1.17"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/ainar/go/go1.17/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17.3"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3097813802=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

</details>
Repository: go
Issue: all: decide and document Android supported versions
Labels: Documentation,OS-Android,NeedsDecision,mobile

Neither https://golang.org/wiki/MinimumRequirements, https://golang.org/wiki/Mobile, nor https://github.com/golang/mobile#readme mention what versions of Android are supported, other than to say support is experimental.

Similarly to #48076, it would be helpful to find agreement and document what versions of Android we aim to offer support for.

(There have been individual issues for specific Android versions, such as #23750, but I didn't find an existing tracking issue for a higher level decision.)
Repository: pytorch
Issue: `vmap` performance warnings from `jacobian`
Labels: module: performance,triaged,module: vmap

As requested in [the documentation](https://pytorch.org/docs/stable/generated/torch.autograd.functional.jacobian.html), I'm reporting the performance warnings I get when using `vectorize=True` on my model:
```
[W BatchedFallback.cpp:74] Warning: Batching rule not implemented for aten::softplus_backward falling back to slow (for loop and stack) implementation (function warnFallback)
```
for the operations:
 - `aten::softplus_backward`
 - `aten::copy_`
 - `aten::index_put_`
 - `aten::gather`
 - `aten::_index_put_impl_`

cc @VitalyFedyunin @ngimel @zou3519
Repository: flutter
Issue: [flutter_plugin_tools] Enforce consistency of plugin and example build targets
Labels: team,platform-android,platform-ios,p: tooling,package,team-ecosystem,P2,triaged-ecosystem

On both Android and iOS we have the behavior that our CI could pass, while plugin clients could have build failures without any warning or useful error message. This is because our CI behavior is based on the example app build target, but the warnings/errors clients see are based on the build target set in the plugin.
- On Android, the `targetSdkVersion` in the plugin's `build.gradle` isn't used in the build; the building application's `targetSdkVersion` is what matters. As of current master, clients will get a warning if their application's `targetSdkVersion` is lower than any plugin's version.
- On iOS, the `platform` version in the plugin's Podspec will be overridden if it's lower than the building application's `IPHONEOS_DEPLOYMENT_TARGET`. If the application's `IPHONEOS_DEPLOYMENT_TARGET` is lower than any plugin's `platform` version, the Cocoapods integration will fail with a relatively clear error.

So in both cases, there is the potential to unconditionally use an API that requires a newer target version, but only update the example app and have things pass. It's likely that for any plugin with native unit tests (which should be most), the build would catch this, but we shouldn't rely on that since not every plugin will always have native unit tests. We should have the tooling assert that the plugin and the example are using a consistent version.