WhereIsAI/github-issue-similarity huggingface dataset:
Issue 1:
Is this a bug report or feature request?

Bug

Repro repo.

Input Code

export default class {
method ({ ...object }) {}
}

Babel/Babylon Configuration (.babelrc, package.json, cli command)

{
"presets": [
[
"@babel/env",
{
"shippedProposals": true,
"targets": {
"node": 8
},
"useBuiltIns": "usage"
}
]
]
}

Expected Behavior

Should compile.

Current Behavior

TypeError: index.js: Duplicate declaration "object"
1 | export default class {
> 2 | method ({ ...object }) {}
| ^
3 | }
4 |
at File.buildCodeFrameError (issue-babel-env-duplicate/node_modules/@babel/core/lib/transformation/file/file.js:209:12)
at Scope.checkBlockScopedCollisions (issue-babel-env-duplicate/node_modules/@babel/traverse/lib/scope/index.js:303:27)
at Scope.registerBinding (issue-babel-env-duplicate/node_modules/@babel/traverse/lib/scope/index.js:485:16)
at Scope.registerDeclaration (issue-babel-env-duplicate/node_modules/@babel/traverse/lib/scope/index.js:404:14)
at Object.BlockScoped (issue-babel-env-duplicate/node_modules/@babel/traverse/lib/scope/index.js:146:28)
at Object.newFn (issue-babel-env-duplicate/node_modules/@babel/traverse/lib/visitors.js:266:17)
at NodePath._call (issue-babel-env-duplicate/node_modules/@babel/traverse/lib/path/context.js:64:19)
at NodePath.call (issue-babel-env-duplicate/node_modules/@babel/traverse/lib/path/context.js:34:14)
at NodePath.visit (issue-babel-env-duplicate/node_modules/@babel/traverse/lib/path/context.js:99:12)
at TraversalContext.visitQueue (issue-babel-env-duplicate/node_modules/@babel/traverse/lib/context.js:139:18)

Possible Solution

Context

Your Environment

software
version(s)

Babel
7.0.0-beta.39

Babylon

node
9.4.0

npm

Operating System

Issue 2:
See: https://github.com/babel/babel/pull/7869/files#r189395861

Hey all, I'm concerned about this. Now that we've defined the ability to pass options to Babylon plugins, ordering becomes critical. What if some other piece of tooling injected a syntax plugin into the plugin list after this one, or before? Which one should take priority? For instance for https://github.com/babel/babel/pull/7934/files#diff-3a8233bcd2766d2c7d87f23f944f7726R12, say the user's framework auto-enables flow, but the user wants to enable all, which comes first?

So far we've avoided this problem by not having options, and not worrying about duplicates. Now it will matter very much both what order your Babel plugins are in, but also what order they enable Babylon plugins in.

At a minimum, have we verified that the ordering on these is consistent with the ordering of visitors? e.g. If two plugins are enabled with different options, whichever one's visitors run first, is also the one who's Babylon configuration takes affect?

The plugin map logic in https://github.com/babel/babel/pull/7869/files#diff-8b7138068ab1dfcbfafe8422f16505cbR45 will always take the last set of options. If I'm piecing things together in my head correctly, that'll be a problem, because the first plugin in the list will run its visitors first, but the last plugin in the list will be the thing specifying the options to Babylon.
Issue 1:
Description of the problem

It would be great to have the option to render in grayscale. It could be implemented as a new tonemapping type and set in renderer.tonemapping.

Issue 2:
I see that there's been some work done in the past in #15360 and @greggman has put together a nice article on the topic here. It's not entirely clear to me why the previous PR was closed but I wanted to bring this up as a nice addition to three.js. The utility has been better explained in the two links above but 3DLUTs are great for controlling the look and feel of a scene.

3DLUTs are supported in a variety of 3d engines and video editing software include Unity, Unreal Engine, and Babylonjs. There are also a couple existing file formats for them including .cube and .3dl (though 3dl looks relatively undocumented).

