sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: kubernetes
Issue: Ephemeral storage doesn't account for deleted files with open handles
Labels: kind/bug,sig/node,help wanted,priority/important-longterm,lifecycle/frozen,needs-triage

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!

If the matter is security related, please disclose it privately via https://kubernetes.io/security/
-->


**What happened**:

A pod that creates large files in the ephemeral storage (either in an explicit `emptyDir` volume or just by writing to the container's filesystem) and then deletes them while keeping an open file handle will cause serious stability issues on the node while making it very hard for an operator to find out that it's the root cause. From kubelet's perspective the pod's `ephemeral-storage` usage will be close to zero, so it'll go and evict other pods first while the offending pod continues using more and more disk space. None of the reported metrics (e.g. cadvisor's container_fs_usage_bytes) will report this pod's usage correctly, so the only way to even find it is manually running `lsof -a +L1` on the node. This also prevents Ephemeral Storage limits from working correctly, making it impossible for cluster operators to use those to protect nodes from faulty applications.

**What you expected to happen**:

A pod's filesystem usage is accounted for correctly, even if disk space is used by deleted files. When the node runs out of disk space, the offending pod is evicted.

**How to reproduce it (as minimally and precisely as possible)**:

Deploy a pod that'll create large files, delete them while still keeping the handle open and writing no logs or any other data. Wait until the node runs out of disk space. Observe that `kubelet` tries to evict all other pods instead (since they'll consume non-zero space for their logs), then gives up and the node dies completely.

**Environment**:
- Kubernetes version (use `kubectl version`): 1.14.6
- Cloud provider or hardware configuration: [kubernetes-on-aws](https://github.com/zalando-incubator/kubernetes-on-aws/)
- OS (e.g: `cat /etc/os-release`): Ubuntu 18.04.3 LTS
- Kernel (e.g. `uname -a`): 4.15.0-1048-aws
Repository: pytorch
Issue: setup.py install error
Labels: module: build,triaged

When I performed the steps to "python setup.py install", the following error occurred.
------------------------------------------------------------------
make: *** No rule to make target 'install'.  Stop.
Building wheel torch-1.3.0a0+a395c31
-- Building version 1.3.0a0+a395c31
cmake --build . --target install --config Release -- -j 12
Traceback (most recent call last):
  File "setup.py", line 756, in <module>
    build_deps()
  File "setup.py", line 320, in build_deps
    cmake=cmake)
  File "/home/****/****/****/DFG/pytorch/tools/build_pytorch_libs.py", line 59, in build_caffe2
    cmake.build(my_env)
  File "/home/****/****/****/DFG/pytorch/tools/setup_helpers/cmake.py", line 334, in build
    self.run(build_args, my_env)
  File "/home/****/****/****/DFG/pytorch/tools/setup_helpers/cmake.py", line 142, in run
    check_call(command, cwd=self.build_dir, env=env)
  File "/usr/lib/python2.7/subprocess.py", line 541, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['cmake', '--build', '.', '--target', 'install', '--config', 'Release', '--', '-j', '12']' returned non-zero exit status 2
Repository: terminal
Issue: Optionally persist font size changes when changed with CTRL+Mousewheel
Labels: Area-Settings,Product-Terminal,Issue-Task

<!-- 
🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨

I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING:
1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement.
2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement.
3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number).
4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement.
5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement.

All good? Then proceed!
-->

# CTRL+MouseWheel font size changes should optionally persist to profiles.json

<!-- 
A clear and concise description of what the problem is that the new feature would solve.
Describe why and how a user would use this new functionality (if applicable).
-->

<!-- 
A clear and concise description of what you want to happen.
-->

I move between monitors a lot and this means I change monitor geometries, resolutions, and pixel pitches frequently.  Frequently enough that I need to change the font size in Terminal almost daily, and it would be lovely if my font size changes "stick" for the day.  The multiple round trips required to change the font size to get it exactly where I want it via `profiles.json` is a bit tedious.  So, for some, and for me definitely, changes to font size should persist when I use CTRL+MouseWheel.

I know this goes against the folks who want this to **never** persist, so perhaps a new keyboard shortcut is in order, or perhaps the behavior of CTRL+MouseWheel should be exposed in the `keybindings` section of `profiles.json` as a `command`.  An additional `command` could be created (which persists the font size when you zoom) and could then be chosen by those who want this behavior.  

Persisting the font size when it is changed with CTRL+MouseWheel is the behavior in Sublime Text and I've gotten quite used to this over time, and now I miss it (I especially miss it in VScode, but that's another issue.)

Thank you.
Repository: create-react-app
Issue: Add scss import pattern to allow importing all css/scss files from folder
Labels: issue: proposal,needs triage

### Is your proposal related to a problem?

