WhereIsAI/github-issue-similarity huggingface dataset:
Issue 1:
Problem Description

Dropdown component causing dom change error in hot reload. When the basic Dropdown is rendered we get the following hot reloading error:

Uncaught Invariant Violation: findComponentRoot(..., .0.1.1.1.2.1.$1/=11.0.2.1.0.$2016-03-07T13=208=201-05=2001.1:$37.3.0.1.0): Unable to find element. This probably means the DOM was unexpectedly mutated (e.g., by the browser), usually due to forgetting a <tbody> when using tables, nesting tags like <form>, <p>, or <a>, or using non-SVG elements in an <svg> parent. Try inspecting the child nodes of the element with React ID ``.

This is usually a result of bad formed HTML. We checked all components and only the Dropdown is causing this problem.

Versions

Material-UI: 15 alpha 1

React: 14.7

Browser: Chrome / Firefox

Webpack: 1.12.12

Webpack dev server 1.14.1

react-hot-loader: 1.3.0

Issue 2:
I have a universal app with HMR in development. I noticed something very strange when using an <IconMenu />.

My code:

<IconMenu
iconButtonElement={ <IconButton><MoreVertIcon color="#fff" /></IconButton> }
targetOrigin={ { horizontal: 'right', vertical: 'top' } }
anchorOrigin={ { horizontal: 'right', vertical: 'top' } }
>
<MenuItem
primaryText="Logout"
onClick={ () => actions.logout() }
/>
</IconMenu>

The rendered HTML:

If you look at the highlighted part, there is an extra, unclosed <noscript> in there. I believe this is what's causing issues.

Edit:

Looks like it's coming from the react-event-listener library: https://github.com/callemall/material-ui/blob/master/src/popover/popover.jsx#L384

@oliviertassinari

Versions

Material UI Version: 0.15.0-alpha.1

React: 0.14.7

Browser: Chrome
Issue 1:
I wonder if that can be achieved. I tried to to use cpu profiler using "net/http/pprof", but without binary it didn't manage to get anything useful for top or list commands. Unpacked apk and used .so as binary but it also didn't help.

Host OS - Windows 8.1.

Mobile OS - Android 4.4.

Can be anything done about it? Or I am doing something severely wrong?

Issue 2:
I haven't tested this, but I suspect it is true: if you build a Go library using -buildmode=c-archive or c-shared, and call the Go library from a C program, and the Go library tries to use runtime/pprof.StartCPUProfile, I expect it won't work. The problem is that Go will not have installed the SIGPROF signal handler.
Issue 1:
I am using @types/core-js 0.9.34. I am getting the following error. This is the statement i had it in the tsconfig.json file

{

"compilerOptions": {

"target": "es5",

"module": "commonjs",

"lib": ["es5","dom"],

"moduleResolution": "node",

"declaration": false,

"noImplicitAny": false,

"removeComments": true,

"emitDecoratorMetadata": true,

"experimentalDecorators": true,

"sourceMap": true,

"typeRoots": [ "node_modules/@types" ]

},

"exclude": [

"node_modules",

"typings/browser.d.ts",

"typings/browser/"

],

"compileOnSave": false,

"filesGlob": [

"public/*.ts",

"public//*.ts"

]

}

when I compile it i am getting the following error: node_modules/@types/core-js/index.d.ts(21,14): error TS2300: Duplicate identifier 'PropertyKey'. The typescript version I have used is :"typescript": "2.0.10"

Please give me an idea how to rectify the issue

Issue 2:
Is something wrong with CI or publishing infrastructure?

Check the Infrastructure status updates thread for known issues.

Leave a message on the DefinitelyTyped Gitter.

If you know how to fix the issue, make a pull request instead.

I tried using the @types/react-redux package and had problems.

I tried using the latest stable version of tsc. https://www.npmjs.com/package/typescript

I have a question that is inappropriate for StackOverflow. (Please ask any appropriate questions there).

Mention the authors (see Definitions by: in index.d.ts) so they can respond.

