sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: electron
Issue: [Feature Request]: Provide a warning / option to avoid data loss when downgrading
Labels: enhancement :sparkles:

**Preflight Checklist**

* [x] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/master/CONTRIBUTING.md) for this project.
* [x] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/master/CODE_OF_CONDUCT.md) that this project adheres to.
* [x] I have searched the issue tracker for a feature request that matches the one I want to file, without success.


**Problem Description**

Related to #24882, I've found that when running Electron 12 beta and then running Electron 11 on the same profile causes the indexeddb data to be deleted.

This is not a request to support downgrading, as that is understandable not possible as mentioned in #24882.

However, perhaps there is a way for Electron to warn and provide a callback or simply refuse to load if attempting to load a newer profile in an older version?

**Proposed Solution**

Perhaps there could be a method on app, eg. `app.warnOnMismatchProfileVersion` that would then generate a `unknown-profile-version` callback. By default, if callback is not handled, loading would continue regardless.

However, if an application wanted to stop loading if there is a mismatch in profile version (presumably from a newer profile), it could then handle the event, display a `dialog` and quit, or given the user option to continue.

This assumes that it is possible for Electron to check the profile version, but maybe this is not the case.

**Alternatives Considered**

There aren't really any possible alternatives, other than perhaps maintaining different profile versions for different versions of Electron.

Perhaps some sort of 'channel' system could be implemented, with separate release, beta, alpha, etc... channels and distinct profiles for each one. However, this still doesn't prevent the automatic data loss that would occur if loading an older version with a newer profile.

Perhaps there's a better way to handle this at the application level by checking the Chromium version used?


**Additional Information**

Electron releases are a bit different with Chrome/Chromium. Probably by design, it is not as easy to downgrade chromium to an older version, especially for end users, as Google generally makes only the latest version available.

However, this is not the case with Electron, as there are often multiple versions and a beta that is out, making it easy to switch to a newer beta from an older release, and vice versa.

For end users, Electron application releases are often published to github, and a user may choose to install an older version after trying a newer version, not realizing that doing so may lead to irreversible data loss.

Again, maybe there's a simpler solution to this that I'm not aware of, by checking Chromium versions,
if so, happy to try that as well!
Repository: terminal
Issue: `less` with -r option causes strange display behavior for input with ANSI control characters
Labels: Area-Output,Issue-Bug,Needs-Attention,Product-Terminal,Priority-2

# Environment

```
Windows build number: [run `[Environment]::OSVersion` for powershell, or `ver` for cmd]: 10.0.19041.0
Windows Terminal version (if applicable): 1.5.10411.0

Any other software?
Ubuntu on WSL 1
```

# Steps to reproduce

Have a long file, in this case produced with `git reflog.` Examine with `less`. Notice that output does not include the first ~10 lines.

```
git reflog > reflog.out
head reflog.out
5240aea1 HEAD@{0}: checkout: moving from zachmu/windows to aaron/indexed-in-subquery-filter
56ac2928 HEAD@{1}: checkout: moving from aaron/indexed-in-subquery-filter to zachmu/windows
5240aea1 HEAD@{2}: checkout: moving from zachmu/windows to aaron/indexed-in-subquery-filter
56ac2928 HEAD@{3}: checkout: moving from aaron/indexed-in-subquery-filter to zachmu/windows
5240aea1 HEAD@{4}: checkout: moving from master to aaron/indexed-in-subquery-filter
1acb0aab HEAD@{5}: pull: Fast-forward
66627818 HEAD@{6}: checkout: moving from zachmu/windows to master
56ac2928 HEAD@{7}: commit: Added some more query tests for window funcs
cb14e839 HEAD@{8}: commit: Working row_number() function
5f08c885 HEAD@{9}: commit: Semi working sort order. Moved more functions and types around to avoid cycles.
```

`less reflog` presents me with a screen that starts like this:

```
rtField up to the sql package and gave it some more methods.
e9c3d6d8 HEAD@{11}: commit: Added window setting to function analysis
98044728 HEAD@{12}: commit: Chalked in outline of adding all rows to a window expression. Now need a way to get Window values into the functions.
d8fcf55e HEAD@{13}: commit: Sketched out an iter
000efaba HEAD@{14}: commit: Chalked out a window node. This involved moving some Sort related types out of the plan package to the expression package
66627818 HEAD@{15}: checkout: moving from master to zachmu/windows
```

