sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: x/net: IPConn.Read() Not able to read FIN/FIN-ACK/ACK packet
Labels: NeedsInvestigation



### What version of Go are you using (`go version`)?

<pre>
$ go version
1.5

</pre>

### Does this issue reproduce with the latest release?
didnt check, but possible on latest go lang version also


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
dev-dsk-smvikash-2a-be3e7414 % go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/user/.cache/go-build"
GOENV="/home/user/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/user/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/user/go"
GOPRIVATE=""
GOPROXY="direct"
GOROOT="/usr/lib/golang"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/golang/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build710417058=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

I am trying to create raw tcp connection using dialIP(). 
//Creating
  conn, err := net.DialIP("ip4:tcp", &localaddr, &remoteaddr)

// Sending SYN packet 
    packetbuf := gopacket.NewSerializeBuffer()
    opts := gopacket.SerializeOptions{
    FixLengths:       true,
    ComputeChecksums: true,
    }
    
    ipv4 := &layers.IPv4{
    SrcIP:    rawInput.SrcIP,
    DstIP:    rawInput.DstIP,
    Protocol: layers.IPProtocolTCP,
    }
    
    tcp := &layers.TCP{
    SrcPort: rawInput.SrcPort,
    DstPort: rawInput.DstPort,
    Window:  rawInput.Window,
    Urgent:  rawInput.Urgent,
    Seq:     rawInput.Sequence,
    Ack:     0,
    SYN:     true,
    }
    tcp.SetNetworkLayerForChecksum(ipv4)
    payload := gopacket.Payload(rawhandoffBytes)
    gopacket.SerializeLayers(packetbuf, opts, tcp, payload)
    
    println("Sending PacketData..")
    _, err := conn.Write(packetbuf.Bytes())

// Reading on connection for FIN/FINACK, as connection is closed at server side
conn.SetReadDeadline(time.Now().Add(5 * time.Second))
	n, err := conn.Read(packet_data)

But couldnot capture the FIN-ACK packet, but working for SYN-ACK. 





### What did you expect to see?
Able to capture FIN-ACK packet 


### What did you see instead?
Stuck in reading bytes
Repository: pytorch
Issue: Add efficient symmetric tensor representations
Labels: triaged,module: linear algebra,module: __torch_function__

## 🚀 Feature
<!-- A clear and concise description of the feature proposal -->
Hello! It would be nice to have an memory and compute efficient way to represent symmetric (and partially symmetric) tensors.
 
## Motivation
I am working on a project in which I do lots of calculations with big symmetric tensors, which is the limiting factor in my batch size (among other things). A space-efficient symmetric tensor would only need to use ~1/2 the space, and thus would let me ~double my batch size. 

<!-- Please outline the motivation for the proposal. Is your feature request related to a problem? e.g., I'm always frustrated when [...]. If this is related to another GitHub issue, please link here too -->

## Pitch
If a user declares a symmetric tensor, for example:
```python
x = SymTensor(size=(5, 5))
```
it would internally represent the data as a tensor with `5 x (5 + 1) / 2 = 15` elements, but allow for something like `x[1, 2:4]` to get the corresponding data as if it were a full `5x5` matrix.  

Additionally, this should support partially-symmetric tensors (that is, tensors which are only symmetric along certain dimension). For example, a 3d tensor might only be symmetric along 2 dimensions, essentially making it a list of symmetric matrices. Something like
```python
x = SymTensor(size=(4, 5, 5), sym_along=[1, 2])
```
could represent a batch of symmetric matrices as input to a model. 

The same idea could be used for upper- and lower-triangular tensors---the only difference being that instead of having mirrored data, we'd have 0s (or some other constant) on the opposite side. 

<!-- A clear and concise description of what you want to happen. -->
I've had a go at implementing this myself, but I got stuck rather early since I have a very limited understanding of how libtorch/pytorch internals work (I was worried about screwing up autograd). I also found it tricky to get the indexing to line up right.
For example, using the `5x5` example below, `x[1, 2:4]` is, in the efficient representation, `x[[4,7]]`, but I couldn't think of an easy way to convert between the two. (I zero'd out the top half to indicate that it's not actually being stored in memory)
```
1   -   -   -   -
2   3   -   -   -
4   5   6   -   -
7   8   9   10  -
11  12  13  14  15
```
Thanks for reading!

