sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: opencv
Issue: Some of the features2d algorithms would need a little bit of refactoring
Labels: feature,category: features2d,category: gpu/cuda (contrib)

As the title mentions, in the latest version of the "opencv" repository up-to-date (master-2c4ed7f8a5a6a2dce331b2f075f425cfe7ad522b, thus OpenCV3.1.0-dev), I think that some of the algorithms (both CUDA and non) that falls in the category of features detection, descriptors extraction, and features matching need a little bit of refactoring so that they match the current guidelines for implementing a new algorithm (http://docs.opencv.org/master/db/dfa/tutorial_transition_guide.html#tutorial_transition_algorithm) and a user can easily reuse the code using them with different algorithms.

Up to now, I identified the following issues:
- the CUDA version of the BFMatcher does not have a create() function as the non-CUDA counterpart, and as other algorithms, do; but has a specific create function (https://github.com/Itseez/opencv/blob/ddf82d0b154873510802ef75c53e628cd7b2cb13/modules/cudafeatures2d/include/opencv2/cudafeatures2d.hpp#L92).
- the CUDA version of ORB does not allow to use just the descriptor extractor as the non-CUDA counterpart do, because of the assertion on the flag "useProvidedKeypoints" and maybe some missing implementation about how to deal with just the extraction of the descriptors given the keypoints (https://github.com/Itseez/opencv/blob/master/modules/cudafeatures2d/src/orb.cpp#L583).
- I think that there should be consistency on how to create an algorithm, as the case of the features detectors and matchers, which all of them have an implemented create (and not anymore the general create function which took the string of the feature as input), while in the specific descriptors matchers (i.e., BFMatcher and FlannBased) classes there is not such a function (and thus the matcher can be created by calling "create" passing the name of the matcher as parameter).

As I am currently using them for doing research, if I find anything else and if useful, I will update the list (I would like to contribute to the actual process with some pulls, but unfortunately I do not have much free time soon).

Thanks.
Repository: TypeScript
Issue: Consider re-ordering Array#reduce overloads in lib.d.ts
Labels: Suggestion,Help Wanted,Domain: lib.d.ts,Good First Issue

Example code:

``` typescript
type UnaryFunction = (arg1) => any;
type BinaryFunction = (arg1, arg2) => any;

let binaryFuncs: BinaryFunction[] = [];
let unaryFunc = arg1 => {};
let reduced = binaryFuncs.reduce((prev, next) => prev, unaryFunc);

// ACTUAL:
let f: UnaryFunction = reduced;     // ERROR binary not assignable to unary

// EXPECTED:
let f: UnaryFunction = reduced;     // OK - both lhs and rhs really are unary
```

The call to `Array#reduce` in the above example definitely returns a unary function, but the type system erroneously infers the return type as a binary function.

This seems to be caused by the declaration order of the two overloads of `Array#reduce` in `lib.d.ts`. If the declaration order is reversed, the problem is solved.

The two overloaded declarations in `lib.d.ts` are as follows:

``` typescript
reduce(callbackfn: (previousValue: T, currentValue: T, currentIndex: number, array: T[]) => T, initialValue?: T): T;
reduce<U>(callbackfn: (previousValue: U, currentValue: T, currentIndex: number, array: T[]) => U, initialValue: U): U;
```

The first overload matches the example with `T=BinaryFunction`, since it satisfies the compiler's assignability checks. So the second overload is never considered, even though it is a strictly better match, with `T=BinaryFunction` and `U=UnaryFunction`.

Would it be possible to swap the overload order for `Array#reduce` (and `Array#reduceRight`) in `lib.d.ts` to resolve this issue?
Repository: rust
Issue: Can't Unify Super Generic Code
Labels: A-type-system,A-associated-items,T-compiler,C-bug,T-types

I was trying to verify that the associated-items-based HKT described in the associated items RFC still worked. As best I know, I updated everything to work with today's stable Rust (1.7), but it fails out in unifying in the actual implementation of `Mappable for Vec<T>` (see the FIXME). 

``` rust

// The kind * -> *
trait TypeToType<Input> {
    type Output;
}

struct Vec_;

impl<T> TypeToType<T> for Vec_ {
    type Output = Vec<T>;
}

trait Mappable 
    where Self: Sized,
{
    type E;
    type HKT: TypeToType<Self::E, Output=Self>;

    fn map<F, O>(self, f: F) -> <Self::HKT as TypeToType<O>>::Output
        where F: FnMut(Self::E) -> O,
              Self::HKT: TypeToType<O>;
}

impl<T> Mappable for Vec<T> {
    type E = T;
    type HKT = Vec_;

    // FIXME: I won't unify `Vec_::Output = Vec<O>`!
    fn map<F, O>(self, mut f: F) -> <Self::HKT as TypeToType<O>>::Output
        where F: FnMut(Self::E) -> O,
              Self::HKT: TypeToType<O>
    {
        let r: Vec<O> = self.into_iter().map(&mut f).collect();
        r
    }

}


fn main() {
    let nums: Vec<u32> = vec![1, 2, 3, 4, 5, 6];
    let bools: Vec<bool> = nums.map(|x| x < 3);
}
```
Repository: TypeScript
Issue: Emitted extends clause should come after deatched-comment at the top of the file 
Labels: Bug,Help Wanted

``` typescript
// --------------------------------------------------
// Some Copy Right
// --------------------------------------------------
class B {}
class C extends B {}
```

``` js
"use strict";
var __extends = (this && this.__extends) || function (d, b) {
    for (var p in b) if (b.hasOwnProperty(p)) d[p] = b[p];
    function __() { this.constructor = d; }
    d.prototype = b === null ? Object.create(b) : (__.prototype = b.prototype, new __());
};
// --------------------------------------------------
// Some Copy Right
// --------------------------------------------------
var B = (function () {
    function B() {
    }
    return B;
}());
var C = (function (_super) {
    __extends(C, _super);
    function C() {
        _super.apply(this, arguments);
    }
    return C;
}(B));
```
Repository: go
Issue: x/build: use `go tool dist test -k` on fast builders?
Labels: Builders,Proposal,Proposal-Accepted

Especially for fast builders, I suggest that we make then use the keepgoing
mode of `go tool dist test` so that even if a test fails, all the remaining tests
are still tested.

This will be especially useful if a flaky tests fails and then masks the real
problem of a given a CL because the affected tests are not run.

As an example, https://golang.org/cl/19455 changes the runtime, but
the openbsd builder fails a unrelated net tests, and the runtime tests are
not run so we don't actually know if the CL catches any problems on
OpenBSD/386.
http://build.golang.org/log/38e92c1c987f7a7eeb4b6bb418c0d95ed706ba80

I don't know if it's worthwhile to also use the -k for the trybots. I can see
arguments from both sides.

/cc @bradfitz @adg
Repository: rust
Issue: `create_dir_all` can't create directories through a dangling symlink.
Labels: T-libs-api,C-feature-accepted,A-io

Currently `create_dir_all` first does a stat on the file to see if it is a directory, and if not tries to create the parent dirs. This does not take into account that stat can fail if the path is a dangling symlink.
The classic `mkdir -p` just tries to create a directory and see why it fails. This spares a syscall and handles dangling symlinks transparently.

On Windows this method hit two problems:
- When we have to recurse all the way op to the disk letter, `create_dir_all` fails.
  You can't mkdir `c:\` or `\\host\share`. But we can just stop recursing in time.
- Windows can't create a directory through a dangling symlink.
  We would have to read the symlink (and possibly resolve it if relative), and create the directory
  at the target location ourself.

Would it make sense to go trough this trouble?

I think it is best to only fix this for `create_dir_all` and to document the normal `create_dir` can not
create a directory trough a dangling symlink on Windows.
Repository: youtube-dl
Issue: please add support for rte.ie/archives
Labels: site-support-request

http://www.rte.ie/archives/2016/0210/766882-beat-of-the-feet/

```
$ youtube-dl http://www.rte.ie/archives/2016/0210/766882-beat-of-the-feet/ -v
[debug] System config: []
[debug] User config: []
[debug] Command-line args: [u'http://www.rte.ie/archives/2016/0210/766882-beat-of-the-feet/', u'-v']
[debug] Encodings: locale cp1252, fs mbcs, out None, pref cp1252
[debug] youtube-dl version 2016.02.10
[debug] Python version 2.7.11 - Windows-XP-5.1.2600-SP3
[debug] exe versions: ffmpeg N-78067-g9079e99, ffprobe N-78067-g9079e99, rtmpdump 2.4
[debug] Proxy map: {}
[generic] 766882-beat-of-the-feet: Requesting header
WARNING: Falling back on generic information extractor.
[generic] 766882-beat-of-the-feet: Downloading webpage
[generic] 766882-beat-of-the-feet: Extracting information
ERROR: Unsupported URL: http://www.rte.ie/archives/2016/0210/766882-beat-of-the-feet/
Traceback (most recent call last):
  File "c:\python27\lib\site-packages\youtube_dl\extractor\generic.py", line 1294, in _real_extract
    doc = compat_etree_fromstring(webpage.encode('utf-8'))
  File "c:\python27\lib\site-packages\youtube_dl\compat.py", line 248, in compat_etree_fromstring
    doc = _XML(text, parser=etree.XMLParser(target=etree.TreeBuilder(element_factory=_element_factory)))
  File "c:\python27\lib\site-packages\youtube_dl\compat.py", line 237, in _XML
    parser.feed(text)
  File "c:\python27\lib\xml\etree\ElementTree.py", line 1642, in feed
    self._raiseerror(v)
  File "c:\python27\lib\xml\etree\ElementTree.py", line 1506, in _raiseerror
    raise err
ParseError: undefined entity: line 8, column 13
Traceback (most recent call last):
  File "c:\python27\lib\site-packages\youtube_dl\YoutubeDL.py", line 666, in extract_info
    ie_result = ie.extract(url)
  File "c:\python27\lib\site-packages\youtube_dl\extractor\common.py", line 315, in extract
    return self._real_extract(url)
  File "c:\python27\lib\site-packages\youtube_dl\extractor\generic.py", line 1930, in _real_extract
    raise UnsupportedError(url)
UnsupportedError: Unsupported URL: http://www.rte.ie/archives/2016/0210/766882-beat-of-the-feet/
```
Repository: java-design-patterns
Issue: Composition root pattern
Labels: info: help wanted,epic: pattern,type: feature

### Description:
The Composition Root design pattern is a method of organizing code to ensure that all dependencies are created in a single location within an application. This helps manage dependencies more effectively, improve testability, and promote a clear separation of concerns. By centralizing the creation of dependencies, the Composition Root pattern ensures that an application's object graph is constructed in a consistent manner.

**Main elements of the pattern:**
1. **Centralized Dependency Creation**: All dependencies are instantiated in a single location, typically at the application's entry point.
2. **Dependency Injection**: Dependencies are injected into classes rather than being created within those classes, supporting Inversion of Control (IoC).
3. **Separation of Concerns**: Ensures that the construction of objects and their usage are separate, enhancing maintainability and testability.

**References:**
- [Composition Root - Mark Seemann](https://blog.ploeh.dk/2011/07/28/CompositionRoot/)
- [Dependency Injection Principles, Practices, and Patterns](https://www.manning.com/books/dependency-injection-principles-practices-patterns) by Mark Seemann and Steven van Deursen
- [Project Contribution Guidelines](https://github.com/iluwatar/java-design-patterns/wiki)

### Acceptance Criteria:
1. Implement the Composition Root pattern in the project, ensuring all dependencies are instantiated in a single location at the application's entry point.
2. Demonstrate the use of dependency injection to provide these dependencies to various components of the application.
3. Ensure that the implemented pattern adheres to the project’s contribution guidelines and includes relevant documentation and examples.
Repository: go
Issue: x/text/currency: position of the ISO code or sign in amounts
Labels: NeedsInvestigation

``` go
    currencyCode = "PLN"
    unit, _ := currency.ParseISO(currencyCode)
    p := message.NewPrinter(language.Polish)
    amount := float64(100)
    p.Print(currency.Symbol(unit.Amount(amount)))
```

The result is `zł 100` but I would expect `100 zł`.
https://en.wikipedia.org/wiki/ISO_4217#Position_of_ISO_4217_code_in_amounts
http://publications.europa.eu/code/en/en-370303.htm#position

I would expect `100 zł` but maybe there is "other" library/func/method that handles order?
Or if this is on TODO list, any idea how could I workaround the problem?
Repository: go
Issue: cmd/go: decide, document standard benchmark data format
Labels: Documentation,Proposal,Proposal-Accepted,NeedsInvestigation

We propose to make the current output of `go test -bench` the defined format for recording all Go benchmark data. Having a defined format allows benchmark measurement programs and benchmark analysis programs to interoperate while evolving independently.

See [golang.org/design/14313-benchmark-format](https://golang.org/design/14313-benchmark-format) for details.
Repository: TypeScript
Issue: Permit type alias declarations inside a class
Labels: Suggestion,In Discussion

I normally want my class declaration to be the first thing in my file:

``` typescript
module foo {

  /** My foo class */
  export class MyFoo {

  }
}
```

So when I want to declare an alias, I don't like the fact that my class has been pushed down further:

``` typescript
module foo {

 type foobar = foo.bar.baz.FooBar;

  /** My foo class */
  export class MyFoo {

  }
}
```

I suggest the following be permitted:

``` typescript
module foo {

  /** My foo class */
  export class MyFoo {
    type foobar = foo.bar.baz.FooBar;
  }
}
```

Since `type foobar` is just a compile-time construct, and if people want to write it that way, then they should be permitted to do so. Note that the type `foobar` is private to the class. It should not be permissible to export `foobar`.
Repository: flutter
Issue: Draggable feedback should animate back to the draggable when the drop fails
Labels: c: new feature,framework,a: animation,customer: solaris,P3,team-framework,triaged-framework

Possibly giving me an offset from it's original position.
Repository: rust
Issue: Compiletest doesn't pass environment variables to emscripten tests
Labels: O-wasm,O-emscripten

Compiletest sometimes passes environment variables when building the `Command` object. However in the case of emscripten, these values get passed to `node` instead of the program itself.

`node` can't propagate env vars to the javascript code, since javascript has no concept of an environment variable. It is possible to pass environment variables to the "emscripten runtime", but that must be done by manually adding some JS code in the header of the file.

For the moment the tests that rely on env vars are ignored and point to this issue.
Repository: angular
Issue: fix(Changedetection): ngAfterViewChecked is called when component is set to OnPush and no input properties changed
Labels: feature,area: core,core: change detection,feature: under consideration

Similar to https://github.com/angular/angular/issues/7054 it seems that `ngAfterViewChecked()` is called, when a component is set to `OnPush` and **no input property changed, or event is fired inside that component**.

Here's a plunk that demonstrates the issue: http://plnkr.co/edit/3HEH7AcrQaVUF0PTQBNv?p=preview

You'll see two components. One gets bootstrapped and the second one is set to `OnPush`, so it should only run change detection when either one of its input properties changes, or an event is fired inside that component.

**Expectation**: OnPush Child Component should **not** turn green when the button is clicked, as no input properties are changing and no event is fired from inside the child component.

**UPDATE:** Similar to #7054 `ngAfterViewCheck()` is called, but change detection is **not** performed as we can see in this plunk: http://plnkr.co/edit/picW7fedYGY2PIPxp0Ur?p=preview

The subtree of `OnPush` component is not checked when we trigger CD.
Repository: flutter
Issue: ui.window.locale should be set on startup
Labels: a: tests,framework,engine,f: material design,c: performance,a: internationalization,d: examples,P2,team-design,triaged-design

Currently, it's not, which means we waste 16ms in every app with a MaterialApp because we spin an entire frame waiting for the locale to be set.

This requires some redundant pumps in tests, too.
Repository: go
Issue: cmd/compile: recognize append loop
Labels: Performance,compiler/runtime

Loops with appends are common in Go. And often the loops have a fixed iteration count.

cmd/compile could recognize something of the form:

``` go
        for ... := range x {
            s = append(s, v)
        }
```

And compile it as:

``` go
        s = runtime_ensurecapacity(s, len(x))
        for ... := range x {
            s = append(s, v)
        }
```

Likewise with `for i := 0; i < n; i++`.

That would remove the need for the (often premature) optimization of:

``` go
      s := make([]T, 0, len(x))
```

And let people just write instead:

``` go
    var s []T
    for k := range m {
          s = append(s, k)
    }
```

This would also help eliminating garbage when the number of iterations is very large. (e.g. @campoy's https://news.ycombinator.com/item?id=11098802)

/cc @randall77 @dr2chase @rsc
Repository: opencv
Issue: solvePnP fails with perfect coordinates (and cvPOSIT passes)
Labels: bug,category: calib3d,affected: 2.4,affected: 3.4

I have found a set of parameters for which solvePnP does not give correct results although :
- the image points are perfect coordinates obtained with projectPoints applied to the objectPoints (no error at all in the image points)
- cvPOSIT is perfectly able to reconstruct the pose, when solvePnp seems not to be able to do so

solvePnp leads to a reprojection error of  8.94 pixels using SOLVEPNP_ITERATIVE,  about 0.21 using P3P, and about 44 pixel when using other flags (DLS, EPNP and UPNP)

The reprojection error is zero only when using SOLVEPNP_ITERATIVE + useExtrinsicGuess = true (with initial rotation and translation set to zero) .

Please do look at the corresponding thread on the forum : http://answers.opencv.org/question/87546/solvepnp-fails-with-perfect-coordinates-and-cvposit-passes/

Note : as mentionned by Eduardo in the forum, SOLVEPNP_ITERATIVE returns a pose that is behind the camera when useExtrinsicGuess=false
Repository: go
Issue: x/mobile: gomobile bind unsupported seqType: string Array
Labels: mobile

when i'm trying to build aar library for undroid i have panic 
panic: unsupported seqType: [100][100][2]string / *types.Array

Gomobile version:
gomobile version +002f07f Fri Feb 5 00:56:26 2016 +0000 (android); 
 androidSDK=/home/user/IDE_Android/adt-bundle-linux-x86_64-20130522/sdk/platforms/android-23

Go version:
go version go1.5.3 linux/amd64

func GetContent(dbPath string, rowCount int, columnCount int, selectedDate string) ([100][100][2]string){
Repository: three.js
Issue: Proposal: Lets make EffectComposer "Stereo Aware" to simplify VR post effects
Labels: Suggestion,Post-processing

So I was trying my hand at stereo effects in ThreeJS and the first issue I ran into is that they are somewhat incompatible with EffectComposer.  The issue is that the "effects" in the examples/js/effects directory are not actually possible to put into the EffectComposer.  This was initially a little confusing to me.  You can put examples/js/passes into the EffectComposer though (maybe it should have been called PassComposer?)  but anyhow....

I think the solution is relatively straight forward.  We could convert the examples/js/effects into Passes and push them through the effect composer pipeline.  I've actually done this in my private branch of ThreeJS already last fall but I am unsure if is the best way, I did it in an expedient way...  I'd like to get this back into ThreeJS proper now if you guys want it....

Here is how I did it:
1. I modified EffectComposer to optionally accept a StereoCamera as the main camera.
2. If the camera passed into EffectComposer is not a StereoCamera it behaves at it current does.  Thus it is backwards compatible.
3. If you pass in a StereoCamera, things change, but only for passes that are "stereoAware".  This is a flag on each pass that defaults to false if not set.  If it is set, if the pass is "stereoAware", then the EffectComposer will call the Pass twice, once for each camera if the stereo rig and with the appropriate viewport settings (only half of the render target is rendered.)

That is it.  It is very straight forward but powerful change.

A pass like RenderPass is stereo aware (stereoAware=true), it needs to generate different images for each camera.  Other passes like a non-adaptive ToneMap are not stereo aware as it operates on each pixel in a simple matter.  The rule generally is any Pass that uses a search area, such as FXAA, SMAA, Botek, SSAO should be stereo aware because otherwise there would be blending across central barrier.

Right now I make the assumption that StereoCamera splits the viewport into two even side-by-side renders.  This seems to make sense to me, but maybe it isn't a valid assumption.

I am sure there are ways to further extend this design, but it does achieve what is minimally necessary, to unify Effects and Passes to make it easier to do high quality VR with ThreeJS.

I think this is a generally decent design and it is really simple to implement.  I'd also suggest implementing a few new passes for this workflow, such as Lenticular (interleave), and Anagraph, which just engage in pixel re-arrangement.  These could take the side-by-side renderings and turn them into new forms for output, thus all stereo effects could use the same pipeline -- thus we'd have simplicity and efficient of code.

This change should mostly gut the existing examples/js/effects in terms of rendering, the main thing we would need to keep is the particular StereoCamera setup code that is particular to each device.
Repository: java-design-patterns
Issue: Service Stub pattern
Labels: info: help wanted,epic: pattern,type: feature,status: stale

### Description
The Service Stub design pattern is used to create a simplified version of a service that mimics the behavior of a real service in a controlled manner. This is especially useful during development and testing phases when the actual service might be unavailable or its usage might be costly or impractical. The stub can return predefined responses and simulate various scenarios to ensure the application behaves as expected.

#### Main Elements of the Pattern:
- **Stub Creation:** Develop a stub that implements the same interface as the real service.
- **Predefined Responses:** Configure the stub to return predefined responses based on input parameters.
- **Behavior Simulation:** Simulate various behaviors such as success, failure, and exceptions.
- **Seamless Replacement:** Ensure the stub can be seamlessly replaced with the real service with minimal changes to the application code.

### References
1. [Service Stub Pattern - Martin Fowler](http://martinfowler.com/eaaCatalog/serviceStub.html)
2. [Mock and Stub in Unit Testing](https://www.baeldung.com/mockito-vs-easymock-vs-jmockit)
3. [Java Design Patterns Wiki - Contribution Guidelines](https://github.com/iluwatar/java-design-patterns/wiki)

### Acceptance Criteria
1. Create a new package `service-stub` under the `patterns` directory.
2. Implement the service stub following the principles of the pattern, including predefined responses and behavior simulation.
3. Provide comprehensive unit tests to validate the stub's behavior in different scenarios.
4. Update the README with an explanation of the Service Stub pattern, including example usage and code snippets.