WhereIsAI/github-issue-similarity huggingface dataset:
Issue 1:
Windows build number: 10.0.18362.900
PowerToys version: V0.19.0
PowerToy module for which you are reporting the bug (if applicable): FancyZones

Steps to reproduce

Set up Fancy Zones

Shift + Drag window to zone next to the taskbar

The window goes under taskbar

Expected behavior

Zones to stop at the taskbar

Actual behavior

When moving a window to a zone near the taskbar, the window goes under the taskbar.

Screenshots

Zone next to taskbar

Zone away from taskbar

Larger Taskbar

Issue 2:
Environment

Windows build number: 10.0.18363.900
PowerToys version: 0.19.0
PowerToy module for which you are reporting the bug (if applicable): FancyZones
Monitor(s): 2 side-by-side 4K monitors (one set to display scaling 100% and the other to 125%)

Steps to reproduce

Set Windows taskbar location to Top

Snap a window to a FancyZone (2 priority grid zones in my case)

Expected behavior

The window should snap to the full-height of the FancyZone below the task bar

Actual behavior

The window snaps behind the task bar (as shown with the green arrows)

The window leaves a gap underneath each window (as shown with the red arrows), which exposes the desktop background underneath

Screenshots
Issue 1:
When a Kafka index task successfully publishes some segments then it persists the latest consumed offsets info in the metadata store. Now if the supervisor is stopped or stops because of some reason and restarted at a later point and the earliest msg offset in Kafka is greater than persisted offset in the metadata (probably because earlier messages were dropped by kafka brokers or something else) then Kafka Index task will get OffsetOutOfRangeException and keep on retrying the same offset indefinitely.

One way to solve this issue is to reset the consumer offset if the persisted offset is less than the earliest offset at the Kafka broker. Although I think in this case the persisted offset information would need to be delete from metadata store otherwise the new tasks will fail to publish segment because of consecutive offset check. Any thoughts ?

Issue 2:
The Kafka indexing service can get into a stuck state where it is trying to read the Kafka offset following the last one recorded in the dataSource metadata table but can't read it because Kafka's retention period has elapsed and that message is no longer available. We probably don't want to automatically jump to a valid Kafka offset since we would have missed events and would no longer have ingested each message exactly once, so currently we start throwing exceptions and the user needs to acknowledge what happened by removing the last committed offset from the dataSource table.

It would be nice to include an API that will help them by either removing the dataSource table entry or setting it to a valid Kafka offset, but would still require a manual action/acknowledgment by the user.
Issue 1:
Apache Airflow version: 2.1.1

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): Linux e08g09383.cloud.eu13 3.10.0-327.ali2010.rc7.alios7.x86_64 #1 SMP Thu Jun 29 21:45:21 CST 2017 x86_64 x86_64 x86_64 GNU/Linux

Install tools: docker-compose

Others:

I installed the airflow via docker-compose.yaml, and my docker-compose.yaml is as attach file: docker-compose.txt

What happened:

A task was set to be failed directly by scheduler, while all up streams were success.

The task has not be run, no log info either.

What you expected to happen:

The task should be running

How to reproduce it:

It happens by chance, I can not reproduce it.

Anything else we need to know:

A log from scheduler:

[2021-08-01 21:46:14,003] {scheduler_job.py:600} INFO - Executed failure callback for <TaskInstance: blink_create_cluster.create_master_ecs_task 2021-08-01 13:46:09.195000+00:00 [failed]> in state failed

Issue 2:
Apache Airflow version

2.1.4 (latest released)

Operating System

official docker image

Versions of Apache Airflow Providers

No response

Deployment

Official Apache Airflow Helm Chart

Deployment details

using KEDA

What happened

Somehow, downstream task ends in state 'upstream failed' even though the upstream task retried and succeeded.

What you expected to happen

"upstream failed" should only happen when upstream task fails

How to reproduce

No response

Anything else

No response

Are you willing to submit PR?

Yes I am willing to submit a PR!

But I have no ideas about cause here.

Code of Conduct

I agree to follow this project's Code of Conduct
Issue 1:
Bug summary

If set_xscale("log") is set for an inset_axes instance, the default tick formatter is applied irrespective of any calls to set_xticklabels() (before or after the scaling). The same is true for the y-axis.

Code for reproduction

fig, axes = plt.subplots(1, 2)
for ax_main in axes:
ax_in = ax_main.inset_axes([0.05, 0.5, 0.25, 0.5])
ax_main.plot((1,2))
ax_in.plot((1,2))
ax_in.set_xticklabels(())
ax_in.set_yticklabels(())

