WhereIsAI/github-issue-similarity huggingface dataset:
Issue 1:
Preflight Checklist

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

I have read the Contributing Guidelines for this project.

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

Electron Version

12.0.5

What operating system are you using?

Other Linux

Operating System Version

Arch Linux

What arch are you using?

Other (specify below)

Last Known Working Electron version

No response

Expected Behavior

Electron shouldn't change the default behavior of apps, launched by electron

Actual Behavior

All electron apps will start additional 3rd party apps in xwayland mode. This results in a conflict for some of them. Like firefox, if firefox is already launched and you press a link in an electron app, firefox will respond with a message "Firefox is already running, but is not responding. To use Firefox, you must first close the existing Firefox process, restart your device, or use a different profile.", because firefox xwayland can not run inside a native wayland firefox.

Testcase Gist URL

No response

Additional Information

Steps to reproduce:

Be on a wayland session (with xwayland support, like GNOME; check with echo $XDG_SESSION_TYPE)

Launch firefox in wayland mode: MOZ_ENABLE_WAYLAND=1 firefox (could be default on your distro anyways, you can check after launch in about:support.)

make sure that firefox is your default browser.

Launch an Electron app

Click a link in this electron app

Issue 2:
I'm assuming this is controlled by Atom Shell and not Atom, so I'm reporting it here; process.env.PATH does no longer match the user's $PATH environment variable. It is instead some form of system default, "sanitized" value.

This regression seems specific to OS X. I have verified process.env.Path is not "sanitized" on Windows 8.1 running Atom v0.120.0. The inconsistency might be accidental because on Windows the environment variable is named Path and not PATH. I have not tested to see if the regression also occurs on any GNU/Linux distributions.

Tried to scan through the recent commits to figure out when this regression got introduced, but had no such luck... perhaps it's related to the recently upgraded Chromium?

All other environment variables are correctly read (and passed to) Atom. Which means that this works

$ EVERYTHING=/is/awesome atom

in that the variable can be read in Atom via e.g. console.log(process.env.EVERYTHING), whereas this

$ PATH=$PATH:/ermahgerd atom

does not. Regardless of what I do, console.log(process.env.PATH) always displays /usr/bin:/bin:/usr/sbin:/sbin.

Update:

Tested with Atom v0.120.0 and Atom built from source, running on OS X Yosemite Beta 1.

Installing fresh copies of OS X 10.9.4 and 10.10 in VMs now, to see if I can reproduce the old behavior and the regression.
Issue 1:
Describe the bug