<!--
  Provide a clear and concise description of what the problem is.
  For example, "I'm always frustrated when..."
-->

Since I'm using scss modules, I have a main scss file with some common rules that's being imported in .jsx file. In this main scss file, I need to import all scss files from a folder. They work as template options: each imported scss is one specific template and it can grow over time, increasing the number of templates. Nowadays, I need to import every single file such like this:

**mainTemplate.module.scss**
```
// must import every single template
@import "./templates/template01.scss";
@import "./templates/template02.scss";
// ... some files later ...
@import "./templates/template20.scss";
```

### Describe the solution you'd like

<!--
  Provide a clear and concise description of what you want to happen.
-->

I'd like to achieve the same above with the following syntax:

**mainTemplate.module.scss**
```
// one single import ...
@import "./templates/*";
// ... and it's done!
```

### Describe alternatives you've considered

<!--
  Let us know about other solutions you've tried or researched.
-->

I've found this Stack Overflow question:
https://stackoverflow.com/questions/44646201/create-react-app-how-do-i-import-all-scss-files-from-a-directory/44646609#44646609
Wich refers to this npm package:
https://www.npmjs.com/package/import-glob-loader

### Additional context

<!--
  Is there anything else you can add about the proposal?
  You might want to link to related issues here, if you haven't already.
-->

Nothing to add
Repository: go
Issue: cmd/compile: inline functions that are called only once
Labels: Performance,NeedsDecision,compiler/runtime

### What version of Go are you using (`go version`)?
<pre>
$ go version
go version devel +211932b Mon Sep 23 22:33:23 2019 +0000 linux/amd64
</pre>

### Does this issue reproduce with the latest release?
Yes.

### What did you do?
Take the following functions as an example:
```go
func f(n int) int {
    var sum int
    for i := 0; i < n; i++ {
        sum += aux(i)
    }
    return sum
}

func aux(x int) (res int) {
    // Long function that goes over the inline budget
    // ...

    return res
}
```
If it is known that function `aux` is only called once (in this case, in `f`), in spite of `a` going over the inline budget, I think it would be beneficial to inline it in the caller.
I imagine there are many situations where developers extract a piece of code from a loop into a new function and then only call it once.
Repository: three.js
Issue: Anaglyph 3D - set it to zero parallax: 0 discrepancy at camera (currently set to negative parallax)
Labels: Addons

It's rather amazing that threejs has an anaglyph component - thanks heaps, this is a fantastic tool!

