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

Define a table with enough rows to make the scroll appear

Set the props of the table: height={"100%"} fixedHeader={true}

Now headers are fixed no more

In this scenario omitting height={"100%"} makes no change

Versions

Material-UI: 0.15.0-beta.2

React: 15.0.1

Browser: Chrome 50.0.2661.75 (64-bit)

Issue 2:
material-ui/lib/table/table-body.js:42

propTypes: {

^^^^^^^^^

SyntaxError: Duplicate data property in object literal not allowed in strict mode

#1917 this merge request was merged right after 0.12.4 was released. Can we get a 0.12.5? Otherwise can't use 0.12.4.
Issue 1:
Electron version: v1.4.10

Operating system: Windows 10

While trying to find a workaround for #7977 using the close event of a BrowserWindow, I found out that it doesn't fire in the renderer process as it would in the main process.

How to reproduce

Just add the following lines at the start inside <body> of the default app index.html:

require('electron').remote.getCurrentWindow().on('close', evt => evt.preventDefault())

But you can still close the window.

Issue 2:
This only applies to remote.BrowserWindow (i.e. the one used in renderer processess). It works fine for the other BrowserWindow.

Not sure if this is a documentation issue or an implementation issue, but the docs don't specify a difference.

Ubuntu 15.10 / Electron 0.36.7
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

MenuItem's label cannot be changed once it's appended to a Menu, despite other properties taking effect as usual.

let electron = require("electron");
let menu = new electron.remote.Menu();
let item = new electron.remote.MenuItem({label:"one!"});
item.label = "two!";
menu.append(item);
item.label = "three!";
item.enabled = false; // (to verify that other properties can be changed)
menu.popup();

shows "two!" rather than "three!"; menu item appears disabled - only label change takes no effect.

Electron Version:

7.0.0-beta.4, same effect on 6.0.9 and 4.2.8

Operating System:

Windows 10 (18362)

Last Known Working Electron version:

(doesn't seem like there's one)

Expected Behavior

A menu showing "three!"

Actual Behavior

A menu showing "two!"

To Reproduce

fiddle gist

Screenshots

Additional Information

Is this a limitation like #527? Could add a note to documentation if so.

Issue 2:
Electron Version: 1.8.7

Operating System (Platform and Version): MacOS

Last known working Electron version: 1.8.6

Expected Behavior

Electron.framework doesn't include the use of private APIs and can be approved on the Apple App Store

Actual behavior

Electron.framework includes the use of private APIs and cannot be approved on the Apple App Store

Additional Information

Guideline 2.5.1 - Performance - Software Requirements

Your app uses or references the following non-public APIs:

-Symbol: _CGDisplayUsesForceToGray
From framework: /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics

-Symbol: __CFIsObjC
From framework: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
In binary: Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework

The use of non-public APIs is not permitted on the App Store, because it can lead to a poor user experience should these APIs change.
Issue 1:
Hey guys!

I've noticed a possible inconsistency today. The setup is simple: import two routes with the same name but different patterns from different resource files (so that they don't YAML-override). For example:

# some routing.yml that's imported
foo_page:
pattern: /foo
defaults: { _controller: MainBundle:Default:homepage }

# some other routing.yml that's imported
foo_page:
pattern: /second-foo-page
defaults: { _controller: MainBundle:Default:homepage }

when the matcher is dumped, both routes appear, but the first pattern appears first

when the generator is dumped, only the second route appears, and is used for all generation

I believe the proper behavior should be that only the second route is used in the matcher, to be consistent with the dumper.

Thanks!

Issue 2:
Q
A

Bug report?
yes

Feature request?
no

BC Break report?
no

RFC?
no

Symfony version
3.3.4

When attempting to run ./bin/console server:run after having generated a bundle using ./bin/console generate:bundle --namespace=Acme/MyBundle --bundle-name=AcmeMyBundle --format=annotation I get a ClassNotFoundException.

If I update the autoload psr-4 section of composer.json to include my bundle it all works fine. I didn't have to do this in 3.3.2.
Issue 1:
I use dendrogram with the following ndarray

>>> Z.shape
(36951, 4)
>>> dendrogram(Z)

It returns the following error:

