sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: create-react-app
Issue: Runtime environment variables
Labels: issue: proposal

Regarding this [pull request](https://github.com/facebookincubator/create-react-app/pull/1344#issuecomment-302887448) around the improvements to environment variables, based on @gaearon's suggestion, I wanted to start a discussion on how to handle a docker-centric, 12 factor app-based workflow where environment variables are provided externally at runtime rather than at build time so that the exact same assets can be run in multiple environments.

Constraints / design goals mentioned is:

> It's important though to note that CRA always produces static bundles, and they are expected to work in any environment regardless of server, container, etc.

In the past, I have implemented the following two solutions:

1) render environment variables into the HTML and then hoist them into an application at initialization
2) fetch environment variables from a server (for example, before creating the store and rendering the app with some static content during the initial fetch)

The first solution's benefit is that there is no delay before initial render, but with create react app dynamically modifying the html file, it becomes a little more tricky to implement since you would need to parse or search / replace within the rendered html before serving the file.

I'm just wondering if there is a better / best way to provide runtime environment variables to CRA applications and if we can get agreement on an approach, if it can be integrated into the CRA pipeline.

Thank you for all the great work and hoping for something awesome here! :pray:
Repository: go
Issue: compress: unify Huffman logic in flate and bzip2
Labels: Performance

The Huffman encoding in both `flate` and `bzip2` is identical except for some minor differences:
* `bzip2` treats the leading bits in a bitstream as the MSB of a byte, while `flate` treats the leading bits as the LSB of a byte.
* `bzip2` allows Huffman codes to be up to 20-bits long, while `flate` allows codes up to 15-bits long.

Currently, the implementation of Huffman encoding in `flate` is superior (and faster) to the one in `bzip2`. The differences are very minor and it should be able to unify the two without any performance hit. We should extract the common logic as `compress/internal/huffman`.
Repository: go
Issue: cmd/compile: init code or linker should verify package "fingerprint"
Labels: help wanted,NeedsFix,compiler/runtime

Given a file lib.go:
```
package lib

func F() int { return 42 }
```
and main.go:
```
package main

import "./lib"

func main() { println(lib.F()) }
```
The following command sequence prints 42 as expected:
```
$ go tool compile lib.go 
$ go tool compile main.go
$ go tool link main.o
$ a.out
42
```
If one now changes 42 to 43 in lib.go, the following command sequence still prints 42:
```
$ go tool compile lib.go 
$ go tool link main.o
$ a.out
42
```
rather than 43. The issue is (presumably) that lib.F() got inlined and there's (apparently) no check in the linker that lib.go changed.

While not surprising to an initiated user, this is surprising to an unsuspecting user. Ideally the linker, or then the initialization code should check that a compiler package we link again (or that we initialize) is the same that we compiled against. This could be done with some fingerprint of sorts, perhaps computed on the export data only.

I suspect scenarios can be created where the linker succeeds and the program crashes (because a data type changed in lib.go and main.go wasn't recompiled).

This behavior is no different from C/C++ where we have "independent" compilation: as long as the linker finds the matching symbols, it doesn't care whether they are referring to the same entities that were implied in the source code - hence the independence.

Go should properly implement "separate" compilation: packages can be compiled separately, but correspondence to source code should be enforced.
Repository: go
Issue: cmd/compile: include certain NOP instructions when compiler optimizations are disabled
Labels: NeedsFix,FeatureRequest,Debugging,compiler/runtime

This is a follow up of the discussion here: https://github.com/derekparker/delve/issues/840

### What version of Go are you using (`go version`)?
go version go1.8.3 windows/amd64

### What did you do?
I've tried to debug the following app:  https://play.golang.org/p/74ZR5IYhjn
I've set a breakpoint on line 
```
a := TableModel{} // b demo.go:17
```

### What did you expect to see?
I was expecting to get the debugger to stop there.

### What did you see instead?
The debugger did not stopped there.

From the discussion I understand the reason on why the debugger doesn't stop as expected but as I've mentioned there, I think that's a problem of expectations.
From a user's point of view, the debugger should stop there, it's a variable declaration and initialization. There shouldn't be any reason for it not to stop.
As such, I've decided to open this issue to have a discussion and see if this could make its way in 1.10 and help manage the expectations of the users better.

Thank you.
Repository: flutter
Issue: Add a diagram to explain Canvas.drawImageNine
Labels: engine,d: api docs,P3,team-engine,triaged-engine

Currently, the first paragraph reads:

> Draws the given Image into the canvas using the given Paint.

It should state that it *draws a scaled rendition(?) of the given 9-patch image* or something like that.
Repository: go
Issue: sync: add example for Cond
Labels: Documentation,NeedsInvestigation,compiler/runtime

The sync.Cond should have an example demonstrating its use in a somewhat realistic use.

What would be a good example? It's hardly used at all in standard library. What are typical uses?

Continuation from #20471.
Repository: go
Issue: cmd/link: may need a command line option to set section split size
Labels: help wanted,NeedsInvestigation,compiler/runtime

On ppc64x in external link mode the linker splits the text section into separate sections of size up to 0x1c00000 bytes.  This gives the C linker space to insert stubs for out-of-range bl instructions.  The C linker works in terms of a stub group size: it adds sections to a stub group until it reaches the group size, and then creates a new stub group.  The default stub group size is, not coincidentally, 0x1c00000.

However, 1) it is possible for the linker to fail to insert a stub if there are too many stubs, in which case it can retry with a smaller stub group size; 2) the linker has a command line option to set the stub group size, and it may be set to be smaller.  Either way, when the Go linker produces a section that is larger than the stub group size, the linker emits a warning (at least, the gold linker does), and in some cases the link may conceivably fail.