ax_in.set_xscale("log")

plt.show()

Actual outcome

Expected outcome

The left and right axes of the above should have identical tick labels (i.e. none).

Additional information

No response

Operating system

Ubuntu

Matplotlib Version

3.4.3

Matplotlib Backend

Qt5Agg, module://matplotlib_inline.backend_inline

Python version

Python 3.9.9

Jupyter version

6.4.5

Installation

conda

Issue 2:
Bug report

Bug summary

Units (e.g. datetime) and scales (e.g. log) both come with their own default locators (various DateLocators, LogLocator) and formatters (various DateFormatters, LogFormatter), which are being set in Axis._update_axisinfo and Axis.set_scale, respectively.

If a locator or formatter has already been manually set on the axis, then setting units will not override the user-set locator/formatter -- this is tracked using the slighly awkwardly named isDefault_{maj,min}{loc,fmt}. On the other hand, setting a scale will override locator/formatters previously set.

Code for reproduction

from pylab import *

subplot(121)
xticks([])
xscale("log")

subplot(122)
xticks([])
plot_date([1, 2], [3, 4])

show()

Actual outcome

Expected outcome

Consistent behavior between the two cases. #18571 (comment) is one where scales also respecting user-set locators/formatters would be nice, but I can also see an argument for the opposite behavior for simplicity...

Matplotlib version

Operating system: linux

Matplotlib version: HEAD

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

Python version: 38

Jupyter version (if applicable):

Other libraries:
Issue 1:
Please add the feature to select a column of text with the mouse (like Alt + LMB (Left mouse button), or Shit + RMB) like Sublime Text...

There is a package that provides this functionality (Sublime-Style-Column-Selection), but I think it's better that this feature should be provided by atom itselft

Issue 2:
In plenty editors, doing left-alt (left option) and selecting text will take a slice of that text:

Notice that only characters are selected, empty lines are ignored. Also, after selecting with left-alt, there should be multi-cursors at the end of each selection:

The GIF are from Sublime, the same behavior is observed in TextMate, IntelliJ, vim (visual selection).

The current behavior in Atom is to perform a normal text selection:
Issue 1:
When attempting to copy text from atom to a different program such as a google search in firefox, the copy attempt fails and does not post any text at all.