Traceback (most recent call last):
File "<console>", line 1, in <module>
File "/home/pyk/.virtualenvs/project-lisa/local/lib/python2.7/site-packages/scipy/cluster/hierarchy.py", line 2294, in dendrogram
above_threshold_color=above_threshold_color)
File "/home/pyk/.virtualenvs/project-lisa/local/lib/python2.7/site-packages/scipy/cluster/hierarchy.py", line 2582, in _dendrogram_calculate_info
....
leaf_label_func, i, labels)
File "/home/pyk/.virtualenvs/project-lisa/local/lib/python2.7/site-packages/scipy/cluster/hierarchy.py", line 2332, in _append_singleton_leaf_node
ivl.append(str(int(i)))
RuntimeError: maximum recursion depth exceeded while getting the str of an object

Scipy version

% pip freeze
scipy==0.17.0

Issue 2:
I'm trying to do a dendrogram:

ValueError: Linkage 'Z' uses the same cluster more than once.

Am I doing something wrong here?
Issue 1:
I believe that it's a better choice to have the std library on crates.io, instead of in /usr/local. It makes it easier to have alternative standard libraries, and the compilers shouldn't really link with it automatically anyway. It also makes it easier to build for new targets, making cross compilation multiple grades of magnitude easier.

The standard library requires on a rust version, but implementing a rustc version requirement shouldn't be too hard.

The only argument I've so far heard against this, is that it'd require people to update their Cargo.lock if they are using cargo, or manually update the std if they are not. While this is true, most people will be using cargo or a dependency manager, and updating the lock file shouldn't be an issue.

Today I heard rust prefers explicit over implicit. Not implicitly linking against all the standard libraries would follow this.

Issue 2:
This is somewhat related to issue #19240.

By putting the standard libraries all in one seperate repository, or even each one in their own, it'd make porting rust conciderably easier. It would remove the need to work inside the rustc file tree, and it would make the build process way easier.
Issue 1:
I have searched the issues of this repository and believe that this is not a duplicate.

In short

Using with-apollo with url or query params in pages leads to strange behaviour.

What works:

I extended the index.js in the with-apollo-example, just to print the current query:

export default withData(props => (
<Main>
{(props.url) && console.log(props.url.query)} // THIS WILL BECOME IMPORTANT!
<Header />
<Submit />
<PostList />
</Main>
))