Authors: @tkqubo @kenzierocks @clayne11 @tansongyang @NicholasBoll @mDibyo @Kallikrein @val1984 @jrakotoharisoa @apapirovski @surgeboris @soerenbf @MrWolfZ @DylanVann @Lazyuki @kazuma1989

Hi guys,

I am using redux 3.x.x and react-redux 7.2.0 (they supposed to be compatible )

I am facing problems with @types/react-redux 7.x because they use types from redux 4.x and they are not compatible with types from the previous versions.

Could the version with dependency on the previous redux be added? Or what should be the version for such typings if i submit them via PR?
Issue 1:
CentOS 6.7

Cuda 7.0

cuDNN 4.0.7

I resolve #2266 by hard coding the python2.7 path in third_party/gpus/crosstool/clang/bin/crosstool_wrapper_driver_is_not_gcc.

After also resolving a similar problem with swig, it compiles without errors:

Target //tensorflow/tools/pip_package:build_pip_package up-to-date:
bazel-bin/tensorflow/tools/pip_package/build_pip_package
INFO: Elapsed time: 228.884s, Critical Path: 199.55s

But it seems that build_pip_package was only partially (?) completed:

rdipiet2@jhu.edu@login-node03 tensorflow $ bazel-bin/tensorflow/tools/pip_package/build_pip_package testonly
Tue May 17 11:09:33 EDT 2016 : === Using tmpdir: /tmp/tmp.akIEI1WBAX
cp: cannot stat `bazel-bin/tensorflow/tools/pip_package/build_pip_package.runfiles/tensorflow': No such file or directory
cp: cannot stat `bazel-bin/tensorflow/tools/pip_package/build_pip_package.runfiles/external': No such file or directory

Any ideas? Could something be failing silently?

Issue 2:
bazel-bin/tensorflow/tools/pip_package/build_pip_package /tmp/tensorflow_pkg
2016年 04月 21日 星期四 07:34:12 CST : === Using tmpdir: /tmp/tmp.cMsLMGw3bz
cp: cannot stat ‘bazel-bin/tensorflow/tools/pip_package/build_pip_package.runfiles/tensorflow’: No such file or directory
cp: cannot stat ‘bazel-bin/tensorflow/tools/pip_package/build_pip_package.runfiles/external’: No such file or directory
Issue 1:
Juergen Hoeller opened SPR-6543 and commented

Support for JSF 2.0's view scope, as exposed through UIViewRoot.getViewMap().

Possibly also for "facesRequest" scope: FacesContext.getAttributes().

Also research options for making good use of the JSF 2.0 flash scope.

Issue Links:

#12758 Specific support for JSF 2.2 / 2.3

#11082 Provide conversation management support

51 votes, 44 watchers

Issue 2:
Charles Blaxland opened SPR-2772 and commented

When many threads attempt to create non-singleton beans simultaneously Spring's performance is extremely poor. Spring 2.0 also seems to be worse than Spring 1.2.8 in this regard. I suspect its due to all the synchronized blocks in the BeanFactory.

I have a heavily threaded server application, which at a certain point creates a bunch of nested non-singleton beans via a Spring lookup-method. While running load tests I noticed this step was a bottleneck in our application. I wrote a small test application which created a number of threads which all tried to create a number of non-singleton beans. The results are below:

Spring 2.0
==========
singleton="false"
-----------------
08188ms 1 Thread, 10000 bean creations per thread (10000 total)
15656ms 10 Threads, 1000 bean creations per thread (10000 total)
24703ms 100 Threads, 100 bean creations per thread (10000 total)
27235ms 1000 Threads, 10 bean creations per thread (10000 total)

singleton="true"
----------------
01110ms 1 Thread, 10000 bean creations per thread (10000 total)
01266ms 10 Threads, 1000 bean creations per thread (10000 total)
01281ms 100 Threads, 100 bean creations per thread (10000 total)
01515ms 1000 Threads, 10 bean creations per thread (10000 total)

