WhereIsAI/github-issue-similarity huggingface dataset:
Issue 1:
I'm using the Atom for Windows Alpha from the Atom website (not Chocolatey), version 0.136.0 (as viewed in the Help menu and with --version in the command line, the version file in the Atom folder says v0.17.1; it was downloaded around 12:30AM US Eastern on October 14, 2014 if that helps) on Windows 8.1. I set text-rendering: optimizeLegibility; for .editor in styles.less (because otherwise the ligatures aren't in effect and I get each individual character). This happens regardless of whether hardware acceleration is enabled. It also happens in --safe mode, and the developer tools console shows no errors.

(<*>)::Functor f=>(a->b)->(f a->f b)
fmap::Functor f=>(a->b)->(f a->f b)

in Hasklig, which has ligatures for <*>, ::, =>, and ->.

fifififififififififi

in Calibri, using the ligature for fi. The cursor is at the end of the line, and the misspell underline only leads up to that point as well. The ligature for ff in Calibri has the opposite effect; the cursor and underline extend farther than text on the screen if you put enough f's on a line.

I can provide more details if you need them.

Issue 2:
This is more of a discussion than a concrete list of actionable items. Since Atom's launch, I've started to notice more things seeking my attention in an increasingly aggressive manner. They seem small in isolation, but when you add them up and make them recurring, Atom can begin to nag you.

Below is the most recent example. I wanted to take a quick look at some docs, so I run atom .

a. Non-fatal errors are blocking content - Is this dialog necessary given b.?

b. Duplicate update notices - How can Atom minimize these or get rid of them completely?

c. The ! feels unnecessary - Deprecation and update notices now contain an ! mark. It's small, but this changes the tone of the message from informing me, to shouting at me.

d. More packages. more notices - It seems logical that the longer you are an Atom user, the more package you install, the more notices you are going to get.

Deprecation notices

When you click on the deprecation notice text in the status bar, you are taken to this screen:

This screen feels unnecessary to anyone using Atom. Unless I'm a developer or I'm specifically trying to debug packages, I'm not too concerned with what methods in what packages are deprecated. I would like the deprecation message to go away so I can get back to work. How can Atom help me do that? Could the "Check for updates" step happen automatically? Could updates be installed during relaunch or during idle time?

Package updates

There's 1 update available. When I click the notice in the status bar, I'm taken to this screen that runs an additional check for updates and then lists the packages that have updates. Does Atom need to run this check again since it knows I have a package that needs an update already?

Some considerations

In the spirit of GitHub Zen, here are a few things to consider:

Atom should strive to not block content for non-fatal errors.

Atom should strive to keep notifications to a minimum.

Atom should strive to reduce manual administrative overhead (updating packages, atom, etc.).

🙇 Thanks for the fantastic work
Issue 1:
I ran into this error when running python .\tools\test.py

E:\Workspace\Github\deno\out\debug\deno.exe E:\Workspace\Github\deno\tests\003_relative_import.ts --reload
E:\Workspace\Github\deno\out\debug\deno.exe E:\Workspace\Github\deno\tests\004_set_timeout.ts --reload
E:\Workspace\Github\deno\out\debug\deno.exe E:\Workspace\Github\deno\tests\005_more_imports.ts --reload
E:\Workspace\Github\deno\out\debug\deno.exe E:\Workspace\Github\deno\tests\006_url_imports.ts --reload
127.0.0.1 - - [23/Sep/2018 20:32:26] "GET /tests/subdir/mod2.ts HTTP/1.1" 200 -
127.0.0.1 - - [23/Sep/2018 20:32:27] "GET /tests/subdir/print_hello.ts HTTP/1.1" 200 -
Expected success but got error. Output:
Downloading http://localhost:4545/tests/subdir/mod2.ts
Downloading http://localhost:4545/tests/subdir/print_hello.ts
error TS5009: Cannot find the common subdirectory path for the input files.

OS: Windows 10 x64

Node version: v8.12.0

NPM version: v6.4.1

How to solve this issue?

P.S. Similar issue was faced here and here not sure if both are relevent but I can't figure it out still.

Issue 2:
There is some problem on Windows WRT to module resolution and the $DENO_DIR environmental variable.

I've seen it in #1356 and denoland/deno_std#37