The apollo data (the posts) are fetched correctly on the server and on the client i get them baked into __NEXT_DATA__ as apollo store`.

__NEXT_DATA__ = {"props":{"serverState":{"apollo":{"data":{"Post:cjcq65k4ua4h801287p9h0rw9":{"id":"cjcq65k4ua4h801287p9h0rw9","titl

What does not work:

export default withData(props => (
<Main>
{console.log(props.url.query)} // JUST A MINOR CHANGE..?
<Header />
<Submit />
<PostList />
</Main>
))

Now on the client the apollo store is empty and data gets fetched on the client:

__NEXT_DATA__ = {"props":{"serverState":{"apollo":{"data":{}}}},

Steps to Reproduce (for bugs)

Get an Apollo next repo like https://github.com/ads1018/next-apollo-example

console.log() the query like above

See loading state on client

What am i trying to accomplish?

I want to export a static app with routes like:

/posts/My-first-post
/posts/My-other-post

where posts are known at compile time. For that i fetch all post ids at export-time/compile-time in next.config.js and map them to pages with variables, in the exportPathMap-function, like this:

// ...
routes[`/posts/${slug(post.title)}`] = {page: '/posts', query: {post_id: post.id}}
// ...
return routes

I use graphql wrappers and use the query parameter to fetch the actual data, and the next-apollo package to get the data in getInitialProps:

graphql(
PostDataQuery,
{
options: ({url}) => {
return {variables: {id: url.query.post_id}}
}
)(MyPostComponent)

But as described above, the data i loaded on the client and not on the server if i use query parameters, and the apollo store is not created or not sent to the client.

For example this works:

// ...
return {variables: {id: 'some-hard-coded-id'}}
// ...

Your Environment

Tech
Version

next
v4.2.3

node
v9.2.0

OS
MacOS

browser
Chrome

etc

Issue 2:
First off, thanks for the with-react-intl example! It was very helpful for me in setting up localization in my app.

Currently, the example uses a custom script to generate a JSON of the default messages at lang/en.json. The README explains that you can send this file to your translator for translation.

The react-intl-translations-manager library already does something very similar: it generates JSON files of the default messages for the languages that you specify. It's a bit nicer, though, because it's easily configurable, outputs useful command line messages, and most importantly will insert missing messages into the lang/locale.json files.

Maybe it would be better to replace the default-lang script with react-intl-translations-manager? If so, I'll submit a pull request with this change.
Issue 1:
Hi,

is there any plan to implement the inverse short-time fourier transform (ISTFT)? I saw that STFT is already implemented, but I cannot find the inverse transform. This would be a very important feature for people working on audio and speech.

Thank you!

Mirco

Issue 2:
They would be super useful as fundamental ops (and autograd ops).

STFT can be implemented in terms of ConvTranspose, see github.com/pseeth/pytorch-stft

stft

istft

window functions: bartlett, hann, hamming, blackman

fft, ifft, irfft, rfft

fftshift, ifftshift

cc @mruberry
Issue 1:
System info

Playwright Version: @playwright/teset@1.34.3

Operating System: OpenSUSE Leap 15.4

Browser: Electron

Other info:

playwright/packages/playwright-core/src/server/trace/recorder/tracing.ts

Line 176
in
6db6498

this._changeTraceName(this._state, options.name);

That line needs an await.

Source code

I provided exact source code that allows reproducing the issue locally.

Link to the GitHub repository with the repro

Unfortunately, I am having difficulty producing a minimal test case.

I am seeing errors along the lines of:

tracing.stop: ENOENT: no such file or directory, open '/tmp/playwright-artifacts-GZT396/0ff296554d68f4361c8d9ce7c529610f-pwnetcopy-1.network'

This happens when there's a test failure, and on per-describe afterAll I'm calling (effectively) _electron.launch().context().tracing.stop(). This also produces truncated trace zip files (which are unusable). Manually hacking the installed playwright-core to add an await at the indicated position fixes the issue.

While my repository is at https://github.com/mook-as/rd/ I doubt that will be useful in reproducing the bug.

Steps

Run the test (npm run test:e2e e2e/preferences.spec.ts in my repo).

When it fails, try to use the produced trace file (e2e/reports/*.zip in my case) at https://trace.playwright.dev/

Expected

The trace zip file works correctly.

Actual

The trace zip file is truncated, because an exception was thrown in the middle of writing it.

Additional Information

I'm not certain I can deal with the CLA, so I'm not producing a PR directly. Sorry about that.

Issue 2:
System info

Playwright Version: [v1.32.3]

Operating System: [Windows]

Browser: [All]

Other info: I don't have this issue on Mac OS this is Windows only!

in .gitignore tests dir is ignored but with exclusions: https://github.com/tagspaces/tagspaces/blob/execute-playwright-without-jest/.gitignore#L94

Source code

I provided exact source code that allows reproducing the issue locally.

Steps

clone tagspaces repo: git clone https://github.com/tagspaces/tagspaces

npm install && npm run build-e2e

You can repeat this issue removing 'cross-env' from this command line:

https://github.com/tagspaces/tagspaces/blob/execute-playwright-without-jest/package.json#L122

and run npm run test-playwright

Expected

Playwright to find tests in testing dir defined in config:

https://github.com/tagspaces/tagspaces/blob/execute-playwright-without-jest/playwright.config.js#L13

Actual

[Describe actual behavior]

https://github.com/tagspaces/tagspaces/actions/runs/4809491601/jobs/8560812420

No tests found error in github actions
Issue 1:
It's useful for editors & data files to be able to enumerate constants. So instead of having "wrapS" : 1000 you can write "wrapS" : "RepeatWrapping", or if you want to construct a drop down for all the different texture filter modes etc. What seems to be the best approach at the moment is to copy & paste TEXTURE_FILTER, I think it would be better if they were just exported as is instead. Not only is it a whole lot cleaner than copy & paste, but it also guarantees that they're in sync if new ones ever gets added or if it's changed.

Issue 2:
Next to #12574 part 2

The proposal is to use "enum like" object instead of wild constantes, this will prevent user against change them by error. And gain in readability about what values are usable in the same 'enum'

Example:

// RENDERER
var CullFace = Object.freeze( {
None: 0,
Back: 1,
...
} );

// MATERIALS
var MaterialSide = Object.freeze( {
Front: 0,
Back: 1,
...
} );

// TEXTURES
var TextureMapping = Object.freeze( {
UV: 0,
CubeReflection: 1,
...
} );

...

instead of

export var RepeatWrapping = 1000;
export var ClampToEdgeWrapping = 1001;
export var MirroredRepeatWrapping = 1002; <= dude ! I need a new wrapping type
export var NearestFilter = 1003;
export var NearestMipMapNearestFilter = 1004;
export var NearestMipMapLinearFilter = 1005;
export var LinearFilter = 1006;
export var LinearMipMapNearestFilter = 1007;
export var LinearMipMapLinearFilter = 1008; <= Or damned, i need a new filter type, i will need to increase all type bellow...
export var UnsignedByteType = 1009;
export var ByteType = 1010;
export var ShortType = 1011;
export var UnsignedShortType = 1012;

and the call become:

material.blending = THREE.Blending.Normal

instead of

material.blending = THREE.NormalBlending
Issue 1:
Currently, "historical node" accepts such configuration:

druid.segmentCache.locations=[{"path": "/disk2/druidUser/indexCache", "maxSize"\: 10000000000}]
druid.server.maxSize=30000000000

When space need exceeds 10GB, we cannot see error in "coordinator Web UI".

And the usage of space is 33% in coordinator Web UI, which is misleading.

I found the space problem only when I looked into "historical" node's log, and use debugger to trace the code nearby.

I suggest: refuse to start historical node when sum of "indexCache" in all locations < durid.server.maxSize.

Issue 2:
The rules for determining available space on a historical node for a segment seem to include both druid.server.maxSize and druid.segmentCache.locations:maxSize.

However, the Coordinator Console shows the Max Size and Percent Used based only on druid.server.maxSize.

It would be useful if the console showed both values to help diagnose "segment too large" errors thrown by the OmniSegmentLoader (when people accidentally set them to different values).

See https://groups.google.com/forum/#!searchin/druid-development/segment$20too$20large/druid-development/w8Q65ZRusi4/kN0JybUtUfAJ
Issue 1:
I suspect these are related to recent tokenizer changes:

https://github.com/huggingface/transformers/runs/1236753957?check_suite_focus=true

FAILED tests/test_tokenization_deberta.py::DebertaTokenizationTest::test_torch_encode_plus_sent_to_model
FAILED tests/test_modeling_deberta.py::DebertaModelIntegrationTest::test_inference_classification_head

Issue 2:
https://github.com/huggingface/transformers/runs/1204063498?check_suite_focus=true

FAILED tests/test_modeling_deberta.py::DebertaModelIntegrationTest::test_inference_classification_head
FAILED tests/test_tokenization_deberta.py::DebertaTokenizationTest::test_torch_encode_plus_sent_to_model

@LysandreJik I think ?
Issue 1:
If I use read_csv to load a datafile with the default index_col, but the first column does not have unique values, it succeeds at first, but when I try to select rows later, I get Exception: Index cannot contain duplicate values!. This raises a couple of points:

Should the default be to use an index column? My data often doesn't have one. Apparently R takes the first column as an index if it doesn't have a header, and otherwise does an integer index.

Non-unique values should be detected when we're creating the index, and either leave that column as a regular column (falling back to an integer index), or raise an exception at that point.

Issue 2:
Hello

I am not sure, maybe this is the expected behaviour, but it was a big surprise for me (and a source of some bugs).

As the title states, dropping rows (whether inplace or not) does not delete corresponding index entries (when the frame has a multiIndex). If one later uses index values directly it causes really unexpected behaviour.

An obvious work-around is to reset index and re-build it, but it is not really elegant code...

Simple example:

>>> import pandas as pd
>>> df = pd.DataFrame([['A', 'a', 1], ['B', 'b', 2], ['C', 'c', 3]], columns=['upper', 'lower', 'num'])
>>> df = df.set_index(['upper', 'lower'])
>>> df = df.drop('A')
>>> df.index
MultiIndex(levels=[['A', 'B', 'C'], ['a', 'b', 'c']],
labels=[[1, 2], [1, 2]],
names=['upper', 'lower'])
>>> df.index.levels[0]
Index(['A', 'B', 'C'], dtype='object', name='upper')

Even though the row was deleted correctly.

show_versions():

INSTALLED VERSIONS
------------------
commit: None
python: 3.4.3.final.0
python-bits: 64
OS: Linux
OS-release: 4.2.0-18-generic
machine: x86_64
processor: x86_64
byteorder: little
LC_ALL: None
LANG: en_US.UTF-8

pandas: 0.17.1
nose: 1.3.7
pip: None
setuptools: 18.4
Cython: 0.23.3
numpy: 1.10.1
scipy: 0.14.1
statsmodels: 0.6.1
IPython: 4.0.0
sphinx: 1.3.1
patsy: 0.4.1
dateutil: 2.4.2
pytz: 2015.7
blosc: None
bottleneck: None
tables: None
numexpr: 2.4.4
matplotlib: 1.5.0
openpyxl: None
xlrd: None
xlwt: None
xlsxwriter: 0.7.3
lxml: 3.4.4
bs4: 4.3.2
html5lib: 0.999
httplib2: 0.9
apiclient: None
sqlalchemy: None
pymysql: None
psycopg2: None
Jinja2: None
Issue 1:
Jason Day opened SPR-9801 and commented

It appears the migration of the build to use Gradle dropped the OSGi manifest headers from getting added.

Affects: 3.2 M1, 3.2 M2

Issue Links:

#13543 Users of the SpringSource EBR need Spring framework bundles to continue to be published there for Spring 3.2 ("duplicates")

3 votes, 4 watchers

Issue 2:
Rob Winch opened SPR-9858 and commented

This is related to SEC-2064 which states:

It strikes me that ThrowableAnalyzer is not only suitable for its current role in Spring Security and is more generally useful. I've found a need for something along the lines of ThrowableAnalyzer in Spring Social, but do not wish to force a dependency on Spring Security. As things stand currently, I must duplicate ThrowableAnalyzer to avoid the otherwise unnecessary dependency on Spring Security.

I wonder if ThrowableAnalyzer might be better suited for Spring Core's org.springframework.util package? I already depend on Spring Core, so I wouldn't have the same dependency concerns there and would be able to get rid of my duplicate ThrowableAnalyzer.

Let me know if this is something that is acceptable and I can put a pull request together.

Issue Links:

SEC-2064 Extract ThrowableAnalyzer, perhaps to Spring Core ("is depended on by")
Issue 1:
I need to use some external modules without .d.ts files, but, I do not want to use the corresponding third party .d.ts files. Please tell me how to just suppress the errors - "Cannot find the module ...", thinks.

Issue 2:
When compiling a script (main.ts) that imports another module (dependency.ts):

typescript 0.9.5 used to take as input the definition file (dependency.d.ts) when available.

since 1.0.x, it seems like typescript always compiles dependency.ts even when a definition file is available.

This significantly slows down compilation for most projects. Is there a workaround? A compilation argument to opt for the old behavior?
Issue 1:
Context and Rationale

At the moment, flutter create --template=plugin (ref) defaults to Objective C and Java. It is my suggestion that the we switch the default to Swift and Kotlin respectively instead.

Kotlin is first-class language supported by Android, and officially preferred by Android rather than Java (ref) even if Kotlin adds a little bit overhead (ref)

When it comes to Swift, the case is even stronger. While Kotlin is officially endorsed and preferred by Android team, it's still developed by another entity, JetBrain. Meanwhile, Swift is developed by Apple specifically for iOS, macOS and tvOS development. In the first quarter of 2018 Swift surpassed Objective-C in measured popularity (ref). The runtime overhead will no longer be an issue for Swift 5, according to wwdc 2018

And we also have another release coming up for you in the language, Swift 5. The focus of Swift 5 is greater adoption by delivering Swift as part of the OS. Apps will no longer need to include the Swift runtime when delivering on our newer OS releases, resulting in smaller downloads and faster launches. We're very excited about this, too, and we have made great progress toward this goal. And you'll see it in a release coming early next year.

Proposed actions

Change https://github.com/flutter/flutter/blob/master/packages/flutter_tools/lib/src/commands/create.dart to switch the default language to Swift and Kotlin.

Change https://github.com/flutter/flutter-intellij accordingly

Convert all "first-party" plugins https://github.com/flutter/plugins to Swift and Kotlin.

Write platform unit test in Swift (#10141) and Kotlin (#10140)

Issue 2:
UI nodes require a unique key for arrays of homogeneous children. They key is nominally Object but internally it seems to be converted to String. This causes the surprising behavior that custom objects are rejected as keys:

[0612/154234:ERROR:dart_error.cc(20)] Unhandled exception:

Uncaught Error: If multiple non-interchangeable nodes of the same type exist as children

of another node, they must have unique keys.

Duplicate:

The current workaround is to add a custom .toString() method to any custom class used as key

For example

class Cell {

final int posX;

final int posY;

Cell(this.posX, this.posY);

String toString() => 'Cell($posX, $posY)';

}

without the toString() method, it cannot be used as a key.