One question regarding anaglyph parallax setting: currently it is using negative parallax, as in, the zero point is further away from the viewer, and there is disparity both at a distance zero and far away (see screenshot for the problem, taken from the bottom of the screen, which has the white line starting 0 distance away. Further details about zero/negative parallax here: http://paulbourke.net/stereographics/stereorender/)

![Screen Shot 2019-09-25 at 10 21 58 pm](https://user-images.githubusercontent.com/3745745/65600325-446bda80-dfe3-11e9-81a5-5d88d025a05a.png)

It would be more pleasing to the eye to have zero disparity where the camera is, so everything seemed to be "behind" the computer screen.

After a quick look, it appears that the matrix values would need to change in https://github.com/mrdoob/three.js/blob/master/examples/js/effects/AnaglyphEffect.js to achieve this? I'm not entirely sure. 

Any help would be appreciated! :)
Repository: node
Issue: http.ClientRequest with Upgrade header sometimes hangs on first request
Labels: http,macos

* **Version**: 12.10.0 (also checked on 12.9.1)
* **Platform**: macOS 10.14.6 — Darwin 18.7.0 Darwin Kernel Version 18.7.0: Tue Aug 20 16:57:14 PDT 2019; root:xnu-4903.271.2~2/RELEASE_X86_64 x86_64
* **Subsystem**: http

Connecting to a newly started `http.Server` with a `http.ClientRequest` using `Connection: Upgrade` occasionally (~0.2% probability) hangs indefinitely. The request never reaches the server (no `connection` event is fired), but strangely the same issue does not appear when using a raw `net.Socket` on the client and sending equivalent data. The issue also does not appear if the server is bound to `127.0.0.1` rather than the default `0.0.0.0`.

The following code replicates the issue reliably; typically it will freeze after ~500 iterations:

```js
const http = require('http');

async function test() {
  const server = http.createServer();
  server.on('connection', () => {
    process.stdout.write(`${Date.now()} | - connection\n`);
  });
  server.on('upgrade', (req, socket) => {
    socket.end('HTTP/1.1 404 Not Found\r\n\r\n');
  });

  await new Promise((resolve) => server.listen(0, resolve));
  const { port } = server.address();

  await new Promise((resolve) => {
    const req = new http.ClientRequest({
      port,
      headers: {
        Connection: 'Upgrade',
        Upgrade: 'x'
      }
    });
    req.once('close', resolve);
    req.end();
  });

  await new Promise((resolve) => server.close(resolve));
}

(async () => {
  for (let i = 0; ; i++) {
    process.stdout.write(`${Date.now()} | Attempt ${i}\n`);
    await test();
  }
})();
```

---

Changes which make the issue disappear:

- Change `server.listen` call to `server.listen(0, '127.0.0.1', resolve)`
- Change `http.ClientRequest` block to:
  ```js
    await new Promise((resolve) => {
      const s = new net.Socket();
      s.on('close', resolve);
      s.on('data', () => {});
      s.connect(port, 'localhost', () => {
        s.write([
          'GET / HTTP/1.1',
          'Connection: Upgrade',
          'Upgrade: websocket',
          '',
          '',
        ].join('\r\n'));
        s.end();
      });
    });
  ```
- Remove headers, and change related server event (`server.on('request', (req, res) => res.end());`)

---

Changes which *do not* make the issue disappear:

- adding a delay between `server.listen` and the request (tested with up to 1 second)

---

When the issue appears, even the server-side `connection` event does not fire.

This was found while debugging a suite of tests with occasional failures. Initially reported to https://github.com/websockets/ws/issues/1635
Repository: go
Issue: spec: clarify when calling recover stops a panic
Labels: Documentation,NeedsInvestigation

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
go version go1.13 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes

### What did you do?

```golang
package main

import "fmt"

func demo() {
	defer func() {
		defer func() {
			// recover panic 2
			fmt.Println("panic", recover(), "is recovered")
		}()

		// recover panic 1
		defer fmt.Println(" (done).")
		defer recover()
		defer fmt.Print("To recover panic 1 ...")

		defer fmt.Println("now, two active panics coexist")
		panic(2) // If this line is commented out, then the program will not crash.
	}()
	panic(1)
}

func main() {
	demo()
}
```

### What did you expect to see?

Not crash.

### What did you see instead?

Crashes.
Repository: kubernetes
Issue: Add startup resource requirements
Labels: kind/feature,sig/apps,needs-triage

<!-- Please only use this template for submitting enhancement requests -->

**What would you like to be added**:

I would like startup resources requirements to be added. Now we have `request` and `limits` and I want something like `startup-request` for CPU and RAM.

**Why is this needed**:

Some applications use a lot of RAM and CPU during the startup and use not much while running. Now, such applications need to require high `requests` to be able to started. And when app is running and uses few resources it blocks unused resources so that other applications cannot use it. 

For example, there is an app which requires 1 GB RAM and 1 CPU during the startup. And when it finished all preparations and started to work in normal mode it requires only 200 MB RAM and 200m CPU. Now, to make it deployable to k8s we need to set resource requests as 1 GB for RAM and 1 core for CPU which is honest. But when app is running it uses only fifth part of requested resources and other applications can not claim to use these resources. 

What I am suggesting for this cases is to introduce `startup-request`  which will be actual until `startupProbe` (introduced in 1.16) returns `OK`. So, when app finished startup,  k8s frees unnecessary resources (making them available for other apps) and application left only with resources specified in `request` section
Repository: pytorch
Issue: Google Summer of Code
Labels: triaged

@soumith Will PyTorch take part in GSoC next year?
Repository: TypeScript
Issue: Higher order type inference doesn't work with overloads
Labels: Suggestion

@ahejlsberg 

**TypeScript Version:**  typescript@3.7.0-dev.20190925

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**

**Code**

```ts
interface Curried2<a, b, z> {
  (a: a, b: b): z;
  (a: a): (b: b) => z;
}
interface Curry {
  <a, b, z>(f: (a: a, b: b) => z): Curried2<a, b, z>;
}

declare const curry: Curry;

curry(<T extends 0, U extends 1>(n: T, m: U) => n + m)(1)(0);
curry(<T extends 0, U extends 1>(n: T, m: U) => n + m)(1, 0);
```

Also the following doesn't work:

```ts
interface Curried2<a, b, z> {
  (a: a): (b: b) => z;
  (a: a, b: b): z;
}
```

When removing overloads as follows:

```ts
interface Curried2<a, b, z> {
  (a: a, b: b): z;
}
```

or

```ts
interface Curried2<a, b, z> {
  (a: a): (b: b) => z;
}
```

These work correctly.

**Expected behavior:**

Infer type parameters correctly and all parameter values are rejected correctly.

**Actual behavior:**

no error.

**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior -->

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
Repository: TypeScript
Issue: Disallowing `throw`ing expressions that aren't assignable to `Error`
Labels: Suggestion,Awaiting More Feedback

## Search Terms

throw, throwing non-error

## Suggestion

Add typechecking to `throw` statement, allowing it to only throw `Error`s and `any`s.

Code currently allowed, but with strong potential for bugs:
```
throw null;
throw undefined;
throw 'foobar';
throw ''; 
throw 42;
throw {foo: 'bar'};
throw potentiallyNullable; // with –strictNullChecks
```

After implementing this feature request, such code wouldn't be allowed.

## Use Cases

Even if it's possible to throw non-errors in JavaScript code, it's extremely confusing and hard to debug. Failing to properly handle such cases happened even to [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=1099071).

## Examples

Forbidden code:
```
throw null;
throw undefined;
throw 'foobar';
throw 42;
throw {foo: 'bar'};
throw potentiallyNullable; // with –strictNullChecks
```
Allowed:
```
throw new Error();
throw null as any;
```

## Checklist

My suggestion meets these guidelines:

* [ ] This wouldn't be a breaking change in existing TypeScript/JavaScript code - it can break existing TypeScript code.
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).
Repository: angular
Issue: Optional Routing Parameters issue
Labels: type: bug/fix,freq2: medium,area: router,state: confirmed,router: URL parsing/generation,P3

