WhereIsAI/github-issue-similarity huggingface dataset:
Issue 1:
Methods in Dates have a habit of causing ambiguities for packages that define new AbstractArray types, e.g., JuliaArrays/StaticArrays.jl#18 where nearly half of the ambiguities are due to Dates-related methods. The problem, in a nutshell, is that Dates specializes several AbstractArray methods on the element type whereas packages tend to specialize on the container type.

Getting rid of such ambiguity warnings, back in the days of 0.4-dev, was the final trigger for introducing promote_op (#12292 and #12370); now that we've gotten rid of it, it would be lovely to see whether we can reduce the ambiguity-causing footprint of Dates even further.

Now that ambiguities are silent until called this is not as crucial as it once was, but ideally we'd like to move to a world where packages can include detect_ambiguities as part of their tests.

Issue 2:
Dates redefines +(::Array{Date}, Date...) = .+, meaning that array + scalar doesn't throw an error.

julia/stdlib/Dates/src/arithmetic.jl

Line 94
in
f8d82cc

(-)(x::AbstractArray{T}, y::T) where {T<:TimeType} = x .- y

This should probably be deprecated for consistency.
Issue 1:
Bug report

What is the current behavior?

Optional chaining operators being removed which causes a runtime errors.

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

env.js

export const env = {}

index.js

import { env } from './env';
console.log(env.foo?.bar)

config

const { resolve } = require("path");

module.exports = {
devtool: false,
mode: "development",
entry: "./index.js",
target: ["web", "es2020"],
node: false,
};

Output

/*!******************!*\
!*** ./index.js ***!
\******************/
__webpack_require__.r(__webpack_exports__);
/* harmony import */ var _env__WEBPACK_IMPORTED_MODULE_0__ = __webpack_require__(/*! ./env */ "./env.js");

console.log(_env__WEBPACK_IMPORTED_MODULE_0__.env.foo.bar)
})();

What is the expected behavior?

Operator is retained.

Other relevant information:

webpack version: 5.65.0

Node.js version: 14.18.1

Operating System: darwin x64

Additional tools:

Issue 2:
Bug report

What is the current behavior?

Webpack incorrectly compiles x?.value to (something).value when x is something that's been imported.

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

webpack.config.js:

module.exports = {
entry: "./index.js",
target: "web",
};

index.js:

import x from './x.js';
console.log(`optional value is: ${x?.value}`);

x.js:

export default undefined;

Produces dist/main.js:

(()=>{"use strict";console.log(`optional value is: ${(void 0).value}`)})();

which leads to TypeError: Cannot read property 'value' of undefined at runtime.

What is the expected behavior?

The ? should be retained or converted to a ternary operator.

