sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: storybook
Issue: Update standalone-preview to not use deprecated configure
Labels: feature request,needs triage

**Is your feature request related to a problem? Please describe**
The standalone-preview example still uses the deprecated `configure` method:
https://github.com/storybookjs/storybook/blob/ea65ace452f0243072cd89eea1bdb642dee3fa40/examples/standalone-preview/storybook.ts#L15

**Describe the solution you'd like**
Update the example.

**Describe alternatives you've considered**
Accept that this prints a deprecation message and eventually stops working.

**Are you able to assist to bring the feature to reality?**
maybe, if I can get advice on how to implement it.
Repository: neovim
Issue: unclear behavior of keymap function callback for visual mode mappings
Labels: mappings

### Neovim version (nvim -v)

v0.8.0-dev+96-gd9dcfd021

### Vim (not Nvim) behaves the same?

-

### Operating system/version

macOS 12.2

### Terminal name/version

kitty 0.25.0

### $TERM environment variable

tmux-256color

### Installation

build

### How to reproduce the issue

```lua
function Print_range()
    local pos = {
        start = vim.fn.getpos("'<"),
        ["end"] = vim.fn.getpos("'>"),
    }
    vim.pretty_print(pos)
end

vim.keymap.set({ "n", "x" }, "<leader>v", Print_range)
vim.keymap.set({ "n", "x" }, "<leader>V", ":lua Print_range()<cr>")
```

enter visual mode on line 1 and use `<leader>v`
enter visual mode on line 2 and use `<leader>V`

### Expected behavior

the two mappings behave identically in visual mode.

### Actual behavior

when using the callback mapping during visual mode, visual range position is not updated.

it would be nice to control the execution of the callback as if it was executed using `":<C-u>call luaref()<cr>"` versus `"<cmd>call luaref()<cr>"`
Repository: godot
Issue: Inherited scenes with PopupMenu only respects inheritance if base scene is open during saving
Labels: bug,topic:editor

### Godot version

3.4.4

### System information

Windows 10

### Issue description

When using a base scene (`Base.tscn`) with a PopupMenu node, any **inherited** scene's content will be different depending on if the base scene is open (in the editor) or not.

 **Base.tscn**
```
[gd_scene format=2]

[node name="Base" type="Control"]
anchor_right = 1.0
anchor_bottom = 1.0

[node name="PopupMenu" type="PopupMenu" parent="."]
margin_right = 20.0
margin_bottom = 20.0
items = [ "Item 0", null, 0, false, false, 0, 0, null, "", false ]
```

 **Inherited.tscn** (If Base.tscn is open in the editor) = GOOD
```
[gd_scene load_steps=2 format=2]

[ext_resource path="res://Base.tscn" type="PackedScene" id=1]

[node name="Inherited" instance=ExtResource( 1 )]
```

 **Inherited.tscn** (If Base.tscn is **NOT** open in the editor) = BAD
```
[gd_scene load_steps=2 format=2]

[ext_resource path="res://Base.tscn" type="PackedScene" id=1]

[node name="Inherited" instance=ExtResource( 1 )]

[node name="PopupMenu" parent="." index="0"]
items = [ "Item 0", null, 0, false, false, 0, 0, null, "", false ]
```

So in the case of not having the base open, the PopupMenu is saved redundantly...
Which is mostly annoying and more of a pet peeve of mine I would imagine.

### Steps to reproduce

1. Make a scene with a PopupMenu (+ Add an item to it) and save it as `Base.tscn`
2. Create an inherited scene `Inherited.tscn` which inherits from `Base.tscn`

Two cases:
- Save `Inherited.tscn` WHILE `base.tscn` is open in the editor --> `Inherited.tscn` saves correctly
- Save `Inherited.tscn` WHILE `base.tscn` is NOT open in the editor --> `Inherited.tscn` is bloated with redundant information

### Minimal reproduction project

