WhereIsAI/github-issue-similarity huggingface dataset:
Issue 1:
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

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

Authors: @galkin @SimonSchick and many others (and git blame doesn't load them all...)

The Node typings appear to be incompatible with tsc 3.6.4:

~/src/DefinitelyTyped/types/node $ tsc --version
Version 3.6.4

~/src/DefinitelyTyped/types/node $ tsc
../../../../.config/yarn/global/node_modules/typescript/lib/lib.es2015.iterable.d.ts:41:6 - error TS2300: Duplicate identifier 'IteratorResult'.

41 type IteratorResult<T, TReturn = any> = IteratorYieldResult<T> | IteratorReturnResult<TReturn>;
~~~~~~~~~~~~~~

index.d.ts:72:11
72 interface IteratorResult<T> { }
~~~~~~~~~~~~~~
'IteratorResult' was also declared here.

index.d.ts:72:11 - error TS2300: Duplicate identifier 'IteratorResult'.

72 interface IteratorResult<T> { }
~~~~~~~~~~~~~~

../../../../.config/yarn/global/node_modules/typescript/lib/lib.es2015.iterable.d.ts:41:6
41 type IteratorResult<T, TReturn = any> = IteratorYieldResult<T> | IteratorReturnResult<TReturn>;
~~~~~~~~~~~~~~
'IteratorResult' was also declared here.

test/querystring.ts:47:11 - error TS2322: Type 'ParsedUrlQueryInput' is not assignable to type 'string | ParsedUrlQuery | null'.
Type 'ParsedUrlQueryInput' is not assignable to type 'string'.

47 const query: string | null | querystring.ParsedUrlQuery = queryInput;
~~~~~

Found 3 errors.

Issue 2:
I created my typings repository before, but since this one is already much more popular I think that I should move my typings here, so they can reach more people and people can improve them.

So if you don't mind, can I move my typing here?

Thanks in advance.

PS: My repository is this one: https://github.com/soywiz/typescript-node-definitions
Issue 1:
In 0.10.8, if I have a TypeScript Definition for a JavaScript file, there is validation done on the parameters. This was particularly useful for finding broken APIs.

Example of definition file and code:

In 0.10.8, a warning is shown for an incorrect type:

Now, in 0.10.10, there is no validation at all. The "100" shows as being valid:

Losing the validation is a big loss. When switching to Salsa, was this the intention? Is there any properties that can be set to have the JavaScript intellisense + validation go back to the old engine (I believe it was using the TypeScript engine).

Thanks

Issue 2:
See #6658 for background.

Currently for JavaScript files we provide a very limited set of errors, mostly for syntax errors. There are a number of grammatical and type errors that would be useful to display also.

Brief notes from ad hoc discussion in the team room include:

Move the code that flags TypeScript syntax in JavaScript files for better error handling

Add a distinction between errors and warnings to avoid "valid" JavaScript containing errors

Make the warnings user configurable as part of the project (i.e. may enable/disable certain warnings)

More detailed design to come...
Issue 1:
I have not had a chance to test this under other conditions yet, but i suspect it may affect other non mod_rewrite url rewriting modules, and does not happen with path info based routing, nor when a bundle:controller:action style path is given.

given the twig snippet:

{% render url('some_partial') %}

the sub request to handle the render tag seems to ignore the uri passed to it and use UNENCODED_URL instead, this continues round and round until the stack gets too big and it errors.

from a really quick look it appears to be a conflict in how Request::prepareRequestUri retrieves the uri and how Request::create creates it, along with the fact DefaultRenderingStratergy::createSubRequest passes through the original server array.

Off the top of my head a solution might be to check for a SYMFONY_URI environment variable above all else and set that in create method, this would ensure the frameworks value is always honoured.

Issue 2:
I am using child forms to prevent code duplication as explained here: https://symfony.com/doc/current/form/inherit_data_option.html

But this result in "nested" fields names for child forms (foo[address], foo[zipcode], etc...).

In a classical web application, this is not a problem because Symfony render form HTML and we don't really care about fields names.

But when using it for an API application, we want all the request parameters as the same level and not in a nested sub level.

Actually it's possible to set an empty form name on the root form only.

Why can't we make it possible on child forms too?

Maybe another way exists to add field of a form type we want to include in our form at the same level of the current form?
Issue 1:
What problem does this feature solve?

Having multiple event handlers that call the very same function add noise to the templates.

I propose to DRY that a bit.

What does the proposed API look like?

Currently you can pass multiple functions to a single event handler like so:

<component
@click="func1(); func2()"
></component>

However, I think it would be really handy to be able to do the inverse, ie. passing the same function to multiple event handlers.

Today for instance I have to do this:

<component v-model.number="foo"
@doDelayedStuff="delayedStuff"
@wheel.native="delayedStuff"
@mouseenter.native="callFooUpdate"
@focus.native="callFooUpdate"
@keyup.native="callBar"
@mouseleave.native="callFooClear"
@blur.native="callFooClear"
@change.native="callFooClear"
@click.prevent="doStuff"
@keyup.75="doStuff"
></component>

It would be great if you could instead do that:

<component v-model.number="foo"
@[doDelayedStuff, wheel.native]="delayedStuff"
@[mouseenter.native, focus.native]="callFooUpdate"
@keyup.native="callBar"
@[mouseleave.native, blur.native, change.native]="callFooClear"
@[click.prevent, keyup.75]="doStuff"
></component>

That way you can more clearly see in one glance how many different behavior are attached to a component. Also, modifying the callbacks is easier.

Thoughts? 😄

Issue 2:
What problem does this feature solve?

So far a hack such as
<template>
{{foo}}
</template>

//js
var promise = new Promise(s=>setTimeout(s(1)))
{
data:{foo:''},
computed:{
async bar(){
return await promise
}
},
watch:{
async bar(){
this.foo = await bar
}
}
}

What does the proposed API look like?

<template>
{{await foo}}
</template>

//js
var promise = new Promise(s=>setTimeout(s(1)))
{
computed:{
async foo(){
return await promise
}
},
}
Issue 1:
julia> using LinearAlgebra

julia> LinearAlgebra.hello()
ERROR: UndefVarError: hello not defined
Stacktrace:
[1] getproperty(x::Module, f::Symbol)
@ Base ./Base.jl:26
[2] top-level scope
@ REPL[2]:1

The error could be more helpful with ERROR: UndefVarError: no binding hello defined in module LinearAlgebra

Issue 2:
Following this LoopVectorization issue asking for begin/end support: JuliaSIMD/LoopVectorization.jl#246

I was curious how Base Julia correctly handled begin/end with CartesianIndex.

julia> i = CartesianIndex((1,2))
CartesianIndex(1, 2)

julia> A = rand(6,5,4,3,2);

julia> A[i,begin,end,2]
ERROR: BoundsError: attempt to access 6×5×4×3×2 Array{Float64, 5} at index [1, 2, 1, 4, 2]
Stacktrace:
[1] getindex
@ ./array.jl:834 [inlined]
[2] getindex(::Array{Float64, 5}, ::CartesianIndex{2}, ::Int64, ::Int64, ::Int64)
@ Base ./multidimensional.jl:638
[3] top-level scope
@ REPL[17]:1

julia> A[i,begin,begin,begin]
0.5712471105637651

julia> A[i,begin,begin,end]
ERROR: BoundsError: attempt to access 6×5×4×3×2 Array{Float64, 5} at index [1, 2, 1, 1, 3]
Stacktrace:
[1] getindex
@ ./array.jl:834 [inlined]
[2] getindex(::Array{Float64, 5}, ::CartesianIndex{2}, ::Int64, ::Int64, ::Int64)
@ Base ./multidimensional.jl:638
[3] top-level scope
@ REPL[19]:1

The Meta.@lower, shown separately because it messes up highlighting of all downstream code (edit: edited it to close the opening "`"):

julia> Meta.@lower A[i,begin,end,2]
:($(Expr(:thunk, CodeInfo(
@ none within `top-level scope`
1 ─ %1 = Base.firstindex(A, 2)
│ %2 = Base.lastindex(A, 3)
│ %3 = Base.getindex(A, i, %1, %2, 2)
└── return %3
))))

begin/end is syntax based, so the second index -> firstindex(A,2)/lastindex(A,2), without considering that the first index could be of varying dimension.
Issue 1:
Description of the new feature/enhancement

There doesn't seem to be an obvious way to detect when running from the terminal. This is a issue for applications and libraries where behavior is dependent on the terminal. For example, a Python library may require colorama for some terminals and not others.

Proposed technical implementation details

The most common and portable way to do this is to set the TERM environment variable when initializing the terminal.

Issue 2:
Environment

Windows build number: 10.0.18362.239[run "ver" at a command prompt]
Windows Terminal version 0.2.1831.0:

Any other software? No

Steps to reproduce

material. -->

Opened one WSL terminal tab with a relatively long path like this:

The path is too long to give other opened tabs space to show.

I opened another WSL tab, but I cannot see it in the tab bar, only when I maximize the window size can I see it.

normal size

maximum size

Expected behavior

The tab with relatively long path should shorten itself to give other tabs enough space to show, like in vscode or vs.

Actually this could not be a bug, but may be an issue or feature to be considered.
Issue 1:
Description

The old documentation for Scheduler Basics should be reviewed and incorporated into Airflow Documentation

Use case / motivation

To remove documentation duplication and clean it up.

Related Issues

#10178

Issue 2:
Apache Airflow Provider(s)

google

Versions of Apache Airflow Providers

apache-airflow 2.5.0

apache-airflow-providers-apache-beam 4.1.0

apache-airflow-providers-cncf-kubernetes 5.0.0

apache-airflow-providers-google 8.6.0

apache-airflow-providers-grpc 3.1.0

Apache Airflow version

2.5.0

Operating System

Debian 11

Deployment

Official Apache Airflow Helm Chart

Deployment details

KubernetesExecutor

What happened

GCSToBigQueryOperator allows multiple ways to specify schema of the BigQuery table:

Setting autodetect == True

Setting schema_fields directly with autodetect == False

Setting a schema_object and optionally a schema_object_bucket with autodetect == False

This third method seems to be broken in the latest provider version (8.6.0) and will always result in this error:

[2022-12-16, 21:06:18 UTC] {taskinstance.py:1772} ERROR - Task failed with exception
Traceback (most recent call last):
File "/home/airflow/.local/lib/python3.9/site-packages/airflow/providers/google/cloud/transfers/gcs_to_bigquery.py", line 395, in execute
self.configuration = self._check_schema_fields(self.configuration)
File "/home/airflow/.local/lib/python3.9/site-packages/airflow/providers/google/cloud/transfers/gcs_to_bigquery.py", line 524, in _check_schema_fields
raise RuntimeError(
RuntimeError: Table schema was not found. Set autodetect=True to automatically set schema fields from source objects or pass schema_fields explicitly

The reason for this is because this block where if self.schema_object and self.source_format != "DATASTORE_BACKUP":. fails to set self.schema_fields. It only sets the local variable, schema_fields. When self._check_schema_fields is subsequently called here, we enter the first block because autodetect is false and schema_fields is not set.

What you think should happen instead

No error should be raised if autodetect is set to False and a valid schema_object is provided

How to reproduce

Create a simple BigQuery table with a single column col1:

CREATE TABLE `my-project.my_dataset.test_gcs_to_bigquery` (col1 INT);

Upload a json blob for this object to a bucket (e.g., data/schemas/table.json)

Upload a simple CSV for the source file to load to a bucket (e.g., data/source/file.csv)

Run the following command:

gcs_to_biquery = GCSToBigQueryOperator(
task_id="gcs_to_bigquery",
destination_project_dataset_table="my-project.my_dataset.test_gcs_to_bigquery",
bucket="my_bucket_name",
create_disposition="CREATE_IF_NEEDED",
write_disposition="WRITE_TRUNCATE",
source_objects=["data/source/file.csv"],
source_format="CSV",
autodetect=False,
schema_object="data/schemas/table.json",
)

Anything else

No response

Are you willing to submit PR?

Yes I am willing to submit a PR!

Code of Conduct

I agree to follow this project's Code of Conduct
Issue 1:
System info

Playwright Version: [v1.29.2]

Operating System: [macOS 13.2, macOS 11.5.2] ※but, I didn't check other versions.

Browser: [Chromium]

Other info:

Source code

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

Config file

// playwright.config.ts
import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
projects: [
{
name: 'chromium',
use: { ...devices['Desktop Chrome'], },
},
});

Test file (self-contained)

import { expect, test } from '@playwright/test';

test('testTitle', async ({ page }) => {
await page.goto('url');
await expect(page).toHaveTitle(/pageTitle/);
await page.evaluate(() => window.scroll({ top: 0 }));
await expect(page).toHaveScreenshot(); // problem occurred
});

Steps

Run the test

and then error occurred

Error: Screenshot comparison failed:
6 pixels (ratio 0.01 of all image pixels) are different.

Expected

The test should be succeeded no matter who does it.

Actual

The following errors may or may not occur when the same test is performed by different engineers.

There are people who succeed even if the version of mac Os is different, but the error in the attached screenshot occurs

Issue 2:
System info

Playwright Version: 1.32.1

Operating System: Windows 11

Browser: All

Other info: We leverage "Webpack" normally to package our test files but we are able to remove all of the "Webpackifying" except for the source map comment to repro this issue

Source code

Create two test files in the same directory:

// bad.playwright.ui.test.js
throw new Error("ERROR");
//# sourceMappingURL=bad.playwright.ui.test.js.map

// good.playwright.ui.test.js
import { test, expect } from "@playwright/test";

test("has title", async ({ page }) => {
await page.goto("https://playwright.dev/");
await expect(page).toHaveTitle(/Playwright/);
});

//package.json

{
"name": "repro",
"version": "1.0.0",
"description": "repro",
"main": "index.ts",
"module": "index.ts",
"private": true,
"sideEffects": false,
"license": "UNLICENSED",
"dependencies": {
"@playwright/test": "1.32.1",
"playwright": "1.32.1"
}
}

Steps

yarn install

yarn playwright test good.playwright.ui.test

Expected

I expect the good.playwright.ui.test.ts to execute and pass since it's the example test from Playwright

Actual

Error: ERROR

at bad.playwright.ui.test.js:1

> 1 | throw new Error("ERROR");
| ^
2 | //# sourceMappingURL=bad.playwright.ui.test.js.map
3 |

at Object.<anonymous> (C:\Users\...\Downloads\PortableCookie\bad.playwright.ui.test.js:1:7)

error Command failed with exit code 1.

For some reason the bad Playwright test gets executed, if I remove the //# sourceMappingURL=bad.playwright.ui.test.js.map comment it works fine .

This is very strange, I don't think this is by design.

For more context, we have "Jest" and "Playwright" test files side by side as we are migrating runners..
Issue 1:
A_mul_B!(B, A, B) replaces B with all zeros for the case where A is not small and square:

X = randn(3, 2)
Y = randn(3, 3)
Z = randn(3, 4)

M = randn(3, 3)
R = expm(M - M')

display(A_mul_B!(X, R, X))
display(A_mul_B!(Y, R, Y))
display(A_mul_B!(Z, R, Z))

outputs:

3x2 Array{Float64,2}:
0.0 0.0
0.0 0.0
0.0 0.0

3x3 Array{Float64,2}:
1.6548 0.742438 -1.50673
0.282773 -1.35856 -0.39896
0.700949 -1.27408 -0.846028

3x4 Array{Float64,2}:
0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0

Here's my version info:

Julia Version 0.4.0
Commit 0ff703b* (2015-10-08 06:20 UTC)
Platform Info:
System: Darwin (x86_64-apple-darwin13.4.0)
CPU: Intel(R) Core(TM) i7-3615QM CPU @ 2.30GHz
WORD_SIZE: 64
BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
LAPACK: libopenblas64_
LIBM: libopenlibm
LLVM: libLLVM-3.3

Issue 2:
It seems there is a bug in A_mul_B! when both matrices have dimension (1, 1)

a = fill(1.0, (1,1)) ; b = fill(1.0, (1,1)) ; A_mul_B!(a, a, b)
#> 1x1 Array{Float64,2}:
#> 0.0

I expected the results to return 1 but it returns 0. This happens both in 0.3.9 and 0.4.0-dev+5446
Issue 1:
by jackbox55:

What steps will reproduce the problem?
1. Download test case
2. extract test case
3. cd unmarshal_testcase && make && ./unmarshal_testcase

Expected: 9th and 16th item to be parsed like the others
Instead: the 9th and 17th item are empty strings

It doesn't appear to to effect further items? at least up to 24.

(hg log -l 1): changeset: 4024:1d9d926b1aa7

Attachments:

unmarshal_testcase.tar.gz (595 bytes)

Issue 2:
What does 'go version' print?

go version go1.3.2 darwin/amd64

What steps reproduce the problem?

1. hg pull && hg update
2. cd src
3. ./all.bash

What happened?

--- FAIL: TestParseInSydney (0.00 seconds)
format_test.go:201: ParseInLocation(Feb 01 2013 EST, Sydney) = 2013-02-01 00:00:00 +0000 EST, want 2013-02-01 00:00:00 +1100 AEDT

Please provide any additional information below.

I have Mac OS X Mavericks 10.9.5. I removed the original installation and tried to build
on a fresh clone but I got the same result.
Issue 1:
I upgraded my game to r70 (From r63) and noticed that my torch was not moving with the camera.

I position the target for the spot light in-front of the camera, but it now appears I must manually call

this.flashLight.target.updateMatrix() ;

to get the light to follow the new target position.

Was this an intended change? If so please close this issue, but this did work correctly in r63 and before.

James

Issue 2:
Bug: The changes to spotLight.target.position are not affecting.

Normal work with r68: http://jsfiddle.net/doexclusive/jhoe4ynr/

Bug with r69 and from dev branch: http://jsfiddle.net/doexclusive/6dhdbpw9/
Issue 1:
Describe your issue.

I'm inconsistently getting a RuntimeWarning from scipy, seemingly only after running a matplotlib plotting function. This isn't really a problem for me, but it is weird and I didn't see it referenced anywhere so I figured I would at least raise an issue.

I don't get the runtime error if I just run beta.pdf(xs, 1.2, 1.8) outside the plotting function. In general the error seems to appear inconsistently, and I'm not entirely sure how to characterise the conditions accurately.

This is possibly related to #13364, since this comment has the same error from some tests. I am also on an M1 mac, and using the miniforge version of scipy).

Reproducing Code Example

import matplotlib.pyplot as plt
from scipy.stats import beta
import numpy as np

xs = np.linspace(0, 1, 100)
plt.plot(xs, beta.pdf(xs, 1.2, 1.8))
beta.ppf(0.01, 1.2, 1.8)

Error message

/opt/homebrew/Caskroom/miniforge/base/envs/smokey/lib/python3.9/site-packages/scipy/stats/_continuous_distns.py:624: RuntimeWarning: overflow encountered in _beta_ppf
return _boost._beta_ppf(q, a, b)

SciPy/NumPy/Python version information

1.7.0 1.21.2 sys.version_info(major=3, minor=9, micro=6, releaselevel='final', serial=0)

Issue 2:
Describe your issue

Several statistical distribution methods emit warnings stemming from Boost. This issue tracks the status of all of them.

beta.ppf as reported here; should be fixed by boostorg/math#827

ncf as reported in gh-17101, should be fixed by boostorg/math#846

nct - I'm not sure that this has been reported separately yet. Is it caused by the same sort of thing?

ncx2 - Ditto.

gh-17272 will silence the failures in SciPy's tests temporarily, but as many of these marks as possible should be removed when gh-17207 merges.

Original Post

Describe your issue.

macOS CI is failing due to an overflow. I am still trying to reproduce locally.

NumPy was updated to 1.21.3, could be this or another dependency.

https://github.com/scipy/scipy/runs/3960228039

Reproducing Code Example

# from scipy/stats/tests/test_distributions.py:2878: in test_issue_12796
import numpy as np
from scipy import stats
q = 0.999995
a = np.array([ 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20])
b = np.array([99999, 99998, 99997, 99996, 99995, 99994, 99993, 99992, 99991, 99990, 99989, 99988, 99987, 99986, 99985, 99984, 99983, 99982, 99981])
stats.beta.ppf(q, a, b)

Error message

FAILED scipy/stats/tests/test_distributions.py::TestBeta::test_issue_12635 - ...
927
FAILED scipy/stats/tests/test_distributions.py::TestBeta::test_issue_12794 - ...
928
FAILED scipy/stats/tests/test_distributions.py::TestBeta::test_issue_12796 - ...
...
scipy/stats/_continuous_distns.py:626: in _ppf
916
return _boost._beta_ppf(q, a, b)
917
E RuntimeWarning: overflow encountered in _beta_ppf

SciPy/NumPy/Python version information

master on macOS/CI
Issue 1:
@bstrie So, this code raises an assertion in llvm when compiling with -g. Without -g it works fine.

#![feature(unboxed_closures)]

pub struct A;

impl A {
pub fn foo(&self, f: Box<Fn<(), ()> + 'static>) ->
Box<Fn<(), ()> + 'static> {
(box move |&:| {
(*f).call(())
})
}
}

Raised assertion is

rustc: /home/rustbuild/src/rust-buildbot/slave/nightly-linux/build/src/llvm/lib/IR/Instructions.cpp:1086: void llvm::StoreInst::AssertOK(): Assertion `getOperand(0)->getType() == cast<PointerType>(getOperand(1)->getType())->getElementType() && "Ptr must be a pointer to Val type!"' failed.
[1] 1800 abort (core dumped) rustc --crate-type lib test.rs -g

Edit: reduced code more

Issue 2:
rust version: rustc 0.12.0-pre-nightly (09abbbd 2014-09-11 00:05:41 +0000)

Assertion failed: (getOperand(0)->getType() == cast<PointerType>(getOperand(1)->getType())->getElementType() && "Ptr must be a pointer to Val type!"), function AssertOK, file /Users/rustbuild/src/rust-buildbot/slave/nightly-mac/build/src/llvm/lib/IR/Instructions.cpp, line 1085.

code to reproduce:

trait Tr: Clone {
fn clone_to_tobj(&self) -> Box<Tr> {
return box self.clone()
}
}

#[deriving(Clone)]
struct A;
impl Tr for A {
}

fn main() {
let a: Box<Tr> = box A;
}

but this compiles fine

trait Tr: Clone {
fn clone_to_tobj(&self) -> Box<Tr> {
box self.clone()
}
}

#[deriving(Clone)]
struct A;
impl Tr for A {
}

fn main() {
let a: Box<Tr> = box A;
}