Spring 1.2.8
============
singleton="false"
-----------------
04797ms 1 Thread, 10000 bean creations per thread (10000 total)
05719ms 10 Threads, 1000 bean creations per thread (10000 total)
13000ms 100 Threads, 100 bean creations per thread (10000 total)
17922ms 1000 Threads, 10 bean creations per thread (10000 total)

You can see that for the same number of bean creations, the time taken increases rapidly as you increase the number of threads. Obviously there is some overhead in managing the many threads, but not enough to account for what is seen here. Its apparent that Spring 2.0 is also 60-70% slower than 1.2.8 for this task, even with a single thread.

Affects: 1.2.8, 2.0 final

Attachments:

screenshot profiling session.jpg (293.05 kB)

Spring2TestBean.java (672 bytes)

springtest.zip (1.98 kB)

Issue Links:

#7573 Poor performance creating prototype beans ("is duplicated by")

#7667 Spring performance is insufficient for intensive work at short scopes

6 votes, 2 watchers
Issue 1:
There is a sample on the bootstrap website

Navigate to http://getbootstrap.com/javascript/#modals

click "Launch demo modal"

scroll down, click "Close"

again, click "Launch demo modal"

again, scroll down, click "Close"

second time, modal will not close. ESC works.

Issue 2:
Hi,

The code used on last Thursday worked fine. But after updated to latest code on Monday (GMT+8), the modal dialog when clicks to dismiss for seconds onward cannot be close.

I am checking on source code line 932, if I commented out this line then it is working again.

this.$element

.removeClass('in')

.attr('aria-hidden', true)

//.off('click.dismiss.modal')

Am I missing anything...?

Sorry for the grammar. Thanks.
Issue 1:
Which website or app were you using when the bug happened?

Please provide a link to the URL of the website (if it is public), a CodeSandbox (https://codesandbox.io/s/new) example that reproduces the bug, or a project on GitHub that we can checkout and run locally.

What were you doing on the website or app when the bug happened?

If possible, please describe how to reproduce this bug on the website or app mentioned above:

Generated information

DevTools version: 4.13.1-93782cfed2

Call stack:

at chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:21499:43

at bridge_Bridge.emit (chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:19607:22)

at chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:19767:12

at listener (chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:37788:39)

Component stack:

(none)

GitHub URL search query:

https://api.github.com/search/issues?q=Cannot%20remove%20node%20%20because%20no%20matching%20node%20was%20found%20in%20the%20Store.%20in%3Atitle%20is%3Aissue%20is%3Aopen%20is%3Apublic%20label%3A%22Component%3A%20Developer%20Tools%22%20repo%3Afacebook%2Freact

Issue 2:
Edit: If you have issues but you did NOT upgrade to 18, or if you upgraded but get confusing errors from dependencies, the problem is likely that some library (incorrectly) specifies @types/react as a dependency with version * rather than an optional peer dependency. Find which library it is and file an issue for it. See #24304 (comment) for diagnostics and common workarounds.

A few hours ago, a major version of React types for Typescript was released.

I have tried to test this right away to see if there are any changes that require adaptation in my own projects.

Due to a very large number of users using React's type library (we use fundamental types like React.FC by the hundreds in our own projects), it's reasonable to question whether there's been a small mistake here.

Specifically, the following type declaration still exists in the 18 release.

type PropsWithChildren<P> = P & { children?: ReactNode | undefined };

However, this is no longer used in the library, at least not when looking at the diff

DefinitelyTyped/DefinitelyTyped@55dc209

A quick search on Github yields millions of hits that use the type alias React.FC to the actual type React.FunctionalComponent.

Before

interface FunctionComponent<P = {}> {
(props: PropsWithChildren<P>, context?: any): ReactElement<any, any> | null;
...
}

Now

interface FunctionComponent<P = {}> {
(props: P, context?: any): ReactElement<any, any> | null;
}

I think matching very, very many places in a single project doesn't seem to do justice to the change made; always the property children?: ReactNode to be redefined is definitely too much effort.

Positions at which PropsWithChildren were used before

FunctionComponent, as shown in the example

ForwardRefRenderFunction,

und das Funktions-Interface propsAreEqual von memo

Thx!
Issue 1:
Hi,

In version 0.10.10 intellisense is not working after downloading typescript for the modules which I have downloaded using npm like express, firebase etc. But version 0.10.08 is working fine and I am able to see intellisense working flawlessly.

Issue 2:
I updated to 0.10.10 today, hoping to try out the new JavaScript support with Salsa. Unfortunately, my Intellisense has stopped working. I am using type definition files from definitely typed (e.g. the express.d.ts).

For example, using 0.10.8:

var exp = require("express");

exp.Router

I will see the content assist for the "Router" function and I can visit the definition file by right clicking on "Router" > Go to Definition

Now when I do the same thing in 0.10.10, I don't see "Router" in the Intellisense list. In addition, the list seems to have variables I had defined earlier in my code (which doesn't apply to express at all).
Issue 1:
By calling