As you can see, the first ~10 lines of the file are not there. If I press the up arrow, less does not respond (chimes the bell). If I press the down arrow key twice, then the up arrow key twice, I see this:

```
5240aea1 HEAD@{0}: checkout: moving from zachmu/windows to aaron/indexed-in-subquery-filter
56ac2928 HEAD@{1}: checkout: moving from aaron/indexed-in-subquery-filter to zachmu/windows
98044728 HEAD@{12}: commit: Chalked in outline of adding all rows to a window expression. Now need a way to get Window values into the functions.
d8fcf55e HEAD@{13}: commit: Sketched out an iter
```

Something very strange is happening with the display buffering here. I've noticed this on other invocations of `less` as well, not just when examining this particular file.

# Expected behavior

When `less` is invoked the terminal should contain the first page of text from the input. Instead, it's starting about 10 lines in.

# Actual behavior

As described above
Repository: TypeScript
Issue: Index signatures in type definitions: now we have `noUncheckedIndexedAccess`, include or omit `undefined`?
Labels: Suggestion,In Discussion

# lib Update Request

<!--
  Please fill in each section completely. Thank you!

  Are you here for one of these commonly-requested lib changes?
    * Object.keys - see https://stackoverflow.com/questions/55012174/
    * Array methods - see https://github.com/microsoft/TypeScript/issues/36554
    * parseInt, parseFloat, isFinite, isNaN, etc. - see https://github.com/microsoft/TypeScript/issues/4002

  The DOM lib is maintained elsewhere and you can skip a step by filing issues/PRs for the DOM at that repo.
  See https://github.com/microsoft/TypeScript-DOM-lib-generator
-->

Before we had `noUncheckedIndexedAccess`, it was common practice to add `undefined` to an index signature as a workaround. For example:

- https://github.com/microsoft/TypeScript/issues/13792 in which the index signature inside `DOMStringMap` (`lib.dom.d.ts`) was modified to include `undefined`.
- https://github.com/DefinitelyTyped/DefinitelyTyped/pull/43931 in which all index signatures in `@types/node` were modified to include `undefined` (e.g. `ProcessEnv` and `ParsedUrlQuery`).

However, it seems this workaround wasn't extended to all index signatures, e.g. 
[`RegExpMatchArray['groups']`](https://github.com/microsoft/TypeScript/blob/847992b64b4d79e0370de1c0001ce8c903482b9e/lib/lib.es2018.regexp.d.ts#L22) in `lib.es2018.regexp.d.ts` and [`PropertyDescriptorMap`](https://github.com/microsoft/TypeScript/blob/847992b64b4d79e0370de1c0001ce8c903482b9e/lib/lib.es5.d.ts#L116) in `lib.es5.d.ts`.

Now we have `noUncheckedIndexedAccess` I would like to ask what the best way forward is regarding these workarounds? For people who enable `noUncheckedIndexedAccess`, these workarounds are redundant. For people who don't enable `noUncheckedIndexedAccess`, these workarounds are still necessary—but potentially not always desirable since it forces a higher level of strictness.

It seems inconsistent that some index signatures use this workaround and others do not, so I think we should decide either to use this workaround in all index signatures or remove it from all index signatures and suggest people use `noUncheckedIndexedAccess`.

Including `undefined` creates a few problems, for example:

```ts
declare const v: DOMStringMap;

Object.values(v).map((value) => {
    // Expected: string;
    // Actual: string | undefined; ❌
    value;
});

for (const value of Object.values(v)) {
    // Expected: string;
    // Actual: string | undefined; ❌
    value;
}

const test: DOMStringMap = {
    // This should error
    foo: undefined
}
```

If the TypeScript team can decide the best way forward then this will also provide some guidance to the community—for example we're trying to decide what the best option is for `@types/node`: https://github.com/DefinitelyTyped/DefinitelyTyped/pull/51177.
Repository: pytorch
Issue: [docs] Official apex -> torch.cuda.amp migration guide
Labels: module: docs,feature,triaged,module: amp (automated mixed precision)

I propose to add such a guide directly to https://pytorch.org/docs/stable/amp.html or at https://pytorch.org/docs/stable/notes/amp_examples.html. Apex was the dominant (and mostly stable) fp16 training method before implementation of torch.cuda.amp by @mcarilli 

Common questions include - would torch.cuda.amp achieve similar memory reduction? speed? is apex O2-mode at all beneficial compared to amp?

It is often aked, e.g. https://discuss.pytorch.org/t/torch-cuda-amp-vs-nvidia-apex/74994/2 https://github.com/NVIDIA/apex/issues/818. But the amp is getting improved, so it would be good to have a current state of affairs somewhat officially published

cc @mcarilli @ptrblck @brianjo @mruberry @jlin27
Repository: vscode
Issue: Community Question regarding Issue Handling
Labels: question-discussion

Over the last few weeks, I have started regularly contributing to VSCode and helping where I can. But I have seen some issues / PRs that have been left unanswered and have been abandoned due to no response. This could lead to a large backlog, taking a lot of time to maintain, and (speaking from personal experience) can discourage the community members from involving.

Of course, we are all in hurry sometimes (or forget things, are on holiday, sick-leave …), but I was wondering about the team’s perspective on this topic.

Is there a document / section in the wiki that describes a procedure on what a community member can / should do in cases where a discussion in an issue is left unanswered? Or more importantly, there is no reaction on a PR from the assignee? Surely there cannot be one *right* solution, as this varies strongly from case to case, but a general guideline would be very helpful in my opinion. 
From the top of my head, specifically the following questions arise:
* Is there a (rough) estimate on how long one should wait before pinging an assignee again, when a question etc. has been left unanswered? A week? two weeks? 
* What can / should one do, when an assignee does not respond anymore, and pings don’t seem to help? Is there anyone that can be involved in this case to further pursue the issue / PR (e.g. mentioning the person responsible for inbox tracking this week)?
* What to do with existing issues that do not have an assignee anymore?

If there is already a documentation about this, I would suggest linking this in the *How-to-Contribute* section in the wiki. If not, and the procedure is explained to me, I would be happy to add it myself (or maybe even add a link to this issue).

If this is not the correct place to discuss such things, please point me in the right direction. Thanks :)
Repository: go
Issue: os: docs say nothing about path slash types
Labels: Documentation,NeedsInvestigation