2018-12-20T21:08:48.3095557Z C:\Users\VssAdministrator\.deno\bin\deno.exe test.ts --allow-run --allow-net
2018-12-20T21:08:48.3724814Z ##[command]"C:\Windows\system32\cmd.exe" /D /E:ON /V:OFF /S /C "CALL "D:\a\_temp\eaf9adfb-fc74-4aa4-9a31-70201da22e50.cmd""
2018-12-20T21:08:48.9943938Z Compiling D:/a/1/s/test.ts
2018-12-20T21:08:49.6446393Z Downloading https://deno.land/x/testing/testing.ts...
2018-12-20T21:08:49.8951715Z Downloading https://deno.land/x/testing/util... NOT FOUND
2018-12-20T21:08:50.1296920Z Downloading https://deno.land/x/testing/util.ts...
2018-12-20T21:08:51.0053504Z ‌error‌ TS5009: ‌Cannot find the common subdirectory path for the input files.‌
2018-12-20T21:08:51.0054022Z

You can reproduce this by cloning https://github.com/denoland/deno_std and running deno test.ts
Issue 1:
GradientBoostingClassifier does not work correctly, when the BasePredictor (init) is set to something like linear_model.LogisticRegression().

I thinks the source of the error is in in BaseGradientBoosting.fit() where

# init predictions

y_pred = self.init_.predict(X)

y_pred should be initialized by class probabilities and not with the winner class.

Replacing y_pred = self.init_.predict(X) with y_pred = self.init_.predict_proba(X) can solve the problem.

Issue 2:
here is a tiny script which reproduces the crash.

from sklearn.datasets import load_iris
from sklearn import ensemble
from sklearn.cross_validation import train_test_split

iris = load_iris()
X, y = iris.data, iris.target
X, y = X[y < 2], y[y < 2] # make it binary

X_train, X_test, y_train, y_test = train_test_split(X, y)

# Fit GBT init with RF
rf = ensemble.RandomForestClassifier()
clf = ensemble.GradientBoostingClassifier(init=rf)

clf.fit(X_train, y_train)
acc = clf.score(X_test, y_test)
print("Accuracy: {:.4f}".format(acc))

It also seems that the init param in GradientBoostingClassifier is

not really tested.

@pprett @glouppe @ogrisel
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: v12.0.0-beta.28

Operating System: macOS 11.1

Actual Behavior

The borders are incorrectly drawn. It was fine in macOS Catalina.

To Reproduce

const mainWindow = new BrowserWindow({
width: 800,
height: 600,
titleBarStyle: 'hiddenInset',
vibrancy: 'sidebar'
})

Fiddle Gist: https://gist.github.com/0d9f9327689a795cc95f1c046cbed488

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:

11x

Operating System:

macOS 11.1 [Big Sur]

Last Known Working Electron version:

Expected Behavior

when using BrowserWindow vibrancy effects eg: vibrancy: 'sidebar', the corners of the window are squared.

Actual Behavior

To Reproduce

Create a new BrowserWindow with vibrancy effects eg: vibrancy: 'sidebar'.

https://gist.github.com/262108f4d281d9aa780ecc18f7ade2ba

Screenshots

Additional Information

Adding titleBarStyle: 'hidden' rounds the corners, but the corner radius is smaller that normal windows in Big Sur.

Which seems to be the issue shown here: #27061
Issue 1:
julia> using LinearAlgebra

julia> @which Matrix(Diagonal(rand(3)))
(::Type{Array{T,2} where T})(D::Diagonal) in LinearAlgebra at /Users/osx/buildbot/slave/package_osx64/build/usr/share/julia/stdlib/v0.7/LinearAlgebra/src/diagonal.jl:56

julia> versioninfo()
Julia Version 0.7.0-beta.201
Commit cdd4e84ac9 (2018-07-07 22:13 UTC)
Platform Info:
OS: macOS (x86_64-apple-darwin14.5.0)
CPU: Intel(R) Core(TM) i7-3820QM CPU @ 2.70GHz
WORD_SIZE: 64
LIBM: libopenlibm
LLVM: libLLVM-6.0.0 (ORCJIT, ivybridge)

Issue 2:
Seems to be two, possibly disjoint problems observed here:

"repeated 387 more times" and the immediately subsequent "repeated 166 more times" are precisely the same stacktrace

the interpreter duplicates f28442 on the callstack

$ ./julia --compile=min -q
julia> begin
f28442(c) = g28442(c + 1)
g28442(c) = c > 2000 ? (return backtrace()) : f28442(c + 1)
bt = f28442(1)
Base.show_backtrace(stdout, bt)
end

