sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: In ItemList, the text and icon don't have margin and is even rendered outside their row Rect.
Labels: bug,topic:gui

Found similar but not same issue with ItemList.

**Godot version:**
<!-- Specify commit hash if non-official. -->
Latest at this time master https://github.com/godotengine/godot/commit/ca084db4aa6d5da8f34fc889d70f1b8e46990b82.

**OS/device including version:**
<!-- Specify GPU model and drivers if graphics-related. -->
Windows 10 1903

**Issue description:**
<!-- What happened, and what was expected. -->
The text and label don't have margin and is even rendered outside their row Rect. 
![Capture46](https://user-images.githubusercontent.com/11459028/60112228-0d402000-978d-11e9-8b89-8eca654988da.PNG)
![Capture47](https://user-images.githubusercontent.com/11459028/60112233-103b1080-978d-11e9-8704-d80b28049ba0.PNG)
Left ItemList is in ICON_MODE_LEFT;  Right ItemList2 is in ICON_MODE_TOP.
Code:
```
var item_list : ItemList = $ItemList
item_list.icon_mode = ItemList.ICON_MODE_LEFT
item_list.add_icon_item(a)
item_list.add_item("Hi",a)
item_list.add_item("Hi")
item_list.add_icon_item(a)
var item_list2 : ItemList = $ItemList2
item_list2.icon_mode = ItemList.ICON_MODE_TOP
item_list2.add_icon_item(a)
item_list2.add_item("Hi",a)
item_list2.add_item("Hi")
item_list2.add_icon_item(a)
```


**Steps to reproduce:**
Run minimal project or add items to ItemList using add_item or add_icon_item.

**Minimal reproduction project:**
<!-- Recommended as it greatly speeds up debugging. Drag and drop a zip archive to upload it. -->
[tests.zip](https://github.com/godotengine/godot/files/3326049/tests.zip)
Repository: react
Issue: getDerivedStateFromError for Control Flow
Labels: Type: Feature Request,Component: Reconciler,React Core Team

Spinoff from https://github.com/facebook/react/pull/15797#issuecomment-504782329.

We might want to offer a way to "bubble" control flow up the tree a la Algebraic Effects. `throw Redirect()` is a canonical example. However, we want them to bypass the normal error boundaries. So it probably needs to be a first-class API.
Repository: react
Issue: Collapsible Error Dialogs for the Ecosystem
Labels: Type: Feature Request,Component: Developer Tools,React Core Team

Spinoff from https://github.com/facebook/react/pull/15797#issuecomment-504782329.

Both in React Native and Create React App, redboxes are full screen. But in React, most errors are recoverable. Even with accidental runtime crashes it's useful to look "underneath" to see whether your boundary worked as expected, and to have an idea of the end user experience.

We could solve this with a collapsed-by-default floating error panel that just shows a list of messages. You can click to expand. We could also use this as an opportunity to unify the RN and web designs.
Repository: flutter
Issue: iOS platform view clip path: Find a better approximate for conic path
Labels: platform-ios,engine,a: platform-views,P2,a: plugins,team-ios,triaged-ios

In current PlatformView clipping behavior, clipPath is not completely accurate when the path is a `conic path`. For example [conicTo](https://api.skia.org/classSkPath.html#a9edc41978765cfe9a0b16e9ecf4d276e)

Quartz doesn't support `conic path`. We currently uses quad to approximate conic. This is inaccurate when the weight value is far away from 1. eg. weight = 0.1 or weight = 2. 

We need to find a better way to approximate conic path using quartz.

To reproduce:
1. Add a clipPath with conic path widget on top of any PlatformView widget, with a large weight (e.g. weight = 2)
2. Add the same clipPath to a container widget that has the same size with the PlatformView widget.
3. See the visual difference.
Repository: flutter
Issue: TextField maxLines should be a double, not an int.
Labels: a: text input,c: new feature,framework,f: material design,good first issue,P3,team-design,triaged-design

We need to be able to define a fractional maximum number of lines for a TextField. When using an integer number of lines, and there is a lot of text, the user will only see a few of the lines and may think that there are no more.

On the contrary, if you define, say 5.5 lines, and there are in fact, say, 10 lines, the user immediately notices that there is more text to the bottom. In other words, half-lines are visual cues to the users that they are able to scroll to see the rest. 

It's a **small change** that **improves usability**. To be consistent, I would make minLines also double, although in terms of usability that one is probably not important.

This is NOT a breaking change, and preserves existing maxLines behavior. 

Note: I'm the author of https://github.com/flutter/flutter/issues/19105 which was fixed by https://github.com/flutter/flutter/pull/27205
Repository: terminal
Issue: Add a "tab busy indicator" to show when a tab has belled or has output
Labels: Issue-Feature,Area-UserInterface,Product-Terminal

# Summary of the new feature/enhancement

if something output to tab which no in view, give it a sign, mean something output in that tab, but you no watch it, has below

![1](https://user-images.githubusercontent.com/983106/60125055-8bb4b600-97bd-11e9-8283-123f05807d29.png)

green point and blue background mean tab which in your view, green point and white background mean tab no in your view and nothing output in that tab, exclamation mark and white background mean tab no in your view and something output in that tab

# Proposed technical implementation details (optional)

<!-- 
A clear and concise description of what you want to happen.
-->
Repository: pytorch
Issue: [doc] nn.Module.forward documentation unclear
Labels: module: docs,module: nn,triaged,enhancement

## 📚 Documentation

This note is totally unclear to me. What does it mean? I don't know what should be called afterward. The link doesn't point to a function, just to torch.nn.Module. 

![image](https://user-images.githubusercontent.com/44090/60126626-b6d3e100-978e-11e9-9d76-d7df1f7415dc.png)
Repository: go
Issue: encoding/json: memoize strings during decode
Labels: Proposal,Proposal-Accepted

Part of the motivation for #32593 is the observation in json-iterator/go#376 that when you json decode, many of the same strings appear over and over in the JSON and get copied and reconstructed in the result over and over as well. 

We do _not_ want to make the JSON coalesce all the allocated strings into one giant buffer, because then holding on to just one of them holds onto the entire thing.

But it might make sense to add to the decoder state a simple map[[]byte]string and remember which specific byte slices we've already converted to string and reuse those allocated strings instead of doing the same conversions again in a particular Decode or Unmarshal operation. 

It's unclear to me whether the map in a Decoder should persist between Decode operations. Probably? That will affect users who put Decoders in a pool or something like that, though. (Solution: don't put decoders in pools.)
Repository: flutter
Issue: Pure Flutter support for Native Ads Advanced
Labels: c: new feature,package,team-ecosystem,P3,triaged-ecosystem

Split off #12114

Users would like to use Flutter widget for rendering AdMob [Native Ads Advanced](https://developers.google.com/admob/android/native/start) ads.

Note: Native Ads Advanced is only available to a limited set of approved app developers(publishers)
Repository: pytorch
Issue: [FYI] Introducing Quantized Tensor
Labels: module: docs,triaged

Hello everyone, here is an update about quantized Tensor, we are actively working on brining in more support for quantization in PyTorch, please stay tuned.
https://github.com/pytorch/pytorch/wiki/Introducing-Quantized-Tensor
Repository: godot
Issue: `inst2dict` does not work with objects having no script on them
Labels: bug,discussion,topic:core,confirmed

Godot 3.1.1

The following does not work:
```gdscript
var sprite = Sprite.new()
var d = inst2dict(sprite)
```
Error:
```
Error calling built-in function 'inst2dict': Not a script with an instance
```

Is there a reason why the object must have a script on it? Either way, if it's intented it should also be documented.
Repository: TypeScript
Issue: Type named capture groups better
Labels: Suggestion,Awaiting More Feedback

## Search Terms

named regexp, named capture groups

## Motivation

Currently named capture groups are a bit of a pain in TypeScript:
1. All names are of type string even if the regexp doesn't have that named group.
2. You need to use non-null assertion for `.groups` even when that is the only possibility.

## Suggestion

I propose making `RegExp` higher order on its named capture groups so that `.groups` is well typed.

```ts
// Would have type: RegExp<{ year: string, month: string }>
const date = /(?<year>[0-9]{4})-(?<month>[0-9]{2})/

const match = someString.match(date)
if (match) {
  // match.groups type would be { year: string, month: string }
  // currently is undefined | { [key: string]: string }
}

// Would have type RegExp<{ year: string, month?: string }>
const optionalMonth = /(?<year>[0-9]{4})(-(?<month>[0-9]{2}))?/
```

## Checklist

My suggestion meets these guidelines:

* [✓] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [✓] This wouldn't change the runtime behavior of existing JavaScript code
* [✓] This could be implemented without emitting different JS based on the types of the expressions
* [✓] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [✓] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).
Repository: pytorch
Issue: [libtorch] header warning suppression
Labels: triaged,module: build warnings

```
libtorch/include/c10/util/logging_is_not_google_glog.h:136:0: warning: "CHECK_GT" redefined
 #define CHECK_GT(val1, val2) CHECK_OP(val1, val2, >)

```

How to disable those header file warnings?
Repository: opencv
Issue: bug in videoio dshow access violation exception
Labels: category: videoio,incomplete,platform: win32,needs reproducer,needs investigation

- OpenCV => 4.1.0
- Operating System / Platform => Windows 7 64 Bit
- Compiler => Visual Studio 2017

my app crashed because of videoio, the call stack is 
VCRUNTIME140!MoveSmall  **line 430** f:\dd\vctools\crt\vcruntime\src\string\amd64\memcpy.asm

opencv_videoio410!SampleGrabberCallback::SampleCB
qedit!CSampleGrabber::Receive
qedit!CTransformInputPin::Receive
qedit!CBaseInputPin::ReceiveMultiple
qcap!COutputQueue::ThreadProc
qcap!COutputQueue::InitialThreadProc
kernel32!BaseThreadInitThunk
ntdll!RtlUserThreadStart

looking into opencv code
https://github.com/opencv/opencv/blob/master/modules/videoio/src/cap_dshow.cpp

        STDMETHODIMP SampleCB(double , IMediaSample *pSample){
        if(WaitForSingleObject(hEvent, 0) == WAIT_OBJECT_0) return S_OK;

        HRESULT hr = pSample->GetPointer(&ptrBuffer);

        if(hr == S_OK){
            latestBufferLength = pSample->GetActualDataLength();
              if(latestBufferLength == numBytes){
                EnterCriticalSection(&critSection);
                      memcpy(pixels, ptrBuffer, latestBufferLength); // I believe here it happens
                    newFrame    = true;
                    freezeCheck = 1;
                LeaveCriticalSection(&critSection);
                SetEvent(hEvent);
            }else{
                DebugPrintOut("ERROR: SampleCB() - buffer sizes do not match\n");
            }
        }

        return S_OK;
    }

I do not know when this method is called I guess while opening the camera stream, for now, It happened just once
Repository: PowerToys
Issue: Two Monitors screenshot picker
Labels: Idea-New PowerToy

Hello,

I have two Monitors and I want when I press screenshot to give me a picker to select 
Option 1: Screenshot for All Monitors 
Option 2: Screenshot for either Monitors 1, Monitors 2

Thanks
Repository: pytorch
Issue: using multi thread lead to gpu stuck with GPU-util 100%
Labels: high priority,needs reproduction,module: cuda,triaged,quansight-nack

I tried to  inference using multi thread, but gpu stuck with GPU-Util 100%.
The pytorch  was builded from source in branch v1.1.0.
But if i install the torch from pip or conda, the some code can work smoothly.
Is there ignore some import process in building?
I followed the guidance：
```
conda install numpy ninja pyyaml mkl mkl-include setuptools cmake cffi typing
conda install -c pytorch magma-cuda100
git clone --recursive --single-branch --branch v1.1.0 https://github.com/pytorch/pytorch.git
cd pytorch
git submodule sync
git submodule update --init --recursive
export CMAKE_PREFIX_PATH=${CONDA_PREFIX:-"$(dirname $(which conda))/../"}
python setup.py install
```




cc @ezyang @gchanan @zou3519 @ngimel
Repository: TypeScript
Issue: Dynamic import breaks global onError with requirejs
Labels: Needs Investigation

**TypeScript Version:**  3.2.2

**Search Terms:** dynamic import, requirejs, amd, onerror

**Code**

```ts
import('module').then(()=>{ /* some code*/ });
```
compiled to

```js
new Promise(function (resolve_1, reject_1) {
   require(['module'], resolve_1, reject_1);
});
```

If require are called with 3 arguments then require.onError is not fired. _Reject_ should be adeed only in case when we have a _catch_ call after _import_.


**Some propose:**
```ts
//@ts-import-no-reject
import('module').then(()=>{ /* some code*/ });
```
```js
new Promise(function (resolve_1) {
   require(['module'], resolve_1);
});
Repository: go
Issue: cmd/compile: debugger jumps around declarations
Labels: NeedsInvestigation,compiler/runtime

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version devel +9bf62783d2 Wed Jun 26 06:27:56 2019 +0000 windo
ws/amd64
</pre>

### Does this issue reproduce with the latest release?
Yes


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary>
<pre>
$ go env
set GO111MODULE=on
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\florin\AppData\Local\go-build
set GOENV=C:\Users\florin\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=D:\go
set GOPRIVATE=
set GOPROXY=direct
set GOROOT=C:\go-master
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\go-master\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=D:\go-samples\debugging\go.mod
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-m
ap=C:\Users\florin\AppData\Local\Temp\go-build286245954=/tmp/go-b
uild -gno-record-gcc-switches
</pre></details>

### What did you do?
- use the code at https://github.com/dlsniper/debugging/tree/0cf1692cb8518c1ec982c72d71064ffba1d0ed1c
- use Delve at version 79ad269
- run ` dlv debug main.go `
- invoke the following commands in Delve:
```
b main.go:38
c
n
n
n
n
n
n
```


### What did you expect to see?
I would expect the execution pointer to follow the code and step thru the structure construction as it's defined in the code.


### What did you see instead?
The execution pointer randomly jumps around, like in this video https://youtu.be/0FcDOg5ez4o (and it happens from command line as well as GoLand so it's not an implementation issue for the UI)
Repository: go
Issue: cmd/go/internal/modfetch: re-evaluate the undocumented proxy behavior in proxyRepo.latest()
Labels: Documentation,NeedsInvestigation,modules

Forked from the discussion during the review of https://golang.org/cl/183402

1) undocumented `/@v/list` format

[`proxyRepo.latest()`](https://github.com/golang/go/blob/19690053606dd14dedcf028bb37df79e3e33c003/src/cmd/go/internal/modfetch/proxy.go#L283) assumes `/@v/list` could return a list of version, commit timestamp pairs. This is not documented in the proxy protocol doc, and I am not sure if there is any proxy that's following this format. Please reject the undocumented format or document it.

One of the benefit of preserving this feature is, when this `proxyRepo.latest()` is invoked, the commit timestamp info here is more reliable than the timestamp parsed from the pseudo-version like version string and helps avoiding an extra `proxyRepo.Stat()` call.  On the other hand, the code path can be completely eliminated if proxies implement the `/@latest` endpoint, which is also not documented.

2) whether to include pseudo-versions or not in `/@v/list` 

The `proxyRepo.latest()` itself is also relying on part of undocumented behavior of `/@v/list`, which is supposed to include pseudo-versions. Before https://golang.org/cl/183402 (pre-1.13), we assumed it's not a good idea to include the pseudo versions in the `/@v/list` output and planned to include that in the proxy protocol spec.

https://go-review.googlesource.com/c/mod/+/176540/5/proxy/server.go#40

	// List returns a list of tagged versions of the module identified by path.
	// The versions should all be canonical semantic versions
	// and formatted in a text listing, one per line.
	// Pseudo-versions derived from untagged commits should be omitted.
	// The go command exposes this list in 'go list -m -versions' output
	// and also uses it to resolve wildcards like 'go get m@v1.2'.`

If the spec draft is valid, the `proxyRepo.latest()` implementation doesn't do anything but an extra network round trip for the proxies that follow the spec. If the go command can handle the list output including pseudo-versions, we may want to revisit the decision. 
 
So, I propose either
  1) tighten the spec to require the `/@latest` endpoint. Then, remove the code that leads to the `proxyRepo.latest()`, or
  2) relax the `/@v/list` format and allow pseudo versions in its output, and document it.

`Option 2)` implies more code to maintain on `cmd/go` side. `Option 1)` implies breakage of proxies that doesn't implement the `/@latest` endpoint.

p.s. having the go command's `proxyRepo.Versions` ensure not to return pseudo versions is  a good fix though.
Repository: create-react-app
Issue: Looking for a reference documentation to use CRA with (NWB) external modules in the same monorepo
Labels: issue: proposal

### Is your proposal related to a problem?

<!--
  Provide a clear and concise description of what the problem is.
  For example, "I'm always frustrated when..."
-->

Since monorepo support was reverted on v2 release, some of my projects are stuck in pre-release, which is not durable. I need a robust solution to share modules with all the CRA projects of the monorepo, in a dev-friendly way. Looking at CRA issues, it seems that i'm not alone in this situation.

### Describe the solution you'd like

<!--
  Provide a clear and concise description of what you want to happen.
-->

@Timer said in the [Completion roadmap for react-scripts@2.0](https://github.com/facebook/create-react-app/issues/5024) (5024 - 3) :
"_We're going to revert monorepo support in favor of consuming library packages via nwb and provide excellent documentation on how to do so. This is arguably the best way._"

This documentation would be so useful... Is this still planned?

(And really, thanks for this incredible and really useful work !)
Repository: go
Issue: api: document the purpose of and review process for next.txt
Labels: Documentation,NeedsInvestigation

@andybons sent me [CL 183919](https://golang.org/cl/183919) and I wasn't quite sure what to do with it:
* The diff from `api/next.txt` to `api/go1.13.txt` was not entirely trivial, but there were no visible failures on the build dashboard indicating any kind of skew (even for the symbols found in `next.txt` that were subsequently removed from the API).
* The final update to `go1.13.txt` goes through @golang/osp-team as part of the release process, but it's not obvious to me what kinds of problems we're supposed to look for.
* The last couple of CLs updating `api/next.txt` were sent between folks very central in the project, with very minimal descriptions and almost no visible discussion on the review thread.
* Some recent CLs have updated `api/next.txt` in the same CL as the API addition itself, but it's not obvious to me which CLs should do the API update simultaneously vs. saving or leaving the update for someone else to review later.

`api/README` doesn't clarify these points very much. Its description of the file is:
> `next.txt` is the only file intended to be mutated. It's a list of
features that may be added to the next version. It only affects
warning output from the `go` `api` tool.

We should expand the `README` file to more clearly describe the purpose and review process for `next.txt`.
Repository: node
Issue: http server respond with inappropriate default headers for `HEAD` method
Labels: help wanted,http

<!--
Thank you for reporting a possible bug in Node.js.

Please fill in as much of the template below as you can.

Version: output of `node -v`
Platform: output of `uname -a` (UNIX), or version and 32 or 64-bit (Windows)
Subsystem: if known, please specify the affected core module name

If possible, please provide code that demonstrates the problem, keeping it as
simple and free of external dependencies as you can.
-->

* **Version**: >= 10.x
* **Platform**: any
* **Subsystem**: http

<!-- Please provide more details below this comment. -->

To implement a HTTP keep alive mechanism, I use the `http.Agent({ keepAlive: true })` and `http.request({ agent, method, host, port })`.

Everything is ok when the method is `GET` or `TRACE` and others, the agent reuse the TCP connection as I expect.

But when changing the method to `HEAD`, the agent close the connection when server responded.

From the response header, the only different is that: for `HEAD` method, there isn't a `Content-Length: 0` or `Transfer-Encoding: chunked` in the default header (but `GET` has by default), so the HTTP parser think this connection should not be kept alive. 

But from the RFC, we can infer that if keep-alive was enabled, either `Content-Length: 0` or `Transfer-Encoding: chunked` should be setted in response header, I think this should be a default behavior.

```js
# server
const http = require("http")

const server = http.createServer((req, res) => {
  // res.setHeader("Content-Length", 0)
  // res.setHeader("Transfer-Encoding", "chunked")
  res.end()
})

server.keepAliveTimeout = 0
server.listen(2333, "x.x.x.x")
```

```js
# client
const http = require("http")

const agent = new http.Agent({
  keepAlive: true,
})

request = () => {
  const req = http.request({
    agent,
    host: "x.x.x.x",
    port: 2333,
    method: 'HEAD',
  })

  req.end()
}

request()
```
Repository: TypeScript
Issue: Language service OOM on lodash DT tests when batch compilation succeeds
Labels: Bug,Crash

Various CI runs on lodash for DefinitelyTyped confirm that batch compilation works fine, but certain language service operations OOM consistently, and the PR doesn’t look particularly costly. This makes me wonder if the language service is doing more work than necessary.

https://github.com/DefinitelyTyped/DefinitelyTyped/pull/36288

Benchmarking logs tell us exactly where the OOM happened, so we should be able to repro in VS Code by checking out `refs/pull/36288/merge` and requesting quick info and/or completions at one of the problem locations: https://dev.azure.com/definitelytyped/DefinitelyTyped/_build/results?buildId=6947