WhereIsAI/github-issue-similarity huggingface dataset:
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:

8.x - 12.0.0-beta14

Operating System:

Windows 10 (Build 18363)

Last Known Working Electron version:

N/A

Expected Behavior

BrowserView should fill the available space in BrowserWindow when application window size is changed when it has been set to autoresize view according to BrowserWindow width/height.

Actual Behavior

BrowserView does fill the available space, but leaves small gaps to the right/bottom side of the view. Gap size is relative to how much the size is enlarged. This happens only in Windows. On Linux there are no gaps and changing window size works without

issues.

To Reproduce

Gist for Electron Fiddle: https://gist.github.com/4c1a403df092cded0d8ff85640a9c19f

Screenshots

2021-01-12.21-38-28.mp4

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: confirmed in 8.0.1, 7.1.2, 5.0.7, 4.0.0

Operating System: Windows 10

Expected Behavior

I have a BrowserView that is configured to resize with the window. I have a resize handler on the BrowserWindow that in some cases calls setBounds/setSize to change the size of the window.

I expect the BrowserView to resize with the window.

Actual Behavior

The BrowserView doesn't resize correctly and shrinks.

To Reproduce

Download the quickstart app. Replace main.js with:

const { app, BrowserWindow, BrowserView } = require('electron')

async function createWindow() {
const mainWindow = new BrowserWindow({ backgroundColor: "#000" });
const view = new BrowserView();
mainWindow.setBrowserView(view);

const contentBounds = mainWindow.getContentBounds();
view.setBounds({ x: 0, y: 0, width: contentBounds.width, height: contentBounds.height });
view.setAutoResize({ width: true, height: true });

await view.webContents.loadURL("https://google.com");

mainWindow.once("maximize", () => {
mainWindow.once("resize", () => {
mainWindow.setSize(1000, 1000);
setTimeout(() => {
console.log(mainWindow.getBounds()); // logs what it used to be at {x: 914, y: 62, width: 800, height: 600}
console.log(view.getBounds()); // bounds are not resized correctly: {x: 0, y: 0, width: 0, height: 145}
}, 1000);
});
});
}

app.on('ready', createWindow)

Run npm start, maximize the window to set up the resize handler, and then unmaximize it.

Observe all the black space in the window where you would expect to see the browser view (google).

Another thing to note is how the window size doesn't increase to 1000x1000 and stays whatever size it was. It does look like the BrowserView size increases, and it ends up out of sync with the window.

Maybe the issue isn't about the BrowserView, but more about the window size not increasing.

Gif
Issue 1:
Also, what is the latest stable version? I use 3.7.0 but I see there is a 3.8 and a 3.7.1? Which is the latest stable?

Issue 2:
Right now Glide is in a bit of an awkward state with 3.x being updated from times to times while the focus seems to be on version 4.

3.x is a bit of a pain to compile with JVM 7 and old support libraries while improvements made on the 4.x branch can only be used if we compile it ourselves.

Is there any plan to officially publish Glide 4.0 soon ? From what I can gather it is already used internally at Google on some products so it sounds stable enough.

IMO it would benefit the library to focus on this branch and only maintain 3.x .
Issue 1:
My issue is about scipy.signal.medfilt(values, window). It works perfectly between values[(window+1)/2 : -(window+1)/2]. Near the edges it returns a ascending sorted list of values at the beginning and descending sorted list of values at the end.

This should be either metioned in the document or fixed as a proper median.

The input list at the example below:

values = [0,1,1,0.8,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,1,1]

should produce (assuming nanmedian behavior for values outside the list):

0: median([nan, nan, nan,0,1,1,0.8]) = (0.8+1)/2 = 0.9

1: median([nan,nan,0,1,1,0.8,1]) = 1