[Inherited Scene with PopupMenu.zip](https://github.com/godotengine/godot/files/8598767/Inherited.Scene.with.PopupMenu.zip)
Repository: youtube-dl
Issue: MEGA.NZ SUPPORT
Labels: site-support-request

## Checklist
- [x] I'm reporting a new site support request
- [x] I've verified that I'm running youtube-dl version **2021.12.17**
- [x] I've checked that all provided URLs are alive and playable in a browser
- [x] I've checked that none of provided URLs violate any copyrights
- [x] I've searched the bugtracker for similar site support requests including closed ones


## Example URLs
- Single link: https://mega.nz/file/jSh2gBwY#XKIUH0VhebYshA4oWbBES4gATLzas_EagmyuqKbYWGo
- Folder: https://mega.nz/folder/2Ox0EZYS#PjfMx4pPPg0xtvSw3CZ5jQ


## Description
plz add suppot for mega.nz, its a pain to download without archive support with mega sync
Repository: godot
Issue: ISO8601 datetime parsing in `Time.get_unix_time_from_datetime_string`
Labels: bug,topic:core

### Godot version

v4.0.alpha7.official [3e9ead05f]

### System information

Windows 10

### Issue description

There are still some inconsistencies in ISO8601 datetime parsing.

### Steps to reproduce

### Valid ISO 8601 strings that fail

```gdscript
func test_valid_iso8601_strings():
	var valids = [
		'2022-12-31T12:34', # seconds are optional
		'2022-12-31T12',    # minutes are optional too
		'20221231',         # short format date
		'20221231T123456',  # short format datetime
	]	
	for valid in valids:
		print(valid, ' = ', Time.get_unix_time_from_datetime_string(valid))
```

Output:

```
2022-12-31T12:34 = -1
2022-12-31T12 = -1
20221231 = 0
20221231T123456 = -1
```

I think optional seconds and minutes should be supported (first two test cases). ISO 8601 contains also short format for date and time (last two test cases). Sure, it would be nice if short format were supported, but in my experience ISO 8601 pretty much always means the long format. If the short format is not supported, it should be said in the documentation.

###  Return value 

`Time.get_unix_time_from_datetime_string` seems to return either 0 or -1 when parsing fails. That makes checking errors a little bit more difficult compared to a single error value. This is error prone, if the code just checks if the return value is 0. I would suggest using only one error value.

###  Invalid ISO 8601 strings that succeed

```gdscript
func test_invalid_iso8601_strings():
	var invalids = [
		'1999 2022-12-31T12:34:56',    # totally invalid format gets odd result
		'2022-12-31-09T12:34:56',      # garbage in date is silently ignored
		'  2022-12-31T12:34:56',       # leading spaces are allowed
		'2022-12-31 12:34:56',         # space is not an accepted separator in ISO 8601
	]
	for invalid in invalids:
		var t = Time.get_unix_time_from_datetime_string(invalid)
		print(invalid, ' = ', t, ' = ', Time.get_datetime_string_from_unix_time(t))
```

Output:

```
1999 2022-12-31T12:34:56 = 946643696 = 1999-12-31T12:34:56
2022-12-31-09T12:34:56 = 1672490096 = 2022-12-31T12:34:56
  2022-12-31T12:34:56 = 1672490096 = 2022-12-31T12:34:56
2022-12-31 12:34:56 = 1672490096 = 2022-12-31T12:34:56
```

I think the first two cases should be fixed, especially the first one. The last two cases are less severe although I think that ISO 8601 parser should not do white space trimming as it might cause not noticing incorrect data.

### Minimal reproduction project

_No response_
Repository: terminal
Issue: Bracketed paste mode probably shouldn't disable the multiline paste warning
Labels: Help Wanted,Area-Input,Issue-Bug,Product-Terminal,Priority-3

### Windows Terminal version

1.13.10336.0

### Windows build number

10.0.19041.1415

### Other Software

_No response_

### Steps to reproduce

1. Make sure the [`multilinePasteWarning`](https://docs.microsoft.com/en-us/windows/terminal/customize-settings/interaction#warn-when-the-text-to-paste-contains-multiple-lines) setting is enabled.
2. Open `pwsh` in Windows Terminal tab.
3. Execute the following command: ```echo "`e[?2004h`e]52;;ZGlyCnJlbQo=`e\"```
4. Right click in the terminal window (NB: this is going to execute a `dir` command without prompting - it could just as easily be something more malicious).


### Expected Behavior

I'd expect the terminal should warn me before pasting and executing multiline commands.

### Actual Behavior

The terminal pastes the multiline command without any confirmation and the shell immediately executes it.

Basically we've got a security feature (the multiline paste warning), which can be trivially disabled with an escaped sequence (bracketed paste mode). This might be OK if we could assume all shells supported bracketed paste mode, and wouldn't execute commands when wrapped in a bracketed escape sequence, but that's not the case for PowerShell or the cmd shell.

I realise this behavior was added intentionally (see #7006 and PR #9586), but in retrospect I think that was a mistake. The multiline paste warning is giving an illusion of safety which now can't be relied on.
Repository: godot
Issue: macOS exporter ignores shared objects tags
Labels: platform:macos,documentation,topic:gdextension,topic:export

### Godot version

3.4.4.stable

### System information

macOS 11, M1 Pro, GLES 3

### Issue description

When exporting GDNative shared objects on macOS, the exporter ignores the shared object tags and stores multiple `dylib` files under the same path, effectively overwriting the file. This makes it impossible to export a multi-arch app on macOS.

https://github.com/godotengine/godot/blob/3.4.4-stable/platform/osx/export/export.cpp#L936-L954

Godot Export Log:
```
export dylib: [...]/native/target/x86_64-apple-darwin/release/libnative.dylib -> [...]/Library/Caches/Godot/Game.app/Contents/Frameworks/libnative.dylib
codesign ([...]/Library/Caches/Godot/Game.app/Contents/Frameworks/libnative.dylib):
[...]/Library/Caches/Godot/Game.app/Contents/Frameworks/libnative.dylib: signed Mach-O thin (x86_64) [libnative-555549449b9f202bca4f3c55b3b6bf69762e15a8]

export dylib: [...]/native/target/aarch64-apple-darwin/release/libnative.dylib -> [...]/Library/Caches/Godot/Game.app/Contents/Frameworks/libnative.dylib
codesign ([...]/Library/Caches/Godot/Game.app/Contents/Frameworks/libnative.dylib):
[...]/Library/Caches/Godot/Game.app/Contents/Frameworks/libnative.dylib: replacing existing signature
[...]/Library/Caches/Godot/Game.app/Contents/Frameworks/libnative.dylib: signed Mach-O thin (arm64) [libnative-555549447c38cc49f3c13759a06cbbf489f3bfad]
```


### Steps to reproduce

1. add a gdnative `gdnlib`
2. add the `dylib` paths similar to this:
```
OSX.x86_64="res://native/target/x86_64-apple-darwin/release/libnative.dylib"
OSX.arm64="res://native/target/aarch64-apple-darwin/release/libnative.dylib"
```
2. add the features `x86_64` and `arm64` to the export preset
3. export the project

### Minimal reproduction project

_No response_
Repository: pytorch
Issue: WeightNorm: Add reset_parameters Linear override
Labels: feature,module: nn,triaged,module: norms and normalization

### 🚀 The feature, motivation and pitch

I have faced some problems when trying to **reset the parameters of a Linear module to which I have applied weight normalization**. I have realized that the `reset_parameters` instance method of the Linear module doesn't consider potential modifications of its parameters attributes names, i.e., `self.weights` might be split into `self.weight_g` and `self.weight_v` when using `weight_norm` for instance, so this instance method implementation become kind of useless in these cases.

### Alternatives

I guess that a proper solution may lead to some refactoring, but a naive solution could be just something like this with any luck:

https://github.com/a-canela/pytorch/pull/1/files

### Additional context

Reproducing the issue:

```
import torch

module = torch.nn.utils.weight_norm(torch.nn.Linear(20, 40), name='weight')
params_before = {k: p.mean() for k, p in module.named_parameters()}
module.reset_parameters()
params_after = {k: p.mean() for k, p in module.named_parameters()}
assert all([params_before[k] != params_after[k] for k in params_before])
```

cc @albanD @mruberry @jbschlosser @walterddr @kshitij12345
Repository: godot
Issue: MSBuild-15.9 not working with Godot 3.4.4-mono
Labels: platform:linuxbsd,topic:editor,needs testing,topic:dotnet

### Godot version

3.4.4

### System information

Linux localhost 5.15.32-gentoo-r1-x86_64 #1 SMP Mon Apr 18 21:16:59 CEST 2022 x86_64 Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz GenuineIntel GNU/Linux

### Issue description

I have MSBuild-15.9 installed along with Mono-6.12.0-stable and godot just fails to build any CS file.
The message its reporting is basically telling me that my version is either incompatible or I am missing some dependency.
```
Running: "/home/tino/bin/msbuild"  "/home/tino/Software/godot/test/New Game Projectxxx.sln" /restore /t:Build "/p:Configuration=Debug" /v:normal "/l:GodotTools.BuildLogger.GodotBuildLogger,/home/tino/Software/GodotVersions/Godot_v3.4.4-stable_mono_x11_64/GodotSharp/Tools/GodotTools.BuildLogger.dll;/home/tino/.local/share/godot/mono/build_logs/412526998dd3745cb2b486a94e16e341_Debug" /p:GodotTargetPlatform=x11
Microsoft (R) Build Engine version 15.9.20.62856 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

MSBUILD : Logger error MSB1029: The "GodotTools.BuildLogger.GodotBuildLogger" logger could not be instantiated from the assembly "/home/tino/Software/GodotVersions/Godot_v3.4.4-stable_mono_x11_64/GodotSharp/Tools/GodotTools.BuildLogger.dll". Please verify the logger assembly has been built using the same version of the Microsoft.Build.Framework assembly as the one installed on your computer and that your host application is not missing a binding redirect for Microsoft.Build.Framework. Specified cast is not valid.

```
`/home/tino/bin/msbuild` is a symlink to `/usr/local/bin/msbuild-15.9`

I have no clue how to proceed beyond this point. Any pointers would help.

### Steps to reproduce

* Install MSBuild-15.9
* Create new project
* Add a node
* Add a C# script
* Call `GD.Print("");` somewhere
* Make sure Godot can find the MSBuild binary
* Build

### Minimal reproduction project

[test.zip](https://github.com/godotengine/godot/files/8599439/test.zip)
Repository: PowerToys
Issue: [FancyZones] Remember window layout when changing display configuration.
Labels: Idea-Enhancement,Product-FancyZones,Needs-Triage,Needs-Team-Response

### Description of the new feature / enhancement

When docking/undocking a portable computer. Your windows end up in a jumbled mess, at least on Windows 10. This is a massive inconvenience. I propose two solutions:

1. When display settings are changed, save the current window layout for the old display configuration, and load the previously saved window layout for the new configuration, if one exists.

2. Allow the user to assign a virtual desktop to a display. In the absence of the physical display, windows that were on that display are moved to the virtual desktop.

### Scenario when this would be used?

Any time the user has multiple displays.

### Supporting information

_No response_
Repository: pytorch
Issue: Pytorch can't process special unicode
Labels: needs reproduction,module: serialization,triaged

### 🐛 Describe the bug

Trying to make use of a program that use pytorch i ended up with this issue:

"[E] UnicodeEncodeError: 'charmap' codec can't encode character \uff0f"
Which "uff0f" is " ／ " A special unicode.
My path folder has this unicode and therefor because of this the program wasn't able to work.
Result...
**The Bug: pytorch is unable to process path folder containing special unicodes**

### Versions

Lastest Version ( 1.11 )

cc @mruberry
Repository: animate.css
Issue: BackOutUp animation has an Opacity of 0.7 at 100%
Labels: feature request

### Describe The Bug

The animation for BackOutUp has an Opacity of 0.7 for 20% and 100%. 

```
0% {
    transform: scale(1);
    opacity: 1;
  }

  20% {
    transform: translateY(0px) scale(0.7);
    opacity: 0.7;
  }

  100% {
    transform: translateY(-700px) scale(0.7);
    opacity: 0.7;
  }
```

I wanted to confirm if this is accurate and whether the opacity should actually be 0. With 0.7 since it is an exit animation, if the area is greater than 700px then the element is still visible. 

### Steps To Reproduce

Apply a BackOutUp animation on a element where the height is greater than 700px

### Expected Behavior

The element disapears from the screen either via the opacity. 

### Screenshots

<img width="705" alt="image" src="https://user-images.githubusercontent.com/9876466/166177635-da720a86-de80-4697-810d-c3f31749ecbc.png">

In the above screenshot the element is still visible. 

### Desktop

- OS MacOS
- Browser Chrome
- Version 100.0.4896.127 (Official Build) (x86_64) 

### Smartphone

_No response_

### Additional Context

_No response_
Repository: pytorch
Issue: `torch.nn.HuberLoss` backwards unexpectedly fail
Labels: module: nn,module: loss,triaged,module: type promotion

### 🐛 Describe the bug

`torch.nn.HuberLoss` backwards unexpectedly fail with error message `Found dtype Float but expected Double`. 
For its documentation, "When delta is set to 1, this loss is equivalent to [SmoothL1Loss](https://pytorch.org/docs/stable/generated/torch.nn.SmoothL1Loss.html#torch.nn.SmoothL1Loss)". As a result, it should succeed to backward like `SmoothL1Loss`

```python
import torch
t1_tensor = torch.rand([67, 1], dtype=torch.float64)
t2_tensor = torch.rand([67, 1], dtype=torch.float32)

t1 = t1_tensor.clone().detach().requires_grad_().to('cpu')
t2 = t2_tensor.clone().detach().requires_grad_().to('cpu')
HL = torch.nn.HuberLoss()
HL_res = HL(t1, t2).sum()
try:
    HL_res.backward()
except Exception as e:
    print("HuberLoss Fail Backward:", e)

t1 = t1_tensor.clone().detach().requires_grad_().to('cpu')
t2 = t2_tensor.clone().detach().requires_grad_().to('cpu')
SL = torch.nn.SmoothL1Loss()
SL(t1, t2).sum().backward()
print("SmoothL1Loss Succeed Backward")

# HuberLoss Fail Backward: Found dtype Float but expected Double
# SmoothL1Loss Succeed Backward
```

### Versions

pytorch: 1.11.0

cc @albanD @mruberry @jbschlosser @walterddr @kshitij12345 @nairbv
Repository: create-react-app
Issue: Yes
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..."
-->

(Write your answer here.)

### Describe the solution you'd like

<!--
  Provide a clear and concise description of what you want to happen.
-->

(Describe your proposed solution here.)

### Describe alternatives you've considered

<!--
  Let us know about other solutions you've tried or researched.
-->

(Write your answer here.)

### 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.
-->

(Write your answer here.)
Repository: neovim
Issue: BufReadCmd/FileReadCmd does not work with vim.ui.select
Labels: bug,lua,events

### Neovim version (nvim -v)

0.7.0

### Vim (not Nvim) behaves the same?

NA

### Operating system/version

Ubuntu 20.04.4 LTS

### Terminal name/version

Kitty 0.15.0/konsole 19.12.3

### $TERM environment variable

xterm-256color

### Installation

appimage

### How to reproduce the issue

```shell
$ nvim --clean -u minimal.lua
```
```
:edit some_file
```

```lua
-- minimal.lua
-- I didn't see a place to upload the minimal.lua so here ya go
local M = {}

function M:do_thing(origination)
    print("Coming from " .. tostring(origination))
    vim.ui.select({"Yes", "No"} ,{prompt = "Yes No?"}, function(choice) print("choice " .. tostring(choice)) end)
end

do
    if not M.inited then
        vim.api.nvim_command('augroup testing')
        vim.api.nvim_command('autocmd!')
        vim.api.nvim_command('augroup END')
        vim.api.nvim_command('autocmd testing BufReadCmd * :lua require("minimal"):do_thing("bufreadcmd")')
        vim.api.nvim_command('autocmd testing FileReadCmd * :lua require("minimal"):do_thing("filereadcmd")')
        M.inited = true
    end
end

return M
```

### Expected behavior

I have had incredibly inconsistent behavior with `vim.ui.select` so I am not exactly sure _what_ I expect at this point. Given the documentation, I would expect for a sort of selection menu to appear when a file is opened. 
Per the documentation
```
select({items}, {opts}, {on_choice})                         *vim.ui.select()*
                Prompts the user to pick a single item from a collection of
                entries
```


### Actual behavior

I am not quite able to pin down what exactly is happening but it appears as if `vim.ui.select` is doing _something_ as the `choice` function is called immediately. I found this by removing the `tostring(choice)` wrapper on the print line. Doing this will generate a `attempt to concatenate a nil value` error when you try to edit a file of any kind.

Using the `minimal.lua` that is attached, you _can_ require the file and manually run the `do_thing` function (eg, `:lua require("minimal"):do_thing()`) and the select appears. So the select functionality works, it just appears to do weird stuff when its called from an autocommand?
Repository: godot
Issue: [right] in RichTextLabel does not work for particular font
Labels: bug,topic:gui

### Godot version

3.4.4

### System information

Mac OS 12.3.1

### Issue description

set bb code to 
[right]5-1 09:04[/right]
show 
09:04  5-1




### Steps to reproduce

set bb code to 

[right]5-1 09:04[/right]  

set font

run

### Minimal reproduction project

[Archive.zip](https://github.com/godotengine/godot/files/8600880/Archive.zip)
Repository: node
Issue: Promise version of stream.finished does not give access to cleanup function
Labels: stream

### Version

16.13.0

### Platform

Darwin Kernel Version 21.3.0: Wed Jan  5 21:37:58 PST 2022; root:xnu-8019.80.24~20/RELEASE_X86_64 x86_64

### Subsystem

streams

### What steps will reproduce the bug?

```
const readStream = fs.createReadStream(<a folder>)
const writeStream = fs.createWriteStream("foo.txt")

readStream.on("error", (error) => {
   throw new errlop('Caught the error', error)'
})

readStream.pipe(writeStream);
await stream.finished(writeStream);
```

### How often does it reproduce? Is there a required condition?

Always reproduces

### What is the expected behavior?

await stream.finished(writeStream) returns the cleanup function specified at https://nodejs.org/docs/latest-v16.x/api/stream.html#streamfinishedstream-options-callback so we can clean up the error call. 

Or that error rejects the promise we're awaiting on and gets treated as part of the normal Promise error handling flow.

### What do you see instead?

"Uncaught Error: Caught the error"

### Additional information

https://github.com/nodejs/node/blob/master/lib/internal/streams/end-of-stream.js#L242 drops the cleanup function that `eos` returns.

I think I can work around this by manually making my own promises that resolve/reject based on callbacks firing