WhereIsAI/github-issue-similarity huggingface dataset:
Issue 1:
This could just be a limitation of my knowledge of bespoke css, but it seems there is redundant code in /dist/css/bootstrap.css (and, presumably in the .min file).

Lines 723 - 761 contain repeats, e.g.,

.container:before,
.container:after {
display: table;
content: " ";
}

.container:after {
clear: both;
}

.container:before,
.container:after {
display: table;
content: " ";
}

etc. I did not see this anywhere else in the .css issues, so I apologize if this is known.

Issue 2:
show on bootstrap.css

https://github.com/twbs/bootstrap/blob/3.0.0-wip/dist/css/bootstrap.css#L581

https://github.com/twbs/bootstrap/blob/3.0.0-wip/dist/css/bootstrap.css#L723

https://github.com/twbs/bootstrap/blob/3.0.0-wip/dist/css/bootstrap.css#L743

https://github.com/twbs/bootstrap/blob/3.0.0-wip/dist/css/bootstrap.css#L2023

https://github.com/twbs/bootstrap/blob/3.0.0-wip/dist/css/bootstrap.css#L2433

https://github.com/twbs/bootstrap/blob/3.0.0-wip/dist/css/bootstrap.css#L2617

https://github.com/twbs/bootstrap/blob/3.0.0-wip/dist/css/bootstrap.css#L2637

https://github.com/twbs/bootstrap/blob/3.0.0-wip/dist/css/bootstrap.css#L3032

https://github.com/twbs/bootstrap/blob/3.0.0-wip/dist/css/bootstrap.css#L3296

https://github.com/twbs/bootstrap/blob/3.0.0-wip/dist/css/bootstrap.css#L3453
Issue 1:
version: go version go1.5 darwin/amd64

There is an example about variable initialization order in the go specs:

var (
a = c + b
b = f()
c = f()
d = 3
)

func f() int {
d++
return d
}

the spec gives the initialization order is d, b, c, a. but the result of above example is not the same as the order spec gives.

package main

import "fmt"

var (
a = c + b
b = f()
c = f()
d = 3
)

func f() int {
d++
return d
}

func main() {
fmt.Println(a, b, c, d)
}

$go run example.go

9 5 4 5

according to the result, the actual init order should be d ,c ,b, a, not the same as the order in spec.

Issue 2:
$ cat incorrect_init.go
package main

var (
a = p("a") + c + b
b = p("b") + f()
c = p("c") + f()
d = p("d") + 3
)

func f() int {
d++
return d
}

func p(s string) int {
println(s)
return 0
}

func main() {
println(a, b, c, d)
}

compiling and executing produces:

$ go run incorrect_init.go
d
c
b
a
9 5 4 5

But the correct order per the spec should be: d, b, c, a, with values 9, 4, 5, 5.

See: http://tip.golang.org/ref/spec#Package_initialization
Issue 1:
This is my simple code in index.js

globalShortcut.register("CmdOrCtrl+q", () => {
app.isQuiting = true;
app.quit();
})

This works fine. But when used via an azerty keyboard, CMD + A is triggering the actions inside this block.

Issue Details

Electron Version:

8

Operating System:

Mac 10.15.7

Expected Behavior

CMD + A should select all

Actual Behavior

CMD + A is triggering events for CMD + Q

Issue 2:
Preflight Checklist

I have read the Contributing Guidelines for this project.

I agree to follow the Code of Conduct that this project adheres to.

I have searched the issue tracker for an issue that matches the one I want to file, without success.

Issue Details

Electron Version:

9.0.0-beta.2

8.0.1

7.1.13

7.0.0

Operating System:

Linux xps 5.5.4-arch1-1 #1 SMP PREEMPT Sat, 15 Feb 2020 00:36:29 +0000 x86_64 GNU/Linux (Arch Linux current)

macOS 10.15.3

Last Known Working Electron version:

6.1.8 -- fine, not affected

Expected Behavior