We've been hitting this for awhile but finally dug into exactly why it's happening. With the addition of a normal offset bias for shadows (#18915) normals are required in the vertex shader to compute the fragment position in the shadow frame. However if vertex normals are not available on the geometry then the behavior of this section of code seem unpredictable. On an NVidia GTX 1080 and Intel integrated graphics no shadows are rendered on the mesh with flat shading enabled but shadows are rendered as expected with a Radeon Pro 560. We are using flat shaded materials on some of our models that do not have vertex normals and / or it's too expensive to generate them because our geometry is dynamic.

To Reproduce

Steps to reproduce the behavior:

Go to https://jsfiddle.net/1dptcou6/.

See that shadows are not displayed on the plane with flatShading enabled and no geometry normals.

Comment out the flatShading: true line on material instantiation and line removing vertex normals.

Shadows are rendered as expected.

Live example

https://jsfiddle.net/1dptcou6/

Expected behavior

Shadows render normally even when Material.flatShading = true and no vertex normals are available. This worked as expected until r118 onward.

Platform:

Device: 2017 Microsoft Surface Laptop

OS: Windows 10

Browser: Chrome

Three.js version: r118+

Also observed with NVidia GTX 1080 GPU on Windows and Intel Integrated Graphics on OSX.

cc @Oletus

Issue 2:
Minecraft Education edition has a tool for exporting .GLB files directly from the game, but the resulting GLB file won't receive shadows when displayed using three.js on Windows devices.

This issue occurs when using Windows browsers (Firefox, Chrome, Edge), but not when using MacOS browsers (Chrome, Firefox, and Safari). See the original thread on discourse.threejs.org for more information.

Steps to reproduce the behavior:

Go to the demo website.

Note that on Windows, the red sphere does not cast a shadow onto the Minecraft model.

Live example

https://2cf782ea.minecraft-website.pages.dev/

Source code can be found in this GitHub repository.

Expected behavior

The red sphere should cast a shadow onto the 3D model.

Screenshots

Windows users don't see the sphere shadow, its absence circled in red.

Mac users see the shadow as expected, as well as the model casting shadows on itself.

Platform:

Device: [Desktop]

OS: [Windows]

Browser: [Chrome, Firefox, Edge]

Three.js version: [r126]
Issue 1:
Electron version: v1.2.4

Operating system: docker image node:6.2.2 (debian derived) running Xvfb

When running electron-prebuilt on debian in docker, electron exits WITHOUT firing the app.on('ready', () => {}) callback.

Here's the stack dump generated by running with ELECTRON_ENABLE_STACK_DUMPING=true:

Received signal 11 SEGV_MAPERR 000000000000
#0 0x00000140f1eb <unknown>
#1 0x7ff897ff98d0 <unknown>
r8: 0000000000000006 r9: 0000000000000002 r10: 00000000034ac851 r11: 00007ff8997953ec
r12: 0000192062db5280 r13: 00007ff88f875b00 r14: 00000000000025cf r15: 0000192062dff420
di: 00007ff88f875b00 si: 00000000000025cf bp: 0000192062ddec90 bx: 0000000000000001
dx: 00007ff88f65ac40 ax: 0000192062ddec80 cx: 00000000034ac918 sp: 00007ffefcf3aed8
ip: 0000000000000000 efl: 0000000000010206 cgf: 0000000000000033 erf: 0000000000000014
trp: 000000000000000e msk: 0000000000000000 cr2: 0000000000000000
[end of stack trace]

See this gist for a minimal example that reproduces the issue here: https://gist.github.com/qrohlf/02b4152d788a103a9596b2444b0d5500

Issue 2:
Electron version: 1.2.4

Operating system: Linux xxx 4.2.0-38-generic #45~14.04.1-Ubuntu SMP Thu Jun 9 09:27:51 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

I was trying to set 1.2.2 - 1.2.3 versions and works fine. When updating to 1.2.4 app.on('ready'...) never works. No errors output on console.

Trying "Quick start" from electron. https://github.com/electron/electron-quick-start
Issue 1:
It would be really nice if we could show the name of the shell in the tab title instead of the full path to it. It would make the tab titles shorter, and allow for easier visual recognition of which tabs are what. Ideally, if there is more than one tab with the same name it should append "-1", "-2", etc. to the tab name.

Issue 2:
"Is it also possible to shown a short title instead of the whole path?"

Originally posted by @wahid in #491 (comment)
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

Steps to reproduce this issue

Expected Result

Actual Result

// private 应该改为 private static 保持统一
static private class DestroyableExporter<T> implements Exporter<T> {
// 省略
}

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: 2.7

Operating System version: Ubuntu 16.04 x64

Java version: 1.7

Steps to reproduce this issue

是这样的，我在想为什么dubbo2.7的异步调用返回的结果不用ChannelFurture去实现呢

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

Example：https://netty.io/4.0/api/io/netty/channel/ChannelFuture.html
Issue 1:
What problem does this feature solve?

I'm using a global error handler for process errors during component render function and watchers.

But it does not catch the exception thrown in the list method below:

export default {
data() {
return {
key: null,
};
},
watch: {
async key() {
await this.list();
},
},
methods: {
async list() {
return axios.get('An invalid url');
},
},
};

What does the proposed API look like?

No need to change API

Issue 2:
Version

2.5.17-beta.0

Reproduction link

https://jsfiddle.net/w5d9gqmo/3/

Steps to reproduce

In provided example:

open console

hit increment

observe computed value evaluations in console

In vue terms:

create dependency structure with many paths to the same watcher (A->B, B->C, A->C)

Notify leaf watcher about change (data change)

Observe too eager synchronous updates of watchers on every intermediate change

What is expected?

All updated computed values are executed once and with correct dependant values.

twoCounts evaluated to: {count: 2, countPlusOne: 3}

What is actually happening?

Computed values are executed multiple times with all intermediate dependency values.

twoCounts evaluated to: {count: 2, countPlusOne: 2}
twoCounts evaluated to: {count: 2, countPlusOne: 3}

The issue is clearly caused by this commit: 653aac2

I did some debugging and found the cause.

Dependencies are notified synchronously about the watcher update in the notify loop, but the updating watchers might be accessed too early with stale value and no information about necessary recomputation.

I attempted a fix by splitting Dep.notify into two phases with separate loops for dirtify and update. It worked for simple situations where there is triangle of dependencies (countPlusOne in the example), but it stops working when the graph is any more complicated (paths are larger than 1). This is illustrated by countPlusTwo computed in the example.

Possible full fix would involve either traversing the full dependency graph to dirtify all deep dependants first, or collecting the the array of dependants of my dependants like in previous implementation.
Issue 1:
Bug report

Hi guys, when I use dev: false inside my app, material-ui classes wont load.

Describe the bug

That's the code:

const port = process.env.PORT || 3000;
const dev = process.env.NODE_ENV !== 'production';
const app = next({ dev: false });
const handle = app.getRequestHandler();

app.prepare().then(() => {
const server = express();

// Routes and stuff...
})

The expected result should be:

but is:

To Reproduce

Steps to reproduce the behavior, please provide code snippets or a repository:

Install @material-ui

"@material-ui/core": "latest",
"@material-ui/icons": "^3.0.1",
"@material-ui/styles": "^3.0.0-alpha.2",

Run the server with production build

System information

OS: macOS Mojave v10.14.2

Version of Next.js: 7.0.2

Issue 2:
Bug report

Describe the bug

Used the material-ui Next.js starter https://github.com/mui-org/material-ui/tree/master/examples/nextjs, and wrote an app.

The app works fine when running with yarn dev, yarn start, and a custom server.js with dev set to true, but when I deploy it using a custom server.js, CSS styles aren't applied when running in production mode (next({dev: false})).

The HTML comes just fine, styled, from the server (for less than a second it looks as it should), but as soon as the client side code executes, the styling goes away. There is nothing in the Console.

To Reproduce

Here's my server.js, which I execute with: yarn build ; node server.js:

const compression = require('compression');
const next = require('next');

const port = parseInt(process.env.PORT, 10) || 3000;

const dev = false;
const app = next({dev});
const handle = app.getRequestHandler();

app.prepare()
.then(() => {
const server = express();
server.get('*', (req, res) => {
return handle(req, res);
});
server.listen(port, (err) => {
if (err) throw err;
console.log(`> Ready on http://localhost:${port} Dev? ${dev}`)
})
});

Expected behavior

The page should look the same no matter what the value of dev is.

System information

OS: Windows 10, Ubuntu

Browser Chrome, Firefox, Edge

Version of Next.js: 7.0.2

Additional context

I searched the existing issues and the closest that matched was 4470, but that recommended using the material-ui code example, which I'm already doing.

I have a custom next.config.js for loading environment variables:

const path = require('path');
const dev = process.env.NODE_ENV !== 'production';
module.exports = {
webpack: (config) => {
config.plugins.push(new Dotenv({
path: path.join(__dirname, dev ? '.env.development' : '.env.production'),
systemvars: true
}));
config.resolve.extensions = ['.js', '.jsx'];
return config
}
};
Issue 1:
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

Given a 3rd-party component that correctly uses OnPush change detection (since it only renders based on inputs), if you try to communicate with that 3rd-party component using ngModel and a ControlValueAccessor, the component fails to respond to change detection and never triggers the ngOnChanges() life-cycle method.

Expected behavior

When the ControlValueAccessor writes to the 3rd-party component's inputs, it should trigger change detection and the ngOnChanges() life-cycle method. This way, 3rd-party components that you do not have ownership over can be integrated into an ngModel control-flow.

Minimal reproduction of the problem with instructions

Plunkr: https://plnkr.co/edit/oS1qWN7x7nXlQ4oNwR5j?p=preview

In the demo, you'll see that the two components cannot stay in sync. This is because the first one uses input and the second one uses ngModel.

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

I believe this is a bug that inhibits the ability to consume components that you did not write yourself.

Please tell us about your environment:

Chrome on Plunkr.

Angular version: 2.0.X

This is with whatever Plunkr is currently using for @angular.

Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]

