sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: No mousewheel events on Ubuntu 18.04
Labels: engine,platform-linux,a: desktop,e: OS-version specific,P2,team-linux,triaged-linux

At work I have issue with mouse wheel on Flutter Desktop on Linux Mint 19.3 (based on 18.04 LTS).
Lists are draggable (they are scrolling with click&drag) but no scrollable with mouse. 
I tried also `Listener` widget and `onPointerSignal` method is not triggered when scrolling.

At home I have Linux Mint 20.1 (based on Ubuntu 20.04) and everything works fine - scrolling works and `onPointerSignal` receive event. 

I wonder if it is problem with use of older `clang`, `cmake`, `ninja` versions.

I don't know if also a layer from remote desktop (working from home, on machine at work) is making the issue - but everywhere else on the system mousewheel works as expected.

<details>

```
Analyzing bug...                                                  
No issues found! (ran in 1.2s)
```

<!-- Finally, paste the output of running `flutter doctor -v` here. -->

```
[✓] Flutter (Channel dev, 2.1.0-10.0.pre, on Linux, locale pl_PL.UTF-8)
    • Flutter version 2.1.0-10.0.pre at /home/dgr/development/flutter
    • Framework revision cc9b78fc5c (2 weeks ago), 2021-02-25 13:26:03 -0800
    • Engine revision a252ec09b7
    • Dart version 2.13.0 (build 2.13.0-77.0.dev)

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at /home/dgr/Android/Sdk
    • Platform android-30, build-tools 30.0.3
    • ANDROID_HOME = /home/dgr/Android/Sdk
    • Java binary at: /home/dgr/.local/share/JetBrains/Toolbox/apps/AndroidStudio/ch-0/201.7042882/jre/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)
    • All Android licenses accepted.

[✓] Chrome - develop for the web
    • Chrome at google-chrome

[✓] Linux toolchain - develop for Linux desktop
    • clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
    • cmake version 3.10.2
    • ninja version 1.8.2
    • pkg-config version 0.29.1

[✓] Android Studio
    • Android Studio at /home/dgr/.local/share/JetBrains/Toolbox/apps/AndroidStudio/ch-0/201.7042882
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • android-studio-dir = /home/dgr/.local/share/JetBrains/Toolbox/apps/AndroidStudio/ch-0/201.7042882
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)

[✓] Connected device (2 available)
    • Linux (desktop) • linux  • linux-x64      • Linux
    • Chrome (web)    • chrome • web-javascript • Google Chrome 90.0.4430.19 dev

• No issues found!

```

</details>
Repository: godot
Issue: Unknown global transform when Particles2D is set to false for local coordinates and connected to PhysicsBody2D
Labels: bug,confirmed,topic:physics,topic:2d,topic:particles

**Godot version:**
Using Godot 3.22, and also verified with Godot 3.2.4rc4

**OS/device including version:**
Windows 10 Pro
OpenGL ES 3.0 Renderer: GeForce RTX 2070 with Max-Q Design/PCIe/SSE2


**Issue description:**
I have a 2d lantern hanging from a chain. The lantern has three particles2d effects on it: Sparks, fire, and smoke. When I set the Local Coords to false for all three particle effects the behavior is expected and when I bump into lantern, the lantern swings and the particles are "left" in global coordinates, as expected.

My intention was to disable emitting of the "fire" particles if the "capture_rect" result is not within the rectangle of the sprite. The result of the "capture_rect" (when the Local Coords is disabled) is in a certain global transform that I cannot "determine"? I have tried the following:

`
ar _rootGlobalTransform = get_tree().root.get_child(0).get_global_transform()
var _tempParticlesRectangle = _rootGlobalTransform.xform(get_node("Lantern_Basic_Particle_Smoke").capture_rect())
print(_tempParticlesRectangle)
_tempParticlesRectangle = get_node("Lantern_Basic_Particle_Smoke").capture_rect()
print(_tempParticlesRectangle)
var _tempParticlesTransform = get_node("Lantern_Basic_Particle_Smoke").get_global_transform()
_tempParticlesRectangle = _tempParticlesTransform.xform(get_node("Lantern_Basic_Particle_Smoke").capture_rect())
print(_tempParticlesRectangle)
`

The first two print instructions provides the same result, hence my assumption is that the coordinates are based upon the global transform, however, the information does not make sense. The third one starts of by saying the rectangle starts at 0,0. If I just enable the Local Coords for the particle system, then (apart from the obvious that the particles move with the lantern), then the result of "capture_rect" makes sense and is as the particles is (if I do the last "print" section as mentioned).