When safeDialogs option is used, I expect to see a "Prevent this app from creating additional dialogs" checkbox on all alerts after the first one, like it happened in Electron 6.1.8.

I expect safeDialogs option to do at least something.

Basically, how 6.x behaves.

Actual Behavior

That checkbox does not appear on second alert, or on any other subsequent alert (tried about 10).

There seems to no observable difference at all between turning that option on or off.

To Reproduce

const { BrowserWindow, app } = require('electron')
app.on('ready', () => {
const window = new BrowserWindow({
webPreferences: {
//partition: 'memory',
safeDialogs: true,
}
})
window.webContents.loadURL('about:blank') // also could be e.g. https://example.com/
window.webContents.on('did-finish-load', () => {
window.webContents.executeJavaScript(`
document.body.innerText = window.navigator.userAgent // (not required)
alert(0)
setTimeout(() => { alert(1) }, 100) // timeout for UA to be shown
`)
})
window.show()
})

Screenshots

v6.1.8 (correct behavior)

v7.0.0

v7.1.13

v8.0.1

9.0.0-beta.2

Additional Information

Documented here: https://www.electronjs.org/docs/api/browser-window#new-browserwindowoptions

This does not seem to be a duplicate of closed #17543, as this affects only versions starting from v7.0.0.

This does not seem to be a problem of specific configuration/url/scheme/whatever -- I was not able to make that option work on a recent Electron version with any attempted configuration.
Issue 1:
I am trying to view image using Glide Library for some reason the background is coming up green/white.. I am checked the image URL the background is transparent. First time the images show up properly but when I open the APP again the images have green/white background. I am not sure why this is happening could be a bug?

Here are the code:

activityadapter.xml:

<RelativeLayout
android:id="@+id/abcd"
android:layout_width="120dp"
android:layout_height="120dp"
android:layout_centerHorizontal="true"
android:gravity="center_vertical">

<ImageView
android:id="@+id/grid_item_image"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:layout_centerHorizontal="true"
android:layout_centerInParent="true"
tools:ignore="ContentDescription" />
</RelativeLayout>

activityAdapter.java: Put all the images inside listview:

Has glide details from aDapter:

Glide.with(DetailActivity.this)
.load(pd.getImage())
.diskCacheStrategy(DiskCacheStrategy.ALL)
.fitCenter()
.dontTransform()
.crossFade()
.into(imageProduct);

Screenshot:

Check the black marks: They have green background - It should be transparent which happens the first time it loads.

{removed}

Is this a bug or am I doing something wrong?

Issue 2:
This is the original image:

This is the image rendered using Glide and ImageView:

I'm already using the ARGB_8888 option with the following initialization code:

new GlideBuilder(this).setDecodeFormat(DecodeFormat.PREFER_ARGB_8888);

Switching to Picasso does seem to resolve the problem. What might be wrong here?
Issue 1:
When I run example in nextjs. Do yarn and yarn dev to run the demo application. Hit to http://localhost:3000 then it throw the error is not a function

[ x ] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior

Can call the createGenerateClasName as usually

Current Behavior

Error throwed:

TypeError: (0 , _styles.createGenerateClassName) is not a function
at createContext (/Users/nampdn/Projects/wfc/@example/nextjs/styles/getContext.js:20:3)
at getContext (/Users/nampdn/Projects/wfc/@example/nextjs/styles/getContext.js:35:5)
at Function.MyDocument.getInitialProps (/Users/nampdn/Projects/wfc/@example/nextjs/pages/_document.js:61:3)
at _callee$ (/Users/nampdn/Projects/wfc/@example/nextjs/node_modules/next/dist/lib/utils.js:36:30)
at tryCatch (/Users/nampdn/Projects/wfc/@example/nextjs/node_modules/regenerator-runtime/runtime.js:62:40)
at Generator.invoke [as _invoke] (/Users/nampdn/Projects/wfc/@example/nextjs/node_modules/regenerator-runtime/runtime.js:296:22)
at Generator.prototype.(anonymous function) [as next] (/Users/nampdn/Projects/wfc/@example/nextjs/node_modules/regenerator-runtime/runtime.js:114:21)
at step (/Users/nampdn/Projects/wfc/@example/nextjs/node_modules/babel-runtime/helpers/asyncToGenerator.js:17:30)
at /Users/nampdn/Projects/wfc/@example/nextjs/node_modules/babel-runtime/helpers/asyncToGenerator.js:35:14
at new Promise (<anonymous>)