Chrome and Firefox.

Language: [all]

Node (for AoT issues): node --version =

Issue 2:
After upgrading to alpha.48 I noticed that the http module no longer can stand on its own...

According to the examples we now have to import rxjs/operators/map to even get access to the essential map() method.

I am wondering, isn't this a bit clunky and unnecessary? Why reveal the dependency on rx.js like this?

Shouldn't this be abstracted from us? Seems like we also have to include rxjs separately in addition to Angular 2??

If rx is this visible in Angular 2.0, why provide map() etc via the http module at all? Can't you just use rx.js directly?

P.S. This is not listed as a breaking change in the change log :-)
Issue 1:
📝 Provide a description of the new feature

It would be great to add the possibility to apply remapping to a specific keyboard device only (for example if the user uses a small keyboard or numpad for macros only). The keyboard can be specified with its USB PID or a more user friendly device selector.

If you'd like to see this feature implemented, add a 👍 reaction to this post.

Issue 2:
A way to switch between different keyboards, specifically those with different layouts

My use case:

I use a windows laptop with a windows keyboard layout. I remap some of those keys to my liking.

When I connect to an external apple keyboard, I would like to be able to utilize a new mapping set so that the keys map the same as on the internal keyboard with the win layout.

What is the expected behavior of the proposed feature? What is the scenario this would be used?