Stacktrace:
[1] g28442(::Int64) at REPL[0]:3
[2] f28442(::Int64) at REPL[0]:2
... (the last 2 lines are repeated 442 more times)
[887] g28442(::Int64) at REPL[0]:3
[888] f28442(::Int64) at REPL[0]:2 (repeats 2 times)
[889] g28442(::Int64) at REPL[0]:3
... (the last 2 lines are repeated 387 more times)
[1664] f28442(::Int64) at REPL[0]:2 (repeats 2 times)
[1665] g28442(::Int64) at REPL[0]:3
... (the last 2 lines are repeated 166 more times)
[1998] f28442(::Int64) at REPL[0]:2
[1999] top-level scope at REPL[0]:4
[2000] eval(::Module, ::Any) at ./boot.jl:319
[2001] eval_user_input(::Any, ::REPL.REPLBackend) at REPL.jl:85
[2002] macro expansion at REPL.jl:117 [inlined]
Issue 1:
The eigen / eigen! functions of the LinearAlgebra package fail with the Adjoint and Transposed types.

Given a square matrix A (e.g. a 10×10 Array{Float64,2}), both the following statements fail:

E = eigen(A')

E = eigen(transpose(A))

with errors

ERROR: MethodError: no method matching eigen(::Adjoint{Float64,Array{Float64,2}})

and

ERROR: MethodError: no method matching eigen(::Transpose{Float64,Array{Float64,2}})

respectively.

A simple fix could be to define the method

LinearAlgebra.eigen(x::Union{Transpose{T, A}, Adjoint{T, A}}) where {T, A<:AbstractMatrix} = eigen(copy(x)) (credit: Twan Koolen on discourse).

However, it could be more efficient to use LAPACK functions directly computing left eigenvectors (i.e. eigenvectors of the transposed) without making another copy of the matrix. It looks like the wrapper LinearAlgebra.LAPACK.geevx! has such a feature. In eigen.jl, the lower level LAPACK call (line 40 as of tag v1.0.0) is

A, WR, WI, VL, VR, _ = LAPACK.geevx!(permute ? (scale ? 'B' : 'P') : (scale ? 'S' : 'N'), 'N', 'V', 'N', A)

According to the documentation,

A, WR, WI, VL, VR, _ = LAPACK.geevx!(permute ? (scale ? 'B' : 'P') : (scale ? 'S' : 'N'), 'V', 'N', 'N', A)

should compute left eigenvectors instead.

I am very new to Julia (I have been mostly a Matlab programmer so far), so I am not quite sure what is a clean way to insert such a fix into eigen.jl. At least, duplicating the eigen! code in eigen.jl does not seem to be a very good idea. Also, adding this may not cover all eigen methods for special matrices. (The eigen! method in eigen.jl applies to StridedMatrix{T}, which I assume excludes at least sparse matrices.)

Note: this issue is similar to Issue #27132 regarding svdfact (now svd) which was fixed in PR #27916 . The fix for svd will not work here though.

Issue 2:
I use Julia (official distribution) on macOS.

Recently I set Terminal.app to start a non-default shell (see screenshot below). Now double-clicking Julia.app no longer starts Julia correctly. It just opens a terminal window.

Julia.app seems to use the following AppleScript to launch julia in a new Terminal.app window:

set RootPath to POSIX path of (path to me)
tell application id "com.apple.terminal"
do script ("exec '" & RootPath & "Contents/Resources/julia/bin/julia'")
activate
end tell

It is the do script that seems to not work under these circumstances, but I don't know how to fix it.
Issue 1:
Electron Version: 1.8.7/2.0.0

Operating System (Platform and Version): Windows 10

Last known working Electron version: Don't know

Expected Behavior

Keep the webview available to interact.

Actual behavior

Every time the webview execute window.close(), it's crashing the webview itself.

To Reproduce

$ git clone https://github.com/saenzramiro/electron-window-close-bug.git
$ npm install
$ npm start || electron .

Additional Information

I realized this because of Slack's. Every time you log in or log out, they redirect to a page that executes window.close(). I searched of this here but no luck, sorry if this is duplicated.

Issue 2:
Output of node_modules/.bin/electron --version: 3.0.0

Operating System (Platform and Version): macOS Sierra 10.12.6

Output of node_modules/.bin/electron --version on last known working Electron version (if applicable): 3.0.0-beta.1

Expected Behavior

creating a new browserWindow with titleBarStyle: hiddenInset, hidden or customButtonsOnHover, should generate the 'traffic lights' in macOS.

Actual behavior

The window doesn't generate the traffic lights, making impossible to control the window. (The buttons actions are still in the same visual place, it's just not being rendered).

To Reproduce

Just create a browser window and set the titleBarStyle to one of the options available.
Issue 1:
Hello,

I was working on a personal project, and I could not figure out why my expressions were not getting rebound in my views after new data. I was not getting any compile or console errors. Eventually I found out that I was not linking to angular2-polyfills in my index.html.