Steps to Reproduce (for bugs)

curl https://codeload.github.com/mui-org/material-ui/tar.gz/v1-beta | tar -xz --strip=2 material-ui-1-beta/examples/nextjs

cd nextjs

yarn

yarn dev

Open browser: http://localhost:3000

Context

Your Environment

Tech
Version

Material-UI
1.0.0-beta.24

React
16.2

browser
Chrome

OS
MacOS

Issue 2:
I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior

App should start without issue with MUI compiling properly.

Current Behavior

I get the following error after installing v0.20.0 and running npm start:

Failed to compile
./node_modules/@devexpress/dx-react-grid-material-ui/dist/dx-react-grid-material-ui.es.js
1071:4-18 'material-ui' does not contain an export named 'TableSortLabel'.

When l look in the node_modules folder, there is no TableSortLabel.js file in the Table folder. I do see it in the repo though (https://github.com/mui-org/material-ui/blob/v1-beta/src/Table/TableSortLabel.js).

Steps to Reproduce (for bugs)

npm uninstall material-ui

npm install material-ui@latest

Start your app (npm start, yarn start, etc.)

See the "Failed to Compile" error.

Context

Can not start app with lastest version of MUI.

Your Environment

Tech
Version

Material-UI
0.20.0

React
15.6.1

browser
all

etc
Issue 1:
Proposed feature

I have often had to use interpolation to plot the mean ROC or PR curves of several classifiers, as the number of thresholds can be distinct for each und thus their TPR, FPR, precision, and recall lengths vary. I thought it would be convenient to add a function argument "interp_dim" to the functions "roc_curve" and "precision_recall_curve" so the user can ensure that all classifier metrics have the same lengths, which would make it easier to plot the average.

Proposed solution

Perform numpy interpolation on TPR, FPR, precision and recall arrays to ensure they have the same length (as specified by the "interp_dim" function argument), which simplifies the computation of the mean.

I opened this issue to see if this idea receives support from the community before making a pull request.

Issue 2:
Hi,

Scikit Learn seems to implement Precision Recall curves (and Average Precision values/AUC under PR curve) in a non-standard way, without documenting the discrepancy. The standard way of computing Precision Recall numbers is by interpolating the curve, as described here:

http://nlp.stanford.edu/IR-book/html/htmledition/evaluation-of-ranked-retrieval-results-1.html

the motivation is to

Smooth out the kinks and reduce noise contribution to the score

In any practical application, if your PR curve ever went up, then you would strictly prefer to set your threshold there rather than at the original place (achieving both more precision and recall). Hence, people prefer to interpolate the curve, which better integrates out the threshold parameter and gives a more sensible estimate of the real performance.

This is also what standard code for Pascal VOC does and explain this in their writeup:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.157.5766&rep=rep1&type=pdf

VL_FEAT also has options for interpolation:

http://www.vlfeat.org/matlab/vl_pr.html

and as shown in their code here: https://github.com/vlfeat/vlfeat/blob/edc378a722ea0d79e29f4648a54bb62f32b22568/toolbox/plotop/vl_pr.m

The concern is that people using the scikit version will see incorrectly reported LOWER performance, than what they might see reported in other papers.
Issue 1:
I just updated my composer deps regarding the fresh new Symfony 3.0.4.

I was surprised to see when I loaded my application in the Web debug bar the symfony version to 3.0.4-dev.

I looked at v3.0.4 tag and seems that it's not pointing to the good commit.

What happened?

Issue 2:
follow up to #12401

in the CMF project we have encountered some bugs with 5.3 that we cannot work around (mostly with image manipulation). Also 5.3 can cause issues with memory consumption with composer.

Also as long as Symfony core supports 5.3, we kind of also imply we expect the same from our eco system. If however our ecosystem starts using 5.4+ more, then it will become more confusing for our users. Especially hosters (even internal IT) might claim that "5.3 is good enough because its supported by Symfony core" .. so I think its worth thinking about moving to 5.4+, even if there are no specific features we intend to use from 5.4 (we can of course provide traits without moving to 5.4)
Issue 1:
I can make changes to an object displayed in an *ngFor repeater with trackBy ... until I do something to trigger trackBy intervention.

NgForTrackBy indeed does prevent unnecessary DOM updates when the list is refreshed with "new" content that satisfies the trackBy selection criteria.

However, it is a little too rigorous. Once I trigger it, it no longer updates the view with changes to the data-bound object.

Here is a plunker repro.

Change the name ... both repeater displays update

Click Refresh Heroes a few times. Each click replaces the heroes list with a new array of hero clones.

Note the message under the first (no trackBy) display that reports each time the DOM elements have changed.

Note that no such message appears under the second (with trackBy) display because the DOM elements are untouched. Although the hero objects change, trackBy doesn't replace the DOM elements. That's exactly what we want from trackBy!

Now change the name again. SAD FACE! The second (with trackBy) display is frozen. The changes do not appear.

This behavior makes ngForTrackBy essentially useless.

the displayed list is semi-immutability, which fits few if any scenarios

we can't update the displayed object in any way once frozen

this is no good for mutable entity scenarios

this is no good for redux or immutable scenarios either ... because we see only the last mutated state of the entities, not the refreshed entities (as they might be after re-query from a server).

Here is an animated gif showing the unexpected and unwanted behavior.

Notice the last few frames where I make changes _after_ freezing the second trackBy display .

Issue 2:
I'm submitting a ...

[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

When Resolve returns Observable and non-false value is resolved, navigation should continue, but it doesn't.

Expected behavior

Navigation should proceed and resolved data should be passed to ActivatedRoute.data field.

Minimal reproduction of the problem with instructions

http://plnkr.co/edit/eJpzsXEM5CyurCs4jc1e?p=preview

In menu click on "Second Link - Correct using Resolve"

Please tell us about your environment:

Fedora 24

Angular version: 2.1.2

Browser: [ Chrome 54 | Firefox 49 ]

Language: [TypeScript 2]
Issue 1:
When you open Atom, the first project is opened in the current window without loading information like opened tabs and panes.

If you try open it in dev mode (shift+cmd+O), the same happens plus it does not open in dev mode like it should.

Issue 2:
Like I mentioned here in my comment opening a folder won't work for the first time you open it, wether if you drag&drop it or just open it via the shortcut.

Same Problem on two different computers with Atom (0.124.0) running on Mac OS X (Mavericks).
Issue 1:
I have an auto-scaling group that's a duplicate of the one created by kube-up for AWS using Ubuntu 15.04 minions, the only difference being it requests spot instances. When a spot instances is rebooted for whatever reason (they aren't stable), it fails to launch any pods because of an aufs error. I don't know if this only happens with spot instances, but this was the case for me this time, so it might be relevant.

This is not the first time I've seen this error. If I manually terminate the instance, which causes the ASG to request a new spot instance, the new node will launch pods successfully.

Error pulling image (prd-beb0010d) from me/project, Driver aufs failed to create image rootfs 08ecf065655b44634e66f45201a7d379d30ba877791b1765322dabf57e993f11: open /mnt/ephemeral/docker/aufs/layers/4a5e6db8c0693a16de88b7559ded7c1cb804018571b137e13abb1713ce6a71cf: no such file or directory
API error (500): error creating aufs mount to /mnt/ephemeral/docker/aufs/mnt/38143c22f7a2644da4bc0cd8782a24a95274eaf255c9468dedbeea2d7c4b2b76-init: invalid argument

Issue 2:
Running Kubernetes 1.4.1 at AWS (Ubuntu 14.04 LTS). Kubernetes cluster is spinned with 'contrib/ansible' playbook with the only change of --cloud-provider aws argument added to all cluster internal services (such as kubelet).

After spinning up and terminating several pods with config like below

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: kafka1
spec:
replicas: 1
template:
spec:
containers:
- name: kafka1
image: daniilyar/kafka
ports:
- containerPort: 9092
name: clientconnct
protocol: TCP
volumeMounts:
- mountPath: /kafka
name: storage
volumes:
- name: storage
awsElasticBlockStore:
volumeID: vol-56676d83
fsType: ext4

I see a following error in kubelet logs logged each 40-60 sec:

E1018 21:03:09.616581 22780 fs.go:332] Stat fs failed. Error: no such file or directory

