WhereIsAI/github-issue-similarity huggingface dataset:
Issue 1:
maybe related to #432.

example code

import jax.numpy as np

N = 80
np.linalg.inv(np.eye(N))

output:

/path/to/project/.venv/lib/python3.7/site-packages/jax/lib/xla_bridge.py:120: UserWarning: No GPU/TPU found, falling back to CPU.
warnings.warn('No GPU/TPU found, falling back to CPU.')
zsh: bus error python -m misc.jax

If N is smaller than 80, it works correctly on my machine.

my environment

macOS 10.14.6

Python 3.7.0 (pyenv)

jax 0.1.55

jaxlib 0.1.37

numpy 1.17.4

scipy 1.3.3

Issue 2:
I'm not exactly sure why this happens, being unfamiliar with the internal architecture, but on MacOS with Python 3.6.8, the following code segfaults if scipy 1.2.1 is installed (the version that comes by default when you pip install jax jaxlib):

import jax.random as random
import jax.scipy.linalg as linalg

key = random.PRNGKey(42)
# For some reason, matrices smaller than (50, 50) or so do not trigger segfaults
X = random.normal(key, (500, 500))
A = X @ X.T # Drawn from standard Wishart distribution
linalg.cholesky(A)
print("Success!")

Output:

$ python -W ignore test.py
zsh: bus error python -W ignore test.py

If I roll back to Scipy 1.1.0, everything works:

$ python -W ignore test.py
Success!

This is a great project by the way--thanks for working on it!

Edit: after further digging, I found the following in the the Scipy 1.2 release notes:

scipy.linalg.lapack now exposes the LAPACK routines using the Rectangular Full Packed storage (RFP) for upper triangular, lower triangular, symmetric, or Hermitian matrices; the upper trapezoidal fat matrix RZ decomposition routines are now available as well.

Perhaps this has something to do with it?

Even more edits: yet more digging has revealed scipy/scipy#9751, which hints that this might be caused by a specific (old) version of XCode. I will report back once XCode is upgraded.
Issue 1:
Issue Details

Electron Version: 7.1.8

Operating System: macOS 10.15.2/Windows 10

Last Known Working Electron version: 4.1.4

Expected Behavior

with Site Isolation enabled in electron 7.x, When I execute

webFrame.setSpellCheckProvider("en-US", {
spellCheck(words, callback) {
setTimeout(() => {
const misspelled = words.filter((text) => checker.isMisspelled(text));
callback(misspelled);
}, 0);
}
});

Spellchecker is not working inside the iframes but works in the top webview.

Provided, it works if I disable site isolation trials using

app.commandLine.appendSwitch('disable-site-isolation-trials', 'true');

Actual Behavior

Irrespective of site isolation feature setting, We should be able to set spellchecker for the entire webview including the iframes.

Thanks.

To Reproduce

git clone https://github.com/Syed-Umair/electron-quick-start.git
git checkout spellcheck-issue
npm i
npm run start

You can checkout the recording of the issue in the following link:

https://mega.nz/#!1M0lUY4Z!j1snymVCCsNZMafzF5RKLR84PcpoLzdeqc4NVOwOwLk

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:

6.1.4 (but happen also on 5.x.x and 6.x.x has a workaround for 4.x.x)

Operating System:

Windows 10

Last Known Working Electron version:

4.2.1

Expected Behavior

webFrame.setSpellCheckProvider API should work for dynamically created iframes.

For example:

When creating an iframe with a source of http://www.mydummywebsite.com/index.html (this doesn't really exist)

The text fields in index.html should invoke the spellCheck function (below) when there is a spelling mistake.

This API should work (example from docomentation)

webFrame.setSpellCheckProvider('en-US', {
spellCheck (words, callback) {
setTimeout(() => {
const spellchecker = require('spellchecker')
const misspelled = words.filter(x => spellchecker.isMisspelled(x))
callback(misspelled)
}, 0)
}
})

Actual Behavior

In Electron version, 4.x.x the webFrame.setSpellCheckProvider API also didnt work for dynamically created iframes. The workaround was to call webFrame.setSpellCheckProvider API again after each iframes creation.

On electron versions >= 5.x.x (including 6.x.x) this workaround dosnt work anymore.

The spellcheck API only works for local HTML files build in the local nodejs project.

To Reproduce

Create a project that uses the electron NPM module.

