WhereIsAI/github-issue-similarity huggingface dataset:
Issue 1:
Hard to reproduce. I attached an array where this happens:

import numpy as np
np.seterr(all='raise')
a = np.load('weird_array.npy')
print(a.shape, a.dtype)
for i, val in enumerate(a):
try:
np.isfinite(np.array(val, ndmin=1))
except:
strange_index = i
print(type(val))
print(val.__class__.__name__)
print(i)
print(val)

print(np.isfinite(a[strange_index]))

Results in:

<class 'numpy.float64'>
float64
1023450
nan
Traceback (most recent call last):
File "test.py", line 15, in <module>
print(np.isfinite(a[strange_index]))
FloatingPointError: invalid value encountered in isfinite

weird_array.zip

Issue 2:
My code failed with a FloatingPointError because isfinite encountered an invalid value. The offending value was... nan. Apparently, it was the wrong kind of nan. I reproduced it as follows:

# (earlier: seterr(all='raise'))
In [204]: x = uint32(0x7f831681).view("<f4")

In [205]: print(x)
nan

In [206]: isnan(x)
---------------------------------------------------------------------------
FloatingPointError Traceback (most recent call last)
<ipython-input-206-b5e847e0f3bf> in <module>()
----> 1 isnan(x)

FloatingPointError: invalid value encountered in isnan

In [207]: isfinite(x)
---------------------------------------------------------------------------
FloatingPointError Traceback (most recent call last)
<ipython-input-207-3d4ef4d5266d> in <module>()
----> 1 isfinite(x)

FloatingPointError: invalid value encountered in isfinite

I'm not sure how this ended up in my data, but it was not on purpose.
Issue 1:
When creating an array from 0.2 to 0.8, the maximum value in the array is 0.8, but when I run max of the whole array, I found the maximum value different from 0.8. It has digits in the 15th and 16th decimal.

When the same is done with 0.7 as the ending value, the maximum of the array is 0.60000000009.. and the value of 0.7 is not included in the array.

PFA the screenshots.

Issue 2:
If I do np.arange(3.18,3.21,0.01), it gives array([ 3.18, 3.19, 3.2 ]). However, if I do np.arange(3.18,3.22,0.01), it gives array([ 3.18, 3.19, 3.2 , 3.21, 3.22]). This seems inconsistent. Why is this so? I am using numpy 1.11.2 on Python 2.7.13.
Issue 1:
Please add standarized/easy way to implement dependent selects form field..

Issue 2:
We long have the problem of creating fields that depend on the value of other fields now. See also:

#3767

#3768

#4548

I want to propose a solution that seems feasible from my current point of view.

Currently, I can think of two different APIs:

API 1

<?php

$builder->addIf(function (FormInterface $form) {
return $form->get('field1')->getData() >= 1
&& !$form->get('field2')->getData();
}, 'myfield', 'text');

$builder->addUnless(function (FormInterface $form) {
return $form->get('field1')->getData() < 1
|| $form->get('field2')->getData();
}, 'myfield', 'text');

API 2

<?php

$builder
->_if(function (FormInterface $form) {
return $form->get('field1')->getData() >= 1
&& !$form->get('field2')->getData();
})
->add('myfield', 'text')
->add('myotherfield', 'text')
->_endif()
;

$builder
->_switch(function (FormInterface $form) {
return $form->get('field1')->getData();
})
->_case('foo')
->_case('bar')
->add('myfield', 'text', array('foo' => 'bar'))
->add('myotherfield', 'text')
->_case('baz')
->add('myfield', 'text', array('foo' => 'baz'))
->_default()
->add('myfield', 'text')
->_endswitch()
;

The second API obviously is a lot more expressive, but also a bit more complicated than the first one.

Please give me your opinions on what API you prefer or whether you can think of further limitations in these APIs.

Implementation

The issue of creating dependencies between fields can be solved by a lazy dependency resolution graph like in the OptionsResolver.

During form prepopulation, the conditions are invoked with a FormPrepopulator object implementing FormInterface. When FormPrepopulator::get('field') is called, "field" is prepopulated. If "field" is also dependent on some condition, that condition will be evaluated now in order to construct "field". After evaluating the condition, fields are added or removed accordingly.

During form binding, the conditions are invoked with a FormBinder object, that also implements FormInterface. This object works like FormPrepopulator, only that it binds the fields instead of filling them with default data.

In both cases, circular dependencies can be detected and reported.
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 an issue that matches the one I want to file, without success.

