sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: cmd/vet: shadow false positive when using exported function
Labels: Analysis

`go tool vet --shadow` returns a false positive when the variable being shadowed is declared from the return of an exported user function from another package. That's a mouthful, so here's some code:

./other/other.go:

``` go
package other

func Foo() (int, error) {
    return 0, nil
}
```

./shadow_test.go:

``` go
package shadow

import (
    "errors"
    "testing"

    "github.com/tamird/shadow/other"
)

func foo() (int, error) {
    return 0, nil
}

func TestVetShadow(t *testing.T) {
    // Local varibles: this passes.
    // a, err := "a", errors.New("Foo")

    // Function from same package: this passes.
    // a, err := foo()

    // Function from standard library: this passes.
    // r := &bytes.Buffer{}
    // a, err := r.Read(nil)

    // Function from different package: this triggers shadowing warning.
    a, err := other.Foo()

    if err != nil {

    }

    if _, err := other.Foo(); err != nil {
    }

    b, err := "b", errors.New("Foo")
    if err != nil {
    }

    _, _ = a, b
}
```

The comments in the code describe the problem. Use `other.Foo()` and you get a false positive; use any of the others (local function, local variables, exported method from the stdlib) and the warning goes away. Weird!

All the code is also available here: https://github.com/tamird/shadow

cc @mberhault
Repository: rust
Issue: Move HashMap to liballoc
Labels: C-cleanup,E-mentor,A-collections,T-libs-api

This is blocked on https://github.com/rust-lang/rust/pull/26870
- [ ] Move FnvHasher from src/librustc/util/nodemap.rs to libcollections
- [ ] Expose FnvHasher as DeterministicState
- [ ] Move HashMap's implementation into libcollections defaulting to DeterministicState
- [ ] Unhardcode HashMap's constructors/methods from using RandomState (instead relying on default fallback)
- [ ] Re-export HashMap in std::collections as `pub type HashMap<K, V, S = RandomState> = core_collections::HashMap<K, V, S>`
- [ ] Do the same for HashSet
- [ ] Re-export DeterministicState in std as well (so we have a better answer to "HashMap is slow")
- [ ] Document the performance-stability/security tradeoff between DeterministicState and RandomState, and that users of the std facade will get a different default from direct users of libcollections (because RandomState requires OS rng to seed its state)

I am willing to mentor this if someone else wants to do it. 

Note that re-exporting HashMap may be the trickiest one; it's not clear to me that it's trivial, and may involve manually re-exporting everything in std::collections::hash_map to get the right behaviour (annoying and potentially fragile).


<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"clarfonthey"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: go
Issue: runtime: make panic dumps more readable
Labels: NeedsDecision,compiler/runtime

When a Go program panics, it dumps information on running goroutines, stack trace, error etc. But it's hard for humans to parse. In a terminal, which is where you're most likely to see panics as you're testing your program, the error message is the first line and you have to scroll to see it.

Python does this really well, as they should, since everything is a runtime "panic". The last line is the error message. Then there's a blank line, and then the stack trace in reverse order, so that the frame that had the error is the next line reading up. 95% of the time those last two lines are all you need to see to understand what's going wrong.

I'd like to see Go lay things out similarly, with the most important information at the bottom, and the least important at the top. It would make debugging Go programs in the terminal a little bit more pleasant. Again that would be the most common case for seeing a panic by far. Production panics are hopefully few and far between.
Repository: go
Issue: doc: document the way the tools work
Labels: Documentation,help wanted,NeedsFix

Nowhere is it explained how go build constructs software: how the compiler and linker run, where files are placed, how test builds its code, and so on. There should be an implementation and explanation document outlining this process. Such a document would also help someone who must use Go from within an existing software construction system.
Repository: java-design-patterns
Issue: Disruptor Pattern
Labels: info: help wanted,epic: pattern,type: feature

**Description:**
The Disruptor is a high-performance inter-thread messaging library. It provides a way to achieve high throughput and low latency in message processing systems. The main elements of the Disruptor pattern include:

1. **Ring Buffer:** A pre-allocated circular buffer that holds the data to be processed. The ring buffer is the core of the Disruptor, allowing for efficient memory allocation and access.
2. **Event Processors:** Components that consume events from the ring buffer. They can be set up in different configurations such as single, multiple, or parallel consumers.
3. **Sequencers:** Components that control the order of events being processed. They ensure that events are processed in the correct sequence and manage dependencies between different event processors.
4. **Producers:** Components that publish events to the ring buffer. Producers write data to the ring buffer, which is then consumed by the event processors.
5. **Wait Strategies:** Strategies that determine how consumers wait for events to be available in the ring buffer. Different strategies can be used to balance between CPU usage and latency.

