sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: neovim
Issue: libnvim: in-process C API/ABI/FFI
Labels: enhancement,build,api

### Problem

Nvim C API is not officially supported. (However, our cmake definition has a `libnvim` target, which is used by e.g. VimR)

### Expected behavior

1. Decide which C types our C interface will use. Do we need to avoid structs?
2. Provide `*.h` headers for consumers include.
3. Declare `SONAME`
4. Document ABI (not API) contract. (+test coverage)
5. Document the correct usage of `libnvim`

### Open questions

- extra considerations for UIs that want to embed `libnvim` ? #2034
    - current process for UIs embedding Nvim in-process is: link to `libnvim` and speak msgpack to it (same as out-of-process UI).
- via @dundargoc  :
  >  libnvim. Does it need explicitly need to be a static library? Couldn't we just not set the type?
  > Apparently you're not supposed to specify if a library is meant to be static or shared anyway so outside projects can choose what type of library they want to use.

### Related

- https://flameeyes.blog/2012/03/07/why-foreign-function-interfaces-are-not-an-easy-answer/
    - > example: moving from `uint32_t` to `uint64_t` for the parameters of a function: ... such a change in the C ABI would make the change incompatible, as the size of the parameters on the stack doubled.
- https://flameeyes.blog/2010/10/08/linkers-and-names/
    - > neither the link editor nor the loader have a real concept of “ABI version”, which is why they don’t enforce it at all
Repository: neovim
Issue: defaults: change eob (end-of-buffer) from tilde "~" to "middle dot"
Labels: enhancement,defaults,complexity:low

# Problem

- The "~" eob fillchar looks very dated.
    - Counterargument: it's distinctive to Vim, familiar, and extremely iconic.
        - Counter-counterargument: Nvim's default UI needs its own subtle distinctiveness.

related https://github.com/neovim/neovim/issues/19354

# Expected behavior