Issue Details

Electron Version:

9.0.0 and later

Operating System:

macOS 10.13.6

Last Known Working Electron version:

8.3.3

Expected Behavior

in BrowserWindow set to do http CORS request

webPreferences: {

webSecurity: false

},

in low version electron, can do CORS request.

Actual Behavior

Access to XMLHttpRequest at 'https://xxx' from origin 'http://localhost:9080' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

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:

12.0.0-beta.21

Operating System:

Windows 10

Last Known Working Electron version:

12.0.0-beta.20

Expected Behavior

No crash.

Actual Behavior

Crash reported to Sentry using minidump uploader:

https://sentry.io/share/issue/70e843318a304dae9616805c3223a1cc/

To Reproduce this might be enough

Use Electron.WebRequest .onBeforeRequest(
{
urls: [],
},
({ url }, callback) => {
if (url.startsWith('https://test..com')) {
callback({ cancel: true });
} else {
callback({ cancel: false });
}
},
);
Issue 1:
Dave Syer opened SPR-5850 and commented

Provide a ContextLoader for WebApplicationApplicationContext: some components (e.g. View implementations) are hard or impossible to test without an instance of WebApplicationContext.

Affects: 3.0 M3

Issue Links:

#9917 Support loading WebApplicationContexts with the TestContext Framework ("duplicates")

Issue 2:
Fritz Richter opened SPR-7784 and commented

In my current webapp project, I found out, that if I post something to the server in the form of ?list=1&list=2&list=3 and I have got a Mapping on my controller, which has the following parameter @RequestParam List<Long>, it will contain String objects, and not Long objects.

Affects: 3.0.5

Issue Links:

#12437 @RequestParam - wanting List getting List ("duplicates")

#12437 @RequestParam - wanting List getting List
Issue 1:
Is it possible to build a subset of babel to just use the transform function for compiling es6/es7/jsx to js in the browser, does it generally have to be this huge? Are there any tricks for using it with webpack?

JSXTransformer and react-tools are going away and babel seems to remain the only available option for transpiling JSX in the browser, however it's 10 times bigger than those two which is often quite a problem.

Issue 2:
Current size browser-polyfill.min.js ~80kb. Possible serious reduce it. Browserify, by default, saves modules path, it's not required.

Full shim version of core-js with browserify (w/o bundle-collapser) - 65kb, with webpack - 43kb.

Possible use webpack or add bundle-collapser.

I think, possible do the same with browser.js.
Issue 1:
Issue Type:

Bug Report

Ansible Version:

Bug on current git devel, introduced with eeb5973

Environment:

Ubuntu 12.04 and 14.04

Summary:

When applying some filters on a list, when the resulting list is empty, it is not recognised as a list anymore.

Steps To Reproduce:

---
- hosts: localhost
gather_facts: false
connection: local
tasks:
- command: cat /proc/cpuinfo
register: cpuinfo
- debug: var=cpuinfo.stdout_lines|difference(cpuinfo.stdout_lines)
- debug: var=item
with_items: cpuinfo.stdout_lines|difference(cpuinfo.stdout_lines)

Expected Results:

TASK: [debug var=cpuinfo.stdout_lines|difference(cpuinfo.stdout_lines)] *******
ok: [localhost] => {
"cpuinfo.stdout_lines|difference(cpuinfo.stdout_lines)": "set([])"
}

TASK: [debug var=item] ********************************************************
skipping: [localhost]

Actual Results:

TASK: [debug var=cpuinfo.stdout_lines|difference(cpuinfo.stdout_lines)] *******
ok: [localhost] => {
"cpuinfo.stdout_lines|difference(cpuinfo.stdout_lines)": "set([])"
}

TASK: [debug var=item] ********************************************************
fatal: [localhost] => with_items expects a list or a set

FATAL: all hosts have already failed -- aborting

Issue 2:
Issue Type:

Bug Report

Ansible Version:

ansible 1.6.6

Environment:

What OS are you running Ansible from and what OS are you managing? Examples include RHEL 5/6, Centos 5/6, Ubuntu 12.04/13.10, *BSD, Solaris. If this is a generic feature request or it doesn't apply, just say “N/A”.

Summary:

I have an ansible task that looks like this:

- name: Distribute Jar files to all other cluster nodes
shell: rsync -avz {{ home }}/.m2 {{ user }}@{{ item }}:{{ home }}/
with_items: groups.hadoop_all | difference(inventory_hostname)
when: groups.hadoop_all | difference(inventory_hostname) | length > 1
ignore_errors: yes
sudo: no
tags:
- distribute_jars