Ideally, this would be a different key mapping for each physical keyboard that does not require manual intervention when docking.

Acceptable would be allowing me to swap keyboard layouts manually. Either by a keymap profile selector, or even a way to save the layout to a config file and load it up.

If you'd like to see this feature implemented, add a 👍 reaction to this post.
Issue 1:
a = torch.tensor(1)

b = torch.tensor(0)

c = a/b (output 'Floating point exception' then crash)

Issue 2:
This seems to be an issue with TH and not pytorch, the same thing happens in lua torch.

import torch
a = torch.IntTensor([0,1])
b = torch.IntTensor([0,1])
print(a.div(b)) # Floating point exception (core dumped)

Another unrelated weirdness happens with float tensors when the answer is inf

import torch
a = torch.FloatTensor([1,1])
b = torch.FloatTensor([0,0])
a.div(b)

which works on lua torch, but gives

<repr(<torch.FloatTensor at 0x7f8a012eee18>) failed: RuntimeError: inconsistent tensor size at /tmp/pip-zh0a53-build/torch/lib/TH/generic/THTensorMath.c:90>

in pytorch.

cc @ezyang @gchanan @zou3519
Issue 1:
In Bootstrap 3.2.0 adding a form-control-feedback icon to a select input causes the icon to hover over the select's dropdown icon, thus it's not clickable anymore.

It looks like this:

with the following HTML:

<div class="form-group has-feedback has-error">
<label for="myselect">A label</label>
<select id="myselect" class="form-control">
<option>Option 1</option>
<option>Option 2</option>
<option>Option 3</option>
</select>
<span class="glyphicon form-control-feedback glyphicon-remove"></span>
</div>

<div class="form-group has-feedback has-error">
<label for="myselect">A label</label>
<div class="input-group">
<div class="input-group-addon"><span class="glyphicon glyphicon-tag"></span></div>
<select id="myselect" class="form-control">
<option>Option 1</option>
<option>Option 2</option>
<option>Option 3</option>
</select>
</div>
<span class="glyphicon form-control-feedback glyphicon-remove"></span>
</div>

The first one is quite easy to fix:

.form-control + .form-control-feedback {
right: 12px;
}

but I haven't found a solution for the latter without using a special class with selects.

See it live: http://jsfiddle.net/wedi/2bht4o65/1/

Edit: Fixed validation error below, moved to jsfiddle, Bootply didn't work anymore.

Issue 2:
I have found a bug at select input with validation icon.

http://jsfiddle.net/57XnU/1/
Issue 1:
https://k8s-gubernator.appspot.com/build/kubernetes-jenkins/logs/kubernetes-e2e-aws/6373/

Failed: BeforeSuite {Kubernetes e2e suite}

/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/test/e2e/e2e.go:158
BeforeSuite on Node 1 failed
/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/test/e2e/e2e.go:158

Previous issues for this test: #26135 #26236 #27920 #28492 #29970 #30075 #32980 #33313

Issue 2:
https://k8s-gubernator.appspot.com/build/kubernetes-jenkins/logs/kubernetes-e2e-gce-scalability/10992/

Failed: BeforeSuite {Kubernetes e2e suite}

/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/test/e2e/e2e.go:158
Sep 23 11:26:08.874: Error waiting for all pods to be running and ready: 1 / 418 pods in namespace "kube-system" are NOT in the desired state in 10m0s
POD NODE PHASE GRACE CONDITIONS
node-problem-detector-v0.1-dwpq2 e2e-scalability-minion-group-i5cw Pending [{Initialized True 0001-01-01 00:00:00 +0000 UTC 2016-09-23 11:12:13 -0700 PDT } {Ready False 0001-01-01 00:00:00 +0000 UTC 2016-09-23 11:12:13 -0700 PDT ContainersNotReady containers with unready status: [node-problem-detector]} {PodScheduled True 0001-01-01 00:00:00 +0000 UTC 2016-09-23 11:16:54 -0700 PDT }]