When import x from './x.js'; is removed and replaced with const x = (() => void console)(); (something complicated enough that webpack doesn't completely constant-fold it), the output is:

(()=>{const o=void console;console.log(`optional value is: ${o?.value}`)})();

which is as expected (the ? is retained).

Other relevant information:

webpack version: latest, 5.27.2

Node.js version: v15.9.0

Operating System: macOS 11.2.2
Issue 1:
Maybe its time to support stylus https://github.com/LearnBoost/stylus

Many users like me use stylus in projects and they want to have bootstrap stylus in project

Everyone know why stylus is much better of less

You maybe use less only for simple mixins/variables But developers ...

We import bootstrap.styl and change config and ... and compile prefix free with nib and ....

Ee have 3 choose

Complete rewrite less files in stylus and don't support less any more, its can be fast as posible, there is good repo in github that converted bootstrap to stylus.

Support stylus too, maybe new brach or something else and continue backward compatibility.

Create new project in twitter org and developers can update it as a separate process.

and you don't need to think about it, we keep it update.

and some day you see it will be much popular.

@fat @mdo I hope you more thinking about this request before close immediately.

Issue 2:
Carousel does not start sliding to the next one after 5 seconds until after I click to the next slide. Only then does the timer start. What am I missing?
Issue 1:
I often find myself doing some quick-and-dirty plotting, and wishing there was a simple, one-step, easy-to-remember way to set the default figsize for all matplotlib plots.

I imagine something very light-weight like sns.set(figsize=(2, 4)) or sns.set_figsize(2, 4).

iPython actually has this already as IPython.core.pylabtools.figsize(sizex, sizey).

I can submit a pull request pretty easily, but I wanted to ask you opinion first.

Issue 2:
sns.set_theme(style="ticks")

sns.pairplot(df)

AttributeError Traceback (most recent call last)

in

----> 1 sns.set_theme(style="ticks")

2 sns.pairplot(df)

AttributeError: module 'seaborn' has no attribute 'set_theme'

I have got this error while using seaborn.
Issue 1:
Some folders/projects, even in safe mode, just search forever and ever. Other folders work just fine since

Started happening with 0.191

What can I provide for more info?

Issue 2:
Searching a folder that contains some broken symlinks:

ENOENT: no such file or directory, stat '/Users/kevin/github/atom/node_modules/temp/node_modules/.bin/rimraf'
at Error (native)
at fs.statSync (fs.js:846:18)
at Object.fs.statSync (ATOM_SHELL_ASAR.js:206:16)
at Object.realpathSync (fs.js:1456:12)
at Object.fs.realpathSync (ATOM_SHELL_ASAR.js:243:29)
at PathScanner.module.exports.PathScanner.stat (/Applications/Atom.app/Contents/Resources/app/node_modules/scandal/lib/path-scanner.js:89:16)
at PathScanner.module.exports.PathScanner.processFile (/Applications/Atom.app/Contents/Resources/app/node_modules/scandal/lib/path-scanner.js:74:19)
at /Applications/Atom.app/Contents/Resources/app/node_modules/scandal/lib/path-scanner.js:52:17
at FSReqWrap.oncomplete (fs.js:77:15)
Issue 1:
Description of the problem

ThreeJs ThreeMF loader is blocking the UI while upzipping the 3MF file.

try {
zip = new JSZip( data ); // eslint-disable-line no-undef
} catch ( e ) {
if ( e instanceof ReferenceError ) {
console.error( 'THREE.3MFLoader: jszip missing and file is compressed.' );
return null;
}
}

According the the JSZip documenation I assume it would be better to unzip the container asynchronously not to block the UI.

Three.js version

[x ] Dev

r120

...

Browser

All of them

Chrome

Firefox

Internet Explorer

OS

All of them

Windows

macOS

Linux

Android

iOS

Hardware Requirements (graphics card, VR Device, ...)

Issue 2:
As discussed in #11301 one of the main problems that we have in WebVR, although is annoying in non-VR experiences too, is blocking the main thread while loading assets.

With the recent implementation on link traversal in the browser non-blocking loading is a must to ensure a satisfying user experience. If you jump from one page to another and the target page start to load assets blocking the mainthread, it will block the render function so no frames will be submitted to the headset and after a small period of grace the browser will kick us out from VR and it will require the user to take out the headset, click enter VR again (user gesture required to do so) and go back to the experience.

Currently we can see two implementations of non-blocking loading of OBJ files:

(1) Using webworkers to parse the obj file and then return the data back to the main thread WWOBJLoader:

Here the parsing is done concurrently and you could have several workers at the same time. The main drawback is that once you've loaded the data you need to send the payload back to the mainthread to reconstruct the THREE objects instances and that part could block the main thread:

https://github.com/kaisalmen/WWOBJLoader/blob/master/src/loaders/WWOBJLoader2.js#L312-L423

(2) Mainthread promise with deferred parsing using setTimeOut:Oculus ReactVR: This loader keeps reading lines using small time slots to prevent blocking the main thread by calling setTimeout: https://github.com/facebook/react-vr/blob/master/ReactVR/js/Loaders/WavefrontOBJ/OBJParser.js#L281-L298

With this approach the loading will be slower as we're just parsing some lines on each time slot, but the advantage is that once the parsing is completed, we'll have the THREE objects ready to use without any additional overhead.

Both has their pros and cons and I'm honestly not an expert of webworkers to evalute that implementation but It's an interesting discussion that ideally would lead to a generic module that could be used to port the loaders to a non-blocking version.

Any suggestions?

/cc @mikearmstrong001 @kaisalmen @delapuente @spite
Issue 1:
It would be nice if I could color-code folders and files, just like you can in macOS. How about a powertoy for this?

Issue 2:
ℹ Computer information

Windows build number: [run "winver"] 20175

PowerToys version: 0.20.0

PowerToy module: n/a

📝 Provide detailed reproduction steps (if any)

After updating, the installer asked if I wanted to restart Windows Explorer.

I picked Yes, and Explorer closed but it did not start again.

✔️ Expected result

Explorer would relaunch itself.

❌ Actual result

Explorer closed (taskbar/desktop). Launching task manager, I discovered that a folder window appeared to still be open (it was minimized when Explorer closed, and was not visible on my desktop). I used Task Manager to close it, then manually ran explorer.exe to relaunch the taskbar process.
Issue 1:
~/jax$ python3 tests/host_callback_test.py fails with:

[ RUN ] CallJaxTest.test_jax_grad
2021-04-15 00:16:53.333864: E external/org_tensorflow/tensorflow/compiler/xla/status_macros.cc:56] Internal: RET_CHECK failure (external/org_tensorflow/tensorflow/compiler/xla/service/gpu/outfeed_thunk.cc:80) ShapeUtil::Equal(source_slices_[index].shape, output_shape) Mismatch between outfeed output buffer shape u32[2]{0} and outfeed source buffer shape f32[]