# 🐞 bug report

### Affected Package
@angular/router


### Is this a regression?

Yes, working in angularjs 1.x


### Description

Optional Routing Parameters issue

Route declaration

const routes: Routes = [
  { path: '', component: SearchpagesComponent ,
    children: [
      {
        path: ’near/:nearSearch/:val1/:val2/:name/:filter', loadChildren: './near-search/near-search.module#NearSearchModule',
      }
    ]
  }
];

RouterLink config

<a [routerLink]="['/near/','','37’,’122','San-Francisco','All']" > Goto Near Page - San Francisco</a>

by this we are able to achieve optional param and able to load component and URL generated by routerLink is below which is expected
http://localhost:3000/near//37/122/San-Francisco/All

but when we refresh or reload page it's not working and redirecting to http://localhost:3000/

-Two forward slash after near "//" is required and url should remain same.

-Expected fix is if we pass `nearSearch ` params as a null component should be loaded and and blank forward slash '//' should be persist in URL'





## 🔥 Exception or Error
Redirecting back to home page


## 🌍  Your Environment

**Angular Version:**
Angular 5
Repository: go
Issue: doc: document/reassert that last two releases are supported equally
Labels: Documentation,Proposal,Proposal-Accepted

The policy for what does and doesn't get backported is currently documented at https://golang.org/wiki/MinorReleases.

> Our default decision should always be to not backport, but fixes for security issues, serious problems with no workaround, and documentation fixes are backported to the most recent two release branches, if applicable to that branch.
>
> Fixes for experimental ports are generally not backported.
>
> A “serious” problem is one that prevents a program from working at all. "Use a more recent stable version" is a valid workaround, so very few fixes will be backported to both previous issues.

This is pretty vague, and it detaches from practice in quite a few ways. We discussed a more complete framework that reflects the current reality with @dmitshur.

I propose we document it at https://golang.org/doc/devel/release.html#policy (in keeping with #34038) with the following text.

/cc @golang/osp-team 

---

### Backporting policy

**Most recent major release.** The following changes are are eligible for backporting to the latest major release.

* Security fixes, in their own release, according to the [security policy](https://golang.org/security).
* Fixes for serious problems with no workaround. A “serious” problem is one that prevents a program from working at all. This includes, for example, miscompilation issues.
* Early fixes for regressions and issues in new functionality. As the release matures, the bar for these changes gets higher: while the first minor release in a series will accept most fixes for user-visible regressions, after five months they will be mostly rejected. As more of the ecosystem upgrades, fixing regressions with workarounds becomes less and less valuable, and the tradeoff with stability shifts.
* Documentation changes that fix incorrect public docs. 

Fixes for experimental ports are generally not backported.

**Previous major release.** The only fixes eligible for backporting to the previous major release (for example, to Go 1.10, once Go 1.11 has been released) are those that address external changes that would make the release unusable. This includes security fixes and platform compatibility fixes (for example, if a new version of an OS breaks Go programs).

We consider upgrading to the latest major release a valid workaround, and the purpose of maintaining the previous major release is only not to force users to upgrade unexpectedly, so pre-existing serious issues and regressions are only fixed in the latest major release.
Repository: go
Issue: x/build: add more race detector builders
Labels: Builders,NeedsFix,new-builder

We should have one for every supported race detector config.

We currently have:
```
darwin/amd64
freebsd/amd64
linux/amd64
windows/amd64
```
We'd need to add:
```
netbsd/amd64
linux/arm64
linux/ppc64le
```
@bradfitz 

When attempting to rebuild the .syso files as part of #33309 , I ran into these additional platforms where race.bash does not pass, usually because of dumb reasons that would be easily caught and fixed if we had builders for them.

Builders would also be useful to test my fix for #33309 .