Either the "capture_rect" is computed incorrectly when the Local Coords are set to false or I am missing a specific transform to this?

**Minimal reproduction project:**
I have added a minimal project that demonstrates the behavior:
[Bug_Capture_Rect.zip](https://github.com/godotengine/godot/files/6129256/Bug_Capture_Rect.zip)

This example has two identical particle system overlapping, one is set to true and the other false for the Local Coords setting, I then display the global and local values recieved.
Repository: PowerToys
Issue: [Feature Request] 'Window Snap' to another window's size
Labels: Idea-Enhancement,Product-Window Manager

## 📝 FancyZones 'Window Snap' to another window's size

_What is the expected behavior of the proposed feature?  What is the scenario this would be used?_

While dragging a window and holding the shift-key to activate zones, there would be another hotkey (ex: right click) that would allow you to hover over another currently active window and snap to it's size/shape. 

Extra fancy:
Could also snap to it's size/shape & position. Or snap to size/shape & position with a small jitter  in position to make it cascaded with the first window.

Use case num 1: Custom windows, certain apps are unique for their usage and typically have different desirable dimensions that don't look as good in the usual 16:9 or 4:3 or 9:8 (half screen). Typically most fancyzones are probably designed for common apps such as text editors, web browsers, file explorer, and etc. But a few examples of uniquely shaped apps are the calculator, widgets, terminals, system hardware monitors, etc. When I resize a window to a special shape (ex: skinny vertical) then it may be useful to open another window, shift+drag+rightclick to shape this new window to this unique shape based on the shape of an already open window.

Use case num 2: Cascaded windows with custom size. I'll use myself as an example. I was editing a PowerPoint and using a handful of old custom PowerPoints to grab old graphics from (stacked on a second monitor for reference). These windows had a unique aspect ratio and I wanted to drag and resize each new one I opened to the similar size/shape of the other PowerPoint windows. Thus I could have them neatly organized on a second monitor, all with the ideal aspect ratio. This unique aspect ratio did not match my regular template that is designed for 4:3 16:9 etc common ratio windows.

---

If you'd like to see this feature implemented, add a 👍 reaction to this post.
Repository: terminal
Issue: Expose time, date, mouse, ideally CPU / GPU / memory utilization to custom HLSL shaders
Labels: Issue-Feature,Area-Rendering,Product-Terminal


# Description of the new feature/enhancement

Custom shaders rock, but they would rock even more if they were interactive. They simply don't know what's happening outside of the shader. I would love to have my shaders respond to what's happening on the system: for example, have them change color by time of day, or have them act up and be all energetic when CPU utilization is high, and calm down when CPU utilization is low. That would be a totally sweet command prompt.

# Proposed technical implementation details (optional)


On the HLSL side, expose additional state in the cbuffer. I don't think this would break existing shaders if we just add items to the end of the cbuffer, but even if it does, hey, it's an experimental feature as someone said. :)
 
```
cbuffer PixelShaderSettings {
  float  Time;
  float  Scale;
  float2 Resolution;
  float4 Background;

  // Additional proposed constants

  float4 TimeOfDay;        // .x = hours; .y = minutes; .z = seconds; .w = msecs
  float4 Date;             // .x = year;  .y = month;   .z = day
  float  CpuUtilization;
  float  MemoryUtilization;
  float  GpuUtilization;   // ok, may be a long shot, but would be nice to have
  float2 Mouse;            // Mouse coordinates if mouse is over the window! Interactive pixel shader backgrounds! :)
};
```

Minor tech note: if fetching cpu / memory / gpu utilization is costly, it's ok to do them every 500ms or so. They don't need to be per-frame.


----

_maintainer notes:_

#15837 is another feature that might be a good thing to plumb through here. Consider: swapchainPosition, so that you can use the offset relative to the desktop origin. (we would of course have to plumb the desktop image into the shader, ala #14073)
Repository: pytorch
Issue: GoogleNet pretrained/scratch bug?
Labels: triaged,module: vision

## 🐛 Bug

<!-- A clear and concise description of what the bug is. -->
After the model training, there is a huge difference between the evaluation directly on the test machine and the evaluation after the model weight is saved and reloaded. This is a problem existing in the GoogleNet pretrained mode, but the model of training from scratch does not have this problem. I also made a comparison between resnet18 pretrained and scratch, but there is no such problem.
## To Reproduce