Error contains a different line number than in #17725 , so I assume this one is probably not a duplicate.
Issue 1:
Eric Bottard opened SPR-5924 and commented

Hard coded request mapping values should take precedence over path variables. Wild card patterns in a path are currently inferior to explicit values. Path variables should be applied after explicit paths and before wild cards.

For example:

@RequestMapping(value = "/resources/new/", method = RequestMethod.GET)

is currently trumped by

@RequestMapping(value = "/resources/{resourceName}/", method = RequestMethod.GET)

@RequestMapping(value = "/resources/new/", method = RequestMethod.GET)

currently trumps

@RequestMapping(value = "/resources/*/", method = RequestMethod.GET)

@RequestMapping(value = "/resources/new/", method = RequestMethod.GET)

should trump

@RequestMapping(value = "/resources/{resourceName}/", method = RequestMethod.GET)

should trump

@RequestMapping(value = "/resources/*/", method = RequestMethod.GET)

Affects: 3.0 M1

Issue Links:

#10035 @RequestMapping best match gives wrong Controller method when using wildcards ("is duplicated by")

#10040 PathVariable mappings are greedy over hard coded mappings

#10401 @Controller method order effects @RequestMapping behavior in ways not expected

Referenced from: commits 8073efd, abfc479

Issue 2:
Jonathan Ruckwood opened SPR-7242 and commented