These formats are available online and can also be created in tools like Photoshop and would enable more artistic control over the look of the final scene.

I figure that just like gamma correction there could be a postprocessing effect and WebGLRenderer support that adds the LUT application to the end of the built in shaders:

const lut = new LUTLoader().load( '../path/to/lut.3dl' );
renderer.colorLUT3D = lut;
Issue 1:
Add ability to flip from vertical to horizontal bar charts

Issue 2:
Make sure these boxes are checked before submitting your issue - thank you!

I have checked the superset logs for python stacktraces and included it here as text if any

I have reproduced the issue with at least the latest released version of superset

I have checked the issue tracker for the same issue and I haven't found one similar

Superset version

Latest one, I'm pretty sure

Expected results

There is no horizontal bar chart visualization type. I was thinking it would be nice to add a "Transpose" checkbox under the Style tab to do this.

Actual results

No horizontal bar chart option:

Where I suggest putting the Transpose option:

Steps to reproduce

Go to a chart, then see screenshots above
Issue 1:
The e2e test Load capacity [Feature:Performance] should be able to handle 30 pods per node fails frequently in the scalability test suite with the error: /go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/test/e2e/density.go:144 There should be no high-latency requests Expected : 1 not to be > : 0

Recent failures:

http://kubekins.dls.corp.google.com/view/Critical%20Builds/job/kubernetes-e2e-gce-scalability/4961/

http://kubekins.dls.corp.google.com/view/Critical%20Builds/job/kubernetes-e2e-gce-scalability/4954/

http://kubekins.dls.corp.google.com/view/Critical%20Builds/job/kubernetes-e2e-gce-scalability/4949/

http://kubekins.dls.corp.google.com/view/Critical%20Builds/job/kubernetes-e2e-gce-scalability/4916/

http://kubekins.dls.corp.google.com/view/Critical%20Builds/job/kubernetes-e2e-gce-scalability/4891/

http://kubekins.dls.corp.google.com/view/Critical%20Builds/job/kubernetes-e2e-gce-scalability/4841/

Issue 2:
Examples:

http://kubekins.dls.corp.google.com/view/Critical%20Builds/job/kubernetes-e2e-gce-scalability/4970/

http://kubekins.dls.corp.google.com/view/Critical%20Builds/job/kubernetes-e2e-gce-scalability/4955/

http://kubekins.dls.corp.google.com/view/Critical%20Builds/job/kubernetes-e2e-gce-scalability/4967/

@gmarek
Issue 1:
Summary of the new feature/enhancement

Proposed technical implementation details (optional)

Issue 2:
Summary of the new feature/enhancement

Currently, if I put a window into a zone, then take it out of the zone, it retains the size of the zone. There should be an option for it to go back to it's original, or "pre-zoned" size.

Proposed technical implementation details (optional)

Essentially providing an option (and I think it should be an option, not a forced feature) that's similar to the way Windows' built-in window snapping works. By default on Windows 10, if you snap into the left or right, or in 1 of 4 grids, and then drag the window out of it, it'll return to it's pre-snap size. It will also help it feel like a more built-in feature.
Issue 1:
Keith Donald opened SPR-7544 and commented

Currently empty form fields are mapped to "" (empty string). This has several issues:

Neither a @NotNull JSR-303 constraint or a "not null" relational DB constraint fails in this case. You're left with defining a min @Size constraint or relying on a implementation-specific @NotEmpty. In addition, there is no DB min constraint you can define at the Db level. Simply mapping "" to null would solve these problems and we could just rely on @NotNull/not null.

Affects: 3.0.4

Issue Links:

#12969 Formatter subsystem's ParserConverter skips Parser invocation if input string is empty

#10090 With binder.setRequiredFields constraint set, submitting an empty value for a required request parameter not binding an empty string to backing JavaBean

Issue 2:
Keith Donald opened SPR-7380 and commented

ParserConverter, which invokes parser.parse(String, Locale) on the Parser/Formatter SPIs maps [null] and "" inputs to [null]. The target Parser is not invoked in this case (and never sees the "" value).