Steps to reproduce the behavior:

```
        net = models.googlenet(pretrained=True, aux_logits=False)
        net.fc = nn.Linear(1024, num_classes)
        ....
        best_acc = 0.0
        ....
        if test_acc > best_acc:
            best_acc = test_acc
            torch.save(net.state_dict(), os.path.join('.', 'checkpoints', 'model_best_acc.pt'))

        ....
       # reload
       net = models.googlenet(num_classes=num_classes, aux_logits=False)
       net.load_state_dict(torch.load(os.path.join('.', 'checkpoints', 'model_best_acc.pt'), map_location=device))
```


## Environment

Collecting environment information...
PyTorch version: 1.6.0
Is debug build: False
CUDA used to build PyTorch: 10.1
ROCM used to build PyTorch: N/A

OS: CentOS Linux 7 (Core) (x86_64)
GCC version: (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39)
Clang version: Could not collect
CMake version: Could not collect

Python version: 3.7 (64-bit runtime)
Is CUDA available: True
CUDA runtime version: Could not collect
GPU models and configuration: 
GPU 0: Tesla V100-PCIE-32GB
GPU 1: Tesla V100-PCIE-32GB
GPU 2: Tesla V100-PCIE-32GB
GPU 3: Tesla V100-PCIE-32GB

Nvidia driver version: 450.80.02
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.19.4
[pip3] torch==1.6.0
[pip3] torchsummary==1.5.1
[pip3] torchvision==0.7.0
[conda] blas                      1.0                         
[conda] cudatoolkit               10.1.243             
[conda] mkl                       2020.2                    
[conda] mkl-service               2.3.0           
[conda] mkl_fft                   1.2.0           
[conda] mkl_random                1.1.1           
[conda] numpy                     1.19.4                  
[conda] numpy-base                1.19.2           
[conda] pytorch                   1.6.0          
[conda] torchsummary              1.5.1                    
[conda] torchvision               0.7.0                





cc @fmassa @vfdev-5
Repository: go
Issue: cmd/go: "no required module provides package" is confusing for paths under the current module
Labels: NeedsFix,GoCommand,modules

Using https://pkg.go.dev/golang.org/x/tools/cmd/benchcmp as an example:

```
$ go version
go version devel +cf59850466 Wed Mar 10 09:01:05 2021 +0000 linux/amd64
$ cd tools
$ git checkout -q 44abc2a71b321b77c0a579d8c5bf2704d648c9e0
$ cd cmd/benchcmp
$ sed -i 's@benchmark/parse@missing/package@g' *.go
$ go build
benchcmp.go:15:2: no required module provides package golang.org/x/tools/missing/package; to add it:
	go get golang.org/x/tools/missing/package
$ go get golang.org/x/tools/missing/package
go get golang.org/x/tools/missing/package: no matching versions for query "upgrade"
```

What I do here is add an import to a missing package that could be part of the current main module. The example I use is perhaps silly, but it's somewhat common to end up in this situation. For example:

* Rebasing or applying an old patch that imports a package which is now moved or deleted
* Writing an import manually and making a typo

I get why the errors are technically correct. When I run `go build`, the go tool doesn't know if there happens to be a module with path `golang.org/x/tools/missing` or `golang.org/x/tools/missing/package`, which could possibly contain the package needed. And, when I run the `go get`, it finds no such module, and the main module can't be upgraded to contain such a package.

First, an assumption: nested Go modules are very rare, and should not be encouraged. So I don't think that we should be optimizing the error messages for that use case.

Now, some suggestions from the user's point of view, for this scenario:

1) The `go build` error shouldn't suggest `go get`. It's very unlikely that it will fix the problem. If the user really has nested modules that would be fixed with a `go get`, I imagine they know what they're doing and can figure out what to do.

For example, here's a suggestion:

```
$ go build
benchcmp.go:15:2: package golang.org/x/tools/missing/package does not exist in the main module
```

2) The `go get` error is confusing. For example, see what happens if I try to upgrade the main module:

```
$ go get -d golang.org/x/tools@latest
go get: can't request version "latest" of the main module (golang.org/x/tools)
```

Now, compare that with package paths:

```
$ go get -d golang.org/x/tools/foo/bar
go get golang.org/x/tools/foo/bar: no matching versions for query "upgrade"
$ go get -d golang.org/x/tools/foo/bar@latest
go get golang.org/x/tools/foo/bar@latest: no matching versions for query "latest"
```

If no nested module is found, I think it should just show the `can't request version` error, just like `go get -d golang.org/x/tools@latest`.
Repository: flutter
Issue: [flutter_localizations] Add a setting to l10n.yaml to specify the abstract class as an interface for the generated class (AppLocalizations). 
Labels: tool,a: internationalization,c: proposal,P3,team-tool,triaged-tool

When creating a package with support for localization, it would be possible to describe the necessary getters in an abstract interface, specify a delegate in the application that will return the generated class with support for this interface. Then, inside the package, there will be access to the necessary text strings.

## Use case

In the package
```
abstract class PackageL10n {
  /// Caption of the widget
  String get caption;

  /// Text on the button
  String get buttonText;
}

// Usage
Text(
  Localizations.of<PackageL10n>(context, PackageL10n).caption,
)
```

In the application
```
@override
Widget build(BuildContext context) {
  return MaterialApp(
    ...
    localizationsDelegates: [
      L10nGenericDelegate<PackageL10n>({'en': AppLocalizationsEn()}),
      ...AppLocalizations.localizationsDelegates,
    ],
    supportedLocales: AppLocalizations.supportedLocales,
    ...
  );
}
```

Generic delegate code
```
class L10nGenericDelegate<T> extends LocalizationsDelegate<T> {
  final Map<String, T> localizations;

  const L10nGenericDelegate(this.localizations);

  @override
  Future<T> load(Locale locale) {
    return SynchronousFuture<T>(_lookup(locale));
  }

  @override
  bool isSupported(Locale locale) => localizations.keys.contains(locale.languageCode);

  @override
  bool shouldReload(L10nGenericDelegate<T> old) => false;

  T _lookup(Locale locale) {
    if (localizations.containsKey(locale.languageCode)) {
      return localizations[locale.languageCode];
    }

    throw FlutterError('L10nGenericDelegate.delegate failed to load unsupported locale "$locale". This is likely '
        'an issue with the localizations generation tool. Please file an issue '
        'on GitHub with a reproducible sample app and the gen-l10n configuration '
        'that was used.');
  }
}
``` 

## Proposal

To implement this approach, at the moment, you have to do it using the following workround:
```
class AppLocalizationsEnPackage extends AppLocalizationsEn with PackageL10n {}
```

This could have been avoided if for the generated class it was possible to specify a mixin and it would turn out like this:
```
abstract class AppLocalizations with PackageL10n {
  ...
}
```
Repository: pytorch
Issue: Check Archive.org for Failed Dataset Downloads
Labels: module: dependency bug,triaged,enhancement

## 🚀 Feature

Upon the failure of a download of a built-in dataset, the downloader should try downloading from Archive.org.

## Motivation

For the last day or so the host for the MNIST dataset has been down resulting in `HTTPError: HTTP Error 503: Service Unavailable` when attempting to use the download feature of the MNIST dataset class. Since it is common that hosts go down for a variety of reasons, it would be a good idea to have an alternate means of downloading the data directly through the convenient interface provided by the torchvision datasets package.

## Pitch

Upon an HTTP failure to download a dataset from the default URL, the dataset downloader should attempt to download it from one or several backup locations. One reliable backup location is at Archive.org where snapshots of the internet are taken on a regular basis. For example, the labels for the test set of the MNIST dataset can be found here: 

https://web.archive.org/web/20210124213857/http://yann.lecun.com/exdb/mnist/t10k-labels-idx1-ubyte.gz

## Alternatives

Two possible alternatives include:

1. Rather than rely on other hosts, the pytorch team could choose to host all of the datasets on their own.
2. Have dataset data available in a peer to peer fashion using the BitTorrent or similar protocol.

The first alternative does not seem feasible since it would rely on a significant amount of resources while the second alternative seems like it would be more challenging to implement than the original proposal.

## Additional context

N/A


cc @ezyang @seemethere @malfet @walterddr @pytorch/pytorch-dev-infra
Repository: pytorch
Issue: terminate called after throwing an instance of 'c10::Error'   what():  isTuple() INTERNAL ASSERT FAILED at "/home/wenda/libtorch/include/ATen/core/ivalue_inl.h":927, please report a bug to PyTorch. Expected Tuple but got GenericList
Labels: needs reproduction,module: crash,module: cpp,triaged