which works fine on ansible 1.6.5 but fails on 1.6.6

Steps To Reproduce:

Working on a reduced test case now.

Expected Results:

I would expect the playbook to complete without errors.

Actual Results:

The actual result is that it fails in 1.6.6 with this output:

TASK: [dev | Distribute Jar files to all other cluster nodes] ***********
fatal: [dev] => with_items expects a list or a set

FATAL: all hosts have already failed -- aborting

I've stepped back through ansible versions on a machine, keeping everything else the same and as soon as you upgrade to 1.6.6, it starts falling with this error. I'm using ansible installed via pip, if that makes any difference.
Issue 1:
Today I've upgraded our codebase from r88 -> r91, everything seems to work fine aside from the reflectors (code which has not significantly changed since r88 from what I see). I've noticed that when checking individual upgrades, the problem starts at r90.

It seems to go exponentially bad when our entire model + mirror are in the frustrum, when I'm right in front of it & little else of the model, the performance is OK. Now since I can't provide live examples, I was wondering if someone could point me on where to look/investigate, or what could have changed in that release that affects them?

Three.js version

Dev

r91

r90

r89

r88

Browser

All of them

Chrome

Firefox

Internet Explorer

OS

All of them

Windows

macOS

Linux

Android

iOS

Hardware Requirements (graphics card, VR Device, ...)

Issue 2:
Right now, there are two ways to adjust the positioning of a texture on an object:

UV coordinates in geometry

.offset and .repeat properties on Texture

It would be useful to also have .offset and .repeat properties on Material as well, so that these values could be varied on different objects without having to allocate additional geometries or texture resources.

I'm considering an interesting use case: breaking down sky spheres/domes into smaller components. Rather than create a single, large, solid sphere, imagine a fraction of an icosahedron (subdivided) and repeated as multiple meshes to construct a sphere out of pieces. It would cost a few extra draw calls, but provide at least two benefits:

Significantly reduce the number of vertices computed by excluding the ones that are off camera, which is well more than half. Spheres can have hundreds of vertices, depending on the level of detail. This is not such a big deal on desktop, but I suspect it could make a big difference on mobile devices with tiled GPU architectures that would cause the vertex shader to be run many times.

Reduce overdraw by fixing z-sorting. If an entire sky sphere is positioned at [0, 0, 0], it will almost certainly be sorted incorrectly and drawn first every time, even though it should be drawn last. By positioning individual sphere components far away, they should be correctly sorted last.

Implementing this approach today would require duplicating either the geometry (for different UV coordinates) or the texture (for different offsets) for each piece of the sky. If we could set the offset on the material, each piece would use the same geometry, shader and sampler, only varying the uniform values between draw calls.
Issue 1:
Hello, folks.

Version 3.0.3 of bootstrap.css has ineffective rules for striped tables which have rows with .danger or other contextual class(es), if tbody is used

Given a table with the following structure...

<table class="table table-striped table-hover">
<tbody>
<tr class="danger">
<td>Row 1</td>
</tr>
<tr class="danger">
<td>Row 2</td>
</tr>
<tr class="danger">
<td>Row 3</td>
</tr>
</tbody>
</table>

...only Row 2 gets emphasized with the .danger contextual class rules. On hovering these rows, the normal emphasis returns, including the darker color on the shaded rows.

In dist, the rule for table-striped in bootstrap.css : 1712 overrides the rule in bootstrap : 1770, because the former contains a tbody selector node, which determines the rule to be sharper than the latter, where this node is missing.

This bug has probably been introduced with the super-specific rules for .table-striped class in 224296f/less/tables.less, purposed to fix #7281.

Issue 2:
i have table with class .table-striped. it has 3 rows with tr.danger. only the middle one is red, the other two are default color.

when i remove .table-striped, it works correctly
Issue 1:
Stephen Todd opened SPR-3450 and commented

Spring's current code makes it difficult to use java collections as a command in command controllers. Specifically, referencing elements in the collection is prevented. Currently, elements in an collection are references using []. Support needs to be added to allw paths to start with [index/key] as in "[1].property".

The application for this is probably rare, which is probably why it hasn't been brought up before (at least I couldn't find an similarly reported issues). I use the functionality for executing multiple of the same commands. I currently have a form that has multiple objects that can be selected. If the user clicks "Delete" with multiple objects selected, I have an array of id's that get passed to a delete form. This form creates a delete command for each object specified. Details for the way the objects are deleted are stored in an object, which is put in to a list. When the user submits the form, each command is executed in succession (the list is actually passed to the business layer and executed in a single transaction).