I'm in a situation where there is prolific use of @ModelAttribute annotations in a project, however in most circumstances the model-data is only needed on either the POST or GET, consequently we are needlessly resolving attributes when they won't be used.

I'm proposing something along the lines of this:

@ModelAttribute("orderAddressList", RequestMethod.GET)
@ModelAttribute("orderAddressList", {RequestMethod.GET, RequestMethod.POST})
@ModelAttribute("orderAddressList") // Optional, without any RequestMethod the annotation works as it does currently.

The following should not be allowed, i.e. an exception should be thrown:

@ModelAttribute("foo", RequestMethod.GET)
public Foos getFoos() {
return foos;
}

@RequestMapping(method = RequestMethod.POST)
public String doPost(@ModelAttribute("foo") Foos foos) { // <-- causes exception as foo is only available for GET request.
return "fooView";
}

An added benefit of this is that it increases readability of annotated controllers. For example, a new developer can get more information from a controller's data-model by scanning the annotations alone.

Implementing this would help us mitigate our problem, however I also feel that it would be a useful enhancement to the wider community.

Thanks.

Affects: 3.0.2

4 votes, 7 watchers
Issue 1:
I'm submitting a ... (check one with "x")

[x] feature request

Current behavior

There's no way to list the current validators that are applied to a FormControl / AbstractControl.

What is the motivation / use case for changing the behavior?

I'd like to create dynamic error messages, and apply attributes in child components based on the validators that are present.