This leads to an inconsistency when doing a form binding, where some properties are formatted and others are not. In the formatted case, empty form fields always result in [null] property values, even if the target property is a String. In the default case, empty form fields result in empty string "" values when the target property is a String.

Affects: 3.0.3

Issue Links:

#12969 Formatter subsystem's ParserConverter skips Parser invocation if input string is empty
Issue 1:
Bug Report

Current Behavior

The transpilation result of generator functions is incomplete when a specific preset is enabled.

Input Code

The following code doesn't transpile correclty with the "firefox >= 45" preset enabled.

class Plug {

*[Symbol.iterator]() {
yield 1;
yield 2;
}
}

The generated output on the babel REPL is referencing a _callee variable which is never defined.

Expected behavior/code

Some valid transpiled code.

Babel Configuration (.babelrc, package.json, cli command)

module.exports = function() {
const presets = [
[
"@babel/preset-env",
{
"targets": {
"firefox": "53"
}
}
]
];

var config = {
presets
};

return config;
};

Environment

Babel version(s): 7.3.4

Node/npm version: Node v10.15.3/npm 56.4.1

OS: Ubunut 16.04

Monorepo: ?

How you are using Babel: cli

Issue 2:
Bug Report

Current Behavior

Class with a generator method like this:

class Foo {
method(){
thia.val = 10;
}

*bar(){
yield this.val;
return 'bar';
}
}

I disabled class transform option because many browsers are natively support this feature. But I got a bad transformed output:

class Foo {
method() {
thia.val = 10;
}

bar() {
return regeneratorRuntime.wrap(
function _callee$(_context) {
while (1)
switch ((_context.prev = _context.next)) {
case 0:
_context.next = 2;
return this.val;

case 2:
return _context.abrupt("return", "bar");

case 3:
case "end":
return _context.stop();
}
},
_callee,
this
);
}
}

When run in browser, got _callee is not defined.

Expected behavior/code

The correct transform result maybe looks like:

class Foo {
method() {
thia.val = 10;
}

bar() {
return regeneratorRuntime.mark(function bar() {
return regeneratorRuntime.wrap(
function bar$(_context) {
while (1) {
switch ((_context.prev = _context.next)) {
case 0:
_context.next = 2;
return this.val;

case 2:
return _context.abrupt("return", "bar");

case 3:
case "end":
return _context.stop();
}
}
},
bar,
this
);
});
}
}

Additional context/Screenshots
Issue 1:
Given this rust:

class apple {
let one_field_is_required: int;

new() {
self.one_field_is_required = 0;
for [1,2,3].each |_x| {}
// let _dummy = 4;
}
}

fn main() {
}

rustc fails with:

test.rs:7:8: 7:32 error: mismatched types: expected `apple` but found `()` (class apple vs ())
test.rs:7 for [1,2,3].each |_x| {}
^~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to previous error

This is pretty wierd. Its like rustc thinks the for loop is an implicit return expression.

Un-commenting the let _dummy = 4; line makes the code compile as expected.

Issue 2:
The compiler panics when you put an extern function inside a structure implementation.

struct Dummy;
impl Dummy {
pub extern fn printme() {
println!("Hello...");
}
}

fn main() {
Dummy::printme();
}

error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: http://doc.rust-lang.org/complement-bugreport.html
note: run with `RUST_BACKTRACE=1` for a backtrace
thread 'rustc' panicked at 'assertion failed: f.abi == Rust || f.abi == RustCall', /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/librustc_trans/trans/base.rs:2440

Try it: http://is.gd/MUQsZd
Issue 1:
Part of what made node.js take off so much wasn't the http server, but rather, the runtime's ability to allow developers to use JS to write a server, mobile app, and even hardware.

In that same spirit, wouldn't it be advantageous to add direct support for serial, usb, ble, etc?

Also if the goal is to make it more "web like" or webby, adding support for modern web API's like #5954 mentions could be really help this.

