WhereIsAI/github-issue-similarity huggingface dataset:
Issue 1:
I was just messing around with some toy problems and discovered that you could create multiple methods with the same signature when using concrete types in parametric methods:

julia> foo(a::Int64, b::Int64) = a + b
foo (generic function with 1 method)

julia> foo{T<:Int64}(a::T, b::T) = a - b
foo (generic function with 2 methods)

julia> foo{A<:Int64,B<:Int64}(a::A, b::B) = a * b
foo (generic function with 3 methods)

julia> methods(foo)
#3 methods for generic function "foo":
foo{T<:Int64}(a::T, b::T) at none:1
foo{A<:Int64,B<:Int64}(a::A, b::B) at none:1
foo(a::Int64, b::Int64) at none:1

If a parametric type variable uses a concrete type shouldn't that type replace the type variable in the signature?

Issue 2:
@jakebolewski, @jiahao and I have been thinking through some type system improvements and things are starting to materialize. I believe this will consist of:

Use DataType to implement tuple types, which will allow for more efficient tuples, and make tuple types less of a special case in various places. This might also open the door for user-defined covariant types in the future. (DONE)

Add UnionAll types around all uses of TypeVars. Each UnionAll will bind one TypeVar, and we will nest them to allow for triangular dispatch. So far we've experimented with just sticking TypeVars wherever, and it has not really worked. We don't have a great syntax for this yet, but for now will probably use @UnionAll T<:Int Array{T}. These are mostly equivalent to existential types.

Unspecialized parametric types will actually be UnionAll types. For example Complex will be bound to @UnionAll T<:Real _Complex{T} where _Complex is an internal type constructor.

Technically, (Int,String) could be a subtype of @UnionAll T (T,T) if T were Union(Int,String), or Any. However dispatch doesn't work this way because it's not very useful. We effectively have a rule that if a method parameter T only appears in covariant position, it ranges over only concrete types. We should apply this rule explicitly by marking TypeVars as appropriate. So far this is the best way I can think of to model this behavior, but suggestions are sought.

TypeVars should only be compared by identity, and are not types themselves. We will not have syntax for introducing lone TypeVars; @UnionAll should suffice.

This is being prototyped in examples/juliatypes.jl. I hope this will fix most of the following issues:

method lookup and sorting issues:

#8959 #8915 #7221 #8163

method ambiguity issues:

#8652 #8045 #6383 #6190 #6187 #6048 #5460 #5384 #3025 #1631 #270

misc. type system:

#8920 #8625 #6984 #6721 #3738 #2552 #8470

In particular, type intersection needs to be trustworthy enough that we can remove the ambiguity warning and generate a runtime error instead.
Issue 1:
I don't know who's making the bug, so reporting here. I'll move to correct repo if someone helps me debug it.

Do you want to request a feature or report a bug?

Bug

What is the current behavior?

Please watch below screencast:

https://drive.google.com/file/d/1KMP44qsZ4y3MwrLLDdnOzPZ8z5mMElFP/view

Goto https://react-devtools-tutorial.now.sh/editing-props-and-state

Change the last ListItem prop to isComplete from false to true.

Click the checkbox in the view to change the state again from true to false.

What is the expected behavior?

It should just change the state of that ListItem. Instead, it's adding 3 more in the list with duplicate keys.

Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?

Latest React.

Mac, Chrome Version 75.0.3770.142 (Official Build) (64-bit)