For example, I would like to be able to add the maxlength HTML attribute on to a text box control, if the maxLength validator is present (to reduce duplication) - but I need to be able to access the validator's metadata to do so.

The closest I can get is the following, but because the error object only exists after the user has typed over the validator limit, I can only limit it to 11 chars, instead of the expected 10:

FormBuilder config excerpt:

firstName: ['', [Validators.required, Validators.maxLength(10)]]

Template:

<input type="text"
formControlName="firstName"
[attr.maxlength]="control.getError('maxlength')?.requiredLength"

Where control is an AbstractControl.

Issue 2:
Potential Bug:

The string "1" results in query param value true:

this.router.navigate([
'/UserList',
{page: '1'}
]);

// --> /users/?page (actual)
// --> /users/?page=1 (expected)

Question:

Update: Duplicate of #2959.

Is it intended that more complex query params aren't supported? Example:

this.router.navigate([
'/UserList',
{
filtering: {
name: 'Andrew',
age: 22
}
}
]);

// --> /users/?filtering=[object%20Object] (actual)
// --> /users/?filtering[name]=Andrew&filtering[age]=22 (expected)
Issue 1:
I have searched the issues of this repository and believe that this is not a duplicate.

I have checked the FAQ of this repository and believe that this is not a duplicate.

Environment

Dubbo version: 2.7.3

Operating System version: Windows 10

Java version: 1.8

Steps to reproduce this issue

正常运行demo

Expected Result

不会发生报错

Actual Result

报path和contextpath长度超过200错误。分析代码得知这两个值是系统的环境变量，windows上环境变量通常设置很多，长度很容易超过200。不知道为啥要设置长度不超过200。

Issue 2:
I have searched the issues of this repository and believe that this is not a duplicate.

I have checked the FAQ of this repository and believe that this is not a duplicate.

Environment

Dubbo version: xxx

Operating System version: xxx

Java version: xxx

Steps to reproduce this issue

http://start.dubbo.io/ 无法正常访问

Pls. provide [GitHub address] to reproduce this issue.

Expected Result

What do you expected from the above steps？

Actual Result

What actually happens?

If there is an exception, please attach the exception trace:

Just put your stack trace here!
Issue 1:
Is your feature request related to a problem? Please describe.

Introduced here – #16390, WebGLMultipleRenderTargets extends WebGLMultipleRenderTarget which on the surface works, however when we came to create the .d.ts file – three-types/three-ts-types#85 we began to discuss how maybe this shouldn't be the case. Calling WebGLMultipleRenderTargets.setTexture would fail because you'd either have to supply an array which would break:

texture.image = {
width: this.width,
height: this.height,
depth: this.depth
};

see:

three.js/src/renderers/WebGLRenderTarget.js

Line 46
in
d39d829

texture.image = {

Alternatively not passing an array of Textures, would break the WebGLMultipleRenderTargets.

Describe the solution you'd like

Whilst I appreciate how helpful it is to extend a lot of the features already written in WebGLMultipleRenderTarget, maybe there should be a utility/base class that they both inherit from, this would reduce duplication (which is why we extend classes in the first place) and equally avoid the edge cases described above that will impact users.

Additional context

For anyone interested, the .d.ts file will probably just duplicate the properties and methods included in WebGLMultipleRenderTarget

Issue 2:
In GLTFLoader we can load standard materials using StandardMaterial .

However, the alpha channel of its texture doesn't be handled properly, when renderer's alpha is activated.

In OPAQUE or MASK material, alpha channels of texture should be negated:

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#alpha-coverage

Change the material's blend mode to ZERO-ONE (in GLTFLoader) might solve this problem?

This is how it should be (rendered in Unity):

Here's how it looks like in Three.js GLTFLoader:

This is the source code:

https://github.com/FMS-Cat/cube-gradient-alpha

Environment:

Three.js version: r99

Browser: Confirmed in Chrome, Firefox, Edge

OSes: Windows. Has not tested in other env

Hardware: Probably no requirements