The `os` package docs say:

> Package os provides a platform-independent interface to operating system functionality. The design is Unix-like, although the error handling is Go-like

But nowhere at https://golang.org/pkg/os/ is "slash" mentioned.

Yet there are two Go packages about paths and their slashes: `path` and `path/filepath`.

That quoted line above might suggest only forward slashes are permitted ("the design is Unix-like").

Seems like the `os` package should say what it permits. Users will wonder: forward only? host native only? either way?
Repository: rust
Issue: `Concat` trait has bad codegen for arrays
Labels: I-slow,T-libs-api,A-array

Code: https://rust.godbolt.org/z/TjPcbz
```rust
use std::convert::TryInto;

pub fn t(a: [u8; 32], b: [u8; 32]) -> [u8; 64] {
    [a, b].concat().try_into().unwrap()
}
```

This shouldn't allocate. Nor should it be doing anywhere *near* as many copies. Even if you remove the Vec -> array conversion, it's still doing way more work than it needs to -- the grow calls should not be there for a simple concat.
Repository: pytorch
Issue: DataParallel module fails to handle data with size not divisible by number of GPUs
Labels: triaged,module: data parallel

I have a very lengthy code that I thought to speed up using DataParallel module. I tested it with 2 GPUs but my dataloader pulls from a dataset with an odd number of samples. The training goes well up until the last epoch where the gather function tells me it is expecting a size of 6 while receiving a size of 5 from device number 1.

## To Reproduce

Steps to reproduce the behavior:

1. a dataset with odd number of samples
2. just the normal dataloader
3. use multiple gpus using dataparallel module 

I got this error message
return torch._C._gather(tensors, dim, destination)
RuntimeError: Input tensor at index 1 has invalid shape [1, 5, 256], but expected [1, 6, 256]

## Environment

PyTorch version: 1.7.1
Is debug build: False
CUDA used to build PyTorch: 10.2
ROCM used to build PyTorch: N/A

OS: CentOS Linux release 7.8.2003 (Core) (x86_64)
GCC version: (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39)
Clang version: Could not collect
CMake version: version 2.8.12.2

Python version: 3.6 (64-bit runtime)
Is CUDA available: True
CUDA runtime version: 11.1.74
GPU models and configuration:
GPU 0: GeForce GTX 1080 Ti
GPU 1: GeForce GTX 1080 Ti