In order to accommodate these cases I think that either we need to have a command line option to set the size at which we split the text section, or we need to simply reduce the size to something more likely to work.

CC @laboger
Repository: angular
Issue: *Blocking Issue*: Change detection after error creating infinite loop
Labels: type: bug/fix,freq2: medium,area: core,core: change detection,core: error handling,P4

**I'm submitting a ...**  (check one with "x")
```
[X] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
```

**Current behavior**
Possibly relates to #9531 and #16426. Since the change to continue change detection after an error (4.1.1), I'm getting an infinite loop of errors if there's a problem with template parsing (such as a bound variable doesn't exist). It causes the browser to completely hang, and the browser process must be manually killed.

The console shows the infinite errors like this:
![change detection error loop](https://cloud.githubusercontent.com/assets/140338/26435569/2cca83a0-40de-11e7-9c9b-558a927b4fc8.png)

If I add a breakpoint in my error `handleError()` method, I can get a stack trace which may help with diagnosis. Since it is long, I'll attach it rather than embed.
[angular error loop stacktrace.txt](https://github.com/angular/angular/files/1027943/angular.error.loop.stacktrace.txt)

The issue is not my error handler triggering some sort of change detection, because I can completely remove the custom error handler class and the issue still manifests.

If you look through the stack trace, you can see that everything going on is internal to Angular, SystemJS (maybe it keeps trying to make XHR calls to load files, which triggers change detection?), and/or Zone. I'm not sure yet if it has to do with the fact that this is happening during bootstrap, or possibly something related to Zone.js, or something related to SystemJS.

**Expected behavior**
The browser should not completely hang due to something as basic as a template compilation error or binding error.

**Minimal reproduction of the problem with instructions**
I'm trying to create a Plunkr, but there are a number of pieces to put in place to mimic what's going on, and it is slow going. I'll keep trying.


**Please tell us about your environment:**
Windows 2010 x64

* **Angular version:** Angular 2.1.3, Zone 0.8.10, System 0.19.41.

* **Browser:** all 
* **Language:** TypeScript 2.3.2
Repository: opencv
Issue: Stitching module is not compatible with CUDA8 due to GraphCut has been removed in CUDA8
Labels: bug,priority: low,category: gpu/cuda (contrib),category: stitching

<!--
If you have a question rather than reporting a bug please go to http://answers.opencv.org where you get much faster responses.
If you need further assistance please read [How To Contribute](https://github.com/opencv/opencv/wiki/How_to_contribute).

This is a template helping you to create an issue which can be processed as quickly as possible. This is the bug reporting section for the OpenCV library.
-->

##### System information (version)
<!-- Example
- OpenCV => 3.1
- Operating System / Platform => Windows 64 Bit
- Compiler => Visual Studio 2015
-->

- OpenCV => 3.2
- Operating System / Platform => Win10 64bit
- Compiler => Visual Studio 2010/Visual Studio 2015

##### Detailed description

<!-- your description -->
When I want to use GPU to accelerate the stitching procedure with OpenCV3.2 & CUDA8. I get this error:

`Opencv Error: The function/feature is not implemented (  The called functionality is disabled for current build or platform )`

In the source code  `seam_finders.cpp` line 1445:

`cuda::graphcut(terminals_d, leftT_d, rightT_d, top_d, bottom_d, labels_d, buf_d);`

So the problem is the function `graphcut` which `stitching` bases on is removed in CUDA8 but not updated in the OpenCV source code.

According to this issue #6510 

In the ` graphcuts.cpp` line 45-50:
```
// GraphCut has been removed in NPP 8.0
#if !defined (HAVE_CUDA) || defined (CUDA_DISABLER) || (CUDART_VERSION >= 8000)

void cv::cuda::graphcut(GpuMat&, GpuMat&, GpuMat&, GpuMat&, GpuMat&, GpuMat&, GpuMat&, Stream&) { throw_no_cuda(); }
void cv::cuda::graphcut(GpuMat&, GpuMat&, GpuMat&, GpuMat&, GpuMat&, GpuMat&, GpuMat&, GpuMat&, GpuMat&, GpuMat&, GpuMat&, Stream&) { throw_no_cuda(); }
```

So we just simply deprecated the function without looking relevance.

##### Steps to reproduce
Compile Opencv3.2 with CUDA8 then use stitching:
```
Stitcher::Mode mode = Stitcher::PANORAMA;
Ptr<Stitcher> stitcher = Stitcher::create(mode, try_use_gpu=1);
Stitcher::Status status = stitcher->stitch(input_images, pano);
```
then we will meet the error.

##### My solution:

Since it is hard for me to modify the original source code,  so  I use the CPU version of `GraphCut` in the stitching procedure.  
It'll lose some speed but the rest part of the stitching procedure is working which would save a lot of time compared to the totally CPU version code.

`stitcher->setSeamFinder(makePtr<detail::GraphCutSeamFinder>(detail::GraphCutSeamFinderBase::COST_COLOR));`

Please consider updating the `GraphCut` code to compatible with CUDA8 to fundamentally fix the problem.


Related link:
https://devtalk.nvidia.com/default/topic/973151/no-nppgrabcut-on-cuda-8-0/
Repository: opencv
Issue: HOG human detection causes process exit without any error stack message after changing padding from (16,16) to (8,8)
Labels: bug,category: objdetect

My configuration:

Ubuntu 16.04 64bit desktop
Opencv 3.2.0-dev compiled by 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)
Python 2.7.12
and I am trying to detect human from a video,and detection will exit when comes to this frame,

Problem frame
![problemframe](https://cloud.githubusercontent.com/assets/303353/26446573/372f6bea-410a-11e7-9ad8-d23386e2420f.png)

detection code is:

```
import cv2

image = cv2.imread('problemFrame.png')

cv2.imshow('Problem frame', image)
cv2.waitKey(30)

hog = cv2.HOGDescriptor()
hog.setSVMDetector(cv2.HOGDescriptor_getDefaultPeopleDetector())
founds, weights = hog.detectMultiScale(image, winStride=(4, 4),
                                                          padding=(8, 8), scale=1.05,
                                                          useMeanshiftGrouping=True)   

print founds, weights
```
and if changing padding from (8,8) to (16,16),detection works,and I have checked api doc:

padding – Mock parameter to keep the CPU interface compatibility. It must be (0,0).
but don't know what it mean,why must be (0,0),and this link gives more detailed description:

http://www.pyimagesearch.com/2015/11/16/hog-detectmultiscale-parameters-explained/
padding (optional)

The padding  parameter is a tuple which indicates the number of pixels in both the x and y direction in which the sliding window ROI is “padded” prior to HOG feature extraction.

As suggested by Dalal and Triggs in their 2005 CVPR paper, Histogram of Oriented Gradients for Human Detection, adding a bit of padding surrounding the image ROI prior to HOG feature extraction and classification can actually increase the accuracy of your detector.

Typical values for padding include (8, 8), (16, 16), (24, 24), and (32, 32).
and still can't figure out why,would you please help solve this problem?Thanks in advance.
Repository: vscode
Issue: Match whole word doesn't work in search for non-latin characters
Labels: help wanted,feature-request,search,search-api

#3623

https://github.com/Microsoft/vscode/commit/f151b3ef1fff3f25b02b4f3416888a4fdb5a3011
Repository: rust
Issue: Redundancy in `trace_macro` output
Labels: C-enhancement,A-macros,T-compiler,S-has-mcve,-Ztrace-macros

(filed per https://github.com/rust-lang/rust/pull/42103#issuecomment-303183649 )

`trace_macro` output now contains both "before" and "after" text.

But often a macro-call expands to another macro-call. In that case, we get redundant lines from `trace_macro`:

```console
 note: trace_macro
   --> trace-macro.rs:14:5
   |
14 |     println!("Hello, World!");
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   |
   = note: expanding `println! { "Hello, World!" }`
   = note: to `print ! ( concat ! ( "Hello, World!" , "\n" ) )`
   = note: expanding `print! { concat ! ( "Hello, World!" , "\n" ) }`
   = note: to `$crate :: io :: _print ( format_args ! ( concat ! ( "Hello, World!" , "\n" ) )
           )`
```

The second "`expanding`" note is basically the same as the previous line. We could eliminate that.

Note that it's also common for a macro-call to expand to code that merely *contains* another macro-call somewhere, and in that case we probably shouldn't elide anything.
Repository: vscode
Issue: Explorer / Opened Editors Sorting
Labels: feature-request,file-explorer

Numerous issues have been filed on this topic, merging them into one.

**Done**
* [x] Option for sorting files by type in Explorer #5222
* [x] Give an option to show files before directories in file explorer #22529
* [x] Make listing directories first an option #29329
* [x] Add option to sort files in Explorer side-bar by date modified #11823
* [x] Add sorting to Open Editors list #12453

**Open**
* [ ] Align explorer sorting with platform sorting #27759
* [ ] Feature Request: api to custom files sort order at the sidebar #12345
* [ ] Choose a sort order of directories and files according to the settings pattern #23231
* [ ] Feature to assign a particular file name to appear first in a directory listing #25724
* [ ] Explorer order files names with underline #40679
Repository: You-Dont-Know-JS
Issue: Ch 7 - ES6 and Beyond, typo.
Labels: for second edition

The contribution guidelines says not to worry about typo(s), but I'm not sure I can let a mis-spelled method name slide (:

In the proxies section, right after the first code example, where various traps are listed, 

the explanation for `ownKeys` trap says, that it's invoked for `Object.getOwnSymbolProperties`, but there's no such method.  

You probably meant `Object.getOwnPropertySymbols`

Cheers.
Repository: rust
Issue: Make the ast representation of qualified self paths more syntactic
Labels: C-enhancement,A-parser,T-compiler

The current representation is fine for the HIR, I assume it is optimised for compiler internal stuff. But in the AST, it would be better to be closer to the surface syntax (since that should make parsing, pretty printing, rustdoc, etc. a bit easier). IOW, it is a fine semantic definition, but not a great syntactic definition.
Repository: flutter
Issue: Annotate widgets with a category and subcategory to autogenerate widget catalog
Labels: team,framework,d: api docs,P2,team-framework,triaged-framework

If our widget classes had annotations for category and subcategory, we could:

* extract a widget catalog, and allow our users to slice and dice based on what they are looking for
* explore organization options for docs.flutter.io

Ideally, these annotations are extractable by a tool. For example, dart annotations or very-easy-to-extract doc comments.
Repository: flutter
Issue: onPanEnd, onVerticalDragEnd, onHorizontalEnd have no velocity on fuchsia
Labels: customer: fuchsia,framework,platform-fuchsia,f: gestures,P2,team-framework,triaged-framework

```dart
import 'package:flutter/widgets.dart';

main() async {
  runApp(
    new GestureDetector(
      //onPanStart: (_) => print('p start: $_'),
      //onPanUpdate: (_) => print('p mupdate: $_'),
      //onPanEnd: (_) => print('p end: $_'),
      onVerticalDragStart: (_) => print('v start: $_'),
      onVerticalDragUpdate: (_) => print('v update: $_'),
      onVerticalDragEnd: (_) => print('v end: $_'),
      onHorizontalDragStart: (_) => print('h start: $_'),
      onHorizontalDragUpdate: (_) => print('h update: $_'),
      onHorizontalDragEnd: (_) => print('h end: $_'),
      child: new Container(
        color: new Color(0xFFFFFFFF),
      ),
    ),
  );
}

```
Repository: go
Issue: proposal: x/crypto/ed25519: add montgomery/edwards key conversion
Labels: NeedsFix,Proposal-Crypto

I would like to start building an [XEd25519] implementation.
XEd25519 is a signature algorithm that is fully compatible with Ed25519. It gives you the ability to use the same key for signing and ECDH. I'd like to start by implementing the conversion between points on the equivalent Montgomery and Edwards curves in the [`golang.org/x/crypto/ed25519`] package:

```go
// FromMontgomery converts a montgomery private key to a twisted edwards keypair.
func FromMontgomery(mont []byte) (publicKey PublicKey, privateKey PrivateKey) {}
// ToMontgomery converts a privatekey to its montgomery form.
func (privateKey PrivateKey) ToMontgomery() (mont []byte) {}

// PublicFromMontgomery converts a montgomery public key to an edwards public key.
func PublicFromMontgomery(u []byte) PublicKey {}
func (publicKey PublicKey) ToMontgomery() {}
``` 

It is currently difficult to do this outside of the x/crypto codebase because the [`edwards25519`] package is internal (and this is where all the subtle math that I don't want to reimplement lives). If it is not desirable to have this conversion be in the x/crypto package, an alternative might be moving the `edwards25519` package up a level to make it public (and adding a comment that indiciates that the API is not stable, and maybe never will be; this feels poor though).

## Open Questions

- If accepted, maybe this should live in its own `xeddsa` package in case `curve448` support is implemented later and we want to generalize the implementation over both curves? Or maybe this should only be for if a full xeddsa implementation (not just key conversion) is ever implemented.
- Maybe add `PublicKey` and `PrivateKey` types to the [`curve25519`] package and assume these are always in montgomery format? It would add a dependency loop that would have to be resolved, but might make the API nicer.
- There is some ambiguity about the sign bit when doing the montgomery to edwards conversion; XEdDSA solves this by always setting it to zero [[Jivsov](https://tools.ietf.org/html/draft-jivsov-ecc-compact-05)], but some other scheme might do this differently; maybe we need a generic way in the API to pick the value of the sign bit. There's also a mechanism for cramming it into the signature, but I haven't thought that far ahead yet; it might be worth considering for the API implications though.

[XEd25519]: https://whispersystems.org/docs/specifications/xeddsa
[`golang.org/x/crypto/ed25519`]: https://godoc.org/golang.org/x/crypto/ed25519
[`edwards25519`]: https://godoc.org/golang.org/x/crypto/ed25519/internal/edwards25519
[`curve25519`]: https://godoc.org/golang.org/x/crypto/curve25519

/cc @agl
Repository: opencv
Issue: Drawing functions distorted in OpenCV 3.2.0 when reading buffer in 32BGRA pixel format
Labels: platform: ios/osx,incomplete

When I am trying to draw a circle in iOS using this code

Mat mat = Mat((int)height,(int)width,CV_8UC4,data);
circle(mat, cv::Point(100,100),20.f,cv::Scalar(255,0,0,255), -1);

I get a distorted circle as show in the screenshot. Its almost as if it is drawing in a different space. The pixel format of the camera feed from iOS is 32BGRA.

![screenshot](https://cloud.githubusercontent.com/assets/1677755/26506481/71bebcdc-426a-11e7-84c3-832737b8bda3.jpg)
Repository: youtube-dl
Issue: Request for new site mivo(dot)com
Labels: site-support-request,account-needed

Hello Admin,
I need to record live tv streaming from my country. I found out that youtube-dl can fullfill my need but unfortunately when i've tried it . the result it is said the site not support.
Here is the example:
C:\apk decompile>youtube-dl -u myusername -p mypassword -g https://www.mivo.com/#!/live/metrotv
WARNING: Falling back on generic information extractor.
ERROR: Unsupported URL: https://www.mivo.com/#!/live/metrotv

This site is using account credential..You could signup for free.
Please admin if you have time could you make it work.. Please

Thank You So Much.
Repository: flutter
Issue: Flutter doctor is happy with just JRE, but builds fail without JDK 
Labels: tool,t: flutter doctor,P2,team-tool,triaged-tool

While trying to fix an issue with flutter (`Could not reserve enough space for 1572864KB object heap`) I uninstalled 32bit java and installed 64bit. I picked the JRE isntead of JDK and `flutter doctor` was happy; but builds failed claiming I needed the JDK:

![JDK error](https://cloud.githubusercontent.com/assets/1078012/26508609/4ecc6052-424d-11e7-807a-6200c7a7819e.png)

Installing the JDK fixed the issue. It would be good if `flutter doctor` could check this.
Repository: create-react-app
Issue: Only show lint warnings from most recently edited file in browser console
Labels: tag: enhancement,difficulty: medium,contributions: claimed

This came up in discussion in https://github.com/facebookincubator/create-react-app/issues/2070#issuecomment-304388814.
Seems like a sensible thing to do, although I'm not sure how hard it would be.

Tagging as good first bug but I don't have any ideas on how to do it.