graph.get_tensor_by_name("output:0")

I found that it returns a tensor shaped [batch_size,num]，How to test a saved model trained with tf.train.batch ?

Issue 2:
For an input with an undefined batch size, atrous_conv2d emits tensors where all except the final dimension are undefined:

input = tf.placeholder(tf.float32, (None, 256, 256, 3))

conv = tf.nn.conv2d(input, tf.zeros((3, 3, 3, 16)), strides=[1, 1, 1, 1], padding='SAME')
print(conv.get_shape()) # Correctly displays (?, 256, 256, 16)

dilated = tf.nn.atrous_conv2d(input, tf.zeros((3, 3, 3, 16)), rate=2, padding='SAME')
print(dilated.get_shape()) # Displays (?, ?, ?, 16)

(For concrete batch sizes, everything works as expected.)

Tested on 0.10.0rc0
Issue 1:
Apache Airflow version: None given

Ticket was created 21/Nov/16 18:35

Kubernetes version (if you are using kubernetes) (use kubectl version):

Environment:

Cloud provider or hardware configuration:

OS (e.g. from /etc/os-release):

Kernel (e.g. uname -a):

Install tools:

Others:

What happened:

We are planning to run around 40,000 tasks a day using airflow and some of them are critical to give quick feedback to developers.

Currently having execution date to uniquely identify tasks does not work for us since we mainly trigger dags (instead of running them on schedule) we collide with 1 sec granularity on several occasions. Having a task uuid or associating dag_run to task_instance table and using this for scheduling and updating status will help us here.

What you expected to happen:

How to reproduce it:

Anything else we need to know:

Moved here from https://issues.apache.org/jira/browse/AIRFLOW-642

Issue 2:
Apache Airflow version: 1.10.*

Backport packages version: 2020.10.5rc1

What happened:

Although good work has been done to improve the BigQueryInsertJobOperator by the assigning of a job_id based on a combination of dag_id, task_id, execution_date and an additional uniqueness_suffix, other operators that create BigQuery jobs - e.g. GCSToBigQueryOperator - do not take advantage of this but instead still create a job_id based on a timestamp.

https://github.com/apache/airflow/blob/master/airflow/providers/google/cloud/hooks/bigquery.py#L1475

If more than one task based on this operator are launched at the same time, this will cause an error due to a duplication in the job_id.

Already Exists: Job my-project:EU.airflow_1601894411

What you expected to happen:

Any task that starts a BigQuery should create a job_id that is unique.

Perhaps the method of job_id creation needs to move into the BigQuery hook, if possible?

https://github.com/apache/airflow/blob/master/airflow/providers/google/cloud/operators/bigquery.py#L2060
Issue 1:
Here's a sample code to illustrate the problem which stems from a case sensitive string matching somewhere in the code:

package main

import (
"fmt"
"path/filepath"
)