Nvidia driver version: 455.23.05
cuDNN version: /usr/lib64/libcudnn.so.7.6.5
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.18.1
[pip3] torch==1.7.1
[pip3] torchfile==0.1.0
[pip3] torchnet==0.0.4
[pip3] torchvision==0.8.2
[conda] Could not collect
Repository: go
Issue: os: hard to use DirFS for cross-platform root filesystem
Labels: NeedsInvestigation

I wrote a little package called [cdup](https://github.com/josharian/cdup) that walks a directory and each of its ancestors looking for a file/dir. This is useful e.g. to find the root of a git dir (look for `.git`) or a Go module (look for `go.mod`).

I aimed to write it using `fs.FS` and use `os.DirFS` as a bridge to the OS filesystem as needed, perhaps inside a wrapper function.

I may just be holding it wrong, but I encountered a few surprising bumps.

A typical invocation is `cdup.Find(pwd, ".git")`. The obvious but wrong translation of this is `cdup.FindIn(os.DirFS("/"), pwd, ".git")`.

What is the correct root path to pass to `os.DirFS` on Windows? `filepath.VolumeName` seems like the right API to use. (I think?)

Then we must convert `pwd` to a relative path using `filepath.Rel`. On Windows, we also need to call `filepath.ToSlash`.

So I believe that the correct code is something like:

```go
root := "/"
if vol := filepath.VolumeName(dir); vol != "" {
  root = vol
}
rel := filepath.Rel(root, dir)
rel = filepath.ToSlash(rel)
cdup.FindIn(os.DirFS(root), rel, ".git")
```

This is a surprising amount of non-obvious work for what seems like it should be a trivial bridge between fs.FS and the OS filesystem.

I'm not sure exactly what the fix should be here. Docs/examples? New package filepath API to get the OS fs root for a path? New package os API to construct a root filesystem (and expose the root for use with filepath.Rel)?
Repository: transformers
Issue: Better Fine-Tuning by Reducing Representational Collapse
Labels: Feature request

# 🚀 Feature request

Add r3f/r4f to some popular objective functions as suggested by [Armen et. al](https://arxiv.org/abs/2008.03156).

## Motivation

Finetuning is a primary use case of many users of the transformers library.
We can use r3f/r4f to reduce representation collapse by vocabulary inefficiencies.
This is also a relatively cheap feature to implement.

## Your contribution

Understand that this is a relatively new paper with not too much benchmarking done. Will do PR if requested.
Repository: rust
Issue: Unclear compiler error when `impl Trait` return value captures non-'static argument
Labels: A-diagnostics,A-lifetimes,T-compiler,A-impl-trait,C-bug,D-papercut,D-newcomer-roadblock,fixed-by-TAIT

(cc @estebank)

I tried this code (the explicit `'static` lifetime is unnecessary but emphasizes the implicit `'static` requirement of `impl Trait`):

```rust
fn foo<T>(a: T) -> impl Iterator<Item = String> + 'static
where
    T: std::fmt::Display
{
    std::iter::once(a.to_string())
}

fn bar(a: &str) -> impl Iterator<Item = String> + 'static {
    foo(a)
}
```

See [playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=2434854bb55fd556e785d9e14cf9ffd2).

I expected to see this happen:

Successful compilation or a clear error message suggesting that `impl Trait` can't be used in this way due to the non-`'static` lifetime of `foo`'s argument `a`.

Instead, this happened:

```
error[E0759]: `a` has an anonymous lifetime `'_` but it needs to satisfy a `'static` lifetime requirement
 --> src/lib.rs:9:9
  |
8 | fn bar(a: &str) -> impl Iterator<Item = String> + 'static {
  |           ---- this data with an anonymous lifetime `'_`...
9 |     foo(a)
  |         ^ ...is captured here...
  |
note: ...and is required to live as long as `'static` here
 --> src/lib.rs:8:20
  |
8 | fn bar(a: &str) -> impl Iterator<Item = String> + 'static {
  |                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
help: consider changing the `impl Trait`'s explicit `'static` bound to the lifetime of argument `a`
  |
8 | fn bar(a: &str) -> impl Iterator<Item = String> + '_ {
  |                                                   ^^
help: alternatively, add an explicit `'static` bound to this reference
  |
8 | fn bar(a: &'static str) -> impl Iterator<Item = String> + 'static {
  |           ^^^^^^^^^^^^
```

`foo`'s return value isn't dependent on `a`'s lifetime since `to_string` converts it to an owned `String`. Returning `Box<dyn Iterator<Item = String>>` instead of using `impl Trait` fixes the error.

Neither of the compiler's suggestions are the "right" fix here, since I'd like the return value to have a `'static` lifetime but don't want to require `a` to have one.

I think the ideal fix (to the error message) would be something along the lines of:
* a short explanation of why `impl Trait` doesn't allow the return value not to depend on the lifetime of `a` (maybe with a tracking issue if this limitation is being addressed)
* an additional suggestion to use `Box<dyn Trait>` and/or a concrete type

### Meta

`rustc --version --verbose`:
```
rustc 1.50.0 (cb75ad5db 2021-02-10)
binary: rustc
commit-hash: cb75ad5db02783e8b0222fee363c5f63f7e2cf5b
commit-date: 2021-02-10
host: x86_64-apple-darwin
release: 1.50.0
```
Repository: storybook
Issue: StorybookJS - AngularJS - Controls Addons - Select Control Type with HTML Optgroup
Labels: feature request,addon: controls

**Is your feature request related to a problem? Please describe**
I have a huge dropdown list and a set of categories. I did not find a way to pass in the optgroups for the select control type. Could you please let me know how can I achieve this by providing me a reference code for AngularJS. Thank You, in advance :)

**Describe the solution you'd like**
Ability to pass the opt-groups for the select control type. [link](https://storybook.js.org/docs/react/essentials/controls)

**Describe alternatives you've considered**
N/A

**Are you able to assist to bring the feature to reality?**
Apologies, no

**Additional context**
I have attached the screenshot what is expected from the select control type and how can I achieve the same.

![image](https://user-images.githubusercontent.com/7280745/108018528-fed60480-7052-11eb-8ef7-b2d430e81932.png)
Repository: pytorch
Issue: "LayerNormKernelImpl" not implemented for 'Half' - CPU
Labels: module: nn,module: cpu,triaged,enhancement,module: half

## 🐛 Bug

May be this is more of a feature request than a bug.

LayerNorm doesn't work on CPU with half precision (it works on GPU though).

## To Reproduce


Steps to reproduce the behavior:

Run the following piece of code

```python
import torch

torch.layer_norm(torch.tensor([1., 2., 3.], dtype=torch.float16, device='cpu'), normalized_shape=(3,))
```

## Expected behavior

It should just return the normalized vector

## Environment

`1.7.0+cu101` on Google Colab

cc @VitalyFedyunin @albanD @mruberry @jbschlosser
Repository: TypeScript
Issue: "Generic type ' Example' requires 1 type argument(s)." ts(2314) not thrown in .d.ts file
Labels: Bug

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

### 🔎 Search Terms

<!--
  What search terms did you use when trying to find an existing bug report?
  List them here so people in the future can find this one more easily.
-->
- generic type
- ts 2314
- .d.ts

### 🕗 Version & Regression Information

<!-- When did you start seeing this bug occur?

"Bugs" that have existed in TS for a long time are very likely to be FAQs; refer to
  https://github.com/Microsoft/TypeScript/wiki/FAQ#common-bugs-that-arent-bugs

If possible, please try testing the nightly version of TS to see if it's already been fixed.
  For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly

Note: The TypeScript Playground can be used to try older versions of TypeScript.

Please keep and fill in the line that best applies:
-->
- Versions I tried: I tried `3.3.3`, `4.1.3` and `4.3.0-dev.20210216`.

### ⏯ Playground Link

<!--
  A link to a TypeScript Playground "Share" link which shows this behavior

  The TypeScript Workbench can be used for more complex setups, try
  https://www.typescriptlang.org/dev/bug-workbench/

  As a last resort, you can link to a repo, but these will be slower for us to investigate.
-->
[Repo link with relevant code](https://github.com/donaldpipowitch/d-ts-bug-demo)

(Repo is small. TypeScript is the only dependency.)

### 💻 Code

<!-- Please post the relevant code sample here as well-->
```ts
export type Example = {
  _links: Links<>; // throws error in a .ts file, but not a .d.ts file
};
```

### 🙁 Actual behavior

<!-- What happened, and why it was wrong -->
No error thrown.

### 🙂 Expected behavior

<!-- What you expected to happen instead, and why -->
Throw `"Generic type ' Example' requires 1 type argument(s)." ts(2314)`.