cc @jianyuh @nikitaved @pearu @mruberry @heitorschueroff @walterddr @IvanYashchuk @xwang233 @Lezcano @hameerabbasi @rgommers @peterbell10
Repository: rust
Issue: Error for self-referential type parameter bounds appears in presumptuous circumstances and is unclear
Labels: C-enhancement,T-compiler

According to [RFC-0447](https://github.com/rust-lang/rfcs/blob/master/text/0447-no-unused-impl-parameters.md) type parameters cannot be bound self-referentially. The justification for this is that "impls like this, when used, tend to result in overflow in the compiler, but it's more user-friendly to report an error earlier."

There are two issues with this assumption:
1. The error that is thrown ([E0207](https://doc.rust-lang.org/error-index.html#E0207)) makes no mention of self-referential bounds making it really confusing to debug this error when it shows up
2. With the addition of nightly features such as `const_evaluatable_checked` (and potentially `specialization`) it is now possible to write self-referential trait implementations that would not in fact cause an overflow in the compiler. One can imagine a generic struct that takes a `const U: usize`, has a trait defined for `U = 1`, and then recursively derives implementations for higher `U` values using the implementation for `U = 1` (not entirely sure if specialization would be _required_ for this). Under the current compiler rules code such as this would not compile.

### What Should Be Done About This

At the very least, self-referential type parameter bounds should get their own compiler error. As previously mentioned, the current compiler error makes no mention of self-referential bounds. This makes it really confusing to try and troubleshoot this issue if you're a newcomer to the language, and even in scenarios in which type parameter bounds are more complicated. 

However, I believe that having a compiler error for this issue is not the proper path to take. As mentioned above, if my understanding of some nightly features is correct, it's now possible to write self-referential type parameter bounds that **ought** not overflow at compile-time (they might, but that's not necessarily a problem with the code, but potentially a problem with the compiler), however it's currently impossible to check those scenarios because the compiler will throw an error instead of even attempting to resolve them. It's my opinion that the compiler should no longer throw [E0207](https://doc.rust-lang.org/error-index.html#E0207) for self-referential type parameter bounds, and instead there should be a compiler warning that the code may potentially overflow the compiler, but then proceed in attempting to resolve the implementation anyways. The result is that valid self-referential implementations can be written and will hopefully compile properly, and improper self-referential implementations will overflow the compiler along with a warning explaining a potential reason why the compiler overflowed.

### Related To
Issue #76560
Potentially Issue #31844
Repository: neovim
Issue: architecture: migrate to ltreesitter for tree-sitter integration
Labels: enhancement,refactor,needs:discussion,treesitter

### Feature already in Vim?

No

### Feature description

It's been brought up [here](https://github.com/euclidianAce/ltreesitter/discussions/3) to use (my) [ltreesitter](https://github.com/euclidianAce/ltreesitter) in neovim instead of the existing api. This was a while ago so I'm opening an issue to see if that's still on the table.

I've been recently making ltreesitter more usable from the C-side of things so maybe that could be useful to neovim, as well as focusing an effort on one set of tree-sitter bindings for Lua. Additionally, ltreesitter already has documentation generation that could easily be adapted to vim help docs.

I'm decently proficient with both C and Lua and would be glad to help in any way, including sketching out an initial pr to replicate neovim's existing `vim.treesitter` module but with `ltreesitter` under the hood.

cc @vigoux
Repository: pytorch
Issue: Add tests for DDP broadcast_buffers=True
Labels: high priority,triage review,oncall: distributed,module: bootcamp,pt_distributed_rampup,module: ddp

This is not really well tested in our codebase currently, i.e. if we completely remove DDP's broadcast_buffers feature, the only test failures are related to timeout etc and the tests don't raise an actual correctness issue with DDP. This is true for at least the tests in `distributed_test.py` and `test_c10d_nccl.py`. 

We should fix this by adding tests that ensure module buffer sync works as expected in DDP.

cc @ezyang @gchanan @zou3519 @bdhirsh @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang @agolynski @mrzzd @cbalioglu @gcramer23
Repository: pytorch
Issue: quicklint mypy step fails with assertion
Labels: module: typing,module: lint,triaged

This is happening on https://github.com/pytorch/pytorch/pull/63918, I am running `make quicklint -j 20`

```
x mypy (skipped typestub generation)
Traceback (most recent call last):
  File "tools/linter/mypy_wrapper.py", line 220, in <module>
    main(sys.argv[1:])
  File "tools/linter/mypy_wrapper.py", line 208, in main
    exit_code, mypy_issues, stderrs = run(
  File "tools/linter/mypy_wrapper.py", line 148, in run
    mypy_results = [
  File "tools/linter/mypy_wrapper.py", line 149, in <listcomp>
    mypy.api.run(
  File "mypy/api.py", line 69, in run
  File "mypy/api.py", line 58, in _run
  File "mypy/api.py", line 69, in <lambda>
  File "mypy/main.py", line 90, in main
  File "mypy/build.py", line 179, in build
  File "mypy/build.py", line 253, in _build
  File "mypy/build.py", line 2638, in dispatch
  File "mypy/build.py", line 2962, in process_graph
  File "mypy/build.py", line 3079, in process_stale_scc
  File "mypy/build.py", line 2251, in write_cache
  File "mypy/build.py", line 1461, in write_cache
  File "mypy/nodes.py", line 313, in serialize
  File "mypy/nodes.py", line 3140, in serialize
  File "mypy/nodes.py", line 3076, in serialize
AssertionError
```
cc @ezyang @malfet @rgommers @xuzhao9 @gramster @driazati
Repository: pytorch
Issue: quicklint clang-tidy step fails with many unrelated errors
Labels: module: lint,triaged

I am on https://github.com/pytorch/pytorch/pull/63918, running `make quicklint -j 20`. The clang-tidy step gives me a slew of errors: https://gist.github.com/suo/b4d22c90fcec4754906c0025622e2deb, which is different than the result in CI.

cc @driazati
Repository: pytorch
Issue: More efficient colon backwards in advanced indexing
Labels: module: performance,triaged,module: advanced indexing

@nelhage reports: x[:] does an alloc/zero/copy on the backwards pass … and x[:, h, :, :] does four

Wondering if there's any way to improve this. @anjali411 maybe zero tensors help?

cc @gchanan @zou3519 @VitalyFedyunin @ngimel @heitorschueroff
Repository: node
Issue: doc: Error for "." and ".." specifiers differs from documented Resolver Algorithm
Labels: doc,esm

- **Version**: ✍️

`16.7.0`

- **Platform**: ✍️

`Linux penguin 5.4.119-14945-gafc97d54f809 #1 SMP PREEMPT Tue Aug 10 21:49:04 PDT 2021 x86_64 GNU/Linux`

- **Subsystem**: ✍️

`module`

## Location

Affected URL(s):

- https://nodejs.org/api/esm.html#esm_resolver_algorithm_specification

## Description

I'm not sure if this is a bug with the ESM resolver or with the docs but basically if we do:

```js
import foo from ".";
```

Then Node throws a `ERR_UNSUPPORTED_DIR_IMPORT` error, based on a reading of the Resolver Algorithm I expected this to be `ERR_INVALID_MODULE_SPECIFIER`.

As CommonJS already treats `require(".")` and `require("..")` as directory imports the current behaviour in Node is probably the best, so the docs should be updated to reflect it. This would involve changing ESM_RESOLVE step 3 to:

- Otherwise, if specifier starts with "/", "./" or "../", or specifier equals "." or ".." then

Although if the current documented behaviour is the intended behaviour then the error needs updating.
Repository: godot
Issue: Godot scroll container's scrollbars visible rect and size are not pixel perfect 
Labels: topic:gui

### Godot version

3.3.stable

### System information

Kubuntu 20.04 Nvidia GeForce GTX 650, metapackage from nividia-driver-470 (propretary, tested)

### Issue description

Both the rect in which scrollbar containers show and hide their scrollbars and the size of the scrollbar between both scrollbars being shown or just either vertical or horizontal are not pixel perfect.

things that work..
![image](https://user-images.githubusercontent.com/2453707/130722933-e78788ab-a5b7-434d-b770-22ae590835c4.png)
![image](https://user-images.githubusercontent.com/2453707/130722989-ebfe5857-6856-4c0a-986f-526ea7b72c12.png)

things that are inaccurate..
![image](https://user-images.githubusercontent.com/2453707/130723801-a0348fb3-71e5-4b3f-a244-6b11b0baebb4.png)
![image](https://user-images.githubusercontent.com/2453707/130722867-33534a81-9114-4d1c-8ae0-b95c9d86786a.png)
![image](https://user-images.githubusercontent.com/2453707/130723180-83ecd664-dd8c-449b-8f7b-1b1b14d4d73a.png)


Ideally the scrollbars should meet each other when they are both enabled in the corner leaving a corner gap and they should show and hide the scrollbars when they are inside or outside the container's size minus the v and h scrollbar's size.


### Steps to reproduce

open the project and mess with the custom editor's scene's panel container.
you can also try to get it to work by messing with the theme resource but its not possible.

### Minimal reproduction project

[MazeyGame.zip](https://github.com/godotengine/godot/files/7049179/MazeyGame.zip)
Repository: PowerToys
Issue: Temporarily Maximize a window
Labels: Idea-New PowerToy

### Description of the new feature / enhancement

Sometimes we want to have a brief view of a window in full screen maybe because the window is opened but using a little portion of the screen. 
 Could be a good feature to temporarily maximize an opened window. While holding the window key + taping the maximize button and always holding the windows key to keep the maximize view mode active. 
The purpose is keeping the app window maximized while holding the window key held. 

### Scenario when this would be used?

![Screenshot (143)](https://user-images.githubusercontent.com/80002830/130727688-59840574-ca4c-4a21-828f-909cdb0520d5.png)
Maximize a window while the window key is held. 

### Supporting information

_No response_
Repository: pytorch
Issue: [Poll] Support higher-order gradient computation in DDP
Labels: oncall: distributed,module: c10d,module: ddp

## 🚀 Feature
Computing higher-order gradients has several use cases, i.e. applying a local gradient penalty before running the backwards pass. However, DDP doesn't have great support for higher-order gradients as evidenced by https://github.com/pytorch/pytorch/issues/63812. A couple of issues:
1. `.grad` field of the gradient is not synchronized across processes
2. Calling `.backward()` twice is not well supported: https://github.com/pytorch/pytorch/issues/63812#issuecomment-904939795, as it will cause issues in DDP's internal state
3. Leaf grads accumulated by DDP don't have proper autograd recording, i.e. the allreduce is unknown to autograd and therefore we cannot differentiate through it.

If your use case requires DDP to work with higher-order gradients, please ping this issue with some details about your use case. Thanks!

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @agolynski @SciPioneer @H-Huang @mrzzd @cbalioglu @gcramer23
Repository: flutter
Issue: gifs can cause jank and high cpu usage 
Labels: engine,c: performance,a: images,perf: speed,perf: energy,has reproducible steps,P2,found in release: 2.2,found in release: 2.5,team-engine,triaged-engine

[✓] Flutter (Channel stable, 2.2.3, on macOS 11.5.2 20G95 darwin-x64, locale zh-Hans-CN)
    • Flutter version 2.2.3 at *
    • Framework revision f4abaa0735 (8 weeks ago), 2021-07-01 12:46:11 -0700
    • Engine revision 241c87ad80
    • Dart version 2.13.4

When a page contains gifs, there are serious performance issues

When gif is used:
<img width="1833" alt="138B4A7C-C38B-4442-A210-7A0DB3133436" src="https://user-images.githubusercontent.com/10491688/130737564-dbdd8a41-ff09-4562-b0b5-71d7c0cc2229.png">

When gif is not used:
<img width="1860" alt="B2788268-12F5-4465-AA2B-08AD51978BEB" src="https://user-images.githubusercontent.com/10491688/130737851-0101467f-04b2-4042-84d9-1766a72494aa.png">
Repository: node
Issue: V8 (9.5) has split the `v8.h` header
Labels: v8 engine

See https://github.com/v8/v8/commit/ec06bb6ce5641cf65e400ec55b7421f87d04b999

It shouldn't directly impact the Node.js build because `v8.h` is still here and includes everything it had before, but at least https://github.com/nodejs/node/blob/master/tools/install.py will have to be changed.
Repository: pytorch
Issue: Inconsistent behaviour of index put when assigning from other type
Labels: triaged,module: type promotion,module: advanced indexing

## 🐛 Bug

When assigning to a tensor data from another type. E.g. to a float tensor from a double tensor the bahaviour differs depending on how the tensor is indexed. 

## To Reproduce
import torch
x = torch.zeros((3,3,3), dtype=torch.float32)
y = torch.tensor(5, dtype=torch.float64)

- This is ok
x[:,:,1] = y

- This is not
x[[0,1,2],:,1]=y

- In the second case one has to convert y to float32, so this is ok:
x[[0,1,2],:,1]=y.to(torch.float32)

## Error message

Traceback (most recent call last):
  File "<input>", line 1, in <module>
RuntimeError: Index put requires the source and destination dtypes match, got Float for the destination and Double for the source.

## Environment
PyTorch version: 1.9.0+cu111
Is debug build: False
CUDA used to build PyTorch: 11.1
ROCM used to build PyTorch: N/A

OS: Microsoft Windows 10 Education
GCC version: Could not collect
Clang version: Could not collect
CMake version: Could not collect
Libc version: N/A

Python version: 3.9.6 (tags/v3.9.6:db3ff76, Jun 28 2021, 15:26:21) [MSC v.1929 64 bit (AMD64)] (64-bit runtime)
Python platform: Windows-10-10.0.18363-SP0
Is CUDA available: True
CUDA runtime version: 11.3.109
GPU models and configuration: GPU 0: NVIDIA GeForce GTX 1650 with Max-Q Design
Nvidia driver version: 466.63
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.21.2
[pip3] torch==1.9.0+cu111
[pip3] torchaudio==0.9.0
[pip3] torchvision==0.10.0+cu111
[conda] Could not collect

## Additional context
The issue is present in libtorch also. 


cc @nairbv @mruberry
Repository: vscode
Issue: Editor resolver: untyped `editorGroupFinder#findGroup` causes issues
Labels: debt,workbench-editor-resolver

We are currently calling `editorGroupFinder.findGroup` with untyped inputs, but this is problematic: because some of the logic within requires the editor type to be known to do proper `matches` and `contains` checks. Since the untyped editor doesn't know the `override` before being resolved, I had to add the following ugly workaround:

https://github.com/microsoft/vscode/blob/e4ac631e9dbf0aa93a4371c4f5f3b8dc43422afb/src/vs/workbench/services/editor/common/editorGroupFinder.ts#L205-L205

I would hope that we could possibly stop calling `findGroup` with untyped inputs to address this? How is the group being used in the resolver service given it resolves it again with the typed editor?
Repository: PowerToys
Issue: Single key remap not working
Labels: Issue-Bug,Product-Keyboard Shortcut Manager,Area-App Compat

### Microsoft PowerToys version

0.43.0

### Running as admin

- [X] Yes

### Area(s) with issue?

Keyboard Manager

### Steps to reproduce

Create a remap as:

![image](https://user-images.githubusercontent.com/7273862/130766245-994dcf81-1da5-4335-9d1b-a702db04688f.png)


```json
{
  "remapKeys": {
    "inProcess": [
      {
        "originalKeys": "222",
        "newRemapKeys": "220"
      }
    ]
  },
  "remapShortcuts": {
    "global": [
      {
        "originalKeys": "160;50",
        "newRemapKeys": "160;192"
      },
      {
        "originalKeys": "160;192",
        "newRemapKeys": "160;50"
      },
      {
        "originalKeys": "160;222",
        "newRemapKeys": "160;220"
      },
      {
        "originalKeys": "160;223",
        "newRemapKeys": "160;222"
      },
      {
        "originalKeys": "164;51",
        "newRemapKeys": "222"
      }
    ],
    "appSpecific": [
    ]
  }
}
```

For information this is being used on a MacBook Pro keyboard, the MacBook is running macOS and then connected to another machine running Windows via Sharemouse.

All the shortcut remaps work fine as expected, however the single remapped key does not work

### ✔️ Expected Behavior

The correct character should be printed when pressing the mapped key

### ❌ Actual Behavior

The key is still printing the original character

### Other Software

MacBook Pro running macOS 11.5.2
Using Sharemouse to connect to a Windows machine
Windows 10