func main() {
a,_ := filepath.Glob("c:\\users\\*\\appdata")
fmt.Println(a) //this prints []
b,_ := filepath.Glob("c:\\users\\*\\AppData")
fmt.Println(b) //this prints [c:\users\Default\Appdata ...]
}

Because file and directory names in Windows are case insensitive therefore this is a bug.

Please note that before the asterisk(*) the path name does not have to match case but after the asterisk it doesn't provide any results if the case doesn't match.

Issue 2:
Here are two functions that won't compile:

func f(x int) bool {
if x > 5 {
return true
} else {
return false
}
}

func g(x int) bool {
switch {
case x > 5: return true
default: return false
}
}

Isn't it possible to make these compile? Perhaps I'm being naive, but if the last
statement in a function that requires a return is an if or a switch and the if has an
else with a return or the switch has a default with a return isn't that sufficient to
know that the function will work? Or are you having to allow for gotos or something else
subverting the flow of control?
Issue 1:
I have this simple code:

import * as React from "react";
import * as ReactDOM from "react-dom";

ReactDOM.render(<div>Hi</div>, document.getElementById("root"));

that is giving me this error:

Argument of type 'Element' is not assignable to parameter of type 'ReactElement<any>[]'.
Property 'length' is missing in type 'Element'.

I've currently tried these versions of react and react-dom:

"react": "16.4.2",
"react-dom": "16.4.2",
"@types/react": "16.4.7",
"@types/react-dom": "16.0.6",

and

"react": "16.4.0",
"react-dom": "16.4.0",
"@types/react": "16.3.17",
"@types/react-dom": "16.0.6",

I'd like to have react 16, but I'm not sure what the typing issue is here.

Issue 2:
Below are examples of mistakes I make all the time. For that reason, I would really like for these to be type errors, so I can catch these mistakes earlier.

IIUC, the reason these are not type errors is because the children/ReactNode type includes {}, which allows almost anything through. That begs the question, can we remove {}, or is there a valid reason to keep it?

Passing a function as a React child (forgot to call the function)

import * as React from 'react';
import { FC } from 'react';

const renderChildren = () => 'foo'

declare const MyComponent: FC<{}>;
// Oops! We forgot to call this function. But we got no type error :-(
<MyComponent>{renderChildren}</MyComponent>;

// Should be:
// <MyComponent>{renderChildren()}</MyComponent>;

Passing an Option as a React child (forgot to serialize/decode)

import * as React from 'react';
import { FC } from 'react';

type Option<T> = { value: T, orNull: () => T | null }
declare const myOption: Option<string>

declare const MyComponent: FC<{}>;
// Oops! We forgot to serialize/decode this `Option`. But we got no type error :-(
<MyComponent>{myOption}</MyComponent>;

// Should be:
// <MyComponent>{myOption.orNull()}</MyComponent>;

One workaround I know of is to explicitly define the children prop:

import * as React from 'react';
import { FC } from 'react';

const renderChildren = () => 'foo'

declare const MyComponent: FC<{ children: string }>;
// Oops! We forgot to call this function. We got a type error :-)
<MyComponent>{renderChildren}</MyComponent>;

// Should be:
<MyComponent>{renderChildren()}</MyComponent>;

However I hoped this wouldn't be necessary. That also doesn't help when passing children to a DOM component:

// Oops! We forgot to call this function. But we got no type error :-(
<div>{renderChildren}</div>;

If you know how to fix the issue, make a pull request instead.

I tried using the @types/xxxx package and had problems.

I tried using the latest stable version of tsc. https://www.npmjs.com/package/typescript

I have a question that is inappropriate for StackOverflow. (Please ask any appropriate questions there).

Mention the authors (see Definitions by: in index.d.ts) so they can respond.

Authors: @johnnyreilly @bbenezech @pzavolinsky @digiguru @ericanderson @tkrotoff @DovydasNavickas @onigoetz @theruther4d @guilhermehubner @ferdaber @jrakotoharisoa @pascaloliv @Hotell @franklixuefei @Jessidhia @saranshkataria @lukyth @eps1lon