The current work around is to create a subclass of the java collection you want and make a getter that returns this. Then you can reference the array as (using a getter getSelf()) "self[1].property". Although this method works, a method that doesn't require this simple extension would be preferable.

Affects: 2.0.4

Issue 2:
Alex Antonov opened SPR-2058 and commented

When a BeanWrapper wraps an object that is a map or a collection of sorts, it has trouble retrieving a value using a key property

i.e.

Person p = new Person("John");

Map map = new HashMap();

map.put("key", person);

BeanWrapperImpl wrapper = new BeanWrapperImpl(map);

String name = wrapper.getPropertyValue("[key].name")

This kind of access is very possible when comming from a web-layer using a bind-path of something like [key].name when the top-level object is itself a map.

In this case, when calling errros.rejectValue("[key].name", ...) in the validator, the call throws an exception due to inability to find an object referenced by [key].

Currently a work-around this problem is to subclass a map and provide a getter for every key you might have in the map, so that the path looks like key.name, but

this approach requires a lot of overhead of the getter creation.

11 votes, 9 watchers
Issue 1:
The first build against master where this happened is https://ci.appveyor.com/project/StefanKarpinski/julia/build/1.0.5994/job/l01nwf0rwaedju0o, for 6ec7c21

I can reproduce locally, will try to see whether it's repeatable or intermittent (once I walk over to stata)

Issue 2:
I've gotten this to happen on 2 different Win64 computers, one Sandy Bridge, one Haswell. Happens when running runtests.jl all in parallel, seemingly more often the more cores I use for the tests. One of the workers gets stuck on its first test - so usually linalg, but I just got it to happen even on the strings test - while the rest of the workers happily finish everything else, waiting right before running parallel at the very end like they're supposed to.

This isn't just the usual linalg slowness, I've left these going on multiple computers for half an hour or longer. The offending processes are stuck at 100% of a single core, but the memory consumption isn't changing at all.

This doesn't happen on Win32, or when JULIA_CPU_CORES=1. Any ideas how to narrow this down? OpenBlas interaction? Win64 codegen problem? Something to do with libuv and task spawning? Ignore it and hope it doesn't show up in normal code?
Issue 1:
There's now a number of issues open for thoughts about how to make the printing of types more readable. Here's another notion: it would be nice if printing could replace Unions with appropriate typealiases. For example:

julia> methods(permutedims)
#2 methods for generic function "permutedims":
permutedims(B::Union{Base.ReshapedArray{T<:Any,N<:Any,A<:DenseArray,MI<:Tuple{Vararg{Base.MultiplicativeInverses.SignedMultiplicativeInverse{Int64},N<:Any}}},DenseArray{T<:Any,N<:Any},SubArray{T<:Any,N<:Any,A<:Union{Base.ReshapedArray{T<:Any,N<:Any,A<:DenseArray,MI<:Tuple{Vararg{Base.MultiplicativeInverses.SignedMultiplicativeInverse{Int64},N<:Any}}},DenseArray},I<:Tuple{Vararg{Union{Base.AbstractCartesianIndex,Colon,Int64,Range{Int64}},N<:Any}},L<:Any}}, perm) at multidimensional.jl:959
permutedims{T,N}(A::AbstractArray{T,N}, perm) at permuteddimsarray.jl:47

But the first method is actually defined as permutedims(B::StridedArray, perm) which is rather simpler to read.

This is easy to point out, but actually implementing it seems likely to be hard starting from the jl_uniontype_t itself. Unless Union types get modified to record whether they come from a typealias.

Issue 2:
I'd like to request some speculative brain cells spent on how we print method signatures to the REPL.

Currently, we expand out all typealiases. While this policy has the advantage of producing unambiguous output, the composition of type aliases through type parameters leads to combinatorially long string representations.

A particularly egregious example in Base is eigfact!:

julia> methods(eigfact!)

#12 methods for generic function "eigfact!":

...

eigfact!{T<:Union{Complex{Float32},Complex{Float64}}}(A::Union{DenseArray{T,2},SubArray{T,2,A<:DenseArray{T<:Any,N<:Any},I<:Tuple{Vararg{Union{Colon,Int64,Range{Int64}}}},LD<:Any}}) at linalg/eigen.jl:50