There are also other API's beyond Serial API and the Native File System API, that could definitely help bring native-like app and hardware development to deno such as:

Browser Debugging:

Dev Tool Protocol

Would adding out of the box support for this drastically aid debugging between the server and client communication?

What about browserfy-like opening, refreshing, or even cross-browser visual testing?

Chrome, chromium-edge and firefox all use it (if I'm not mistaken).

Native / Mobile App API's

I2C

USB

web serial

sensor APIs

Web Bluetooth API

Geolocation

Light weight Database Stuff also addresses #5605

IndexDB

WebSQL

[Others Worth considering] (https://www.creativebloq.com/features/15-web-apis-youve-never-heard-of)

Issue 2:
This is a list to track the Web APIs (as per MDN API specifications list) that are implemented in Deno.

Ambient Light Events

Background Tasks

Beacon

Bluetooth API

Broadcast Channel API

CSS Counter Styles

CSS Font Loading API

CSSOM

Canvas API

Channel Messaging API

Console API

Credential Management API

DOM

Encoding API

Encrypted Media Extensions

Fetch API

File System API

Frame Timing API

Fullscreen API

Gamepad API

Geolocation API

HTML Drag and Drop API

High Resolution Time

History API

Image Capture API

IndexedDB

Intersection Observer API

Long Tasks API

Media Capabilities API

Media Capture and Streams

Media Session API

Media Source Extensions

MediaStream Recording

Navigation Timing

Network Information API

Page Visibility API

Payment Request API

Performance API

Performance Timeline API

Permissions API

Pointer Events

Pointer Lock API

Proximity Events

Push API

Resize Observer API

Resource Timing API

Server Sent Events

Service Workers API

Storage

Storage Access API

Streams

Touch Events

URL API

Vibration API

Web Animations

Web Audio API

Web Authentication API

Web Crypto API

Web Notifications

Web Storage API

Web Workers API

WebGL

WebRTC

WebVR API

WebVTT

WebXR Device API

Websockets API
Issue 1:
On Android there's a bug in the margin/paddings/floats CSS of the radio buttons.

See:

On Android (bug): *

On Chrome (correct) *

You can check it also here:

http://twitter.github.com/bootstrap/base-css.html#forms

Regards,

Gunther

Issue 2:
Checkboxes defined as per the examples render with the text floating at least half a line higher than the actual check box.

<label class="checkbox">
<input type="checkbox" name="optionsCheckboxList1" value="option1">
Option one is this and that—be sure to include why it's great
</label>

If you have a group of checkboxes this starts to look very confusing.
Issue 1:
This is something similar to #10363.

When feeding a float to a numpy function, you get a numpy.float64. When feeding an array of rank > 0 to a numpy function, you get an array of the same rank. UNLESS the array is rank 0, i.e., a scalar for most intents and purposes. Then you get a numpy.float64.

MWE:

import numpy

print(type(numpy.sqrt(2.0))) # numpy.float64, okay
print(type(numpy.sqrt(numpy.array([2.0])))) # numpy.ndarray, okay
print(type(numpy.sqrt(numpy.array(2.0)))) # numpy.float64, gnrg

It'd be more consistent if the numpy functions returned an array if you feed it it one, even for rank 0.

Issue 2:
If only given 0d inputs, even if they are of type ndarray, ufuncs will decay their output to a scalar via [()] (as noted in #4563, #5819). While we can't change this behavior now without creating signficant pain downstream, we could add a way to opt out of it.

#13100 raises a case where np.fix resorts to calling np.asanyarray(np.ceil(x, out=out)) in order to ensure that the result is an array. Unfortunately, this has a number of draw-backs:

It discards duck-types, like dask arrays

It changes the dtype of 0d object arrays containing array-likes

Proposed implementation:

Create a new np.leave_wrapped sentinel object that can be passed as an out argument

Add support in ufunc.__call__, np.take, ... for passing out=np.leave_wrapped meaning "do not call PyArray_Return", causing the result to never be a scalar

Expose PyArray_Return to python as np.core.unpack_scalar

Implement np.fix as:

def fix(x, out=None):
if out is None:
do_unwrap = True
out = np.leave_wrapped
else:
do_unwrap = False
res = nx.ceil(x, out=out)
res = nx.floor(x, out=res, where=nx.greater_equal(x, 0, out=np.leave_wrapped))

if do_unwrap:
res = np.unpack_scalar(res) # PyArray_Return
return res

Original unpack_scalars=True proposal

Add a new unpack_scalars=True kwarg to ufunc.__call__, ufunc.reduce. When False, the current behavior of going through PyArray_Return is disabled. Alternative names:

decay=True

unpack_0d=True

unpack_0d_ndarray=True (PyArray_Return already does not apply to subclasses)

Add a new np.unpack_scalar(arr) function to expose PyArray_Return to python code. This would not be overloadable with __array_function__, since existing uses of PyArray_Return are also not.

With these changes, the current implementation of np.fix would change from:

def fix(x, out=None):
res = nx.asanyarray(nx.ceil(x, out=out))
res = nx.floor(x, out=res, where=nx.greater_equal(x, 0))

if out is None and type(res) is nx.ndarray:
res = res[()]
return res

to

def fix(x, out=None, *, unpack_scalars=True):
res = nx.ceil(x, out=out, unpack_scalars=False)
res = nx.floor(x, out=res, where=nx.greater_equal(x, 0, unpack_scalars=False), unpack_scalars=False)

if unpack_scalars and out is None:
res = np.unpack_scalar(res)
return res

If needed, I could promote this to an NEP
Issue 1:
Bug report

matplotlib.pyplot picture is corrupted when the picture is too wide

Code for reproduction

A minimum working example is here:

import matplotlib.pyplot as plt
import numpy as np

num_points = 1000
op_norms = range(1, num_points + 1)
op_names = ["name {}".format(p) for p in op_norms]

for figwidth in [300, 400]:
f = plt.figure(num=None, figsize=(figwidth, 6), facecolor='w', edgecolor='k')
for i, op_norm in enumerate(op_norms):
plt.semilogy(i, op_norm, "o")

plt.xticks(np.arange(num_points), op_names, rotation=90)
plt.tight_layout()
plt.grid(True)
plt.savefig("wideplot_width_{}.png".format(figwidth), bbox_inches='tight')
plt.close()```

Expected outcome:

When figwidth=300, everything is fine; see here. However, when it is increased to figwidth=400, the plot is corrupted (boarder is not complete, x axis label not complete, dirty ink etc.); see here.

Operating system: Debian GNU/Linux 10 (buster)

Matplotlib version (import matplotlib; print(matplotlib.__version__)): 3.3.2

Matplotlib backend (print(matplotlib.get_backend())): agg

Python version: 3.7.9

matplotlib is installed from conda.

Any hint would be very much appreciated! Thanks!

Issue 2:
Bug report

Bug summary

If I try to save a figure with 1024**3 pixels or more, the Python interpreter crashes.

Code for reproduction

The following script segfaults for me on two separate machines:

#! /usr/bin/env python

import matplotlib
import sys

matplotlib.use('agg')

import matplotlib.pyplot as plt

if len(sys.argv) == 3:
figsize = (int(sys.argv[1]), int(sys.argv[2]))
else:
print('using default figsize')
figsize = (463, 232)

fig, ax = plt.subplots(figsize=figsize, dpi=100)
fig.savefig('big.png')

Actual outcome

This segfaults when trying to create this image. The image size is 46300 × 23200 = 1,074,160,000. For comparison, 1024**3 is 1,073,741,824.

Expected outcome

No segfault. If I run the script with arguments 462 232 to create an image of 1,071,840,000 pixels, I get no crash.

Matplotlib version

Operating system: Centos 7.8 or Fedora 33

Matplotlib version: 3.3.3

Matplotlib backend (print(matplotlib.get_backend())): agg

Python version: 3.8.6

Matplotlib installed through Conda using conda-forge.

Other information

The relevant stacktrace is short:

#0 0x00007fffd699ffbd in agg::renderer_base<agg::pixfmt_alpha_blend_rgba<fixed_blender_rgba_plain<agg::rgba8T<agg::linear>, agg::order_rgba>, agg::row_accessor<unsigned char> > >::clear(agg::rgba8T<agg::linear> const&) [clone .part.61] [clone .lto_priv.101] ()
from /a/lib/python3.8/site-packages/matplotlib/backends/_backend_agg.cpython-38-x86_64-linux-gnu.so
#1 0x00007fffd6994d8d in PyRendererAgg_init(PyRendererAgg*, _object*, _object*) [clone .lto_priv.107] ()
from /a/lib/python3.8/site-packages/matplotlib/backends/_backend_agg.cpython-38-x86_64-linux-gnu.so
#2 0x0000555555683888 in type_call (kwds=0x0, args=0x7fffe773fe40, type=<optimized out>)
at /home/conda/feedstock_root/build_artifacts/python-split_1602094424782/work/Objects/typeobject.c:994

I am running this test on 64-bit machines and I can confirm that these are not simple out-of-memory errors.
Issue 1:
I have a problem to update an entity which have more than 250 fields in a form. No assert validator, and a basic template twig.

On PHP 5.4:

In SF2.1, no problem, I sumbit the form, it takes 1-2 seconds to do that.

In SF2.2 or 2.3, I have a "maximum execution time" error ! I try to modify the value and I found it takes about 17 minutes !!!!!

On PHP 5.3:

No problem, the form is submitted in 1-2 seconds with SF 2.1, 2.2 or 2.3

Issue 2:
Hello,

I upgraded to Symfony 2.3 recently an application.

This application has a form with 500 rows and 5 fields in each rows: 2500 fields.

With Symfony 2.3 and the button support feature the form takes 110 seconds (70% of the total request processing time) and this time is spent just in getValidationGroups.

findClickedButton is being called recursively for the whole form on each field restarting a t the root every time, at the end of the recursion, this method is called more than 6.9 Million times.

http://oi41.tinypic.com/rmmag6.jpg

http://oi42.tinypic.com/n5my35.jpg

Adding a "submit" button managed by the form really improved the findClickedButton as it was being called only ~2800 times.

I have no idea if this is a bug or not and how can it be fixed, but i thought reading at the blogpost that managing submit buttons within the form was optional, and considering the overhead of not managing it with the form, i feel like i have to change every forms.

should i change all the "big enough" forms (~50 fields) to be "symfony 2.3" ready ?

Update:

Overhead is low with simple forms.

22 fields leads to 770 calls to findClickedButton in 7.8 micro seconds
Issue 1:
... because we include es6-shim.d.ts in our transitive typings.

Issue 2:
I'm submitting a ... (check one with "x")

[X ] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior

When a dynamically injected component triggers en event (using Output and EventEmitter), it's never catched by the component that has the directive *ngComponentOutlet set,

Expected behavior

The event should be catched

Minimal reproduction of the problem with instructions

<ng-container *ngFor="let dialog of dialogs">
<ng-container (dialogActionCompleted)="onDialogActionSelected($event)" *ngComponentOutlet="dialog.type">
</ng-container>
</ng-container>

On this code, dialogActionCompleted is never catched. In Subject.js (rxjs), this.observers array is empty (indicating that nothing is listening to the event).

I've tried to create a "fake component", thinking that it was related to the fact that ng-container should be a component, But I get the same behavior.

Please tell us about your environment:

Windows 7, Visual Studio

Angular version: 2.0.X

v2.4.9 + ngComponentOutlet directive included manually in the solution

Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]

All browsers

Language: [all | TypeScript X.X | ES6/7 | ES5]

Typescript 2.0

Any workaround (even quick & dirty) would be appreciated :)