```
terminate called after throwing an instance of 'c10::Error'
  what():  isTuple() INTERNAL ASSERT FAILED at "/home/wenda/libtorch/include/ATen/core/ivalue_inl.h":927, please report a bug to PyTorch. Expected Tuple but got GenericList
Exception raised from toTuple at /home/wenda/libtorch/include/ATen/core/ivalue_inl.h:927 (most recent call first):
frame #0: c10::Error::Error(c10::SourceLocation, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) + 0x69 (0x7f38baf4cb89 in /home/wenda/libtorch/lib/libc10.so)
frame #1: main + 0xd41 (0x5595dbce8d11 in ./YOLOv5LibTorch)
frame #2: __libc_start_main + 0xe7 (0x7f386bf36bf7 in /lib/x86_64-linux-gnu/libc.so.6)
frame #3: _start + 0x2a (0x5595dbcea11a in ./YOLOv5LibTorch)
```





cc @ezyang @gchanan @zou3519 @bdhirsh @jbschlosser @anjali411 @yf225 @glaringlee
Repository: go
Issue: testing/fstest: test that ReadDir on file returns error, or returns 0 entries if file is empty
Labels: help wanted,NeedsFix

The Plan 9 builders are consistently failing on the new check added to `testing/fstest.TestFS` in [CL 296391](https://golang.org/cl/296391)
```
--- FAIL: TestDirFS (0.07s)
    os_test.go:2720: TestFS found errors:
        a: ReadDir of non-dir file should return an error
        b: ReadDir of non-dir file should return an error
        dir/x: ReadDir of non-dir file should return an error
FAIL
FAIL	os	9.258s
```

[2021-03-12T02:56:04-e8b8278/plan9-arm](https://build.golang.org/log/3ccea637923a00d784c58608d7546a291773f768)
[2021-03-12T02:30:33-e87c4bb/plan9-arm](https://build.golang.org/log/b6dc1bb71e730d1570e31a9e558e1bccd70f60d0)
[2021-03-12T01:47:01-a607408/plan9-arm](https://build.golang.org/log/d8e8f2222e2d4f8bf29615e6eda36377ecd516e3)
[2021-03-12T00:52:00-71a6c13/plan9-arm](https://build.golang.org/log/356638e6e051e0188227d17d7a760f93a5941d24)
[2021-03-11T21:43:04-7fc638d/plan9-arm](https://build.golang.org/log/f30dc1e0240cc867047e6d37eeeff737cc773750)
[2021-03-11T20:46:21-b3896fc/plan9-arm](https://build.golang.org/log/dff7d3083f988a55afc79e91653d9ee5c6a4e89e)
[2021-03-11T20:01:00-4dd9c7c/plan9-arm](https://build.golang.org/log/b289e23ffc143ccf90285560d3df790b043a919d)
[2021-03-11T19:11:46-43d5f21/plan9-arm](https://build.golang.org/log/6257a52ca489109fa3405bb4a1630382569e5426)
[2021-03-11T19:04:42-b0733ba/plan9-386-0intro](https://build.golang.org/log/40e281ab300f7db24d3d35a81ee2c2aab144869e)
[2021-03-11T19:04:42-b0733ba/plan9-arm](https://build.golang.org/log/6333b0102a50b892d33c88893dbd5e3e7b2ec4fb)
[2021-03-11T19:00:06-64d323f/plan9-arm](https://build.golang.org/log/51f89cc77f103c5bc4f4e076aab952f542daf28e)
[2021-03-11T18:50:12-ae9cd12/plan9-arm](https://build.golang.org/log/6ef240d14bb71875237fcca1cf44c2f22e2f713e)
[2021-03-11T18:25:50-86d6678/plan9-386-0intro](https://build.golang.org/log/07e1b0f1aa531cac0683d560e2f5e983f8b4821e)
[2021-03-11T18:25:50-86d6678/plan9-arm](https://build.golang.org/log/f7c3bc687706e19487232b68735127619f3e79c1)
[2021-03-11T18:25:41-1853411/plan9-arm](https://build.golang.org/log/a1862331bced17ae2bc31f7cf1a802374c51fa4b)

It's not obvious to me whether this is a defect in the `os` implementation of `ReadDir` on Plan 9, or an overly-optimistic assertion in `testing/fstest.TestFS`.

CC @josharian @rsc @ianlancetaylor @fhs @millerresearch @0intro