2: median([nan,0,1,1,0.8,1,1) = 1

3: median([0,1,1,0.8,1,1,1]) = 1

4: median([1,1,1,0.8,1,1,1]) = 1

The output should thus start as [0.9,1,1,1,1,1,...]

alternatively if the window size is reduced when approaching the edge:

0: median([0]) = 0

1: median([0,1) = 0.5

2: median([0,1,1]) = 1

3: median([0,1,1,0.8]) =(0.8+1)/2 = 0.9

4: median([0,1,1,0.8,1]) = 1.0

The output should then start [0,0.5,1,0.9,1,1,1,1,1,...]

Instead the actual output start is [0,0.8,1,1,...] which is a sorted list of first 4 elements.

The same happens at the end.

This current output is perfectly ok if it would be mentioned in the documentation. For example: "Medfilt returns the median with a running window when index is greater than (window+1)/2. The beginning of the output is the ascending list of input values upto the (window+1)/2. Behavior is the same near the end of the input list but with descending input values from indices - (window+1)/2"

Reproducing code example:

from scipy.signal import medfilt
values = [0,1,1,0.8,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,1,1]
print(medfilt(values,7))

Scipy/Numpy/Python version information:

Python 3.8 64bit

1.4.0 1.17.4 sys.version_info(major=3, minor=8, micro=0, releaselevel='final', serial=0)

Python 2.7 32bit

('1.2.2', '1.15.4', sys.version_info(major=2, minor=7, micro=15, releaselevel='final', serial=0))

Issue 2:
Hi, I have been facing a lot of issues while installing python packages such as scipy, skearn, numpy, spacy and scikit-learn. I tried using pip, conda but unfortunately i was not able to install all requirements. Is there any problem of mac m1 processor with packages like scipy, skearn, numpy, spacy and scikit-learn

I tried a lot and seeking a way to get the things resolved.
Issue 1:
Hi

when I write this code:

export default function Bug(props) {
return (
<Bug></Bug>
)
}

it will cause crashes and my browser never responses on the page and the page progress indicator turns forever without any error or something else. and the whole page freezes:

I report it because I know React provides infinite loops, but here it crashes unexpectedly.

Issue 2:
Do you want to request a feature or report a bug?

Feature (possibly bug?)

What is the current behavior?

I've been trying out the new Context API in my project and it's awesome. However, in my haste to start using it, I managed to stumble into a situation where every time I would try and render a certain component which was making use of a few different contexts, the app would completely freeze, and the only thing that would let me get out of this error state was to forcefully kill the process via the chrome task manager.

Nothing would be logged to the console, the app would just completely freeze, and when I opened up the task manager and saw the CPU spiked up every time i would go to this component, and the only way I could stop it was to crash the tab.

I finally threw some console statements in and saw that it had just entered into an infinite loop between these providers. I managed to get the app to stop crashing, but I'm still unsure as to why exactly this was happening. I'm sure I was just using this API incorrectly somehow, but this was a very confusing problem to diagnose, and some error checking here would be incredibly useful

What is the expected behavior?

It would be very beneficial to have some sort of checks in place, similar to what happens with too many setState calls happening too closely when you call it from componentDidUpdate, for example. That way, instead of freezing everything up permanently, the app could at least crash and report some sort of information and help me realize where I'd gone wrong.

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

React 16.3.0

Chrome 65.0.3325.181
Issue 1:
Displaying Google Maps inside a Bootstrap layout gives some problems.

Check out the examples below.

http://jsbin.com/evuduw/ (master - bad)

http://jsbin.com/evuduw/3 (2.0-wip -- looks fixed)

The maps look okay, but if you try and switch the view to terrain or enable/disable "show labels" in the first the layout of the dropdown inside Google Maps looks quirky.

Issue 2:
When a "bare bones" Google Map is embedded on a Bootstrap-styled page inside a grid row & span, the terrain drop-down menu gets pushed off the side of the map:

http://imagebin.org/index.php?mode=image&id=174078

The satellite drop-down menu is similarly affected when 2 entries are present, but looks normal when only 1 entry is present:

http://imagebin.org/index.php?mode=image&id=174079

Removing the Bootstrap CSS link from the page (i.e. displaying the map un-styled) restores normal behavior.

This behavior observed in Chrome 14.0.835.186 and Firefox 3.6.22 on Ubuntu 10.04.
Issue 1:
Please, add an ability to take into account the Caps Lock key status when remapping shortcuts and maybe other keys which can be turned on and off.

The reason behind this is the following. Some laptops, for instance Surface Book, doesn't contain a numpad and any special key which turns a part of the keyboard to the numpad.

So, I personally had to write an AutoHotKey script to remap the "Shift + u" to 7, "Shift + i" to 8 and so on, but only when Caps Lock key is turned on.

Here is the full script code:

#NoEnv ; Recommended for performance and compatibility with future AutoHotkey releases.
; #Warn ; Enable warnings to assist with detecting common errors.
SendMode Input ; Recommended for new scripts due to its superior speed and reliability.
SetWorkingDir %A_ScriptDir% ; Ensures a consistent starting directory.

#Singleinstance force

#If GetKeyState("CapsLock", "T")
<+m::Send,1
<+,::Send,2
<+.::Send,3
<+j::Send,4
<+k::Send,5
<+l::Send,6
<+u::Send,7
<+i::Send,8
<+o::Send,9
<+n::Send,0
<+/::Send,.
<+8::Send,/
<+9::Send,*
<+p::Send,-
<+`;::Send,{+}

It would be nice if the Keyboard Manager would allows us to remap a shortcut to a single key when some key is turned on.

For instance: remap "Shift + u" to 7 only when "Caps Lock" is turned on.

Thank you!

Issue 2:
Dozens of us don't use Caps Lock at all during our normal workflow (dozens!), so it would be nice to be able to use it as an extra modifier when using the Remap Shortcuts functionality.

This is already a thing in macOS world thanks to tools like Karabiner Elements or BetterTouchTool that allow yout to turn Caps Lock into the "Hyper" modifier as it's commonly refered to. I'm sure there's something similar for Linux but I'm not that familiar with it.

In terms of implementation, I don't mind if Caps Lock is not recognised as a modifier straight away since maybe other people don't see it that way. I would be fine using Remap keyboard to map Caps Lock to this new virtual "Hyper" modifier so I can start using it for my Remap shortcuts.

Thanks for the tool by the way, I'm going to start moving most of my maps from AHK to the PowerToys!
Issue 1:
Hi,

Does tensorflow version r1.9 support Intel Xeon E5645 CPU?

Thanks !

Alan

Issue 2:
As announced in release notes, TensorFlow release binaries version 1.6 and higher are prebuilt with AVX instruction sets. This means on any CPU that do not have these instruction sets either CPU or GPU version of TF will fail to load with any of the following errors:

ImportError: DLL load failed:

A crash with return code 132

Our recommendation is to build TF from sources on these systems.

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): No

OS Platform and Distribution (e.g., Linux Ubuntu 16.04): ubuntu/windows/macos

TensorFlow installed from (source or binary): binary

TensorFlow version (use command below): 1.6 and up

Python version: 2.7, 3.3, 3.4, 3.5, 3.6 and any newer

Bazel version (if compiling from source): n/a

GCC/Compiler version (if compiling from source): n/a

CUDA/cuDNN version: any

GPU model and memory: any

Exact command to reproduce: python -c "import tensorflow as tf"
Issue 1:
On Julia master (so the conditional below evaluates as true).

This works:

julia> module MyMod

"""
A docstring
"""
macro mymac(ex)
return esc(ex)
end

end
Main.MyMod

help?> MyMod.@mymac
A docstring

But it doesn't if we put it inside a conditional expression (e.g., dependent on the Julia version):

julia> module MyMod

if VERSION >= v"1.2.0"
"""
A docstring
"""
macro mymac(ex)
return esc(ex)
end
end

end
WARNING: replacing module MyMod.
Main.MyMod

help?> MyMod.@mymac
No documentation found.

Main.MyMod.@mymac is a macro.

# 1 method for macro "@mymac":
[1] @mymac(__source__::LineNumberNode, __module__::Module, ex) in Main.MyMod at REPL[3]:8

However we can fix it with the post-hoc @doc mechanism:

julia> module MyMod

if VERSION >= v"1.2.0"
macro mymac(ex)
return esc(ex)
end
@doc "A docstring" :(MyMod.@mymac)
end

end
WARNING: replacing module MyMod.
Main.MyMod

help?> MyMod.@mymac
A docstring

Issue 2:
Noted during #22631

Meta.@lower begin
if true
"""
hello
"""
h() = 1
end
end
:($(Expr(:thunk, CodeInfo(
2 1 ─ goto #3 if not true │
6 2 ─ $(Expr(:method, :h)) │
│ %3 = (Core.Typeof)(h) │
│ %4 = (Core.svec)(%3) │
│ %5 = (Core.svec)() │
│ %6 = (Core.svec)(%4, %5) │
│ $(Expr(:method, :h, :(%6), CodeInfo(quote │
return 1
end)))
└── return h │
3 ─ return │
))))

vs

Meta.@lower begin
"""
hello
"""
h() =1
end
:($(Expr(:thunk, CodeInfo(
2 1 ─ $(Expr(:method, :h)) │
│ %2 = (Core.Typeof)(h) │
│ %3 = (Core.svec)(%2) │
│ %4 = (Core.svec)() │
│ %5 = (Core.svec)(%3, %4) │
│ $(Expr(:method, :h, :(%5), CodeInfo(quote │
return 1
end)))
│ %7 = (Base.Docs.Binding)(Main, :h) │
│ %8 = (Core.svec)(" hello\n") │
│ %9 = (Dict)(:path => "REPL[3]", :linenumber => 2, :module => Main) │
│ %10 = (Base.Docs.docstr)(%8, %9) │
│ %11 = (Core.apply_type)(Tuple) │
│ %12 = (Core.apply_type)(Union, %11) │
│ %13 = (Base.Docs.doc!)(Main, %7, %10, %12) │
└── return %13 │
))))
Issue 1:
Currently, you'll get an unexplained

error: unresolved modulename: std

Which is bound to confuse people.

Issue 2:
If you write something like #debug["%u", 10], the type error (unsigned vs signed int) gets reported in core.rs, at the definition of #debug, rather than at the point of use. This is very confusing and makes you think something is fundamentally wrong in the Rust libraries (as in, they don't compile) rather than your own code. I think this ought to be fixed before 0.1 so I associated it with that milestone, but others may disagree.
Issue 1:
details here:

https://groups.google.com/forum/#!topic/druid-user/K7YmcBJM6T4

please help!

Issue 2:
all the tasks keep restarting with this error in the logs:

I tried:

upgrading node from 0.12.1 to 0.12.2

spinning a whole new server and created a replica.

Completely unrecoverable!

2018-08-13 15:41:48,555 INFO i.d.i.o.ForkingTaskRunner [forking-task-runner-1] Exception caught during execution
java.io.IOException: Stream closed
at java.io.BufferedInputStream.getBufIfOpen(BufferedInputStream.java:170) ~[?:1.8.0_181]
at java.io.BufferedInputStream.read1(BufferedInputStream.java:291) ~[?:1.8.0_181]
at java.io.BufferedInputStream.read(BufferedInputStream.java:345) ~[?:1.8.0_181]
at java.io.FilterInputStream.read(FilterInputStream.java:107) ~[?:1.8.0_181]
at com.google.common.io.ByteStreams.copy(ByteStreams.java:175) ~[guava-16.0.1.jar:?]
at io.druid.indexing.overlord.ForkingTaskRunner$1.call(ForkingTaskRunner.java:452) [druid-indexing-service-0.12.2.jar:0.12.2]
at io.druid.indexing.overlord.ForkingTaskRunner$1.call(ForkingTaskRunner.java:224) [druid-indexing-service-0.12.2.jar:0.12.2]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_181]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_181]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_181]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]

Even posted a thread here:

https://groups.google.com/forum/#!topic/druid-user/K7YmcBJM6T4

More details:

Coord+overlord node is still at 0.12.1 (we havent upgraded it yet, for fear of more damage)

another replica of MM node (we deploy 2) has been running without issue. we are very, very scared that if that replica dies and gets stuck like this, ALL ingestion will stop!

All help is highly appreciated.
Issue 1:
I just stumbled upon an illegal instruction while redefining a function called with splatting, under some peculiar conditions. Here is a minimal test case:

b = 1
v = (1,)

# type annotation for A (but not the actual type) is necessary to trigger the bug
# the return value is not important
f(A::Any, I1) = 1

# the splatting is necessary to trigger the bug
# two calls are needed
f(b, v...)
f(b, v...)

f(A::Any, I1) = error()

# the for loop is required to trigger the bug
for i = 1; f(b, v...); end

The output is:

WARNING: Method definition f(Any, Any) in module Main at /home/carlo/Programs/julia/bug.jl:6 overwritten at /home/carlo/Programs/julia/bug.jl:13.

signal (4): Illegal instruction
while loading /home/carlo/Programs/julia/bug.jl, in expression starting on line 16
macro expansion; at /home/carlo/Programs/julia/bug.jl:16
unknown function (ip: 0x7f6df02bc87f)
jl_call_method_internal at /home/carlo/Programs/julia/src/julia_internal.h:86
jl_parse_eval_all at /home/carlo/Programs/julia/src/ast.c:699
jl_load at /home/carlo/Programs/julia/src/toplevel.c:569
include_from_node1 at ./loading.jl:426
unknown function (ip: 0x7f70070fa13c)
jl_call_method_internal at /home/carlo/Programs/julia/src/julia_internal.h:86
do_call at /home/carlo/Programs/julia/src/interpreter.c:65
eval at /home/carlo/Programs/julia/src/interpreter.c:188
jl_toplevel_eval_flex at /home/carlo/Programs/julia/src/toplevel.c:529
jl_toplevel_eval_in_warn at /home/carlo/Programs/julia/src/builtins.c:571
eval at ./boot.jl:231
unknown function (ip: 0x7f70070e07d0)
jl_call_method_internal at /home/carlo/Programs/julia/src/julia_internal.h:86
eval_user_input at ./REPL.jl:62
unknown function (ip: 0x7f6df02bc5b6)
jl_call_method_internal at /home/carlo/Programs/julia/src/julia_internal.h:86
macro expansion; at ./REPL.jl:92
unknown function (ip: 0x7f6df02b8c8f)
jl_call_method_internal at /home/carlo/Programs/julia/src/julia_internal.h:86
jl_apply at /home/carlo/Programs/julia/src/julia.h:1388
unknown function (ip: 0xffffffffffffffff)
Allocations: 4248296 (Pool: 4247549; Big: 747); GC: 9
Illegal instruction (core dumped)

This is on:

Julia Version 0.5.0-dev+4882
Commit 3aafa05* (2016-06-21 12:36 UTC)
Platform Info:
System: Linux (x86_64-linux-gnu)
CPU: Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz
WORD_SIZE: 64
BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
LAPACK: libopenblas64_
LIBM: libopenlibm
LLVM: libLLVM-3.7.1 (ORCJIT, haswell)

Issue 2:
I found that sometimes function overwriting does not work right away. The method redefinition warning gets triggered, but the old function definition is used.

Here is a minimal test case which shows the bug (the last call fails, but calling f() again then produces 2 as expected):

f() = 1

# at least two calls are required to trigger the bug
f()
f()

f() = 2

@assert f() == 2 # fails

This is on version 0.5.0-dev+4882.
Issue 1:
🐛 Bug

To Reproduce

Steps to reproduce the behavior:

import torch
a = torch.arange(1,17).float().reshape(4,4)
print(a)
cpu_res = torch.mean(a, (0,0))
cuda_res = torch.mean(a.cuda(), (0,0))
print(cpu_res)
print(cuda_res)

Result is

tensor([[ 1., 2., 3., 4.],
[ 5., 6., 7., 8.],
[ 9., 10., 11., 12.],
[13., 14., 15., 16.]])
tensor([1.7500, 2.0000, 2.2500, 2.5000])
tensor([ 7., 8., 9., 10.], device='cuda:0')

When transfer a same dim like 0 twice, CUDA and CPU return different result. It seems like CPU calculates mean twice and CUDA not.

cc @ezyang @gchanan @zou3519

Issue 2:
🐛 Bug

I am not sure if this is reproducible for every environment, but I hit the following error when trying to set cuda device in processes. What is weird is that the error disappears if I remove the line x = torch.rand(20, 2).cuda() right after the for loop.

Traceback (most recent call last):
File "/home/shenli/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/home/shenli/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "dist_bug.py", line 5, in run
torch.cuda.set_device(rank)
File "/home/shenli/project/pytorch/torch/cuda/__init__.py", line 265, in set_device
torch._C._cuda_setDevice(device)
RuntimeError: cuda runtime error (3) : initialization error at ../torch/csrc/cuda/Module.cpp:33

Edit: based on the discussion below, the solution should be fixing the "bad fork" error detection, which is duplicated with #17359.

To Reproduce

import torch
from torch.multiprocessing import Process

def run(rank):
torch.cuda.set_device(rank)

if __name__ == "__main__":
size = 2
processes = []
for rank in range(size):
# it would work fine without the line below
x = torch.rand(20, 2).cuda()
p = Process(target=run, args=(rank,))
p.start()
processes.append(p)

for p in processes:
p.join()

Environment

PyTorch version: 1.1.0a0+63214b5

Is debug build: No

CUDA used to build PyTorch: 9.2.88

OS: CentOS Linux 7 (Core)

GCC version: (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28)

CMake version: version 3.12.2

Python version: 3.7

Is CUDA available: Yes

CUDA runtime version: 9.2.88

GPU models and configuration:

GPU 0: Tesla M40

GPU 1: Tesla M40

Nvidia driver version: 396.26

cuDNN version: Could not collect

Versions of relevant libraries:

[pip] numpy==1.15.4

[pip] torch==1.1.0a0+63214b5

[conda] blas 1.0 mkl

[conda] mkl 2019.1 144

[conda] mkl-include 2019.1 144

[conda] mkl_fft 1.0.6 py37hd81dba3_0

[conda] mkl_random 1.0.2 py37hd81dba3_0

[conda] torch 1.1.0a0+63214b5 dev_0
Issue 1:
While running an example from recommender system package for movielens data, the performance of multithreaded parallel version does not seem to scale well.

To run the example download the dataset from here, unzip the files to any folder. Clone this repository and run the movielens example in julia built with multithreading,

have a thread enabled julia build

include the julia file

set OPENBLAS_NUM_THREADS to 1

set JULIA_NUM_THREADS to desired number of threads

call the test_thread(dataset_path) method in the example script

Issue 2:
I ran my Logistic Regression benchmark for threads. Not sure if this is related to earlier issues or not, but I thought I'd post an issue anyway.

Usually the output would be (on a version of master sometime in January)

Warm up run : 25 iterations!
Time taken by serial implementation = 1.508228316
Time taken by parallel implementation = 0.429550363
Speedup over 4 threads : 3.5111792374390336

Now, with the current threaded build of master, it's this:

Warm up run : 25 iterations!
Time taken by serial implementation = 1.831504341
Time taken by parallel implementation = 42.974081761
Speedup over 4 threads : 0.04261881268774738