- Use "middle dot" char instead of `~`. 
  ```
  set fillchars+=eob:·
  ```
    - [Fallback](https://github.com/neovim/neovim/pull/21710#issuecomment-1376502358) to `~` if char2cells() != 1.
- Default colorscheme  `EndOfBuffer` should differ from `Whitespace`.

## Notes

- After using it for awhile myself, it doesn't feel garish or overwrought. It feels appropriate: it's a way to give a visual signal without demanding attention.
- The "middle dot" char is already used for Nvim folds, so there's symmetry/precedent.
- It feels heretical, which usually means we should do it.

Compare before/after:

<img width="287" alt="image" src="https://user-images.githubusercontent.com/1359421/211220368-6a0133af-46c8-4032-a00f-4dd250aef18f.png">

## Alternatives

- ~~vertical ellipsis: ⋮~~ not subtle enough
-
Repository: neovim
Issue: search and replace locks up neovim on big files
Labels: bug,performance,marks

### Describe the bug

If you open a big text file, searching and replacing in a file can lock neovim up completely. 

### Steps to reproduce

- Download zip archive under https://www3.stats.govt.nz/2018census/Age-sex-by-ethnic-group-grouped-total-responses-census-usually-resident-population-counts-2006-2013-2018-Censuses-RC-TA-SA2-DHB.zip
- unpack Data8277.csv (857 MB)
- nvim -u NONE Data8277.csv
- :%s/20/30

### Expected behavior

Neovim instance will ramp up memory usage up to 5 GB over several minutes but will never finish. 
Vim manages to do the replacement above in ~13 sec.

### Neovim version (nvim -v)

0.8.2

### Vim (not Nvim) behaves the same?

no, as of vim 9.0.639

### Operating system/version

macOS 13.1

### Terminal name/version

iTerm2 3.5.0beta8

### $TERM environment variable

xterm-256color

### Installation

homebrew
Repository: godot
Issue: Export var init issue, e.g. "B".unicode_at(0), inspector shows wrong nr: 0
Labels: bug,topic:core,topic:gdscript,confirmed

### Godot version

v4.0.beta10.official [d0398f62f]

### System information

Windows 22H2, Compatibility, GeForce GTX 550 Ti

### Issue description

In 4.0.beta10, the inspector shows the wrong nr: 0
with the line:
```
@export var b = "B".unicode_at(0)
```

But the correct nr: 65 is printed when a project runs with:
```
func _ready():
	print("A".unicode_at(0))
```

It works as expected in: 3.5.1.stable
the inspector shows the correct nr: 66
with the line:
```
export var b = ord("B")
```
And running the project with:
```
func _ready() -> void:
	print(ord("A"))
```
prints the correct nr: 65


### Steps to reproduce

- start Godot
- open the attached project
- click on the Script button at the top of Godot

### Expected

In 4.0.beta10, with the line:
```
@export var b = "B".unicode_at(0)
```
the inspector should show nr: 66

Just like it does in 3.5.1.stable, with the line:
```
export var b = ord("B")
```
the inspector shows the expected nr: 66

### Observed

In 4.0.beta10, with the line:
```
@export var b = "B".unicode_at(0)
```
the inspector shows the wrong nr: 0

The correct nr: 65 is printed when the project runs.
In 4.0.beta10:
```
func _ready():
	print("A".unicode_at(0))
```
And in 3.5.1.stable:
```
func _ready() -> void:
	print(ord("A"))
```

### Minimal reproduction project

[issue, 4.0.beta10, export, char to int.zip](https://github.com/godotengine/godot/files/10369668/issue.4.0.beta10.export.char.to.int.zip)

[3.5.1.stable, export, char to int.zip](https://github.com/godotengine/godot/files/10369669/3.5.1.stable.export.char.to.int.zip)
Repository: pytorch
Issue: torch.Categorical samples indexes with 0 probability when given logits as argument
Labels: module: distributions,triaged

### 🐛 Describe the bug
`torch.distributions.Categorical` samples indexes with 0 probability when given logits as argument.

## To reproduce

```python
import torch
from torch.distributions import Categorical

logits = torch.ones((1_000_000, 500))
logits[:, 1:] = -1e5 
probs = Categorical(logits=logits)

sample = probs.sample()
torch.sum(sample > 0)
```

### Expected behaviour
The sum should be 0, because probs.sample() should only extract the index 0, because the other logits are $-10^5$ while the logit for the index 0 is 1

### Versions

[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.21.5
[pip3] numpydoc==1.4.0
[pip3] torch==2.0.0.dev20230105
[pip3] torchaudio==2.0.0.dev20230105
[pip3] torchvision==0.15.0.dev20230105
[conda] blas                      1.0                         mkl
[conda] cpuonly                   2.0                           0    pytorch-nightly
[conda] mkl                       2021.4.0           haa95532_640
[conda] mkl-service               2.4.0            py39h2bbff1b_0
[conda] mkl_fft                   1.3.1            py39h277e83a_0
[conda] mkl_random                1.2.2            py39hf11a4ad_0
[conda] numpy                     1.21.5           py39h7a0a035_3
[conda] numpy-base                1.21.5           py39hca35cd5_3
[conda] numpydoc                  1.4.0            py39haa95532_0
[conda] pytorch                   2.0.0.dev20230105     py3.9_cpu_0    pytorch-nightly
[conda] pytorch-mutex             1.0                         cpu    pytorch
[conda] torchaudio                2.0.0.dev20230105        py39_cpu    pytorch-nightly
[conda] torchvision               0.15.0.dev20230105        py39_cpu    pytorch-nightly

cc @fritzo @neerajprad @alicanb @nikitaved
Repository: rust
Issue: LTO produces worse codegen for a loop
Labels: A-LLVM,I-slow,T-compiler

I was recently talking to someone who was having trouble with understanding the performance of this function (yes this could theoretically be optimized to a memset):
```rust
pub fn build(weights: &[u32]) -> Vec<u32> {
    let mut cdf = Vec::with_capacity(weights.len() + 1);
    unsafe {
        *cdf.get_unchecked_mut(0) = 0;
    }

    for (i, weight) in weights.iter().enumerate() {
        unsafe {
            *cdf.get_unchecked_mut(i + 1) = cdf.get_unchecked(i) + *weight;
        }
    }

    unsafe {
        cdf.set_len(weights.len() + 1);
    }

    cdf
}
```
I eventually narrowed this down to some kind of instability related to codegen of the inner loop. With the default release profile I see this in `perf annotate`:
```
       │b0:┌─→add    (%r14,%rsi,1),%edx
 34.95 │   │  mov    %edx,0x4(%rax,%rsi,1)
 65.05 │   │  add    $0x4,%rsi
       │   ├──cmp    %rsi,%rbx
       │   └──jne    b0
```
Which seems fine. But then another person (trying to be helpful) suggests turning on LTO and the inner loop now becomes this:
```
       │b0:┌─→add  (%rbx),%edx
 36.45 │   │  add  $0x4,%rbx
  0.77 │   │  mov  %edx,(%rcx)
 61.32 │   │  add  $0x4,%rcx
  0.29 │   ├──cmp  %rax,%rbx
  1.17 │   └──jne  b0
```
Which benchmarks significantly slower.


```
rustc 1.66.0 (69f9c33d7 2022-12-12)
binary: rustc
commit-hash: 69f9c33d71c871fc16ac445211281c6e7a340943
commit-date: 2022-12-12
host: x86_64-unknown-linux-gnu
release: 1.66.0
LLVM version: 15.0.2
```

@rustbot label +A-llvm +I-slow
Repository: vscode
Issue: SCM - Reveal Active File in Git View
Labels: help wanted,feature-request,scm

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->

It would be wonderful if there is a command to `Reveal Active File in Git View`, much like the `Reveal Active File in Explorer View`. I don't think this needs much explanation. 🤣

It should jump right to the Git repo + bring the active file into view or highlight it.
Repository: tauri
Issue: [feat] Add support for custom WiX toolkit installation URL
Labels: type: feature request

### Describe the problem

The current version of WiX that's automatically downloaded doesn't allow for the creation of installers that work on ARM64 Windows devices. That functionality was introduced in a [development build of WiX](https://wixtoolset.org/docs/v3/releases/v3-14-0-6526/).

### Describe the solution you'd like

Currently the URL used to download WiX is hardcoded, but it would be nice if Tauri also checked for the presence of a `WIX_TOOLKIT_URL` environment variable that took precedence over the built-in value. This would allow users who want an ARM64 installer to manually configure their build with a version of WiX that supports ARM64.

### Alternatives considered

I'm aware that v2 is moving to NSIS in lieu of WiX, but I don't expect that to be backported to v1 (or available in the immediate future). Also I don't think Tauri should **default** to the v3.14 version since as I understand it, it introduced breaking changes. Speaking of, I'm also assuming that upgrading to WiX v4 is a significant undertaking, so that's not an option either.

### Additional context

I'd be more than happy to put this PR together. I just wanted to file an issue first so I could solicit feedback!
Repository: stable-diffusion-webui
Issue: [Feature Request]: Add color loss selection in txt2image
Labels: enhancement

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What would your feature do ?

Hi all, I've been OBSESSED with the idea of color constraining the output of Stable Diffusion models. I'm aware of some stuff which partially implements my vision here, namely the current color-sketch tool which was merged https://github.com/AUTOMATIC1111/stable-diffusion-webui/pull/4459

I believe there are at least 3 distinct ways to implement some kind of "color control" within diffusion models.

1. Use color-sketch in-painting / text2img to pre-color the image to be diffused, which should encourage (but not guarantee) the shaded regions have the specified color. 

2. Modify the loss function of the final step to encourage the model to generate colors for particular pixels

3. Add some kind of "filter" to the final diffusion step, banning the diffusion model from diffusing pixels which fall outside of a given RGB color range. I actually wrote about this idea already in the future work of my paper about doing a highly similar technique in transformer language models for generating lipogrammic text (see future work section of here: https://aclanthology.org/2022.cai-1.2/). This is equivalent to "limiting" its vocabulary, but instead of it having a vocabulary of tokenized text, it has a vocabulary of all possibly rgb values for each pixel

There is already a tool for some kind of color control this, implementing 1 within this webui. However, this tool only works for in-painting (and not the main txt2image) and I also believe that this technique is somewhat inferior to 2, and especially 3 because I believe that the model can and will ignore the given colors depending on the prompt. 

I ran across a really neat notebook which demonstrates a unique way to modify the loss function used during diffusion (2). This enables fine-grained color control of the image.  The original notebook is here: https://colab.research.google.com/drive/1dlgggNa5Mz8sEAGU0wFCHhGLFooW_pf1?usp=sharing (see the bottom). I have modified this notebook to include a more sophisticated example where a user can specify (in code) bounding box locations, the rgb channel they want to modify, and the value they want to modify it with. This modified notebook is located here: https://colab.research.google.com/drive/18Kl1DndYEQOlKg9yP3uuNwRHajKqHBkh?usp=sharing

My ideal solution for this is 3, but I'm pretty ignorant about how I'd implement this given the code that I've seen. Certainly more involved than it was for NLP transformer models. 


### Proposed workflow

1. Go to the main txt2image default panel
2. Have a tool similar to the gradio color selection tool which a user can draw on the blank canvas with
3. Have an "intensity" slider to allow users to decide how much they want the custom loss to impact their image. 


### Additional information

_No response_
Repository: go
Issue: net: DialTimeout is not able to connect when /etc/resolv.conf has some unreachable nameservers at the top 
Labels: NeedsInvestigation

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What version of Go are you using (`go version`)?

<pre>
(oath_tools) N9N7C9PNWP:hca palakas$ go version
go version go1.19.4 darwin/arm64
(oath_tools) N9N7C9PNWP:hca palakas$

</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><br><pre>
$ go env

</pre></details>

### What did you do?

We have a small helper function like this:

```
// dial attempts to open a tcp connection to the host:port address with a 3 second timeout
func dial(host string, port int) error {
	conn, err := net.DialTimeout("tcp", fmt.Sprintf("%s:%d", host, port), time.Second*3)
	if err == nil {
		conn.Close()
		return nil
	}

	return err
}
```

This function gets the error "dial tcp: lookup zts.athens.yahoo.com: i/o timeout", when /etc/resolv.conf has nameservers that are not reachable at the top. 

For ex: 

```
[palakas@a26074b9 ~]$ cat /etc/resolv.conf
; Created by cloud-init on instance boot automatically, do not edit.
;
nameserver 98.136.206.44
nameserver 98.136.206.45
nameserver 98.136.206.41
nameserver 98.136.206.42
[palakas@a26074b9 ~]$ telnet 98.136.206.44 53
Trying 98.136.206.44...
^C
[palakas@a26074b9 ~]$ telnet 98.136.206.45 53
Trying 98.136.206.45...
^C
[palakas@a26074b9 ~]$ telnet 98.136.206.41 53
Trying 98.136.206.41...
Connected to 98.136.206.41.
Escape character is '^]'.
^C^]

telnet> quit
Connection closed.
[palakas@a26074b9 ~]$ nslookup www.yahoo.com
Server:		98.136.206.41
Address:	98.136.206.41#53

www.yahoo.com	canonical name = new-fp-shed.wg1.b.yahoo.com.
Name:	new-fp-shed.wg1.b.yahoo.com
Address: 98.137.11.165
Name:	new-fp-shed.wg1.b.yahoo.com
Address: 2001:4998:24:120d::f000

[palakas@a26074b9 ~]$
```


### What did you expect to see?
Go resolver code to continue to try a nameserver that is reachable and pick up the answer. For example, nslookup or dig don't have any issue in resolving the names when an unreachable nameserver is at the top in /etc/resolve.conf


### What did you see instead?

We are getting at timeout, possibly after trying the nameservers that are not reachable.
Repository: opencv
Issue: Implement `div` method for CV::Vec
Labels: feature,category: core

### Descripe the feature and motivation

I've noticed that cv::Vec does not inherit `div` method properly, or at least when used it returns a `Matx<_Tp,cn,1> `result, that makes it an incompatible cast to a `cv::Vec` declaration, as for example:

`
cv::Vec2d vec1(1,1), vec2(1,1);
cv::Vec2d res = vec1.div(vec2);
`

The same does not happen with `mul` operation. It works fine. It would be useful to have `div` implementation as well.

### Additional context

Please, refer [here](https://stackoverflow.com/q/75050990/5321862)  for deeper detail
Repository: PowerToys
Issue: Windows Virtual Desktop Helper Integration
Labels: Needs-Triage

### Description of the new feature / enhancement

It would be cool, if Powertoys could integrate the Windows Virtual Desktop Helper tool at https://github.com/dankrusi/WindowsVirtualDesktopHelper

### Scenario when this would be used?

This would optimize switching between multiple Windows Virtual Desktops

### Supporting information

_No response_
Repository: vscode
Issue: Perf: Tasks problem matcher and JSON schemas block startup
Labels: tasks,debt,perf-startup

Noticed how tasks eager creation of problem matcher and JSON schema parsing contributes to a slower startup because all of this seems to happen eager as part of the module. I wonder if we can delay this until needed.

Refs:
* https://github.com/microsoft/vscode/blob/eaa9b1b70eaad291980a3e74d1748ca7d9bbd195/src/vs/workbench/contrib/tasks/common/problemMatcher.ts#L1400
* https://github.com/microsoft/vscode/blob/eaa9b1b70eaad291980a3e74d1748ca7d9bbd195/src/vs/workbench/contrib/tasks/common/jsonSchema_v1.ts#L104
* https://github.com/microsoft/vscode/blob/eaa9b1b70eaad291980a3e74d1748ca7d9bbd195/src/vs/workbench/contrib/tasks/common/jsonSchema_v2.ts#L648

![problem-matcher](https://user-images.githubusercontent.com/900690/211263628-76c83940-8f13-4f50-8dfd-cc5285706f42.png)

![json-schema](https://user-images.githubusercontent.com/900690/211263635-4db2de3a-9798-4c47-9c01-b312820ce742.png)

The following profile:
* was taken on Windows
* with a non-minified / non-mangled build to aid reading
* has the `ellapsed` event at `6755ms`

[prof-QIBV4was.main.zip](https://github.com/microsoft/vscode/files/10371380/prof-QIBV4was.main.zip)

cc @jrieken
Repository: go
Issue: net/http: http.response not flushing body after writing 1XX headers when client has header Expect: 100-continue
Labels: NeedsInvestigation

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.19.4 darwin/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><br><pre>
$ go env
Not relevant
</pre></details>

### What did you do?

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on go.dev/play is best.
-->

```
func runServer() {
	panic(http.ListenAndServe(":80", http.HandlerFunc(func(writer http.ResponseWriter, request *http.Request) {
		_, _ = io.Copy(io.Discard, request.Body)
		writer.WriteHeader(100)
		writer.WriteHeader(201)
		_, _ = io.WriteString(writer, "CREATED")
	})))
}

func Test100Http(t *testing.T) {
	go runServer()
	time.Sleep(time.Second)
	conn, _ := net.Dial("tcp", "127.0.0.1:80")
	file, _ := os.Open("/tmp/go1.20rc2.src.tar.gz")
	req, _ := http.NewRequest(http.MethodPut, "http://127.0.0.1/go.tar.gz", file)
	req.Header.Set("Expect", "100-continue")
	_ = req.Write(conn)
	_, _ = io.Copy(os.Stdout, conn)
}
```

### What did you expect to see?

output

```
HTTP/1.1 100 Continue

HTTP/1.1 100 Continue

HTTP/1.1 201 Created
Date: Mon, 09 Jan 2023 09:00:36 GMT
Content-Length: 7
Content-Type: text/plain; charset=utf-8

CREATED
```


### What did you see instead?

The program hangs with the following output

```
HTTP/1.1 100 Continue

HTTP/1.1 100 Continue

HTTP/1.1 201 Created
Date: Mon, 09 Jan 2023 09:00:36 GMT
Content-Length: 7
Content-Type: text/plain; charset=utf-8
```

notice response body is not written `CREATED`

### Additional Info

This problem was first discovered when [a caddy user find his webdav server not longer works when he upgraded caddy version](https://caddy.community/t/caddy-2-6-x-stop-webdav-client-to-finish-uploading/17975). Caddy is using a heavily modified reverse_proxy handler from stdlib and merged [1xx status codes](https://github.com/caddyserver/caddy/commit/085df25c7e82b5bdd198787232d559f2ac1e72eb) which was backported from [53164](https://github.com/golang/go/pull/53164).

After some digging in [caddy](https://github.com/caddyserver/caddy/issues/5280), I determined it's a problem with golang http. The handler is a reduced version of caddy reverse_proxy which forwards 1XX from backend. And the example file is small 25MB, using large files like 134MB will produce the correct output.
Repository: godot
Issue: .NET 6 C# - ScriptPropertiesGenerator fail with overridden initialized property on master
Labels: bug,topic:dotnet,regression

### Godot version

v4.0.beta.mono.custom_build [56522f7f8] (with double)

### System information

Arch Linux, Vulkan

### Issue description

C# projects with a parent class including a virtual property that is then overridden & initialized in a child class appear to cause ScriptPropertiesGenerator & ScriptSerializationGenerator to fail to generate source.

The problem appears to be caused by #70483, the Source Generators run fine if built immediately before this PR was committed.
I'm not sure how to debug the Source Generators for a more useful error/stack trace than below, sorry.

### Parent Class

```cs
using Godot;
public partial class TestParentClass : RigidBody3D
{
    public virtual int NodeType { get; set; } = 1;
}
```

### Child Class

If the initialized property override below is commented then the Source Generators work fine.

```cs
public partial class TestChildClass : TestParentClass
{
    public override int NodeType => 10;
}
```

## Warnings/Errors produced

Warnings produced when a child class overrides the initialized property from its parent:
```
0>CSC: Warning CS8785 : Generator 'ScriptPropertiesGenerator' failed to generate source. It will not contribute to the output and compilation errors may occur as a result. Exception was of type 'NullReferenceException' with message 'Object reference not set to an instance of an object.'
0>CSC: Warning CS8785 : Generator 'ScriptSerializationGenerator' failed to generate source. It will not contribute to the output and compilation errors may occur as a result. Exception was of type 'NullReferenceException' with message 'Object reference not set to an instance of an object.'
```

Any `[Export]` properties then throw build errors as ScriptPropertiesGenerator failed:
```
0>csharpbug_03c26d6/Godot.SourceGenerators/Godot.SourceGenerators.ScriptPropertyDefValGenerator/Nothing_ScriptPropertyDefVal.generated.cs(9,33): Error CS0117 : 'Node.PropertyName' does not contain a definition for 'TestInt'
0>csharpbug_03c26d6/Godot.SourceGenerators/Godot.SourceGenerators.ScriptPropertyDefValGenerator/Nothing_ScriptPropertyDefVal.generated.cs(11,33): Error CS0117 : 'Node.PropertyName' does not contain a definition for 'TestFloat'
```

### Steps to reproduce

Build the solution in the minimal reproduction project.

### Minimal reproduction project

[csharpbug_03c26d6.zip](https://github.com/godotengine/godot/files/10371960/csharpbug_03c26d6.zip)