Create an iframe that its source is a local HTML file with text fields. the spell check API will be invoked for them

create another iframe with a source fo a website (or localhost website) that contains text fields. The spellCheck API will not work for them. If you call webFrame.setSpellCheckProvide after the iframe is created it still don't work.

I did see this issue which was not resolved at the end:

#13514

Does this happen to anyone else? Will the be solved in future releases of Electron?

Thanks!
Issue 1:
Circular dependencies are a huge issue when working with third party tooling (graphing dependencies, integrating into other build systems etc).

I think the correct solution here would be to put @types/react in the bundleDependencies (https://docs.npmjs.com/files/package.json#bundleddependencies) attribute in package.json to make the circular dependency invisible to consumers of this package.

I tried using the @types/xxxx package and had problems.

I tried using the latest stable version of tsc. https://www.npmjs.com/package/typescript

I have a question that is inappropriate for StackOverflow. (Please ask any appropriate questions there).

Mention the authors (see Definitions by: in index.d.ts) so they can respond.

Authors: @DovydasNavickas @ferdaber

Issue 2:
Possible duplicate of #32899

I tried using the @types/xxxx package and had problems.

I tried using the latest stable version of tsc. https://www.npmjs.com/package/typescript

I have a question that is inappropriate for StackOverflow. (Please ask any appropriate questions there).

Mention the authors (see Definitions by: in index.d.ts) so they can respond.

Authors: @tkqubo @kenzierocks @clayne11 @tansongyang @NicholasBoll @mDibyo @pdeva @Kallikrein @jrakotoharisoa @apapirovski @surgeboris @soerenbf

bug

connect has inaccurate type checking. Consider the following example:

interface IProps {
a: Ta;
b: Tb;
c: Tc;
}

const mapStateToProps: (state: IState) => Pick<IProps, "a"> = ...
const mapDispatchToProps: (dispatch: Dispatch) => Pick<IProps, "b"> = ...

const MyComponent: (props: IProps) => JSX.Element = ...

export default connect(mapStateToProps, mapDispatchToProps)(MyComponent);

What is the current behavior?

There is no TypeScript compilation error, so the type system becomes inaccurate.

What is the expected behavior?

The last line should throw a typescript compilation error, because Pick<IProps, "a"> & Pick<IProps, "b"> is incompatible with IProps, as it is missing property c.

Which versions of React, ReactDOM/React Native, Redux, and React Redux are you using? Which browser and OS are affected by this issue? Did this work in previous versions of React Redux?

@types/react-redux@7.0.1

react-redux@6.0.0
Issue 1:
This is really annoying.

To reproduce: Set the screen to full screen, do an update. Click on the full screen button to remove the full screen and this happens.

You cant move the screen.. soo annoying.

Version: Current (0.123) and every other version before it

Issue 2:
If you call BrowserPosition::setPosition with 0, 0 as the arguments, it moves window's title bar offscreen.

I think this behavior has changed from previous versions.

Expected

Actual
Issue 1:
Would it be possible to have a dependency against requests (Apache 2 licensed) in Scrapy?

I noticed that it has superior proxy env handling, where urllib fails to parse IPs or CIDR in a $no_proxy variable. This has led to failing testcases for me and I'd like to fix it.

Also, requests provides a nice compat module, wrapping urllib/2 for PY2 and PY3 differences.

If not a dependency, could scrapy do this stuff similarly?

Pulling in urllib/urllib2/urlparse from a local wrapper seems cleaner than throwing six.moves. and try...except statements everywhere we use them. And we have plenty of those imports.

Issue 2:
scrapy version: 1.1.2

python version: 2.7.12

platform: Mac OS X 10.11.6

The issue:

For the url given in the following minimum working example, the HTML text in the response from scrapy is different from the one obtained with requests.get. The latter seems to be the correct one. It seems scrapy somehow duplicates part of the response html. This does not happen for all sites.

See the attached file for the two different html files. Or you may run the following code to generate them.

import scrapy
from scrapy.crawler import CrawlerRunner
from twisted.internet import reactor
import requests

url = 'http://training.sac.net.cn/cms/flkcalone.htm?myId=4028d0ee57ec28180157f55059b87209'

headers = {
'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8',
'Accept-Encoding': 'gzip, deflate, sdch',
'Accept-Language': 'en-US,en;q=0.8,zh-CN;q=0.6,zh;q=0.4,zh-TW;q=0.2',
'Cache-Control': 'max-age=0',
'Connection': 'keep-alive',
'Upgrade-Insecure-Requests': '1',
'User-Agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36',
}

class Test(scrapy.Spider):
name = 'test'

def start_requests(self):
request = scrapy.Request(url=url, callback=self.parse, headers=headers)
yield request

def parse(self, response):
with open('response_with_scrapy.html', 'w') as f:
f.write(response.text.encode('utf-8'))

if __name__ == '__main__':
with open('response_with_requests.html', 'w') as f:
f.write(requests.get(url, headers=headers).text.encode('utf-8'))

runner = CrawlerRunner()
runner.crawl(Test)
d = runner.join()
d.addBoth(lambda _: reactor.stop())
reactor.run()

two_responses.zip
Issue 1:
Is it too late to change the import statement around? (I know it probably is).

If it was

from 'x' import { y }

Tooling could provide very handy intelli-sense about what could be imported.

Issue 2:
Consider the following import statement:

import { int, float } from '../lang';

With auto-suggest I need to start this by typing:

import {} from '../lang';

Then I can go back inside the {} and get auto-suggestions.

It would be very nice if TypeScript supported an alternate syntax for the same expression that was more conducive to auto-complete features.

For example:

import from '../lang' { int, float };

This doesn't introduce any confusion or ambiguity about the meaning of the expression, either to the transpiler or the human reader, yet it provides a time-saving experience to the author when taking advantage of auto-complete features. I can now simply type the expression naturally from left to right, and get auto-suggestions/completions for both the from '...' and {}.

There are other cases where an alternate syntax would be beneficial. I will update this issue as I compile a list. Hopefully others will comment with suggestions as well.
Issue 1:
Proposed new feature or change:

All single-argument np.FUNC functions can be implemented as np.ndarray.FUNC.

Example usage:

# Currently invalid. :(
x.ceil()

Rationale:

np.ndarray already implements some methods:

all
any
argmax
argmin
argpartition
argsort
astype
byteswap
choose
clip
compress
conj
conjugate
copy
cumprod
cumsum
diagonal
dump
dumps
fill
flatten
getfield
item
itemset
max
mean
min
newbyteorder
nonzero
partition
prod
ptp
put
ravel
repeat
reshape
resize
round
searchsorted
setfield
setflags
sort
squeeze
std
sum
swapaxes
take
tobytes
tofile
tolist
tostring
trace
transpose
var
view

It is unclear to a user which ones have been implemented and which ones haven't unless they try one and see if their code works/fails. (Or google the docs for each one they want to use.) For instance, np.ndarray.ceil does not exist, but np.ndarray.round does.

Fully implementing this API style improves interchangeability with libraries such as PyTorch. With this change, there is less need to implement different methods (e.g. torch.sin or np.sin) for functions that just want to think about numerical computations on tensors of any type (np.ndarray or torch.Tensor), e.g.:

def sin2(x: np.ndarray | torch.Tensor):
return (x ** 2).sin()

Instead of:

def sin2(x: np.ndarray | torch.Tensor):
if isinstance(x, np.ndarray):
return np.sin(x ** 2)
else:
return (x ** 2).sin()

Fluent API styles are very natural for chained computations.

((x ** 2).mean(axis=-1).sqrt() > x.mean(axis=-1).sqrt()).nonzero()

versus:

np.nonzero(np.sqrt(np.mean(x ** 2, axis=-1)) > np.sqrt(np.mean(x, axis=1)))

More consistent API for numpy-based libraries (e.g. pandas) that frequently use chained methods in other parts of their API.

df.groupby("column").agg(...)
df["column"].ceil() # looks much more natural with pandas than np.ceil(df["column"])

A (not necessarily exhaustive) list of possible single-argument FUNCs:

negative
positive
absolute
fabs
rint
sign
conj
conjugate
exp
exp2
log
log2
log10
expm1
log1p
sqrt
square
cbrt
reciprocal
sin
cos
tan
arcsin
arccos
arctan
sinh
cosh
tanh
arcsinh
arccosh
arctanh
degrees
radians
deg2rad
rad2deg
invert
logical_not
isfinite
isinf
isnan
isnat
fabs
signbit
spacing
modf
frexp
floor
ceil
trunc

Issue 2:
>>> src = np.ma.masked_where([0, 1, 0], [1, 1337, 1])
>>> dst = np.ma.masked_where([1, 0, 0, 0, 0], np.zeros(5))
>>> dst_view = dst.transpose()
# check the views look ok
>>> dst
masked_array(data = [-- 0 0 0 0],
mask = [ True False False False False],
fill_value = 999999)
>>> dst_view
masked_array(data = [-- 0 0 0 0],
mask = [ True False False False False],
fill_value = 999999)

# now write a slice of the view
>>> dst_view[2:5] = src
>>> dst_view
masked_array(data = [-- 0 1 -- 1],
mask = [ True False False True False],
fill_value = 999999)

# but looking back at the original, the data was updated but the mask was not!
>>> dst
masked_array(data = [-- 0 1 1337 1],
mask = [ True False False False False],
fill_value = 999999)
Issue 1:
Please consider adding block-selection like VS proper; shift-alt-cursor manages selection.

Certain kinds of edits are very repetitive or tedious without it.

Issue 2:
Please Implement Column Mode selection/editing.

Previously requested here

https://visualstudio.uservoice.com/forums/293070-visual-studio-code/suggestions/7761618-implement-column-mode-selection-editing

On Mac preferred shortcut is cmd+option(alt) like Sublime Text does.
Issue 1:
Sam Brannen opened SPR-6050 and commented

In the Spring TestContext Framework (i.e., specifically in AbstractGenericContextLoader), annotation-driven autowiring is automatically enabled. In other words, all ApplicationContexts created by subclasses of AbstractGenericContextLoader (e.g., GenericXmlContextLoader) are automatically configured to process annotations.

If you explicitly wish that annotation processing not be enabled for the configuration files you specify -- for example, if some of the beans are annotated with @Autowired, etc. but you do not want those beans to be autowired -- you are at a loss: there is currently no way to disable this.

As indirectly suggested in the forum, it would be nice if Spring provided a mechanism for disabling automatic annotation-driven autowiring in tests.

Affects: 2.5.6

Reference URL: http://forum.springsource.org/showthread.php?t=74298

Issue Links:

#9309 Load dedicated child ApplicationContext for test instance in the TestContext framework

#14113 Test instances should not be proxied in the TestContext framework

2 votes, 2 watchers

Issue 2:
Costin Leau opened SPR-4924 and commented

Probably the error is caused by the usage of a WeakHashMap..

Below is the stacktrace:

java.lang.NullPointerException

at org.springframework.core.enums.AbstractCachingLabeledEnumResolver.get

LabeledEnumByLabel(AbstractCachingLabeledEnumResolver.java:105)

at org.springframework.osgi.config.AbstractReferenceDefinitionParser.pro

cessCardinalityString(AbstractReferenceDefinitionParser.java:300)

at org.springframework.osgi.config.AbstractReferenceDefinitionParser.det

ermineCardinality(AbstractReferenceDefinitionParser.java:288)

at org.springframework.osgi.config.AbstractReferenceDefinitionParser.app

lyDefaultCardinality(AbstractReferenceDefinitionParser.java:311)

at org.springframework.osgi.config.AbstractReferenceDefinitionParser.doP

arse(AbstractReferenceDefinitionParser.java:223)

at org.springframework.osgi.config.AbstractReferenceDefinitionParser.par

seInternal(AbstractReferenceDefinitionParser.java:181)

at org.springframework.beans.factory.xml.AbstractBeanDefinitionParser.pa

rse(AbstractBeanDefinitionParser.java:56)

at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(N

amespaceHandlerSupport.java:69)

Affects: 2.5.4

Issue Links:

#9598 NPE in AbstractCachingLabeledEnumResolver during namespace parsing ("duplicates")
Issue 1:
Description

I got a DeprecationWarning with the imp module since i update my python version to python 3.7.

Here is the message

XXX\site-packages\sklearn\externals\joblib\externals\cloudpickle\cloudpickle.py:47: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses

Steps/Code to Reproduce

import sklearn

Possible corrections

modify cloudpickle.py file and replace following lines by following values

l.47: import importlib

l.937: mod = types.ModuleType(name)

l.1138: file, path, description = importlib.util._find_spec(part, path)

I'm quite a newby on GitHub, I don't really know how to use pull request and evrything so i post my solution here as if it is a bit ugly...

Versions

On Windows10 environment.

Python 3.7.0

sklean 0.20.0

Issue 2:
Description

I get this error after importing the module

/usr/local/lib/python3.6/dist-packages/sklearn/externals/joblib/externals/cloudpickle/cloudpickle.py:47: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses import imp

Can I ignore it?

How to solve it?

Steps/Code to Reproduce

import sklearn

Expected Results

NO ISSUE

Actual Results

/usr/local/lib/python3.6/dist-packages/sklearn/externals/joblib/externals/cloudpickle/cloudpickle.py:47: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses import imp

Versions

PLATFORM=Linux-4.15.0-34-generic-x86_64-with-Ubuntu-18.04-bionic

PYTHON=Python 3.6.5 (default, Apr 1 2018, 05:46:30) [GCC 7.3.0]

NUMPY=NumPy 1.15.2

SCIPY= SciPy 1.1.0

SKLEARN=Scikit-Learn 0.20rc1
Issue 1:
Scenario

Deno.test() has basically two forms currently (1.9.0):

Deno.test(<name>, <test function>) and

Deno.test(<options object>)

Personally, I tend to write all my tests on the first form for it is generally simpler to read and write.

This leaves the second form to be used only when strictly necessary (i.e to use some of the available options).

Issue

While writing my long list of tests I often feel the need to run only the test being currently worked on, to have a cleaner output and lower wait time.

In order to quickly mark any tests as only or ignore I have to refactor the function considerably in order to add an options object, which will just be removed after the test code is finished.

I suggest reading this discussion where the issue has been pointed out before.

Suggestion

Among the existing suggestions, I'll just add two more.

Deno.test('foobar is bahbaz', function(){
i.like.to('move it move it');
}, 'only') // I know...

Or even accept the options as the last argument too. (easier to add and remove)

Deno.test('foobar is bahbaz', function(){
i.like.to('move it move it');
}, { only: true });

Issue 2:
Currently Deno.test has two overloads:

function test(name: string, fn: () => void | Promise<void>): void;
function test(t: TestDefinition): void;

interface TestDefinition {
fn: () => void | Promise<void>;
name: string;
ignore?: boolean;
only?: boolean;
sanitizeOps?: boolean;
sanitizeResources?: boolean;
};

The name/fn overload is nicer for simple tests, but if we ever want to temporarily use an option like only: true we have to completely rewrite to the TestDefinition overload. If the first overload was changed to...

function test(
name: string,
fn: () => void | Promise<void>,
options?: TestOptions,
): void;

type TestOptions = Omit<TestDefinition, "name" | "fn">;

...then we could easily switch between these two calls:

Deno.test("my test", () => { assertSomething() });

Deno.test("my test", () => { assertSomething() }, { only: true });
Issue 1:
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 a feature request that matches the one I want to file, without success.

Problem Description

For the native tray icons on windows, switching to dark mode will invert them. This is very similar to the behavior on macOS (though on macOS it seems to work for third party apps as well, including electron apps). As far as I can tell, there isn't a clear way for an electron app to do a tray icon on windows that automatically inverts when the light/dark mode setting switches.

I think part of the issue is that the app mode vs the shell mode is two settings, and electron doesn't expose the shell mode: #19729

Proposed Solution

Perhaps electron could provide a tray api update that lets you specify alternative tray icons for light and dark mode on windows?

Alternatives Considered

At the very least, an api that exposes which mode the shell is in, could be nice. Not sure how you'd auto update the tray icon without polling, though. is there a window message or some kind of event we could listen on for this?

cc @hacdias @deermichel

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:

master

Operating System:

win7 sp1 x64

projects generated by gn gen out/Testing-x86 --ide=vs2019

opening all.sln

error: error : Cannot load project with duplicated project items: ../../../../electron/shell/common/api/constructor.h is included as 'None' and as 'None' item types.

removing the duplicate constructor.h entry in the project file resolves the problem
Issue 1:
Applying an emphasis class, such as text-primary, to a heading has no effect - the heading retains it's color. Is this expected? I'm hoping not.

Best wishes

Lee

Edit: I've just noticed we're supposed to use a span. Couldn't the emphasis classes be made Important to over come this?

Issue 2:
.jumbotron h1 sets color to inherit, i'm not really sure why it would need to do this but the problem is that if you try and set text-success, text-warning, text-info, etc on the h1 it fails to set the color because of this. I know i could probably simply wrap the h1 in a div with a text-* class but that's extra markup that i'm thinking we can avoid?!