I know that the quickstart tutorial tells you to include the link, but I think it would be helpful to raise some sort of error if angular2-polyfills is not imported.

Issue 2:
Currently, the application will bootstrap, and the first digest will run successfully. But after that the application will stop reacting to changes, which is extremely confusing.
Issue 1:
How would you suggest I extend THREE.BinaryLoader? I'd like to augment it by adding support for morph targets after the current loading code.

Would it be possible to add createBinModel() and parseMetaData() to THREE.BinaryLoader (and change the call from THREE.BinaryLoader.prototype.createBinModel( xhr.response, callback, texturePath, json.materials ); to this.createBinModel( xhr.response, callback, texturePath, json.materials ); ) so we could override them as necessary in a subclass, or maybe add THREE.BrinaryLoader.init_extra_data( data, start )?

Thanks!

Issue 2:
BufferGeometry.fromDirectGeometry will import indices from DirectGeometry if they exist, and BufferGeometry.fromGeometry passes through DirectGeometry.fromGeometry first (as of r72 dev). But the indices get lost in the middle because DirectGeometry.fromGeometry does not create indices from faces in THREE.Geometry.

In #6377 @mrdoob asked:

Any reason you want indexed buffers out of THREE.Geometry? If it's for performance reasons I would, instead, focus on converting the primitives and loaders to BufferGeometry (or DynamicGeometry).

THREE.Geometry is easier to manipulate, so sometimes it's useful to start there and then convert it to BufferGeometry for rendering.

Related to #6191
Issue 1:
Qhull apparently has limits on how many input points it can handle. Scipy should check that before trying to use it for too big problems.

http://mail.scipy.org/pipermail/scipy-dev/2015-June/020820.html

Issue 2:
As discussed with @rgommers based on my ConvexHull stress tests for the maximum number of input points tolerated, it would perhaps be useful for ConvexHull to capture inputs over the maximum handled size & fail gracefully rather than segfaulting.

So, this issue is mostly a reminder / place to discuss possible ways to do this, or if we even need to. The approximate upper limit appears to be around 238 million points (see above links for details).

We could also check the quickhull publication for details on space complexity:

Barber, C.B., Dobkin, D.P., and Huhdanpaa, H.T., "The Quickhull algorithm for convex hulls," ACM Trans. on Mathematical Software, 22(4):469-483, Dec 1996

free article PDF -- note that this paper has been cited 3501 times.
Issue 1:
Initial window height is off by titlebar height. This got regressed by #3394 in:

terminal/src/cascadia/WindowsTerminal/AppHost.cpp

Lines 197 to 210
in
357e835

RECT islandFrame = {};

bool succeeded = AdjustWindowRectExForDpi(&islandFrame, WS_OVERLAPPEDWINDOW, false, 0, dpix);

// If we failed to get the correct window size for whatever reason, log

// the error and go on. We'll use whatever the control proposed as the

// size of our window, which will be at least close.

LOG_LAST_ERROR_IF(!succeeded);

if (_useNonClientArea)

{

islandFrame.top = -NonClientIslandWindow::topBorderVisibleHeight;

}

adjustedWidth = -islandFrame.left + islandWidth + islandFrame.right;

adjustedHeight = -islandFrame.top + islandHeight + islandFrame.bottom;

That also blocks #3181 which relys on this size calculation.

Steps to reproduce

Set fontSize to 50

Set initialRows to 2

Launch terminal

Expected behavior

2 rows should fit in the window

Actual behavior

About 1.5 of a row fits.

cc @greg904.

Issue 2:
Environment

Windows build number: 10.0.18362.239

Windows Terminal version (if applicable): 0.3.2171.0

Steps to reproduce

Open Windows Terminal (Preview)

The default Powershell tab opens, with the title "c:\windows\system32\WindowsPowerShell\v1.0\powershell.exe"

click the + button to open a new tab

A second tab opens. the title "c:\windows\system32\WindowsPowerShell\v1.0\powershell.exe" does not fit inside the tab, and is cut off at "...\pow" before the new Tab + button

Expected behavior

The x to close the second tab would be visible, after the truncated window title, and before the New Tab + button, to allow the tab to be closed.

Actual behavior

There is no x to close the tab available. It is truncated along with the window title.
Issue 1:
Description of the problem

I am trying to render a scene into another scene using WebGLRenderTarget in VR mode. I created two scenes - mainScene and bufferScene. I draw a red cube in bufferScene, then render the bufferScene to the texture bufferTexture using WebGLRenderTarget . bufferTexture as the texture of mainScene.

