WhereIsAI/github-issue-similarity huggingface dataset:
Issue 1:
[x ] bug report => search github for a similar issue or PR before submitting

[ ] feature request

[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

I have separated my application into `js` directory where all my generated `.js` files are
and an `app` directory where I keep my `.ts`, `.html` and `.css` files together.

For the AoT compilation I use the `tsconfig.aot.json`

{
"compilerOptions": {
"target": "es2015",
"module": "es2015",
"moduleResolution": "node",
"declaration": false,
"removeComments": true,
"noLib": false,
"emitDecoratorMetadata": true,
"experimentalDecorators": true,
"lib": ["es6", "es2015", "dom"],
"sourceMap": true,
"pretty": true,
"allowUnreachableCode": false,
"allowUnusedLabels": false,
"noImplicitAny": true,
"noImplicitReturns": true,
"noImplicitUseStrict": false,
"noFallthroughCasesInSwitch": true,
"outDir": "js",
"typeRoots": [
"./node_modules/@types",
"./node_modules"
],
"types": [
]
},
"files": [
"app/main.ts"
],
"exclude": [
"node_modules",
"js",
"app"
],
"compileOnSave": false
}

and the script: `"ngc": "ngc -p tsconfig.aot.json && npm run copy \"app/*\" \"compiled\" "`

Because I have seprated my app into `js` and `app` folders I have to use it like this:

@Component({
moduleId: module.id.replace("/js/", "/app/"),
selector: 'escl-mainbar',
templateUrl: './mainbar.component.html'
})
export class MainbarComponent {

But when I try to run the script it gives me this error:

> angular-quickstart@1.0.0 ngc C:\dev_escal\project\escal\ui\src\main\webapp
> ngc -p tsconfig.aot.json && npm run copy "app/*" "compiled"

Error encountered resolving symbol values statically. Calling function 'module', function calls are not supported.
Consider replacing the function or lambda with a reference to an exported function,
resolving symbol MainbarComponent in C:/dev_escal/project/escal/ui/src/main/webapp/app/mainbar/mainbar.component.ts, resolving symbol
MainbarComponent in C:/dev_escal/project/escal/ui/src/main/webapp/app/mainbar/mainbar.component.ts

I tried with using:

export function moduleId() {
return module.id.replace("/js/", "/app/");
}

@Component({
moduleId: moduleId(),
selector: 'escl-mainbar',
templateUrl: './mainbar.component.html'
})
export class MainbarComponent { }

but that still gives me Error encountered resolving symbol values statically....

I'm using `@angular/comiler-clie` and the other stuff of version 2.4.6 and typescript version is 2.1.5.

Any idea where, the problem is or if it is really a bug.

Issue 2:
JIT path use relative to wwwroot but AoT use relative path

for JIT: templateUrl:'app/app.html'

for AoT: templateUrl:'app.html'

this bothers me everytime I change from or to AoT compile
Issue 1:
Bug report

Bug summary

The axes of a subplot_mosaic show up in a random order in fig.axes (likely due to the use of a set for uniquification in _identify_keys_and_nested).

Code for reproduction

for _ in $(seq 10); do python -c 'from pylab import *; fig, axs = subplot_mosaic("ab"); print(fig.axes.index(axs["a"]))'; done

Actual outcome

1
0
1
1
1
0
0
0
0
1

Expected outcome

Axes should be added in a consistent order. I guess a reasonable one would be as if iterating the spec in C order (dropping duplicates).

Not release critical (especially as the order was not fixed, so fixing an order is not a backcompat break), but would be nice to get this sorted out before the API moves out of being experimental.

Matplotlib version

Operating system: linux

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

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

Python version: 39

Jupyter version (if applicable):

Other libraries:

Note: the simple solution of replacing unique_ids = set() by unique_ids = cbook._OrderedSet() is good enough for the non-nested case, but doesn't handle nested layouts such as subplot_mosaic([["a", [["b1", "b2"], ["b3", "b4"]]], ["c", "d"]]) because currently the nested submosaic is always added after all the non-nested axes.

Issue 2:
Consider the following example:

import matplotlib.pyplot as plt
import numpy as np

fig,axes = plt.subplots()
line_A = axes.plot( np.random.random(10), label="foo" )[0]
line_B = axes.plot( np.random.random(10), label="bar" )[0]
line_C = axes.plot( np.random.random(10), label="quz" )[0]
lines = [line_A,line_B]

axes.legend( lines, [line.get_label() for line in lines] )

The last line needs to be this complicated since I get unwanted internal information if I just use axes.legend(lines). However, this seems like something legend could do automatically: If I do not specify the handles for the legend, it extracts them from whatever I give it automatically.

This may be a duplicate of this request, but I am not sure.
Issue 1:
I have searched the issues of this repository and believe that this is not a duplicate.

I have checked the FAQ of this repository and believe that this is not a duplicate.

Environment

Dubbo version: latest

Step to reproduce this issue

export a rest service DemoService with a url: rest://127.0.0.1:4444/test/

then we will get a real rest service with rest://127.0.0.1:4444/test/DemoService

but when we export a rest service DemoService with a url: rest://127.0.0.1:4444/test

then we will get a real rest service with rest://127.0.0.1:4444/DemoService

Those are the different results, in the second case the context path test is missing.

So users use explicit exporter and invoker to call rest services, they would feel puzzled.

We should fix it by modifying getContextPath method.

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

I have checked the FAQ of this repository and believe that this is not a duplicate.

Environment

Dubbo version: 2.7.4-SNAPSHOT

Operating System version: win7

Java version: 8

Steps to reproduce this issue

使用springboot，在application.yml无法使用

dubbo:

metircs:

port: 20880

protocol: dubbo
Issue 1:
Current behavior:

Switch to "latest" version of docs

click on the docs link at the top of the page (for example, to switch between the manual and standard library docs

The docs pages revert back to 1.0

Expected behavior:

Once the docs are switched to latest, all links should only refer to latest . And vice-versa

All pages to show somewhere which version of the documentation is being viewed. Currently it is only seen in the URL

Issue 2:
Is there a better way to show the latest and release-0.1 versions of the manual? People cannot guess that the readthedocs icon at the bottom is a clickable drawer that is closed by default. The interface is not easy to use - one frequently has to try a couple of times.

Is there a way to make it so that the default behaviour is that the drawer is open instead of closed, so that the different versions of the manual are all visible when one visits docs.julialang.org?
Issue 1:
Description of what I'm doing:

I'm porting the hello world app on the Quick Start page to Clojurescript

https://github.com/atom/atom-shell/blob/master/docs/tutorial/quick-start.md

Here is my port of main.js to Clojurescript:

https://gist.github.com/frankhale/8fe873601fb4212cdc87

I have the requisite files in my project and it works fine using the provided main.js. When I use my Clojurescript compiled main.js atom-shell tells me my app is not valid. The project structure is exactly as it should be and all I'm replacing is the Javascript version of main.js with a Clojurescript compiled main.js from my translation of the Javascript.

Question for atom-shell developers:

Is there a way to debug what is going on when atom-shell tries to start my application? I'm running atom.exe and dragging my app folder into the window. I've opened the dev tools but no errors are reported. All I get is a message saying that my app is not valid.

Question for somebody that may be able to help debug the Clojurescript:

If anyone knows Clojurescript would you mind taking a look at my Gist to see if I've made any crazy mistakes? I've been trying to get this working for several hours. The code looks straightforward enough and doesn't look like it should be a problem porting.

Here is a repo of my project for those that may want to have a look:

https://github.com/frankhale/hello-atom-shell

Issue 2:
Even when launching from the command line, any JS error occuring in main.js is internally trapped, preventing debugging. Instead, you get the following:

The error is not reported in the console.
Issue 1:
hello! i have the problem when i use the node module "create vite@latest" on Windows OS, with deno it asks me for certain permissions and when i start in the command terminal it does not allow me to select the correct tool, it only stays stuck in the vanilla option, is there any way to solve this? i want to select the react option but it does not allow me, is it a problem of deno or the problem is specific to vite?

another detail is that to use the create vite@latest package as indicated in the official vite documentation is with a blank space between the words, why with deno you have to put a hyphen as in the following form? npm:create-vite@latest

Issue 2:
Is supporting Vite on Deno's radar?

Although many Node.js libraries already work with Deno, Vite is a whole different beast and probably needs changes on Deno's side.

Note that it's not only about supporting Vite, but also its entire ecosystem (SvelteKit, vite-plugin-ssr, etc.).

FYI Bun is working on supporting Vite: oven-sh/bun#250 (comment).
Issue 1:
by namegduf:

What steps will reproduce the problem?
1. Copy the following into a file:

package main

import "fmt"

func main() {
wait := make(chan bool)
go func() {
<-wait
fmt.Printf("Test!")
}()
fmt.Println("Hello World!")
}

2. Build the file with 6g file.go; 6l file.go
2. Run 6prof on the output executable

What is the expected output?

The program's own output, follwed by a sample count and profiling output. Absence of
errors.

What do you see instead?

"ptrace waitpid: unexpected new tid <some tid> status 0x137f", followed
by the program's output, followed by the program hanging. No output from 6prof.

What is your $GOOS? $GOARCH?

GOOS=linux
GOARCH=amd64

Which revision are you using? (hg identify)

58cc2828bfd2 tip

It seems to work sometimes with even an empty goroutine, but removing the channel seems
to make things inconsistent.

Issue 2:
by montsamu:

Before filing a bug, please check whether it has been fixed since
the latest release: run "hg pull -u" and retry what you did to
reproduce the problem. Thanks.

What steps will reproduce the problem?
1. need to make an http.Get request but specify a head (e.g.
"Authorization" "OAuth")
2. see that http.Get doesn't allow this
3. see how ugly it would be to write an additional stack just to do this
outside http.Get (http.send is 'private')

Please provide any additional information below.

Apologies if there is a simple way to do this which I am missing.
Issue 1:
Hi!

I'm (eventually) attempting to build a PostCSS/cssnext setup on top of Next.js, but somehow importing a CSS file cannot be resolved.

My pages/index.js file tries to import the pages/index.css file (that exists):

import './index.css'

With the Webpack config:

next.config.js:

module.exports = {
webpack(config) {
config.module.rules.push({
test: /\.css$/,
exclude: /node_modules/,
loader: ['style-loader', 'css-loader']
});
return config;
}
};

results in

output:

yarn run v0.15.1
$ next
> Using "webpack" config function defined in next.config.js.
DONE Compiled successfully in 3004ms

> Ready on http://localhost:3000
{ Error: Cannot find module './index.css'
at Function.Module._resolveFilename (module.js:469:15)
at Function.Module._load (module.js:417:25)
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)
at Object.<anonymous> (/Users/kpuputti/code/projects/nextlatest/pages/index.js?entry:3:1)
at Module._compile (module.js:570:32)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3) code: 'MODULE_NOT_FOUND' }

Package versions in package.json:

"dependencies": {
"css-loader": "^0.26.1",
"next": "2.0.0-beta.12",
"style-loader": "^0.13.1"
}

Do I need to do some extra setup to get the resolving work, or how should I approach this? Thanks!

Issue 2:
Sometimes it's nice to break out your CSS into a separate .css file. I've tried to do the following:

pages/
└── index
├── index.css
├── index.js
└── component.js

Then in the index.js, I've tried to do:

import css from './index.css'

And in next.config.js:

module.exports = {
webpack: function (config) {
config.module.loaders = (config.module.loaders || []).concat({
test: /\.css$/, loader: 'raw'
})
return config
}
}

But unfortunately, it keeps giving me:

ERROR Failed to compile with 1 errors

This dependency was not found in node_modules:

* ./index.css

Seems like it's not resolving to the right place for some reason, the local component.js works though via import component from './component.js', so I'm not sure what's going on here.
Issue 1:
是否增加eureka注册中心的支持

how do supported eureka as service discovery?

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

I have checked the FAQ of this repository and believe that this is not a duplicate.

Environment

Dubbo version: 2.5.9~2.5.10

Operating System version: any

Java version: any

Step to reproduce this issue

response with attachments is a new feature in release 2.6.3.

but its compatible versions are set to ![2.0.10 ~ 2.6.2] while the "ProtocolVersion" had bean changed to 2.0.1 (implementation version) and 2.0.0 (specification version).

the priority of "implementation version" is greater than other in Version.getVersion.

this will cause dubbo rpc request failing from >2.5.9 to 2.6.3.

So is that a good idea to upgrade the lowest protocol version of attachment-feature to 2.0.2?

it's a big problem

Expected Result

compatible

Actual Result

fail
Issue 1:
Steps to Reproduce

Run the following app: https://gist.github.com/tvolkert/1458377c6d4bfb582e14bb284083c1b2

In the drawer, select "Show Breakage" to set the Material.debugEnablePhysicalModel value to true.

Look closely at the text rendering within the tab contents

Results

The rendering of the contents of the tab seem to have pixel rounding errors. See the screenshots without raster cache checkerboard and with raster cache checkerboard.

Analysis

When you select "Checkerboard Raster Cache Images" in the drawer, the fact that the checkerboard patterns show artifacts as well indicates that this is a raster cache issue -- and that the Material.debugEnablePhysicalModel flag is merely tickling a code path into causing the raster cache to show this underlying issue.

Issue 2:
Test device: Pixel XL

The PageView contents are rendered correctly on the initial render but once you start scrolling they become corrupted. They will remain this way even after the scrollable "settles".

The following are examples of text and a Widget near the edges of a DecoratedBox:

From @abarth (on Gitter): "it sounds like a problem in the raster cache that once we cache the texture for the page we draw the ugly version".
Issue 1:
When clicking the [src] link at the top right of the page of all of the rust docs pages, you are taken to the 'not found' page instead of being taken to the relevant source file.

Issue 2:
I don't think it is, but might be a duplicate of issue #17740.

trait Foo<'a>: 'a {}

impl Foo<'static> for ||: 'static {} // or impl<'a> Foo<'a> for ||: 'a

fn main() {}

<anon>:3:1: 3:37 error: internal compiler error: cannot relate bound region: ReEarlyBound(6, TypeSpace, 0, 'a) <= ReStatic
<anon>:3 impl Foo<'static> for ||: 'static {}
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
note: the compiler hit an unexpected failure path. this is a bug.
note: we would appreciate a bug report: http://doc.rust-lang.org/complement-bugreport.html
note: run with `RUST_BACKTRACE=1` for a backtrace
task 'rustc' failed at 'Box<Any>', /build/rust-git/src/rust/src/libsyntax/diagnostic.rs:116
Issue 1:
Environment

Windows build number: Microsoft Windows [Version 10.0.18362.10005]
Windows Terminal version: master build commit dca0ffe6dd0f76ca7997807424a2c08684e07751

Debugging mode (Debug x64) under Visual Studio 2019.

Steps to reproduce

Use a build from latest master commit dca0ffe.

Start the terminal under VS, then click on the tab down-arrow menu button.

Observe the crash.

Expected behavior

Menu shows up (it did some time ago...)

Actual behavior

A continuable exception is thrown, see the screen-capture below.

Improved stack-trace:

[External Code]
>	Microsoft.UI.Xaml.dll!winrt::throw_hresult(const winrt::hresult result) Line 4282	C++
[Inline Frame] Microsoft.UI.Xaml.dll!winrt::check_hresult(const winrt::hresult)	C++
Microsoft.UI.Xaml.dll!winrt::impl::consume_Windows_System_IDispatcherQueueStatics<winrt::Windows::System::IDispatcherQueueStatics>::GetForCurrentThread() Line 585	C++
[Inline Frame] Microsoft.UI.Xaml.dll!winrt::Windows::UI::ViewManagement::ApplicationView::GetForCurrentView::__l2::<lambda_30d95ff0d0a0221e0e76d5a8187eef0d>::operator()(const winrt::Windows::UI::ViewManagement::IApplicationViewStatics2 &)	C++
[Inline Frame] Microsoft.UI.Xaml.dll!winrt::impl::factory_cache_entry<winrt::Windows::UI::ViewManagement::ApplicationView,winrt::Windows::UI::ViewManagement::IApplicationViewStatics2>::call(winrt::Windows::UI::ViewManagement::ApplicationView::GetForCurrentView::__l2::<lambda_30d95ff0d0a0221e0e76d5a8187eef0d> &)	C++
Microsoft.UI.Xaml.dll!winrt::impl::call_factory<winrt::Windows::UI::ViewManagement::ApplicationView,winrt::Windows::UI::ViewManagement::IApplicationViewStatics2,<lambda_30d95ff0d0a0221e0e76d5a8187eef0d> >(winrt::Windows::UI::ViewManagement::ApplicationView::GetForCurrentView::__l2::<lambda_30d95ff0d0a0221e0e76d5a8187eef0d> &&) Line 5471	C++
[Inline Frame] Microsoft.UI.Xaml.dll!winrt::Windows::UI::ViewManagement::ApplicationView::GetForCurrentView()	C++
Microsoft.UI.Xaml.dll!MaterialHelper::IsFullScreenOrTabletMode() Line 1017	C++
[Inline Frame] Microsoft.UI.Xaml.dll!AcrylicBrush::UpdateAcrylicStatus() Line 573	C++
Microsoft.UI.Xaml.dll!AcrylicBrush::OnConnected() Line 167	C++
Microsoft.UI.Xaml.dll!winrt::impl::produce<AcrylicBrush,winrt::Windows::UI::Xaml::Media::IXamlCompositionBrushBaseOverrides>::OnConnected() Line 5341	C++
[External Code]
WindowsTerminal.exe!wWinMain(HINSTANCE__ * __formal, HINSTANCE__ * __formal, wchar_t * __formal, int __formal) Line 134	C++
[External Code]

Issue 2:
Environment

Windows build number: 10.0.19008.0
Windows Terminal version: 0.6.2951.0
WSL 2: Ubuntu 19.04

Steps to reproduce

Open terminal

Open file to edit in vim

Type ':set mouse=a' to enable mouse mode globally

Attempt to scroll

Expected behavior

Scrolling and other mouse events should be passed through and handled by the respective program

Double clicking should engage VISUAL mode in vim

Actual behavior

Scrolling causes the terminal to scroll into it's scrollback buffer

Double clicking selects text in the terminal, but not in the application itself. This seems more in line with how I would expect single click and drag or shift + click events to be handled.
Issue 1:
Posted first on stackoverflow, but no response as of yet.

Any steps I can do to debug further would be appreciated.

Environment:

centos 6.7

opencv 2.4.12

python 2.7

GNU libc 2.12

gcc version 4.4.7 20120313 (Red Hat 4.4.7-16)

uname output:

Linux xxxx 2.6.32-573.18.1.el6.x86_64 #1 SMP xxx x86_64 x86_64 x86_64 GNU/Linux

Clean download of 2.4.12 release and compiles fine with the following commands:

export PYTHON_EXECUTABLE=/usr/bin/python2.7
export PYTHON_INCLUDE_PATH=/usr/include/python2.7/
export PYTHON_LIBRARY=/usr/lib64/libpython2.7.so
export PYTHON_NUMPY_INCLUDE_DIR=/home/centos/.local/lib/python2.7/site-packages/numpy/core/include/numpy
export PYTHON_PACKAGES_PATH=/home/centos/.local/lib/python2.7/site-packages
cmake \
-DCMAKE_BUILD_TYPE=Debug \
-DCMAKE_INSTALL_PREFIX=/usr/local \
-DBUILD_WITH_DEBUG_INFO=ON \
-DPYTHON_EXECUTABLE=$PYTHON_EXECUTABLE \
-DPYTHON_INCLUDE_PATH=$PYTHON_INCLUDE_PATH \
-DPYTHON_LIBRARY=$PYTHON_LIBRARY \
-DPYTHON_NUMPY_INCLUDE_DIR=$PYTHON_NUMPY_INCLUDE_DIR \
-DPYTHON_PACKAGES_PATH=$PYTHON_PACKAGES_PATH \
-DINSTALL_C_EXAMPLES=OFF \
-DINSTALL_PYTHON_EXAMPLES=OFF \
-DBUILD_EXAMPLES=OFF \
-DWITH_FFMPEG=OFF ..

Output snippet from running make

-- Media I/O:
-- ZLib: /usr/lib64/libz.so (ver 1.2.3)
-- JPEG: /usr/lib64/libjpeg.so (ver )
-- PNG: /usr/lib64/libpng.so (ver 1.2.49)
-- TIFF: /usr/lib64/libtiff.so (ver 42 - 3.9.4)
-- JPEG 2000: /usr/lib64/libjasper.so (ver 1.900.1)
-- OpenEXR: /usr/lib64/libImath.so /usr/lib64/libIlmImf.so /usr/lib64/libIex.so /usr/lib64/libHalf.so /usr/lib64/libIlmThread.so (ver 1.6.1)
--

However. This runs fine:

>$ python2.7 -c "import cv2; cv2.imread('test.png')"

But this does not:

$ python2.7 -c "import cv2; cv2.imread('test.tif')"

OpenCV Error: Assertion failed (udata < (uchar*)ptr && ((uchar*)ptr -
udata) <= (ptrdiff_t)(sizeof(void*)+16)) in fastFree, file
/fleuron-data/opencv-2.4.12/modules/core/src/alloc.cpp, line 78
terminate called after throwing an instance of 'cv::Exception'
what(): /fleuron-data/opencv-2.4.12/modules/core/src/alloc.cpp:78:
error: (-215) udata < (uchar*)ptr && ((uchar*)ptr - udata) <=
(ptrdiff_t)(sizeof(void*)+16) in function fastFree

Aborted

And has me lost..

Issue 2:
Can you please help me understand why I can't get imread to open simple bitonal files like this one?

https://app.box.com/s/y2h71ydjb7uim1um1gwqjvsuqz2cpmf2

This is an example of what I get. It worked in 3.0 rc but with 3.0.0 it no longer works.

Unhandled exception at 0x00007FF992BB9A1D (opencv_world300d.dll) in OpenCv_FastHough.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.