Issue 2:
I'm using Atom ver. 0.189.0 on Ubuntu 14.04.2 LTS. When I copy a piece of text in atom and I try to paste it the right-click menu either won't show up or will show up without giving me option to paste. The paste shortcut doesn't work either and it creates issues even if I try to copy and paste text from other programs (after I have coping something from atom). I have disable all the extra plugins, so it isn't a plugin issue. I didn't had this issue with the previous version (I am using webupd8 ppa). If I do a right click on a place where there isn't a text entry (meaning a place where it doesn't support paste anyway) the right click menu appears fine.
Issue 1:
New to Julia. I get this message:

INFO: Recompiling stale cache file /Users/.../.julia/lib/v0.5/Atom.ji for module Atom.

I'm on MacOS 10.10.5. I use atom-juno. I have to delete the .julia/lib/ directory content to fix the problem. A tad inconvenient. Below describes problem and workaround.

http://stackoverflow.com/questions/43124887/julia-recompiling-stale-cache-file

This is probably a duplicate, but there are 1,858 open issues and couldn't find a similar one in finite time.

Issue 2:
julia should not create .juila directory at $HOME.

It should follow xdg directory guidelines.
Issue 1:
Mention the authors (see Definitions by: in index.d.ts) so they can respond.

Authors: @tomwanzek @gustavderdrache @Ledragon

The release cycle for D3 Version 5 has just started with a first Release Candidate:

d3-request will be dropped in its entirety and replaced with d3-fetch,

d3-contour will be added, and

there is a major re-shuffle including feature deprecations between d3-scale and d3-scale-chromatic combined with the addition of d3-scale-chromatic to the bundle

In particular, the feature deprecation and reshuffle with regard to d3-scale and d3-scale-chromatic (see release notes), imply that we need to pin down the minor versions for the latest/last D3 v4 bundle definitions.

I.e. we need to add a package.json stub back in, so we do not break users running v4, before we add the new bundle definitions for D3 version 5.

@gustavderdrache and @Ledragon any comments/thoughts re preparing for D3 v5?

@andy-ms Any thoughtful guidance, how we ensure we can safely support the migration between version 4 and version 5 definitions without breaking users of v4?

Cheers, T

Related to #23250, #23251 and #23253.

#23252 (d3-selection 1.3) needs to be merged into the final definitions bundle for d3: 4.13.x

Issue 2:
@MarianPalkus @NoHomey @andy-ms

types/enzyme fails with typescript 2.9.1

Error

Interface 'Element' cannot simultaneously extend types 'ReactElement<any>' and 'ReactElement<any>'. Named property 'type' of types 'ReactElement<any>' and 'ReactElement<any>' are not identical.
Issue 1:
There may already be a "standard" in some of the formats for this (e.g. XLIFF), or maybe it's a bad idea for some reason I don't see. Here's the situation:

Imagine you're using translation "keys" (e.g. ->trans('first_name') instead of ->trans('First Name')). When you do this, you may often get duplicate keys that should be translated to the same word, causing a translation resource that might look like this:

registration_first_name: First Name
profile_first_name: First Name

This is a DX issue, because it means you have duplicated keys that you need to manage. It also makes you want to stop using more descriptive keys to try to have less duplicates. Also, with a bundle like FOSUserBundle where form labels are turned into keys, you can't avoid duplication (https://github.com/FriendsOfSymfony/FOSUserBundle/blob/master/Resources/translations/FOSUserBundle.en.yml).

I propose that we can "alias" a translation key to use the value of another:

registration_first_name: "@profile_first_name"
profile_first_name: First Name

Thoughts?

Issue 2:
Symfony version(s) affected: all

Description

Current IBAN validator uses general IBAN checksum only, while some countries use internal check digit algorithms to validate domestic BBAN. What this means is that some invalid IBANs pass the Symfony validation.

How to reproduce

following should return > 0, instead it returns 0

use Symfony\Component\Validator\Constraints\Iban;
use Symfony\Component\Validator\Constraints\IbanValidator;
use Symfony\Component\Validator\Validation;

echo count(Validation::createValidator()->validate('SK1211115351562002977968', [new Iban]));

Possible Solution

Unfortunately I wasn't successful in finding these country specific algorithms, help needed.

Additional context

https://www.iban.com/iban-validation-help.html provides some basic info about this

https://www.ibancalculator.com/iban_validieren.html First result in google for iban validation, it does these country specific validations too, but they sell API for this service.
Issue 1:
When we create a form that's tied to an entity (meaning we pass an entity to createForm()), Form->isValid() should not validate the entire entity. Or there should at least be an option to disable this behavior.

I have my form type and an entity. When there's a direct mapping between the 2 all works well. However, if I add a property to my entity with a constraint, Form->isValid() calls will fail if the field's value doesn't pass. This means the form will validate entity fields that aren't a part of the form.

The only solution I've seen posed is to use validation groups on the entity but this is implying validation rules on my entities that may not be accurate (perhaps my validation constraints on my entity are all the defaults. Requiring me to group constraints for form handling in another layer doesn't seem right). Form validation should validate form fields. If the form wants to work with entity fields, it would ideally only validate the fields that are specified in the form (or be configurable).

Issue 2:
The Drupal project uses the YAML parser component provided by symfony, but we also need

some sort of imports, as provided by the Config component. That one is though not used by Drupal.

Would there be a possiblities to provide some simple functionality to allow imports relative to the YML file itself?

foo.baz:
path: '/foo/baz
defaults:
_controller: '\Drupal\foo\FooController::baz'
imports:
- routes/foo.admin.routing.yml
- routes/foo.pages.routing.yml

Technically I would agree that this would not belong into the Yaml component though.
Issue 1:
System information (version)

OpenCV => 4.1.0

Operating System / Platform => Mac OS Mojave 10.14

Compiler => n/a python 3.7

Detailed description

https://docs.opencv.org/4.1.0/d7/d37/tutorial_mat_mask_operations.html

python version of tutorial divides 1000 after evaluating current time - start time. This is incorrect as it will already return seconds, no need to divide by 1000.

Steps to reproduce

'''

t = (time.time() - t) / 1000

print("Built-in filter2D time passed in seconds: %s" % t)

'''

Issue 2:
System information (version)

OpenCV => 4.1.0

Operating System / Platform => Windows 10 Pro 64bit (10.0, build 17763)

Compiler => Visual Studio 2017 or Python 2.7.15

Detailed description

When using GaussianBlur, when Width = 5 and SigmaX = 9, strange lines are visible at both ends of the image.

Steps to reproduce

Source image

Output image

below code is same thing happens C++.

# coding: utf-8

import numpy as np
import cv2