If you do not mention the authors the issue will be ignored.
Issue 1:
reproduce - Goto

http://getbootstrap.com/javascript/#modals

try to open and close "Launch Demo Modal" Twice using button

Escape key works (ie keyboard) but data-dismiss="modal" fails

Worked in RC1

Regards,

Mike

Issue 2:
Hi,

The code used on last Thursday worked fine. But after updated to latest code on Monday (GMT+8), the modal dialog when clicks to dismiss for seconds onward cannot be close.

I am checking on source code line 932, if I commented out this line then it is working again.

this.$element

.removeClass('in')

.attr('aria-hidden', true)

//.off('click.dismiss.modal')

Am I missing anything...?

Sorry for the grammar. Thanks.
Issue 1:
The Autocomplete demo suggestion container takes up room even when not in use

I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior

Put two autocompletes above each other (or any other element below an autocomplete) and it will sit flush against the bottom

Current Behavior

There is around a 200px height gap between autocomplete and the control below

Steps to Reproduce (for bugs)

https://codesandbox.io/s/mj5q02oo58

Load codesandbox

See two autocompletes

Note that there is a large gap between the two

Context

I fixed it by changing the css. I removed the container key and changed suggestionsContainerOpen to the following.

suggestionsContainerOpen: {
flexGrow: 1,
position: 'relative',
minHeight: 200,
marginTop: theme.spacing.unit,
marginBottom: theme.spacing.unit * 3,
left: 0,
right: 0,
},

So this is not impacting me. However, your Component Demos are awesome and this caused me some confusion. For future visitors it might be nice to change this behavior.

Your Environment

Tech
Version

Material-UI
1.0 beta 22

Issue 2:
I was wondering, if it would be better if we move the selected prop from the MenuItem directly to the ListItem.

I was using the Drawer component and I wanted to show the user which ListItem was active in the Drawer. So I thought I make it selected, but than I realized the ListItem has no selected prop, but I remebered that the MenuItem has this prop. I looked into the code and saw that the MenuItem is basicly a ListItem.

If we do not think this is a good idea, we should at least tell the user in the docs, when he wants to make a ListItem selected he should use a MenuItem instead.

Your Environment

Tech
Version

Material-UI
v1.0.0-beta.16
Issue 1:
After updating Deno to latest version 1.2.0 I got 2 errors:

error: TS2345 [ERROR]: Argument of type 'string | URL' is not assignable to parameter of type 'string'.
Type 'URL' is not assignable to type 'string'.
return new URL(url).pathname
~~~
at https://deno.land/std@v0.53.0/path/win32.ts:911:18

TS2345 [ERROR]: Argument of type 'string | URL' is not assignable to parameter of type 'string'.
Type 'URL' is not assignable to type 'string'.
return new URL(url).pathname;
~~~
at https://deno.land/std@v0.53.0/path/posix.ts:433:18

Found 2 errors.

I have global deps.ts file with dependencies but are actual @0.61.0

Also I tried run with argument -L debug but no more information.

Any ideas what i can do to locate problem ?

Issue 2:
After upgrading to 1.2.0, running deno, will fail with:

Check file:///Users/xxxxxxx/yyyyyyy/code/src/github.com/nats-io/nats.deno/.deno.test.ts
error: TS2345 [ERROR]: Argument of type 'string | URL' is not assignable to parameter of type 'string'.
Type 'URL' is not assignable to type 'string'.
return new URL(url).pathname
~~~
at https://deno.land/std/path/win32.ts:917:18

TS2345 [ERROR]: Argument of type 'string | URL' is not assignable to parameter of type 'string'.
Type 'URL' is not assignable to type 'string'.
return new URL(url).pathname;
~~~
at https://deno.land/std/path/posix.ts:438:18

Found 2 errors.

There's a single reference to URL on a constructor in my project:

let url = new URL(u);
if (!url.port) {
url.port = `${DEFAULT_PORT}`;
...

This is on OS X.