Mismatch between outfeed output buffer shape u32[2]{0} and outfeed source buffer shape f32[]

All test cases seem to fail this way. It's a little hard to tell because after a few test cases run and fail with this, the test will just hang until you kill it (probably because computations are blocked waiting for infeed).

I haven't dug into this at all, but for now I'm planning to disable all of host_callback_test on multi-GPU platforms in order to make our test suite runnable on multi-GPU (since right now it hangs).

Issue 2:
Please:

Check for duplicate requests.

Describe your goal, and if possible provide a code snippet with a motivating example.

Hi all,

Whilst working on a recent project I realised that scipy.stats.multinomial doesn't have a jax.scipy implementation.

I thought it'd be worthwhile to implement as well as a decent first contribution.

I think I'm largely done on the work here but thought to make an issue before making a PR.

Is there any reason this hasn't been implemented thus far?
Issue 1:
Here is my interceptor

axios.interceptors.response.use((response) => {
return response
}, function (error) {
// Do something with response error
if (error.response.status === 401) {
auth.logout()
router.replace('/login')
}

return Promise.reject(error)
})

During this call which returns a 401, the interceptor is not triggered. I can catch the reject() where I called method.

axios.get('/api/employees/')
.then(response => {
commit('SET_EMPLOYEE_LIST', response.data)
resolve(response)
})
.catch(err => reject(err))

axios version: v0.16.2

Environment: chrome 59, windows 10

Issue 2:
#### Summary

I searched through all the issues and double checked the ones referenced in #812 but my problem seems to be different.

My problem is that creating an instance does not copy over or use the interceptors added to the global Axios.

import Axios from "axios";

Axios.interceptors.request.use((config) => {
console.log("Global Interceptor")
return config;
});

const axiosInstance = () => {
let instance = Axios.create();
console.log(Axios.interceptors.request); // Has 1
console.log(instance.interceptors.request); // Has 0
return instance;
}

axiosInstance().post("/test", { testing: "data" }); // Doesn't output "Global Interceptor"
Axios.post("/test", { testing: "data" }); // Outputs "Global Interceptor"