**References:**
1. [Disruptor Pattern Wikipedia](https://en.wikipedia.org/wiki/Disruptor_(software))
2. [LMAX Disruptor: High Performance Inter-thread Messaging Library](https://lmax-exchange.github.io/disruptor/)
3. [Martin Fowler on LMAX Architecture](https://martinfowler.com/articles/lmax.html)

**Acceptance Criteria:**
1. Implement a ring buffer with configurable size to hold the events.
2. Develop event processors that consume events from the ring buffer, supporting different processing configurations.
3. Ensure proper sequencing of events using a sequencer component.
4. Implement producers that can publish events to the ring buffer efficiently.
5. Include at least one wait strategy for managing how consumers wait for events.

Please refer to the [project contribution guidelines](https://github.com/iluwatar/java-design-patterns/wiki) before submitting your pull request.
Repository: go
Issue: encoding/json: UnmarshalTypeError.Offset and json subparsers
Labels: NeedsInvestigation

This is a followup to #9693 that added UnmarshalTypeError.Offset to record textual position of errors during unmarshaling. The problem with the landed patch is that it does not deal with UnmarshalTypeError returned from implementations of Unmarshaler.UnmarshalJSON(). The offset in such case would reflect an offset from the beginning  of the slice, not from the start of the original JSON.

It would be nice to be able to recover the full offset for such cases. For example, UnmarshalTypeError could include a boolean flag indicating that UnmarshalTypeError.Offset should be updated by the caller to reflect the real position in the file. Then the code that handles errors from UnmarshalJSON would do just that.
Repository: kubernetes
Issue: Document the environment for kubectl exec
Labels: priority/backlog,kind/documentation,sig/node,sig/docs,lifecycle/frozen

What PATH is set, etc.  if the PATH is not useful, we should make it useful, so user don't have to 'sh -c'

@ncdc
Repository: go
Issue: path/filepath: Glob should support `**` for zero or more directories
Labels: Documentation,NeedsDecision,FeatureRequest

Go version 1.4.2
Mac OS X 10.10

Example:

```
package main

import "fmt"
import "path/filepath"
import "os"

func main() {
    files, err := filepath.Glob("/usr/local/go/src/**/*.go")
    if err != nil {
            fmt.Print(err)
            os.Exit(1)
    }
    fmt.Printf("files: %d\n", len(files))
    for _, f := range files {
        fmt.Println(f)
    }
}
```

Expected:

```
% ls /usr/local/go/src/**/*.go | wc -l
    1633
```

Actual:

```
files: 732
```

It seems that `**` is equivalent to `*`. The extended `**` pattern is common in shells and is supported in Rust and Java for example.
Repository: opencv
Issue: matchShapes and all zeros HuMoments
Labels: bug,priority: normal,category: shape

I've encountered an issue where, when collecting a list of similar shapes using the matchShapes function, I found one shape was being given a perfect match against any shape. Now, after investigation, it turned out that humoments being calculated for the shape matching all were all zero. I'm using a customized version of matchShapes where the hu moments are precalculated, so I can catch these things. For the built in function, this is all done at function level, abstracted away from the user.

I realize this could be reasonably chalked up to a user issue and a lack of sanitizing data before processing it, but I thought I'd bring the issue up here to raise the idea of validating the calculated moments in the function. Otherwise, you'll have a matchShapes function that could, under the right circumstances, match anything to anything.

Edit - After reviewing the code closely, there definitely needs to at least be an assert in matchShapes to verify that neither of the compared HUMoments have all 7 values set to 0, because if either of them are all zero, the > eps will always return false and no difference will be calculated, returning a perfect match when in fact there is no match at all.
Repository: bitcoin
Issue: Does not use bind to local address for outgoing connections
Labels: Feature,P2P

I have several IPv4 / IPv6 addresses on a host and I wish to use a specific one. So I set up the bind so it would use that.  It seems to be using that for the bind() in the listen socket but not for the outgoing connections.

I've tried settings externalip.  That only seems to change the "localaddresses" returned by getnetworkinfo. I'm guessing that's mostly useful for NAT.
Repository: rust
Issue: Emit warnings on parameter list in closures after {
Labels: C-enhancement,A-diagnostics,P-low,T-compiler

# Reproducing steps

This code compiles (and, in my opinion, it shouldn't):

``` rust
let p = Some(45).and_then({|x|
    Some(x * 2)
});
```

While this doesn't:

``` rust
let p = Some(45).and_then({|x|
    println!("doubling {}", x);
    Some(x * 2)
})
```
### Error message 1 (using x)

The error message is absolutely unintuitive and won't help anyone:

```
<anon>:4:14: 4:15 error: unresolved name `x` [E0425]
<anon>:4         Some(x * 2)
                      ^
error: aborting due to previous error
```

[**Playpen link**](http://is.gd/vgOyRD)
### Error message 2 (not using x)

When the last expression does not use a parameter from the list, the generated error message is even more frightening to newcomers (albeit in retrospect, this one makes more sense):

```
<anon>:2:22: 5:7 error: the trait `core::ops::FnOnce<(_,)>` is not implemented for the type `core::option::Option<_>` [E0277]
<anon>:2     let p = Some(45).and_then({|x|
<anon>:3         println!("doubling {}", x);
<anon>:4         Some(100 * 2)
<anon>:5     });
<anon>:2:22: 5:7 help: see the detailed explanation for E0277
<anon>:2:22: 5:7 error: the trait `core::ops::FnOnce<(_,)>` is not implemented for the type `core::option::Option<_>` [E0277]
<anon>:2     let p = Some(45).and_then({|x|
<anon>:3         println!("doubling {}", x);
<anon>:4         Some(100 * 2)
<anon>:5     });
<anon>:2:22: 5:7 help: see the detailed explanation for E0277
error: aborting due to 2 previous errors
```

[**Playpen link**](http://is.gd/zQAHZU)
# Proposed solution

Emit a warning when encountering this fallible syntax.
# Anecdotic background

Having used a lot of Ruby, I had grown way accustomed to the `{ |x| x * 2 }` syntax. Although I had seen the proper Rust syntax a couple of times, it never was emphasized and the significance never stuck. I spent 30+ minutes trying to figure out why a println! statement breaks the build, generating a random error message that has no obvious connections to the actual bug at hand. Only after inquiring the IRC channel did a solution unveil itself. It shouldn't happen.
Repository: go
Issue: cmd/go: document that a .go file is required even if there is a .swig file
Labels: Documentation,NeedsFix

```
go version devel +aad4fe4 Thu Jul 23 05:50:53 2015 +0000 windows/amd64
```

Only include `example.swig` and `simple.c`:

```
go build
can't load package: package mydev/swig/simple: no buildable Go source files in C:\go\gopkg\src\mydev\swig\simple
```

If i create a `x.go` like this:

```
package example
```

`go build` is ok.
Repository: opencv
Issue: Expose more of the HOG functionality in the python API
Labels: auto-transferred,priority: normal,feature,category: python bindings

Transferred from http://code.opencv.org/issues/103

```
|| Gijs Molenaar on 2010-01-28 12:03
|| Priority: Normal
|| Affected: None
|| Category: python bindings
|| Tracker: Feature
|| Difficulty: None
|| PR: None
|| Platform: None / None
```
## Expose more of the HOG functionality in the python API

```
I would love to see more of the HOG functionality exposed in the Python API. It is really great that it is already implemented in the SVN version, but It would be great to be able to use it for other shapes than people.
```
## History
##### anonymous - on 2010-05-06 10:23

```
After implementing and running the HOG descriptor and classifier of OPENCV with python, i can say that it performs great on people with default pose(walking,standing). On the other hand, it performs bad when i tried to detect people in a little bit complicated pose like sitting,playing golf etc etc. I wish that this algorithm trained on different kinds of human poses.

Thanks for this nice work
```
##### Gijs Molenaar on 2010-05-06 11:51

```
it is trained with standing people, that's why doesn't work other poses. You should train it with other poses to detect other poses. The problem is that you can't do that at the moment with the python API.
```
Repository: opencv
Issue: Separable morphology filters
Labels: auto-transferred,priority: normal,feature,category: imgproc,category: video

Transferred from http://code.opencv.org/issues/137

```
|| Dirk Van Haerenborgh on 2010-02-22 10:11
|| Priority: Normal
|| Affected: None
|| Category: imgproc, video
|| Tracker: Feature
|| Difficulty: None
|| PR: None
|| Platform: None / None
```
## Separable morphology filters

```
Right now, when doing a morphology operation, it is only split into a row and a column filter if the structuring element is a filled rectangle.

In many cases however, due to associativity of morphology operations, a noticeable speed-up (theoretically at least 1,5) can be achieved by using a separated row and column filter.

When using a structuring element of M * N, the speed-up is equal to (M*N)/(M+N).

More information here: http://blogs.mathworks.com/steve/2006/11/28/separable-convolution-part-2/
```
## History
##### Kirill Kornyakov on 2012-06-19 06:39

```
Vadim, am I right that we already have separable implementation of morphology filters? If so, we should close this ticket...
```
##### Vadim Pisarevsky on 2012-10-26 18:42

```
Separable morphology is a bit more general thing, comparing to what we have. Morphological operation with the boolean kernel K can be done as a separable operation iff the kernel can be represented as:

<pre>
Kij = Pi & Qj,
</pre>

where P and Q are 1D kernels. In the case of the rectangular morphology both P and Q are all ones. The practical application of such operations is unclear. Many of real-life non-rectangular morphological kernels that I know (used for edge thinning, finding blobs of certain size etc.) are non-separable.
```
Repository: opencv
Issue: Unicode support requested
Labels: auto-transferred,feature,priority: low,category: highgui-gui

Transferred from http://code.opencv.org/issues/148

```
|| Илья Москвин on 2010-02-25 21:54
|| Priority: Low
|| Affected: None
|| Category: highgui-gui
|| Tracker: Feature
|| Difficulty: None
|| PR: None
|| Platform: None / None
```
## Unicode support requested

```
We use the new Python bindings and have to use non-english chars in window names and file pathes. Please, couldn@t you add Unicode support to OpenCV, if possible?
```
## History
##### David Ullmann on 2011-04-25 09:50

```
It's still not possible to build OpenCV (highgui module) with unicode support (platform windows 7, visual studio 2010, OpenCV SVN, 32 bit).
This makes it almost impossible to use OpenCV with wxWidgets > 2.9, which defaults to unicode.
```
##### None on 2012-02-12 18:57

```
-   Description changed from We use the new Python bindings and have to
    use non-english chars in window n... to We use the new Python
    bindings and have to use non-english chars in window n... More
```
##### Vadim Pisarevsky on 2012-04-24 14:47

```
1. OpenCV can create files with non-English names when they are encoded using UTF-8 and passed as normal text strings (tested on Linux and MacOSX).
2. Since OpenCV does not yet support Python 3.x and in Python 2.x text strings are encoded with UTF-8 (i.e. in the format as OpenCV expects it), it's possible to pass a unicode filename to OpenCV function directly using UTF-8 encoding.
3. On Windows it can work too, but instead of UTF-8 the current 1-byte encoding should be used.

So, it's possible (and there is always rename() function in the case of file names); Therefore, I lower the priority of the task.
-   Priority changed from High to Low
-   Assignee set to Vadim Pisarevsky
```
##### Andrey Kamaev on 2012-08-16 15:23

```
-   Category changed from highgui-images to highgui-gui
```
Repository: opencv
Issue: Add analogon to CV_NEXT_GRAPH_EDGE
Labels: auto-transferred,feature,priority: low,category: core

Transferred from http://code.opencv.org/issues/151

```
|| Matthäus Brandl on 2010-03-03 15:22
|| Priority: Low
|| Affected: None
|| Category: core
|| Tracker: Feature
|| Difficulty: None
|| PR: None
|| Platform: None / None
```
## Add analogon to CV_NEXT_GRAPH_EDGE

```
Add a macro which returns the other vertex, which belongs to an edge
```
## History
##### Alexander Smorkalov on 2012-10-03 08:42

```
-   Target version set to 2.4.3
-   Assignee set to Vadim Pisarevsky
```
##### Andrey Kamaev on 2012-10-31 14:19

```
-   Target version changed from 2.4.3 to 3.0
```
Repository: opencv
Issue: Video codecs adjustment
Labels: auto-transferred,priority: normal,feature,category: videoio

Transferred from http://code.opencv.org/issues/177

```
|| Илья Москвин on 2010-03-14 20:31
|| Priority: Normal
|| Affected: None
|| Category: highgui-video
|| Tracker: Feature
|| Difficulty: None
|| PR: None
|| Platform: None / None
```
## Video codecs adjustment

```
We need a possibility to setup codec options from our program by using python API to OpenCV. Probably it could be smth. like "CreateVideoWriter()" arguments. If it will be difficult to realise a common solution for many codecs that options for some particular codecs would be valuable.
```
## History
##### James Bowman on 2010-05-14 20:25

```
So... I think this ticket is asking for more control over the video codec, by adding arguments to "CreateVideoWriter()".  Is that correct?
```
##### Илья Москвин on 2010-05-14 20:42

```
Replying to [comment:3 jamesb]:
> So... I think this ticket is asking for more control over the video codec, by adding arguments to "CreateVideoWriter()".  Is that correct?
Yes, we are requesting for an additional control over the video codec.
And it seems that adding arguments to "CreateVideoWriter()" could be the handiest way to user.
```
##### James Bowman on 2010-05-14 21:54

```
OK, reassigning to highgui.
```
##### Alexander Shishkov on 2012-02-12 21:41

```
-   Description changed from We need a possibility to setup codec
    options from our program by using python... to We need a possibility
    to setup codec options from our program by using python... More
```
##### Andrey Kamaev on 2012-08-16 14:47

```
-   Category changed from highgui-images to highgui-video
```
Repository: opencv
Issue: Functions undocumented in Python and C
Labels: bug,auto-transferred,priority: low,category: documentation,affected: 2.4

Transferred from http://code.opencv.org/issues/229

```
|| James Bowman on 2010-03-26 14:29
|| Priority: Low
|| Affected: None
|| Category: documentation
|| Tracker: Bug
|| Difficulty: None
|| PR: None
|| Platform: None / None
```
## Functions undocumented in Python and C

```
From the latex2sphinx error log:

The following functions are undocumented
     @Abs@
     @BackProjectPCA@
     @CV_16SC@
     @CV_16UC@
     @CV_32FC@
     @CV_32SC@
     @CV_64FC@
     @CV_8SC@
     @CV_8UC@
     @CV_CMP@
     @CV_FOURCC@
     @CV_IABS@
     @CV_IS_SEQ_CLOSED@
     @CV_IS_SEQ_CONVEX@
     @CV_IS_SEQ_CURVE@
     @CV_IS_SEQ_HOLE@
     @CV_IS_SEQ_INDEX@
     @CV_IS_SEQ_SIMPLE@
     @CV_MAKETYPE@
     @CV_MAT_CN@
     @CV_MAT_DEPTH@
     @CV_SIGN@
     @CalcArrBackProject@
     @CalcArrHist@
     -@CalcOpticalFlowFarneback@-
     @CalcPCA@
     -@CalibrationMatrixValues@-
     @CheckArr@
     @ClearSeq@
     -@ConvertMaps@-
     @CreateCameraCapture@
     @CreateFileCapture@
     @CvtPixToPlane@
     @CvtScale@
     @DecodeImage@
     @DecodeImageM@
     @EncodeImage@
     -@EqualizeHist@-
     -@EstimateRigidTransform@-
     -@GetReal1D@-
     -@GetReal2D@-
     -@GetReal3D@-
     -@GetRealND@-
     @HOGDetectMultiScale@
     -@HoughCircles@-
     @MatMul@
     @MatMulAdd@
     @MaxRect@
     -@Normalize@-
     @ProjectPCA@
     -@PyrUp@-
     -@RandShuffle@-
     @Range@
     @RealScalar@
     @Scalar@
     @ScalarAll@
     @Scale@
     -@SolvePoly@-
     -@Sort@-
     @StartWindowThread@
     @Subdiv2DEdgeOrg@
     -@Subdiv2DNextEdge@-
     -@Watershed@-
     @Zero@


Some of these are synonyms for functions that are documented.
```
## History
##### James Bowman on 2010-05-10 18:40

```
<pre>
```
##### Vadim Pisarevsky on 2011-08-06 19:18

```
Watershed, HoughCircles, DecodeImage, DecodeImageM, EncodeImage, CalcOpticalFlowFarneback, EqualizeHist done in r6354
```
##### Andrey Kamaev on 2012-03-20 11:45

```
-   Description changed from From the latex2sphinx error log: <pre> The
    following functions are und... to From the latex2sphinx error log:
    The following functions are undocumented ... More
```
##### Alexander Shishkov on 2012-03-21 22:29

```
-   Target version deleted ()
-   Priority changed from High to Normal
```
##### Alexander Shishkov on 2012-03-22 14:26

```
-   Priority changed from Normal to Low
```
##### Alexander Shishkov on 2012-03-25 20:49

```
-   Assignee deleted (James Bowman)
```
##### Alexander Shishkov on 2012-04-05 12:48

```
-   Target version deleted ()
```