print('OpenCV version : ' + cv2.__version__)

img = cv2.imread('test.bmp')

gau1 = cv2.GaussianBlur(img, (5,5), 8)
gau2 = cv2.GaussianBlur(img, (5,5), 9)
gau3 = cv2.GaussianBlur(img, (5,5), 10)

cv2.imshow('origin', img)
cv2.imshow('gau1', gau1)
cv2.imshow('gau2', gau2)
cv2.imshow('gau3', gau3)

cv2.waitKey(0)
cv2.destroyAllWindows()
Issue 1:
Feature request

What is the expected behavior?

An external component should be able to invalidate the remoteEntry and cause a refresh of the external module - currently we would have to do a full page reload.

What is motivation or use case for adding/changing the behavior?

If the app is able to detect a new release of the external component a reload might be required - instead of a full page reload we could refresh the module. (it would likely be the module it self knowing if a refresh is needed)

If there was an issue in the loaded module eg. a UI Component having an issue - it would be nice to provide a pr. module refresh eg. letting the user trigger a "retry"

If the external service is down for some reason the fallback module/component could likely detect when the service is up again and trigger a refresh of modules from that service

How should this be implemented in your opinion?

Client code could import a magical import {refresh} from "webpack/module/federation/refresh"

If used as an external module it would communication with the remoteEntry refresh mechanism updating module loader and resetting module cache. (If used in the main application it could either be ignored or trigger a full page reload?)

Are you willing to work on this yourself?

yes, despite being low on time and domain knowledge regarding the webpack code base - although the initial work would likely be figuring out if feasible / practical or if a full page reload is better.

Issue 2:
Do you want to request a feature or report a bug?

As per @TheLarkInn tweet (https://twitter.com/thelarkinn/status/821879942552154112) it has been brought to attention that there are some rather obvious performance gains (upwards of 10x) when using for over for-of and forEach

What is the current behavior?

Currently, forEach is being used throughout project.

If the current behavior is a bug, please provide the steps to reproduce.

N/A

What is the expected behavior?

Well, I expect it to be as fast and optimized as possible :-)

If this is a feature request, what is motivation or use case for changing the behavior?

It is always better when things are faster!

Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.

As per this sample gist

https://gist.github.com/vsemozhetbyt/7f6db3f73dfec8ac08bcfc81b1b11cbb

Local Results

// v8 5.1.281.84 (Node.js 6.8.1)

for : 1.113ms
for-of : 35.201ms
forEach: 24.478ms
Issue 1:
by esko.luontola:

What steps will reproduce the problem?

import (
"testing"
"runtime"
)

func TestBug(t *testing.T) {
pc, fileCaller, lineCaller, _ := runtime.Caller(0)

f := runtime.FuncForPC(pc)
fileFunc, lineFunc := f.FileLine(pc)

t.Log(fileCaller, fileFunc)
if fileCaller != fileFunc {
t.Errorf("file wrong: %v != %v", fileCaller, fileFunc)
}

t.Log(lineCaller, lineFunc)
if lineCaller != lineFunc {
t.Errorf("line wrong: %v != %v", lineCaller, lineFunc)
}
}

What is the expected output? What do you see instead?

--- FAIL: gospec.TestBug
/home/orfjackal/devel/gospec/src/gospec/bug_test.go
/home/orfjackal/devel/gospec/src/gospec/bug_test.go
9 1126
line wrong: 9 != 1126

What is your $GOOS? $GOARCH?
linux amd64

Which revision are you using? (hg identify)
d1615461b60e tip

Issue 2:
My app hangs acquiring a semaphore (within RWMutex).
(Simple workaround is to add a field to sync.RWMutex struct.)

This problem has been happening for about a week.
There were some bugs in the runtime being chased
at the time, so I hoped this was a duplicate.

I switched back to 1.0.3 in which my app runs fine.

That bug was:
https://golang.org/issue/5120

After that bug was fixed, I tried again and it still
hangs, and the same symptoms occur.

I'd define symptoms below.

Whenever I run my application, it hangs at a certain
point acquiring a semaphore.
(I used kill -SIGABRT to get the stacktrace).

goroutine 17 [semacquire]:
sync.runtime_Semacquire(0x7fc24a701370)
/opt/go-contrib/src/pkg/runtime/zsema_linux_amd64.c:165 +0x2e
sync.(*RWMutex).Lock(0x7fc24a701368)
/opt/go-contrib/src/pkg/sync/rwmutex.go:80 +0x81
ugorji.net/util.(*SafeStore).putAll(0x7fc24a701360, 0x0, 0x1, 0x0, 0x149682c01495c0, ...)
/home/ugorji/depot/golang/src/ugorji.net/util/safe_store.go:148 +0x88