eigfact!{T<:Union{Float32,Float64}}(A::Union{DenseArray{T,2},SubArray{T,2,A<:DenseArray{T<:Any,N<:Any},I<:Tuple{Vararg{Union{Colon,Int64,Range{Int64}}}},LD<:Any}}, B::Union{DenseArray{T,2},SubArray{T,2,A<:DenseArray{T<:Any,N<:Any},I<:Tuple{Vararg{Union{Colon,Int64,Range{Int64}}}},LD<:Any}}) at linalg/eigen.jl:121

eigfact!{T<:Union{Complex{Float32},Complex{Float64}}}(A::Union{DenseArray{T,2},SubArray{T,2,A<:DenseArray{T<:Any,N<:Any},I<:Tuple{Vararg{Union{Colon,Int64,Range{Int64}}}},LD<:Any}}, B::Union{DenseArray{T,2},SubArray{T,2,A<:DenseArray{T<:Any,N<:Any},I<:Tuple{Vararg{Union{Colon,Int64,Range{Int64}}}},LD<:Any}}) at linalg/eigen.jl:142

...

I estimate that only three people in the world can read the first method signature and immediately recognize that the original calling signature was

eigfact!{T<:BlasComplex}(A::StridedMatrix{T})

and it would take an eagle eye to realize that the first method takes one argument whereas the other two take two inputs each.

It would be much nicer to print something like the original method signature instead of feeling overwhelmed by C++ expression template-like verbal diarrhea. It's clear, though, that the additional bookkeeping of typealiases and matching of typealiases to method signatures is a hard problem.
Issue 1:
When a typeahead process call receives an array of objects instead of strings it passes "[Object object]" to updater. One would expect that updater would receive the object, as matcher, sorter, and highlighter work as expected.

The problem seems to be that the data is being stored by way of calls to jQuery.attr.

One potential fix is changing https://github.com/twitter/bootstrap/blob/master/js/bootstrap-typeahead.js#L47 and https://github.com/twitter/bootstrap/blob/master/js/bootstrap-typeahead.js#L141 respectively as follows:

47 var val = this.$menu.find('.active').attr('data-value')

becomes

47 var val = this.$menu.find('.active').data('typeahead-value')

and

141 i = $(that.options.item).attr('data-value', item)

becomes

141 i = $(that.options.item).data('typeahead-value', item)

The underlying issue is jQuery's 'attr' function calls toString instead of serializing, whereas 'data' serializes properly - preserving all the useful bits of the object.

Note that I changed 'data-value' to 'typeahead-value' just to avoid any name collisions (although I am sure they are pretty unlikely).

A workaround is to serialize with eg JSON.stringify the results of sorter, and then JSON.parse the item passed to updater.

Issue 2:
your current set up is so:

.clearfix() {
&:before,
&:after {
content: " "; // 1
display: table; // 2
}
&:after {
clear: both;
}
}

.clearfix {
.clearfix();
}

consider switching to this:

.clearfix {
&:before,
&:after {
content: " "; // 1
display: table; // 2
}
&:after {
clear: both;
}
}

.clearfix() {
&:extend(.clearfix all);
}

it will reduce the amount of resulting css when devs use your mixin in their own less files. There will still be some duplicate with .clearfix() calling both mixin .clearfix() and selector .clearfix (known issue with less.js, and I do wish you would change .clearfix() to .makeclearfix() or .addclearfix() or whatever to alleviate this problem, but I know you won't).

When the good fellas over at LESS do fix that problem, this code (combined with my suggested change)

.my-class {
.clearfix();
}

will result in:

.clearfix:before,
.clearfix:after,
.my-class:before,
.my-class:after {
content: " ";
display: table;
}
.clearfix:after,
.my-class:after {
clear: both;
}
.my-class {
color: blue;
}

and of course if a dev uses .clearfix(); throught their own less files, the resultant compiled css will see a pretty significant reduction in size
Issue 1:
Google search (at the top right corner) is broken in both:

http://scikit-learn.org/stable/

http://scikit-learn.org/dev/

It is still working in:

http://scikit-learn.org/0.17/

Issue 2:
Description

I noticed problems with the search results on the scikit-learn website. I am not sure if this problem just occurred today after 0.18 went live. Below is a screenshot of how it looks like when I do a search on the main page; on subpages the search does not seem to work altogether -- tested it on Chrome and Safari.

Steps/Code to Reproduce

Expected Results

Actual Results

Versions