Issue 2:
Where does proptypes doc live? It's confusing it's still on React object but inaccessible from the website through search or table of contents. Let's either reinstantiate it or move it fully to the standalone repo. Also it's confusing we're deprecating createClass but it still lives in the docs ("React without ES6") whereas we're just "moving" PropTypes but they're gone from the docs.
Issue 1:
(This may well be a duplicate, but I didn't find a specific duplicate and I'm not clueful enough to figure out if it's included in any of the others.)

Environment

Windows build number: 10.0.18945.1001
Windows Terminal version (if applicable): 0.3.2142.0

Any other software?

Reproduced using Debian Buster; also, font in use in both Terminal and console is Consolas.

Steps to reproduce

Ensure that you are configured to use the UTF-8 locale and UTF-8 codeset; i.e., that the output of the locale command is as follows:

LANG=en_US.UTF-8 LANGUAGE=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL=en_US.UTF-8

Run pstree, or another command which detects and uses UTF-8 line-drawing characters.

Note that this is not the default configuration of Debian for the en_US.UTF-8 locale, which leaves LC_ALL set to C; sudo update-locale LC_ALL=en_US.UTF-8 is required.

Expected behavior

Actual behavior

Expected behavior is line-drawing characters, as seen in console on the right. Actual behavior is all such characters rendering as "underline", as seen in Terminal on the left.

Issue 2:
Environment

Windows build number: Microsoft Windows [Version 10.0.18362.267]
Windows Terminal version (if applicable): 0.3.2171.0

Any other software?

Steps to reproduce

Edit config.

For any keybinding, add an additional key definition to the "keys" list.

Close and re-open Terminal

See that the entire command has been removed from the "keybindings" section of the config

In my case, I was trying to add shift+insert as an additional paste keybinding. At first, I though the problem was an incorrect key specification on my part, but using "shift+insert" as the sole keybinding worked fine.

Expected behavior

At the very least, I would expect both the keybinding element, and the first item in the "keys" list, to be maintained.

Ideally, all keybindings in the list would work to activate the function (assuming no conflicts with keybindings in other functions).

Actual behavior

The entire keybinding element is removed
Issue 1:
This is a regression from 0.6.2 which affects DataFramesMeta (JuliaData/DataFramesMeta.jl#88). Under some very particular circumstances, expression interpolation reverses the order of keys in a dictionary, compared with the order obtained in other places inside the same function. This is a problem when the function relies on the order of keys matching that of values (as with DataFrames macros).

In the following example, :a appears before :b in the two first lines inside the quoted block, but that's the contrary for the third line.

function with_helper()
membernames = Dict{Symbol,Int}(:a => 1, :b => 2)
quote
$(keys(membernames)...)
$(map(key -> :($key), keys(membernames))...)
$(map(key -> :(somedict[$key]), keys(membernames))...)
end
end

julia> with_helper()
quote
#= REPL[1]:4 =#
a
b
#= REPL[1]:5 =#
a
b
#= REPL[1]:6 =#
somedict[b]
somedict[a]
end

Issue 2:
When computing the matrix product of a transposed real matrix with a complex matrix, I encountered a performance issue.

Consider the following computations:

julia> A=randn(1000,1000);
julia> B=randn(1000,1000);
julia> Z=complex(randn(1000,1000),randn(1000,1000));
julia> # pre-compiling
julia> A'*B;
julia> A'*Z;
julia> complex(A'*real(Z),A'*imag(Z));
julia> # timing
julia> @time A'*B;
0.025224 seconds (130 allocations: 7.637 MB)
julia> @time A'*Z;
1.899244 seconds (6 allocations: 15.259 MB)
julia> @time complex(A'*real(Z),A'*imag(Z));
0.062084 seconds (16 allocations: 45.777 MB, 8.73% gc time)

The latter two computations are mathematically identical, however the last (more complex) expression is ~30x faster (and only ~2 times slower than the corresponding real-real product, as one would expect) than the straightforward expression A'*Z. Shouldn't both expressions be comparable in performance?

I am running Julia 0.5.2 on Ubuntu 14.04.

sysinfo() output:

Julia Version 0.5.2
Commit f4c6c9d4bb (2017-05-06 16:34 UTC)
Platform Info:
OS: Linux (x86_64-linux-gnu)
CPU: Intel(R) Core(TM) i7-4702HQ CPU @ 2.20GHz
WORD_SIZE: 64
BLAS: libopenblas (NO_LAPACK NO_LAPACKE DYNAMIC_ARCH NO_AFFINITY Haswell)
LAPACK: liblapack.so.3
LIBM: libopenlibm
LLVM: libLLVM-3.7.1 (ORCJIT, haswell)
Issue 1:
Continuing #3059.

See also #3092

allow dupe columns when they are in the same block/dtype

Perhaps figure out a way to handle that case as well.

Issue 2:
Code Sample, a copy-pastable example if possible

>>> import pandas as pd
>>> s = pd.Series()
>>> ts = pd.Timestamp('2016-01-01')
>>> s['a'] = None
>>> s['b'] = ts
>>> s
a None
b 1451606400000000000
dtype: object

OK, no worries, we got coerced to integer. Now let's just redo the same assignment:

>>> s['b'] = ts
>>> s
a None
b 2016-01-01 00:00:00
dtype: object

That's ... suprising. This is probably just an unfortunate feature of a type inference algorithm, but it's awfully shocking.

Related examples for testing

#18410

#21143

Expected Output

The two outputs above would be identical; I'd prefer that they were both the second form (with timestamp information preserved), but anything consistent would be better than the current state.

output of pd.show_versions()

>>> pd.show_versions()

INSTALLED VERSIONS
------------------
commit: None
python: 2.7.11.final.0
python-bits: 64
OS: Darwin
OS-release: 15.6.0
machine: x86_64
processor: i386
byteorder: little
LC_ALL: None
LANG: en_US.UTF-8

pandas: 0.18.1
nose: None
pip: 8.1.2
setuptools: 25.1.4
Cython: None
numpy: 1.11.1
scipy: None
statsmodels: None
xarray: None
IPython: None
sphinx: None
patsy: None
dateutil: 2.5.3
pytz: 2016.6.1
blosc: None
bottleneck: None
tables: None
numexpr: None
matplotlib: None
openpyxl: None
xlrd: None
xlwt: None
xlsxwriter: None
lxml: None
bs4: None
html5lib: None
httplib2: None
apiclient: None
sqlalchemy: None
pymysql: None
psycopg2: None
jinja2: None
boto: None
pandas_datareader: None
Issue 1:
Trying to implement a tree-like structure:

extern mod core(vers = "0.5");

priv struct Node<K, V> {
left: core::Option<Node<K, V>>
}

I hit the following compiler error:

rust: task 7f3b6c105dd0 ran out of stack
/usr/local/bin/../lib/librustrt.so(_ZN9rust_task13begin_failureEPKcS1_m+0x4b)[0x7f3b73b0e45b]
/usr/local/bin/../lib/librustrt.so(_ZN9rust_task9new_stackEm+0x158)[0x7f3b73b0e928]
/usr/local/bin/../lib/librustrt.so(+0x30229)[0x7f3b73b22229]
/usr/local/bin/../lib/librustrt.so(upcall_new_stack+0x280)[0x7f3b73b12040]
/usr/local/bin/../lib/librustc-c84825241471686d-0.5.so(+0x767fa2)[0x7f3b742bbfa2]
/usr/local/bin/../lib/librustc-c84825241471686d-0.5.so(+0x2f2c59)[0x7f3b73e46c59]
/usr/local/bin/../lib/librustc-c84825241471686d-0.5.so(_ZN6middle2ty14__extensions__10meth_3526010iter_bytes15_abfbbb3dea17df3_05E+0xc3f)[0x7f3b73e1bc3f]
/usr/local/bin/../lib/librustc-c84825241471686d-0.5.so(_ZN6middle2ty14__extensions__10meth_3525510iter_bytes15_abfbbb3dea17df3_05E+0x85)[0x7f3b73e1adb5]
/usr/local/bin/../lib/librustc-c84825241471686d-0.5.so(+0x2d6ebf)[0x7f3b73e2aebf]
/usr/local/bin/../lib/librustc-c84825241471686d-0.5.so(+0x2d62ef)[0x7f3b73e2a2ef]
/usr/local/bin/../lib/librustc-c84825241471686d-0.5.so(_ZN6middle2ty9mk_struct16_beb59be6919256b3_05E+0x11e)[0x7f3b73e311de]
/usr/local/bin/../lib/librustc-c84825241471686d-0.5.so(_ZN6middle2ty19fold_regions_and_ty17_4c9b12843e648dc73_05E+0x93a)[0x7f3b73e33dfa]
/usr/local/bin/../lib/librustc-c84825241471686d-0.5.so(+0x2e1f54)[0x7f3b73e35f54]
/usr/local/bin/../lib/librustc-c84825241471686d-0.5.so(+0x111321)[0x7f3b73c65321]
/usr/local/bin/../lib/librustc-c84825241471686d-0.5.so(+0x2e03ea)[0x7f3b73e343ea]
/usr/local/bin/../lib/librustc-c84825241471686d-0.5.so(_ZN6middle2ty19fold_regions_and_ty17_4c9b12843e648dc73_05E+0x26a)[0x7f3b73e3372a]
/usr/local/bin/../lib/librustc-c84825241471686d-0.5.so(+0x2e1f54)[0x7f3b73e35f54]
/usr/local/bin/../lib/librustc-c84825241471686d-0.5.so(_ZN6middle2ty5subst16_b2fc4a1db6bca5d3_05E+0x2fb)[0x7f3b73d0772b]
/usr/local/bin/../lib/librustc-c84825241471686d-0.5.so(_ZN6middle2ty17lookup_field_type17_f6b5a6d1e0e9fa5f3_05E+0x1bb)[0x7f3b73d6472b]

Issue 2:
This is an ICE on some obviously bogus input code.

struct A<X>;

fn foo<I:A<&'self int>>() { }

fn main() { }

Transcript:

% RUST_LOG=rustc=1 rustc --version /tmp/baz2.rs
/Users/pnkfelix/opt/rust-dbg/bin/rustc 0.8-pre (dd5c737 2013-09-08 12:05:55 -0700)
host: x86_64-apple-darwin
% RUST_LOG=rustc=1 rustc /tmp/baz2.rs
task <unnamed> failed at 'assertion failed: rp.is_none()', /Users/pnkfelix/Dev/Mozilla/rust.git/src/librustc/middle/typeck/collect.rs:1108
error: internal compiler error: unexpected failure
note: the compiler hit an unexpected failure path. this is a bug
note: try running with RUST_LOG=rustc=1 to get further details and report the results to github.com/mozilla/rust/issues
task <unnamed> failed at 'explicit failure', /Users/pnkfelix/Dev/Mozilla/rust.git/src/librustc/rustc.rs:376
%