When I enter VR mode and turn the head to observe the entire scene, mainScene is fine, but the cube in bufferScene is rendered by split screen, and it will follow my head movement. Generally speaking, in the vr scene, the object should not follow the head movement. What caused this situation?

I have put the code in codeopen.

var mainScene = new THREE.Scene();
mainScene.position.set(0,0,0);
var width = window.innerWidth;
var height = window.innerHeight;
var camera = new THREE.PerspectiveCamera( 70, window.innerWidth / window.innerHeight, 1, 1000 );
camera.position.z = 10;

var renderer = new THREE.WebGLRenderer();
renderer.setSize( window.innerWidth, window.innerHeight );
renderer.vr.enabled = true;
document.body.appendChild( renderer.domElement );
document.body.appendChild( WEBVR.createButton( renderer ) );

//This is where we create our off-screen render target
//Create a different scene to hold our buffer objects
var bufferScene = new THREE.Scene();
//Create the texture that will store our result
var bufferTexture = new THREE.WebGLRenderTarget( window.innerWidth, window.innerHeight,
{ minFilter: THREE.LinearFilter,
magFilter: THREE.NearestFilter});

//Let's create a red box
var redMaterial = new THREE.MeshBasicMaterial({color:0xF06565});
var boxGeometry = new THREE.BoxGeometry( 5, 5, 5 );
var boxObject = new THREE.Mesh( boxGeometry, redMaterial );
boxObject.position.z = -10;
bufferScene.add(boxObject);//We add it to the bufferScene instead of the normal scene!

////////////////////////////Now we use our bufferTexture as a material to render it onto our main scene
var boxMaterial = new THREE.MeshBasicMaterial({map:bufferTexture.texture});
var boxGeometry2 = new THREE.BoxGeometry( 5, 5, 5 );
var mainBoxObject = new THREE.Mesh(boxGeometry2,boxMaterial);
mainBoxObject.position.set(0,0,-10);
mainScene.add(mainBoxObject);

///And a blue plane behind it
var blueMaterial = new THREE.MeshBasicMaterial({color:0x7074FF})
var plane = new THREE.PlaneBufferGeometry( window.innerWidth, window.innerHeight );
var planeObject = new THREE.Mesh(plane,blueMaterial);
planeObject.position.z = -15;
mainScene.add(planeObject);

//Render everything!
function render() {
renderer.setAnimationLoop( render );
renderer.render(bufferScene,camera,bufferTexture,true);
renderer.render( mainScene, camera );

}
render();

Three.js version

Dev

r100

...

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:
Description of the problem

Similar to the addition of renderer.setFramebuffer which fixes this issue specifically for shadow maps, the issue also applies to any WebGLRenderTarget usage.

I have some ideas how to fix this, no stripped down test case yet.

Three.js version

Dev

r99

...
Issue 1:
The docs don't have an entry for A_ldiv_B!, but it has (in version 0.4.0-rc3) 37 methods. Adding a short entry to the docs specifying the order of the arguments would be very helpful.

Issue 2:
Documentation for A_ldiv_B! and company is missing.

Is it correct that it does in-place replacement of A by A / B ? If so, I'll add docs for these functions.
Issue 1:
Elasticsearch version: 2.3.2

JVM version: openjdk-7-jre-headless:amd64 7u101-2.6.6-1~deb8u1

OS version: Debian 8 64bit

Description of the problem including expected versus actual behaviour:

The number of file descriptors set by the Debian systemd service file mismatches Elasticsearches' startup check triggering a WARNing.

Steps to reproduce:

Install elasticsearch package on Debian 8

Start elasticsearch

Watch the elasticsearch logfile

Provide logs (if relevant):

[2016-04-28 13:03:53,452][WARN ][env ] [node-1] max file descriptors [65535] for elasticsearch process likely too low, consider increasing to at least [65536]

Issue 2:
Using a dateHistogram query with pre_zone adjustment together with pre_zone_adjust_large_interval = true and min_doc_count = 0 leads to an infinite loop and consequently OutOfMemory error.

We have observed this in v1.0.2 and verified that the same issue is still in v1.3.1.

To verify this, we used the DateHistogramTests test case singleValue_WithPreZone_WithAadjustLargeInterval and added the line .minDocCount(0L) to the dateHistogram builder.

The issue seems to be in InternalHistogram.reduce(ReduceContext) in the if (minDocCount == 0) { branch. For the previous test case, the line while (key != nextBucket.key) { loops endlessly because the zone adjustments seem not to be taken into account.

We have seen similar things with post_zone (unfortunately, I could not reproduce it with a test case).