WhereIsAI/github-issue-similarity huggingface dataset:
Issue 1:
Bug report

Describe the bug

webpack's config.resolve.alias works different for initial landing and navigation. It seems to be ignored when landing on a page but used as expected when navigating to a page (via next/link).

Edit: Difference is only observable for files inside node_modules/

To Reproduce

See https://github.com/eps1lon/next-webpack-alias#steps-to-reproduce

Expected behavior

aliases are used for initial landing as well. The idea for the implementation was taken from https://github.com/zeit/next.js/tree/canary/examples/with-absolute-imports

Screenshots

N/A

System information

OS: Ubuntu 18.04.2 LTS

Browser: Version 75.0.3770.80 (Official Build) (64-bit)

Version of Next.js: 8.1.0 and 9.0.2

Additional context

The use case in the constructed repository is simpler than our actual use case but I believe that config.resolve.alias working differently in some cases is the root cause.

We have docs and published packages living in a monorepo. Some of the npm packages used in our docs depend on our packages and want only a single version of our published packages in the docs bundle.

Debug notes

why is resolve.alias ignored?

.next/server/static/BUILD_ID/pages/* uses standard require instead of inlining those modules. The node_modules/ are included via node's require at which point webpack's resolve.alias will no longer be of effect. This may be an issue with chunking? Should probably just disable it for static/BUILD_ID/pages

fix iteration

removing externals from the webpack config fixes the issue. Need to find out why all node_modules should be externals.

Issue 2:
Now some of us ships NPM packages (specially components) written in ES2015 without transpiling them.

That's a pretty good thing specially if they are gonna used in a project like Next.js or CRA (which does transpiling). They offer benefits like:

No need to transpile before shipping to NPM

Get the benefit of Webpack 2's tree-shaking

But we can't do this now we exclude everything inside node_modules from babel transpiling.

So, here's the proposed solution.

We have an entry in next.config.js to include modules which needs to go through babel. See:

module.exports = {
transpileModules: [
"my-component",
"redux/src"
]
}
Issue 1:
Migrated issue, originally created by Anonymous

As it says. (I'm talking about the class-level column attributes that can be used like `.filter(User.name == "bob)" etc.)

I suppose there's a logical technical reason for this behaviour, but I think it's still rather unexpected from the perspective of the user. I spent a while tracking down some bugs I was having because of this.

Attachments: orm_attr_testcase.py

Issue 2:
Hello world,

we have a middle sized application that is using SQLAlchemy as the ORM. We started in 2011 with SQLAlchemy 0.6 when the declarative mapping style was still a new feature (and there was Elixir as an alternative).

Today we are still struggling with our mapping configuration. As our data model is mostly hierarchic (a version control system in a database) we have problems with circular dependencies.

With declarative this would be a non-issue given forward declarations. Also, IDE support would be much better (currently most column accesses are flagged as error given that the descriptors are added by calling the mapper on the existing class). Finally, to work around some issues we have classes that don't have any ORM related stuff in their home modules but a final foo_bar_mapper.py import attaches the mapper for multiple related classes.

This really sucks, therefore there have been multiple attempts to convert our code base to use the declarative extension. Some leaf classes have been converted but the core is still stuck.

We tried to go from the base classes downwards or from the leaf classes upward in conversion. But incremental conversion has been unsuccessful.

Therefore I would really like some guidance in the SQLAlchemy documentation about how to approach converting a non-simple code base from classical to declarative mapping. Are there any success stories to do this in an incremental way?

I'd like to help out here but so far all attempts were a dead end wrt. the hard parts.

Thanks and greetings,

Torsten
Issue 1:
Gildas Cuisinier opened SPR-6250 and commented

If you use the 'executor' element of the task namespace ( or simply do a new ExecutorBeanDefinitionParser() ), there are an error :

Exception in thread "main" java.lang.NoClassDefFoundError: edu/emory/mathcs/backport/java/util/concurrent/ThreadPoolExecutor$AbortPolicy

And, even with JDK 6 or 5. But they possess java.util.currurent directly, it should not be any errors.

Affects: 3.0 M4, 3.0 RC1

Issue Links:

#10829 Task namespace usage should not require concurrent backport JARs ("duplicates")

Issue 2:
Oliver Drotbohm opened SPR-7093 and commented

It would be cool to have ViewResolvers like InternalResourceViewResolver available to be declared via the MVC namespace. I imagine something similar to the <mvc:interceptors /> element already present, where you provide either predefined subelements or plain bean definitions. Although one could argue that the benefit is rather limited it completes the picture of configurable MVC components nicely, especially as the order can then be determined explicitly.

Maybe one can also ease the use of ContentNegotiatingViewResolver which is not the most approachable class in regards of configuration currently ;).

I'll probably provide a draft implementation as patch in a few days.

Sub-tasks:

#16605 Update documentation with MVC config view resolution examples

Issue Links:

#14167 Allow configuring view resolution through the MVC Java config ("is duplicated by")

#11222 Add mvc:annotation-driven Tiles Configuration ("supersedes")

Referenced from: commits dfcc1d7, 52f1be7, 10a4c2c, a26b1ef, 5e1a5c8, f54cee4, 92402e7, 5bc7937, cc7e8f5

2 votes, 7 watchers
Issue 1:
The space at the end here seems to be a bug:

julia> @sprintf("%.6g", 1.0)
"1 "

Issue 2:
The printf %g specifier will at times output an additional, unnecessary trailing space:

julia> @sprintf "%g" 1
"1 "
julia> @sprintf "%.8g" 23
"23 "
julia> @sprintf "%.2g" 23
"23"

CC @dfannius (#11941)
Issue 1:

Issue 2:
Challenge Waypoint: Say Hello to HTML Elements has an issue.

User Agent is: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36.

Please describe how to reproduce this issue, and include links to screenshots if possible.

My code:

<h1>Hello World</h1>

After I click run test. The output is not displayed on the right screen. I refreshed it multiple times, tried in different browser. Didn't help.

Please help me out of this. I am new to FCC.
Issue 1:
Scrapy docs recommends using PEP8 coding convention when writing code for inclusion in Scrapy, with the exception of 79 character line length rule . A quick run of pep8 utility shows me that there are several occurrence of PEP8 violation in the master branch. If given the nod from the maintainers, I would like to work on resolving this.

Issue 2:
PEP8 is recommended in the docs but is not strictly enforced.

Some violations:

Multiple imports in one line

Two blank lines not maintained between class definitions.

Unused imports

Lines longer than 80 characters everywhere

I believe we should strictly enforce PEP8 and also edit our CI configurations to test for these violations.

I would love to submit a patch for this if the idea sounds good to everyone.
Issue 1:
interpn returns nan when one of the dimensions of the grid has length 1, even if the inputs are perfectly valid. I know this is an edge case, but it's crucial to my program, and working around it requires ugly hacks.

Reproducing code example:

values = np.array([0.1,1,10]).reshape((1,3))
xi = np.array([[1, 2.2], [1, 3.2], [1, 3.8]])
print(scipy.interpolate.interpn(([1], [2,3,4]), values, xi))

Error message:

No error message, but returns array([nan, nan, nan])

Scipy/Numpy/Python version information:

1.1.0 1.15.1 sys.version_info(major=3, minor=7, micro=0, releaselevel='final', serial=0)

Issue 2:
The documentation for the RegularGridInterpolator states that if the bounds_error is set to False the fill_value is used. And if the fill_value is None, the values are extrapolated.

However, in the case of a dimensions with length 1, this doesn't seem to apply. Interpolating and extrapolating with 1 value is certainly an edge case. But based on the documentation i would expect (correct me if i'm wrong), that extrapolating or interpolating with 1 value will yield that same value.

The current implementation results in nan values. The difficulty is that if you cant be sure that all data dimensions are n>1, you have to check this and slice out those dimensions, and change the call to the Interpolator to exclude those parameters.

Reproducing code example:

This doesnt work:

from scipy.interpolate import RegularGridInterpolator
import numpy as np

def f(x,y):
return (y+1) * x

x = np.array([0, 5., 10])
y = np.array([0.])

data = f(*np.meshgrid(x,y, indexing='ij', sparse=True))
# data = array([[ 0.], [ 5.], [ 10.]])

my_interp = RegularGridInterpolator((x, y), data, fill_value=None, bounds_error=False)
my_interp((5.0, 0.))

output[4]: array(nan)

But adding a value to y makes it work:

y = np.array([0., 1.0])

data = f(*np.meshgrid(x,y, indexing='ij', sparse=True))
# data = array([[ 0., 0.], [ 5., 10.], [ 10., 20.]])

my_interp = RegularGridInterpolator((x, y), data, fill_value=None, bounds_error=False)
my_interp([5.0, 0.])

output[5]: array([ 5.])

Error message:

C:\Miniconda3\envs\py36\lib\site-packages\scipy\interpolate\interpolate.py:2467: RuntimeWarning: invalid value encountered in true_divide
(grid[i + 1] - grid[i]))

Scipy/Numpy/Python version information:

0.19.0 1.12.1 sys.version_info(major=3, minor=6, micro=1, releaselevel='final', serial=0)
Issue 1:
We're seeing it in pretty much all our serial and soak suites and is probably most common failure reason for our tests - including a number of P0 issues. Marking it as a P0 release blocker because of this, @thockin please remove if you think it shouldn't be one.

cc @kubernetes/test-infra-maintainers @derekwaynecarr @rmmh

Issue 2:
Quite a few tests flake with:

an error on the server has prevented the request from succeeding (put replicasets.extensions frontend-
88237173); Current resource version 493

This seems to indicate:

test should retry

that's a lot of flake on GKE

eg: #29149, #30156, #30352 (comment), pretty much all the failures in #31188, #31429 (comment), #31575, #31408
Issue 1:
The Deprecation Cop encourages users to create issues on repositories when deprecated features are being used. This may lead to a lot of duplicate issues.

Issue 2:
I'm not that sure about how to implement this, but plugins repos are getting flooded with duplicate issues reported by deprecation-cop (see, for example, thomaslindstrom/color-picker#49, thomaslindstrom/color-picker#48, thomaslindstrom/color-picker#50 and thomaslindstrom/color-picker#52).

May be querying GitHub's api to check if there already is an issue with the same subject would work - as the subjects are being auto-generated.
Issue 1:
My operation is hacktonish OSX 12.

Graphic is GTX960.

Installed Cuda 8 and CLT.

Python version is 2.7

Try the install from the source show error.

How can i fix it?

[ 4%] Linking CXX shared library libTHD.dylib

Undefined symbols for architecture x86_64:

"_state", referenced from:

_THDTensorDescriptor_newFromTHCudaDoubleTensor in TensorDescriptor.cpp.o

_THDTensorDescriptor_newFromTHCudaFloatTensor in TensorDescriptor.cpp.o

_THDTensorDescriptor_newFromTHCudaLongTensor in TensorDescriptor.cpp.o

_THDTensorDescriptor_newFromTHCudaIntTensor in TensorDescriptor.cpp.o

_THDTensorDescriptor_newFromTHCudaShortTensor in TensorDescriptor.cpp.o

_THDTensorDescriptor_newFromTHCudaCharTensor in TensorDescriptor.cpp.o

_THDTensorDescriptor_newFromTHCudaByteTensor in TensorDescriptor.cpp.o

...

ld: symbol(s) not found for architecture x86_64

clang: error: linker command failed with exit code 1 (use -v to see invocation)

make[2]: *** [libTHD.1.dylib] Error 1

make[1]: *** [CMakeFiles/THD.dir/all] Error 2

make: *** [all] Error 2

Issue 2:
I'm trying to build on Mac OS X, using

MACOSX_DEPLOYMENT_TARGET=10.9 CC=clang CXX=clang++ python3 setup.py install

And I'm running into this error:

[ 4%] Linking CXX shared library libTHD.dylib
ld: warning: directory not found for option '-L/usr/local/cuda/lib64'
Undefined symbols for architecture x86_64:
"_state", referenced from:
_THDTensorDescriptor_newFromTHCudaDoubleTensor in TensorDescriptor.cpp.o
_THDTensorDescriptor_newFromTHCudaFloatTensor in TensorDescriptor.cpp.o
_THDTensorDescriptor_newFromTHCudaLongTensor in TensorDescriptor.cpp.o
_THDTensorDescriptor_newFromTHCudaIntTensor in TensorDescriptor.cpp.o
_THDTensorDescriptor_newFromTHCudaShortTensor in TensorDescriptor.cpp.o
_THDTensorDescriptor_newFromTHCudaCharTensor in TensorDescriptor.cpp.o
_THDTensorDescriptor_newFromTHCudaByteTensor in TensorDescriptor.cpp.o
...
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [libTHD.1.dylib] Error 1
make[1]: *** [CMakeFiles/THD.dir/all] Error 2
make: *** [all] Error 2

Is this a bug or did I miss something?

Edit:

This might be relevant:

error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: no LC_RPATH load command with path: /usr/local/cuda/lib found in: ~/Desktop/pytorch/torch/lib/tmp_install/lib/libTHPP.1.dylib (for architecture x86_64), required for specified option "-delete_rpath /usr/local/cuda/lib"
Issue 1:
To recreate, add the following to config.yml:

twig:
globals:
foo: "@@bar"

Expected behaviour: Twig has a global variable named foo containing the string @bar.

Actual behaviour: ServiceNotFoundException: The service "twig" has a dependency on a non-existent service "@bar".

Environment tested on:

Symfony Standard Distribution 2.3.2

OS X 10.8.4

PHP 5.4.16

Issue 2:
Q
A

Bug report?
yes

Feature request?
no

BC Break report?
yes

RFC?
no

Symfony version
3.4.x

I have a project that depends on symfony/http-foundation. With 3.4.x-dev I'm getting some RuntimeErrors recently:

RuntimeException: Failed to set the session handler because headers have already been sent
by ".../vendor/phpunit/phpunit/src/Util/Printer.php" at line 110.

.../vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php:397
.../vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php:112
.../classes/Http/SessionProvider.php:128
.../vendor/autarky/container/classes/Factory/Factory.php:89
.../vendor/autarky/container/classes/Container.php:256
.../vendor/autarky/container/classes/Container.php:226
.../classes/Application.php:511
.../tests/unit/Session/SessionProviderTest.php:20

I tracked down the line to #23711 which was merged 2 days ago. If I remove the if headers_sent thing from setSaveHandler, my test runs fine again.

PHPUnit 5.7.22, symfony/http-foundation is at 0fe9b3d
Issue 1:
When creating the npz file, each array is written to a temporary file before adding to a zip archive: https://github.com/numpy/numpy/blob/master/numpy/lib/npyio.py#L601

This means that if /tmp is close to full, npz file creation will fail even when the actual target device has plenty of space. Even worse, it fails with a cryptic IOError message that doesn't point to /tmp.

Issue 2:
The size limit causes problems because savez goes through _savez, which creates a temporary file, then zips it. The size limit arises in recent Linux distros -- Ubuntu, Fedora, others -- that have started mounting tmpfs on /tmp. The tmpfs file system is essentially a ram disk and uses memory, which limits the size available. The advantage is spped and that SSD life is extended by not doing large numbers of small writes. On Linux is it probably better to use /var/tmp when writing big temporary files, but probably the easiest solution would be to put the temporary file in the user's directory. It gets deleted in any case.
Issue 1:
Challenge http://www.freecodecamp.com/challenges/waypoint-learn-how-script-tags-and-document-ready-work has an issue. Please describe how to reproduce it, and include links to screenshots if possible.

For this problem, I used the following code:

<script type="text/javascript">
$(document).ready(function(){
});</script>

The last 3 learning 'goals' will show checked and complete, but the first one: "Create a script element" will not for some reason. Not sure why. Thanks for your time

williamroberts643@hotmail.com

Issue 2:
Challenge http://www.freecodecamp.com/challenges/waypoint-learn-how-script-tags-and-document-ready-work has an issue. Please describe how to reproduce it, and include links to screenshots if possible.

The working code (the enter inside the anonymous function is optional)

<script>
$(document).ready(function(){

});
</script>

However there are several versions that do not satisfy the two last tests.

Fails test 3 (the space between [...]ready( and function)

<script>
$(document).ready( function(){

});
</script>

Fails test 4 (closing with });)

<script>
$(document).ready(function(){ });
</script>

Given that javascript is a language where whitespace is (mostly) insignificant.
Issue 1:
I'm a mathematician trying to plot several distributions (notably in this case Gamma and truncated Normal) in order to do some basic notebook-style exploration for different parameter choices. I first started with truncated normal, and after over half an hour, I still could not get scipy.stats.truncnorm to plot a simple normal distribution with mean = 18, standard distribution = 1.5, but truncated at 12 and 24. This includes after trying to follow the formula in the documentation for a and b - the behavior was always surprising, typically cutting the distribution in half and throwing it's support way beyond 24. I finally settled for just plotting a regular normal distribution when I couldn't get it to work.

Now I'm messing around with the gamma distribution, and the API is again surprising. I would suggest that in the spirit of "batteries included", the user shouldn't have to do the sort of computations described in http://docs.scipy.org/doc/scipy/reference/tutorial/stats.html, shape parameter section, just to use the gamma distribution with its two typical parameters (k and theta, or alpha and beta, it doesn't matter - they are easy to translate between) as described on wikipedia https://en.wikipedia.org/wiki/Gamma_distribution.

My request is that these standardized functions which lack a typical, full parameterization expose some kind of API allowing the user to specify all their typical parameters directly and get back a distribution with no further work required.

Issue 2:
scipy.stats defines univariate distributions in a standard form, with location and scale parameters. For some distributions, these do not agree with well with "common" parametrizations, which leads to confusion on various levels.

It might be good to at least identify the most problematic cases and add some text to their docstrings. Possibly there might be a way of adding some actual conversion code(?)

(cross-ref: #4533 (comment))

Likely suspects:

lognormal (gh-5075)

exponnorm (done in gh-4559)

nbinom

rice (gh-4605 for a specific issue and a suggestion for how to fix) EDIT: done in gh-4611
Issue 1:
Feature request

What is the expected behavior?

I need some webpack internals to use a Promise ponyfill instead of the global Promise.

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

I'm bundling a web app that runs on 3rd party websites and I must not pollute their global namespace with polyfills.

How should this be implemented in your opinion?

No idea, but I guess Promise is the only thing that needs a polyfill for IE11.

Are you willing to work on this yourself?

yes

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

I want to report a performance bug.

What is the current behavior?

In projects with a lot of chunks, a lot of time is spent on RemoveParentModulesPlugin.

The original report (angular/angular-cli#5618 (comment)) detailed a 1h build time for a non-production (no uglify etc) build.

The project uses Angular CLI and contains around ~2700 source files. This project has 376 chunks.

A similar sized project (https://github.com/filipesilva/angular-cli-test-repo) takes only a few minutes to build using the same options.

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

The project is closed source so I do not have a source, but the owner is available for some remote debugging (angular/angular-cli#5618 (comment)).

He provided CPU profiles for the first ~10m with node 8.4.0 (here) and with node 9.3.0 (here).

Both profiles show the majority of time being spent in RemoveParentModulesPlugin, specifically within the hasModule function. Also see the "Other information" bit at the end for a comparison with Webpack 4.

What is the expected behavior?

RemoveParentModulesPlugin is optimized to allow having a lot of chunks without a big performance hit.

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

Node.js 8.4.0, Webpack 3.10.0. Unknown browser/OS.

Other information.

I've been looking at Webpack 4 and thought maybe it could help since there are a lot of performance improvements there. The plugin in question has suffered some changes:

in webpack@3.10.0: https://github.com/webpack/webpack/blob/b545b519b2024e3f8be3041385bd326bf5d24449/lib/optimize/RemoveParentModulesPlugin.js

in webpack@4.0.0-alpha.3: https://github.com/webpack/webpack/blob/9334fd8547831ded7f11e05319616a72ea0b4698/lib/optimize/RemoveParentModulesPlugin.js

It looks like there's a fair bit of optimizations changes there. But I'm not sure if the bottleneck has changed.

There's two places where time is being spent on the CPU profile:

a has call inside the hasModule function:

a filter call inside the hasModule function:

This function hasn't changed though so I don't think it would speed up in this case.

/cc @pleerock @TheLarkInn
Issue 1:
System info

"@playwright/experimental-ct-vue": "^1.31.2"

Operating System: All

Browser: All

Source code

Creating a Typescript test file ... I need to mock some test objects that I will use as props in my test... I found that when I use < in normal Typescript (that is not TSX or JSX) that my test file will not get parsed and processed correctly.

import { test, expect } from '@playwright/experimental-ct-vue';

interface MyType {
test: string;
}

const myVar = <MyType>{
test: 'Hello',
};

test('hello', async ({ page, mount }) => {
console.log(myVar);
});

Steps

Run or debug the test

Expected

No Error

Actual

SyntaxError: Unexpected token, expected "}" (8:6)

Personally I never use TSX or JSX... I looked but I couldn't find an option... is there a way to just turn that kind of parsing off?

Thanks!

Issue 2:
System info

Playwright Version: [1.32.3]

Operating System: [macOS Ventura 13.3.1]

Browser: [All]

Other info:

Steps

Run some tests in Playwright

Now run test report through the following command:npx playwright show-report

We get the test result in the browser

Now select the Skipped option in the test result

Now in the search box of the test result, write: s:flaky s:passed s:passed s:passed

We get all the test specs in the report

Expected

Searching with multiple term should not show all test specs

Actual

Searching shows all the spec results in test report

Attachments