/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/test/e2e/e2e.go:128

Previous issues for this test: #26135 #26236 #27920 #28492 #29970 #30075 #32980 #33313
Issue 1:
As the title says, when I trigger my popover from a floating action button, it causes a FOUC in the top left corner of my app.

You can see the code for my setup here: https://github.com/atrauzzi/gerty/blob/wip/src/App/Gerty/Component/App.tsx#L82-L130

Also worth noting that the open animation doesn't get performed, but the close does.

Issue 2:
Problem description

Popover component renders children before applying position styling. This results in a 'flash' of the popover in the top left corner (x: 0, y:0) before positioning correctly. This is caused by the setPlacement function being wrapped in setTimeout. Removing the setTimeout wrapper resolves the issue. The timeout was added for this issue: #7663.

Initial render 'flash':

Split second later, correctly positioned:

Versions

Material-UI: 0.19.0

React: 15.5

Browser: Chrome 60.0.3112.90
Issue 1:
I'm using requests 2.11.1. The following code throws an exception:

from requests import Request, Session
from http.cookiejar import CookieJar

cj = CookieJar()
req = Request('GET', 'http://google.com', cookies=cj).prepare()
resp = Session().send(req)

The exception is:

Traceback (most recent call last):
File "test.py", line 6, in <module>
resp = Session().send(req)
File "C:\Anaconda3\lib\site-packages\requests\sessions.py", line 617, in send
history = [resp for resp in gen] if allow_redirects else []
File "C:\Anaconda3\lib\site-packages\requests\sessions.py", line 617, in <listcomp>
history = [resp for resp in gen] if allow_redirects else []
File "C:\Anaconda3\lib\site-packages\requests\sessions.py", line 159, in resolve_redirects
prepared_request._cookies.update(self.cookies)
AttributeError: 'CookieJar' object has no attribute 'update'

I'm able to avoid this by using Session.prepare_request or by passing the cookies via Session.cookies.

Issue 2:
Duplicate bug disclaimer: this is related to other Unicode + header issues, however, those all focus on errors raised while generating an outbound request. This applies only to inbound requests. (See also: #1082, #400, and to a lesser extent, #390, #409, #421, and #424; if this is already covered by another bug, sorry for bugging you guys. Thanks!)

When inspecting responses with Unicode-encoded non-latin content trailing the HTTP status header in the response, requests raises UnicodeDecodeError.

(requests) marmida@loquat:~$ python
Python 2.7.10 (default, Oct 14 2015, 16:09:02)
[GCC 5.2.1 20151010] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import requests
>>> resp = requests.get('http://jp.apps.gree.net/ja/1604')
>>> resp.ok
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/marmida/venvs/requests/local/lib/python2.7/site-packages/requests/models.py", line 623, in ok
self.raise_for_status()
File "/home/marmida/venvs/requests/local/lib/python2.7/site-packages/requests/models.py", line 837, in raise_for_status
http_error_msg = '%s Server Error: %s for url: %s' % (self.status_code, self.reason, self.url)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position 23: ordinal not in range(128)

The content causing the problem, fetched via curl:

$ curl -v 'http://jp.apps.gree.net/ja/1604'
* Connected to jp.apps.gree.net (116.93.155.51) port 80 (#0)
> GET /ja/1604 HTTP/1.1
> Host: jp.apps.gree.net
> User-Agent: curl/7.43.0
> Accept: */*
>
< HTTP/1.1 503 AKB48ステージファイター
< Server: nginx

In the stack trace above, formatting http_error_msg as a string won't work, because self.reason contains non-ascii unicode.

Requests version: 2.9.1

Run from a fresh virtualenv with only requests installed.
Issue 1:
Environment

0.18.1

PowerToys Run

Steps to reproduce

Search for anything on your system

Expected behavior

Search results to be shown instantaneously

Actual behavior

I search for an application and it takes a noticeable

amount of time to find the application

Screenshots

Difference in uaing keypiranha and PowerToys Run

Issue 2:
I just want to mention something, I hope it will be fixed in the next version. The power toys run is not smooth, when you write something it lags a little bit. It has to be smoother like the windows search .