However, I got it past that point simply by adding a
field to RWMutex ie I added "Ugorji bool" as last
field in sync.RWMutex. And we're fine; no more hanging.
(Hopefully this gives a hint of what is causing this).

I tried applying Remy's patch but that didn't help (pulling straws here).
https://golang.org/cl/8287043/

I've been trying to isolate the issue for a week now.
I even wrote standalone programs that simulate what
I am doing, but they all work fine.

Which compiler are you using (5g, 6g, 8g, gccgo)?
6g

Which operating system are you using?
Linux 3.5.0-26-generic #42-Ubuntu SMP Fri Mar 8 23:18:20 UTC 2013 x86_64 GNU/Linux

Which version are you using? (run 'go version')
go version devel +d646225cb410 Wed Apr 03 17:03:42 2013 -0700 linux/amd64

Please provide any additional information below.
Issue 1:
The QR decomposition works properly when used alone. However, after I plot with a .: linestyle using pyplot, the result of QR decomposition becomes nan. This bug happens under the following condition.

The matrix shape is larger than 9x8. A 8x7 matrix works properly on my computer.

Plot with .: or .-- linestyle. The linestyle .- will not cause a problem.

Windows platform. There is no such bug on MacOS.

Reproducing code example:

import numpy as np
import matplotlib.pyplot as plt

def testQR(A, bug):
if bug:
plt.plot([0, 1], [0, 1], ".:")
else:
plt.plot([0, 1], [0, 1], ".-")

Q, _ = np.linalg.qr(A)
print("==========================")
print("Matrix shape: {}x{}".format(A.shape[0], A.shape[1]))
print("Linestyle of pyplot: {}".format(".:" if bug else ".-"))
print("First row of Q: {}".format(Q[0]))

M_large = np.eye(9, 8)
M_small = np.eye(8, 7)

testQR(M_large, bug=True)
testQR(M_large, bug=False)
testQR(M_small, bug=True)
testQR(M_small, bug=False)

The result of the code above on my computer is

==========================
Matrix shape: 9x8
Linestyle of pyplot: .:
First row of Q: [nan nan nan nan nan nan nan nan]
==========================
Matrix shape: 9x8
Linestyle of pyplot: .-
First row of Q: [1. 0. 0. 0. 0. 0. 0. 0.]
==========================
Matrix shape: 8x7
Linestyle of pyplot: .:
First row of Q: [1. 0. 0. 0. 0. 0. 0.]
==========================
Matrix shape: 8x7
Linestyle of pyplot: .-
First row of Q: [1. 0. 0. 0. 0. 0. 0.]

NumPy/Python version information:

numpy version: 1.18.1

matplotlib version: 3.1.2

python version: 3.7.6 (tags/v3.7.6:43364a7ae0, Dec 19 2019, 00:42:30) [MSC v.1916 64 bit (AMD64)]

Issue 2:
Tests are failing:

FAILED ....\lib\tests\test_regression.py::TestRegression::test_polyfit_build - numpy.linalg.LinAlgError: SVD did not...

FAILED ....\linalg\tests\test_regression.py::TestRegression::test_eig_build - numpy.linalg.LinAlgError: Eigenvalues ...

FAILED ....\ma\tests\test_extras.py::TestPolynomial::test_polyfit - numpy.linalg.LinAlgError: SVD did not converge i...

with exceptions:

err = 'invalid value', flag = 8
def _raise_linalgerror_lstsq(err, flag):
> raise LinAlgError("SVD did not converge in Linear Least Squares")
E numpy.linalg.LinAlgError: SVD did not converge in Linear Least Squares
err = 'invalid value'
flag = 8

and

err = 'invalid value', flag = 8
def _raise_linalgerror_eigenvalues_nonconvergence(err, flag):
> raise LinAlgError("Eigenvalues did not converge")
E numpy.linalg.LinAlgError: Eigenvalues did not converge
err = 'invalid value'
flag = 8

Steps taken:

Create a VM

Install latest Windows 10 and update to the latest version 2004 (10.0.19041)

Install Python 3.8.3

pip install pytest

pip install numpy

pip install hypothesis

run tests in the package

Same happens issue happens when running on tests in the repository.

Version 1.19.0 of numpy

Am I missing any dependencies? Or is it just Windows going bonkers?