#### Context

Axios version: 0.16.2

Environment: Webpack 2.6.1, Chrome Canary 61.0.3147.0, Mac OS X
Issue 1:
I have searched the issues of this repository and believe that this is not a duplicate.

But I think that this issue #3319 can be related and maybe solve the problem.

Current Behavior

Based on what I have:

I have a folder estructure working with yarn workspaces with multiple workspaces like:

|-- packages

|-- .babelrc

..

..

..

|----- shared

|-------- components // named @org/components

|-------- utils // named @org/utils

|----- web

|------- app // named @org/mainApp

|--------- src

|------------ next.config.js

|------------ .babelrc

|----------- pages

....

...

|------- otherPackage // named @org/otherPackage

Where app folder is a next.js app that import code from the other components.

The dev mode of next is run from root folder using npm run web that call next packages/web/app/src to allow next to found the pages folder (and next.config.js and .babelrc )

After run and start compiling, and get the "success" mensaje, some errors arise in the console on web loaded.

Errors referring to the use of type and import keywords in the files that comes from the imported modules (modules named as @org/ that lives inside the same repo but (maybe) in other workspaces).

This means that next webpack configuration is not transpiling the imported files. (the babel-plugin-transform-flow-strip-types is installed in packages/web/app and also in the root folder)

Expected Behavior

Should not have any error with the imported files and works as expected (no problem with es6 and flow).

Steps to Reproduce (for bugs)

Create a project with yarn workspaces activated

Create at least two workspaces

Create a package inside a workspace that run with next

Import file from other workspaces

Context

Your Environment

Tech
Version

next
4.2.3

node
9.3.0

OS
macosx

browser
safari/chrome

yarn
1.3.2

Issue 2:
After configuring next with a webpack function it seems that the function gets called twice during all builds which results in ForkTsCheckerWebpackPlugin running lint/ts checks twice (in my setup).

I have searched the issues of this repository and believe that this is not a duplicate.

Steps to Reproduce (for bugs)

Create a next config with a webpack function which console.logs something

Run the app and see the message log twice.

Your Environment

Tech
Version

next
canary

node
6.11.5

OS
macosx
Issue 1:
interface OverloadedMethod {
(a:string): Object;
(a:number): void;
}

const bar : string|number = 0;
const foo : OverloadedMethod = null;
foo(bar) // red squiggles here under bar: Argument of type 'string | number' is not assignable to 'string'. Type 'string | number' is not assignable to 'number'

This is a minimal example of where typescript complains that bar cannot unify with any of the individual methods on foo, even though it could reasonable deduce that since there's only one implementation of said method, that (a:string|number) : Object|void is a perfectly cromulent alternative.

Looks like this is a consequence of #5766 and it rears it head when dealing w/ Express routing's d.ts.

Issue 2:
The type guard instanceof Array does not seem to recognize the type of the interface IMessage.

interface IMessage {
name: string;
}

function itemFn(pipIn: IMessage[]) {
return pipIn;
}

function baseFn(pipIn: IMessage) {
return [pipIn];
}

function main(pipIn: IMessage|IMessage[]) {
if (pipIn instanceof Array) {
return itemFn(pipIn);
} else {
return baseFn(pipIn);
}
}

The compiler outputs the error message:

unions6.ts(19,23): error TS2345: Argument of type 'IMessage | IMessage[]' is not assignable to parameter of type 'IMessage'.
Type 'IMessage[]' is not assignable to type 'IMessage'.

I'm using master of today.

Thanks
Issue 1:
Following up on this Discourse post. According to @stevengj, this issue might be solved by the resolution this Yggdrasil issue.

I am running into an odd error when using Julia 1.7.0 on my 2017 Mac Book Pro (Intel i7) on Mac OS 12.01. In particular, executing

n = 1000;
A = randn(Float32, n, n);
inv(A)
ERROR: StackOverflowError:

With no further stack trace printed afterwards.

The same error occurs with ComplexF32 and ComplexF64 types, but not Float64.

According to @carstenbauer, the issue is also present in 1.6.4, 1.7.0.rc-2, 1.7.0.rc-3, 1.7.0.

1.6.3 and the current master branch do not exhibit the issue.

More detailed info: On my machine, inv works for all element types up to a certain size. For Float32, the failure size is 514 by 514 and for the complex types, it’s 258 by 258. Below these cutoffs, everything works as usual.

Issue 2:
On macos, using version 1.7.0-rc2, julia just shows StackOverflowError with no other info when taking the matrix exp with a ~ 300x300 complex-valued matrix. Minimum example:

using LinearAlgebra

n = 300
m = rand(ComplexF64, n, n);
mex = exp(m);

Alro ran with --startup-file=no to make sure it's not some clash with other packages.

my versioninfo():

Julia Version 1.7.0-rc2
Commit f23fc0d27a (2021-10-20 12:45 UTC)
Platform Info:
OS: macOS (x86_64-apple-darwin19.5.0)
CPU: Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz
WORD_SIZE: 64
LIBM: libopenlibm
LLVM: libLLVM-12.0.1 (ORCJIT, skylake)
Environment:
JULIA_MATHLINK = /Applications/Mathematica.app/Contents/Frameworks/mathlink.framework
JULIA_MATHKERNEL = /Applications/Mathematica.app/Contents/MacOS/MathKernel

Same code runs fine with Version 1.6.3 (2021-09-23).

Hardware: Macbook pro (intel) with 16 GB ram, activity monitor shows low memory usage.

In addition, the same code sometimes gives ERROR: LoadError: ReadOnlyMemoryError(), not sure how to reproduce that one...

Thanks!
Issue 1:
I have a large mesh, which I intend to render without smooth shading. As such, there is no point calculating vertex normals. Normally, this is ok, since I can do:

geom.computeFaceNormals();
if(smoothShading) geom.computeVertexNormals();

However, when I do geometry.computeMorphNormals(), it does both steps at once. Could this be sensibly split into two distinct steps?

At present, I've just hacked in an impaired version of THREE.Geometry.prototype.computeMorphNormals that doesn't touch vertex normals, but I'm not keen on the code duplication:

// Calculate only face normals, not morph normals, which is much faster
THREE.Geometry.prototype.computeMorphFaceNormals = function () {

var i, il, f, fl, face;

// save original normals
// - create temp variables on first access
// otherwise just copy (for faster repeated calls)

for ( f = 0, fl = this.faces.length; f < fl; f ++ ) {

face = this.faces[ f ];

if ( ! face.__originalFaceNormal ) {

face.__originalFaceNormal = face.normal.clone();

} else {

face.__originalFaceNormal.copy( face.normal );

}

}

// use temp geometry to compute face and vertex normals for each morph

var tmpGeo = new THREE.Geometry();
tmpGeo.faces = this.faces;

for ( i = 0, il = this.morphTargets.length; i < il; i ++ ) {

// create on first access

if ( ! this.morphNormals[ i ] ) {

this.morphNormals[ i ] = {};
this.morphNormals[ i ].faceNormals = [];

var dstNormalsFace = this.morphNormals[ i ].faceNormals;

var faceNormal;

for ( f = 0, fl = this.faces.length; f < fl; f ++ ) {

face = this.faces[ f ];

faceNormal = new THREE.Vector3();
dstNormalsFace.push( faceNormal );

}

}

var morphNormals = this.morphNormals[ i ];

// set vertices to morph target

tmpGeo.vertices = this.morphTargets[ i ].vertices;

// compute morph normals

tmpGeo.computeFaceNormals();

// store morph normals

var faceNormal;

for ( f = 0, fl = this.faces.length; f < fl; f ++ ) {

face = this.faces[ f ];

faceNormal = morphNormals.faceNormals[ f ];

faceNormal.copy( face.normal );

}

}

// restore original normals

for ( f = 0, fl = this.faces.length; f < fl; f ++ ) {

face = this.faces[ f ];

face.normal = face.__originalFaceNormal;

}

}

Issue 2:
FYI I'm working on a parasolid exporter (x_t to begin with). Just posting an issue to avoid duplicating effort or in case anyone wants to discuss / collaborate. I expect to have a PR ready in a few weeks.
Issue 1:
Describe the bug

I am not sure if this a gltf bug or a three js bug but when exporting a skinned mesh with an armature with a specific scale the bounding box will not work correctly, for example, I have an object with an armature of scale 0.018 for all axes and a mesh child with a scale of 1; what happens when I import it to threejs/editor is the bounding box take the scale of the armature, as the image below:

and, via coding, when I try to get the object size by:

let measurementBox = new THREE.Box3().setFromObject( this.threeJsObject ); measurementBox.getSize(this.objectSize);

the result is the armature mesh child size (after scaling) multiplied by the armature scale again!

This means if the x dimension of a mesh after being scaled by an armature is 100 with a scale of 0.5 in the armature (actual size of the mesh is 200 then), the bounding box x size will be 50 and not 100, it will scale too after the mesh!

To Reproduce

here is the file that I am using, the armature scale is 0.018 and the bounding box is 0.018 of the actual size of the mesh rather than being 100% of the actual size of the mesh.

https://drive.google.com/file/d/14Iq0pUmHt1uE3F0brMIVfFL5taV2MEZs/view?usp=sharing

Steps to reproduce the behavior:

just import it in threejs/editor and check the bounding box!

Expected behavior

the bounding box surrounds all the mesh and not being multiplied with the armature scale, it should be like the image below:

Platform:

Device: Desktop

OS: Linux, ubuntu

Browser: All

Three.js version: r120

Issue 2:
Description of the problem

Hi,

I've been playing around with a model for a while, and noticed that if I load it in three.js and zoom closely to the head, it disappears, along with the helmet.

I'm sure it's not the clipping field, because they disappear suddenly, from one frame to another.

I'm also sure this bug is not limited to @donmccurdy 's gltf viewer ( https://gltf-viewer.donmccurdy.com/ ), as I tested it in a project made from scratch recently, and the bug appears there, too.

It works flawlessly in the babylon sandbox: http://sandbox.babylonjs.com/, so I believe this has something to do with three.js.

Also, I think it has something to do with the fact that the mesh is skinned. If I apply the armature pose in blender before exporting, then the model appears correctly in three.js as well.

I attach a zip with 2 model files, one with skin, the other one with the applied pose:

player.zip

Three.js:

Babylon.js:

Three.js version

Dev

r94

...

Browser

All of them

Chrome

Firefox

Internet Explorer

OS

All of them

Windows

macOS

Linux

Android

iOS
Issue 1:
With the latest typescript-material-react example the build fails. It fails because of color="secondary" parameter.

<Button raised color="secondary" onClick={this.handleClick}>
Super Secret Password
</Button>

Error:

create-react-app-with-typescript/src/pages/index.tsx
(61,17): Type '{ raised: true; color: "secondary"; onClick: () => void; children: string; }' is not assignable to type 'IntrinsicAttributes & ButtonProps & { children?: ReactNode; }'.
Type '{ raised: true; color: "secondary"; onClick: () => void; children: string; }' is not assignable to type 'ButtonProps'.
Types of property 'color' are incompatible.
Type '"secondary"' is not assignable to type '"default" | "inherit" | "primary" | "accent" | "contrast" | undefined'.

Working:

<Button raised onClick={this.handleClick}>
Super Secret Password
</Button>

I have searched the issues of this repository and believe that this is not a duplicate.

Issue 2:
is it possible to use material-ui with React 0.14 and ES6?

if yes please post a little gist/example

thanks.