sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: Allow `torch.package` to accept `*.pyc` files
Labels: oncall: package/deploy,imported

### 🚀 The feature, motivation and pitch

I'm working on making an executable python program to train a model and produce the trained model.
The python program is made executable using pyinstaller which compiles the source code into byte code (which can be written in `*.pyc` files).
I'm thinking of having the trained model as a package from `torch.package`, however, currently `torch.package` cannot accept `*.pyc` as the source file, probably due to this line:
https://github.com/pytorch/pytorch/blob/40bb880009e86831d5186f619b33ad390d702b16/torch/package/package_exporter.py#L419

If `torch.package` can accept, it would be easier to use it within pyinstaller and add another layer of difficulty in reading the script in the package.

### Alternatives

Currently I'm converting the `*.pyc` files produced by pyinstaller to `*.py` using `decompyle3`, then pack it with `torch.package`, but it only works for 3.8 or older versions. It cannot work with version 3.9 onwards.

### Additional context

Packing `*.pyc` in the hermetic package by `torch.package` would also add another layer of difficulty for someone who wants to reverse engineer the package.

cc @wconstab
Repository: node
Issue: ShadowRealm Integration
Labels: discuss,realm

### What is the problem this feature will solve?

[ShadowRealm](https://github.com/tc39/proposal-shadowrealm) is a TC39 stage 3 proposal that introduces a new built-in to provide a distinct global environment, with its own global object containing its own intrinsics and built-ins. Its ability is similar to Node.js built-in `vm.Context`, however, ShadowRealm provides a stronger guarantee on object exchanges across realm boundaries.

As the ShadowRealm is a distinct global environment, Web integration is also under work (Like [1](https://github.com/whatwg/webidl/pull/526)) to define which web APIs should be exposed in the ShadowRealm so that people can still utilize the Web APIs that still useful in the ShadowRealm. The line generally draw between the APIs that should be exposed in the ShadowRealm or not is generally if the APIs are side-effect-free to the host environment.


### What is the feature you are proposing to solve the problem?

ShadowRealm is currently under [active development](https://bugs.chromium.org/p/v8/issues/detail?id=11989&q=callable%20boundary&can=2) in v8. The design doc of the Host API could be found at [here](https://docs.google.com/document/d/1k9OZxtbKmzENOMzahmm2C0uBNRc_pVLXMSoKsrkJJBw/edit#). I'd believe in Node.js we may need to be able to re-evaluate the native modules in the ShadowRealm so that their object graph is not tangled with the main context, to not violate the principle of the design. /cc @nodejs/startup 

I'd believe there are a bunch of modules that are useful and can stand in the line of side-effect-free, like EventEmitter, Stream, URL, etc. Also, the Web APIs that are available in Node.js like WebStream could also follow the Web specs to be exposed in the ShadowRealm. We may need to list all the possibilities that can be available in the ShadowRealm, and eventually make them available in the ShadowRealm.


Design Doc: https://docs.google.com/document/d/12_CkX6KbM9kt_lj1pdEgLB8-HQaozkJb7_nwQnHfTTg/edit?usp=sharing


/cc @nodejs/vm
Repository: node
Issue: [http.IncomingMessage] `req.toWeb()`
Labels: http,feature request

### What is the problem this feature will solve?

Reading the body out of the `http.IncomingMessage` is troublesome without any 3th party package...

`Request` on the other hand has features such as text, blob, json, arrayBuffer, formData and body for parsing it.



### What is the feature you are proposing to solve the problem?

It would be a convenient to have something like a `req.toWeb()` utility added onto the simple http server 🚀 

something like the stream.Readable.toWeb() but for the http.IncomingRequest to web Request

```js
import http from 'node:http'

const app = http.createServer(async (req, res) => {
  const request = req.toWeb()
  
  await request.blob()
  await request.arrayBuffer()
  await request.formData()
  await request.json()
  await request.body.pipeTo(dest)
  
  request.headers.has('content-length')
  
  request.url // full url (populated with host from request headers and http(s) based on using http or https)
  
  request.signal // a abort signal that aborts when user cancel the request
})
```

### What alternatives have you considered?

currently doing some simplier variant like this one:

```js
const app = http.createServer((r, res) => {
  const req = new Request(r.url, {
    headers: r.headers,
    method: r.method,
    body: r
  })
})
```

having this `req.toWeb()` built in would be very handy
Repository: transformers
Issue: [TODO] Investigate equivalence tests
Labels: WIP

**(add a lot of assignees just to make you informed and kept updated in the future. Don't hesitate to remove yourself if you think it's irrelevant)**

Currently the PT/TF/Flax equivalence tests use `1e-5` as the tolerance for the absolute differences of outputs.

We see that these tests failed with a non-negligible (although not carefully defined) frequency.

Create this page to track a list of models to investigate.

- **FlaxWav2Vec2ModelTest** (2.2888184e-05 > 1e-5)
  - https://app.circleci.com/pipelines/github/huggingface/transformers/37363/workflows/a4b06424-0ba8-4fbc-9054-6ff52fbf8145/jobs/411654 

- **TFGPT2EncoderDecoderModelTest** (0.001009281724691391 > 1e-3)
  - https://app.circleci.com/pipelines/github/huggingface/transformers/37358/workflows/43c12161-33d8-4df5-ba3c-3e62a4507ee7/jobs/411579
    - This also happens to **TFBERTEncoderDecoderModelTest**
    -  This is caused by some sequence in a batch which gets all 0s as attention mask (generated by ids_tensor) - may happens on both encoder and decoder (especially after combining with the causal mask).
    - For **TFBERTEncoderDecoderModelTest**, the difference is smaller than *TFGPT2EncoderDecoderModelTest* (by a magnitude of 5x~10x) -> this is due to the last hidden states in GPT2 is after layer norm (not the case for BERT).
    - If we look the cross attention diff between PT/TF, it is clear that we have the same issue (both in the magnitude of `1e-3`)
    - The encoder attention diff between PT/TF is in the magnitude of `5e-8`: ~~**not very sure why this doesn't get much larger**~~.
      - This is because PT/TF (at least in BERT) has different `encoder_extended_attention_mask`: `1e-4` vs `1e-9`.

- **TFViTMAEModelTest** (1.013279e-05 > 1e-5)
  - https://app.circleci.com/pipelines/github/huggingface/transformers/37319/workflows/5adfba7a-d12b-4e1e-9a7a-e33c7d5fd6ee/jobs/411002
Repository: rust
Issue: The compiler should error when trying to transmute pointer values with incompatible alignment
Labels: A-type-system,C-enhancement,T-compiler,T-types

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

I tried this code:

```rust
struct Foo {
    a: i32,
    b: i32,
}

fn main() {
    unsafe {
        let mut array: [u8; 1024] = [1; 1024];
        let foo = std::mem::transmute::<&mut u8, &mut Foo>(&mut array[0]);
        foo.a += 1;
    }
}
```

I expected to see this happen: the compiler complains about the alignment of the array not being good enough for the struct Foo

Instead, this happened: the compiler did not complain

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
1.59.0 from the playground
```

This issue was noticed by the creator of Zig in this blog post: https://andrewkelley.me/post/unsafe-zig-safer-than-unsafe-rust.html.
Repository: PowerToys
Issue: Hide window when move to side top
Labels: Idea-New PowerToy,Needs-Triage

### Description of the new feature / enhancement

Hide window when move to side top

### Scenario when this would be used?

When we used windows terminal, If we need to use another app window now,

Then, for active terminal window, we must to key down `Ctrl + Tab` or click terminal icon to active it

But if we can move it to side top and hidden

Then, we can move our mouse to side top to active it by one step.

### Supporting information

_No response_
Repository: vscode
Issue: Allow WebviewViews to be explicitly created, so badges can be shown
Labels: feature-request,api,webview-views

VSCode extensions can now show badges for TreeViews and WebviewViews that they implement: https://github.com/microsoft/vscode/pull/144775

One problem with this implementation is that I believe there is no way for an extension to display a badge for a WebviewView until the user has clicked and opened that WebviewView in the sidebar.  I think this is an important use case: imagine a TODO extension, like https://github.com/Gruntfuggly/todo-tree (they are one extension that wants to use this API). If I used such an extension, I would expect that the badge would show up on the activation bar showing that I have TODOs as soon as I open up the workspace, even if I haven't yet opened up that extension's Webview View.

TreeViews can show badges on startup, because an extension can call `createTreeView` to programatically force TreeView creation, and can then set the badge on the TreeView.  Would it make sense to add a similar method to force creation of a WebviewView?

CC'ing @mjbvz for this issue.  Thanks!
Repository: go
Issue: x/mobile: Duplicate symbol '_OBJC_CLASS_$_Universeerror'
Labels: NeedsInvestigation,mobile

**Environment**

Xcode - 12.4
Language - Objective-C Project
Project Type - React Native 

**Issue**

Converted a couple of go projects/libraries to iOS frameworks (.xc). 
Trying to use those 2 in one iOS project but facing compiler issue like "Duplicate symbol '_OBJC_CLASS_" which are related to objects of autogenerated files like Universe.objc.h. 
<img width="613" alt="Screenshot 2022-03-30 at 11 22 04 PM" src="https://user-images.githubusercontent.com/101170293/160899752-48e5dfff-e1b5-45b4-bbcf-ef9fbdfb9fcd.png">

**Approach tried: 1**

Did prefix binding of the go files 
      `gomobile bind -target ios -prefix My`

Result: Failed - Binder didn't bind the objects under Universe.objc.h.  so the issue of duplicate symbols persists

**Approach tried: 2**

Update the linker flag config in Xcode
      `-objc`

Result: Failed-  The issue of duplicate symbols persists
Repository: vscode
Issue: Markdown preview switches to latest open markdown document
Labels: bug,help wanted,markdown

Steps to Reproduce:

1. Open a markdown preview
2. Close the associated markdown file
3. Scroll around
4. Open the same markdown file again
5. 🐛 Scroll position is reset.
6. Close the markdown file
7. Open a different markdown file
8. 🐛 Preview changes to the new markdown file.

Maybe it's because I use the markdown previews as markdown readers but I don't expect their state to be tied to the currently open markdown file, especially because I can close the markdown file and keep viewing without issue
Repository: pytorch
Issue: Add Unit Tests for Torch.Package Subclasses [Waiting on changes to land]
Labels: oncall: package/deploy,imported

[Torch.package ](https://pytorch.org/docs/stable/package.html) is a handy tool to serialize and deserialize python code. It works as you expect a packager to but with the added benefit of also saving the actual code itself when desired. It was primarily designed with the intention of being the delivery mechanism for [torch::deploy](https://github.com/pytorch/pytorch/blob/master/docs/source/deploy.rst) which is a runtime for getting pytorch models to run on multiple threads in eager mode. There's a great whitepaper about `torch.package` and `torch::deploy` [here](https://arxiv.org/pdf/2104.00254.pdf).

Motivation: A recent refactoring of `torch.package` creates a generic of `torch.package` which does not require `torch` in order to be run. The primary reason we did this was so to do the same for `torch::deploy` which has a dependency on `torch.package`.  You'll find files called `torch/package/package_exporter_no_torch` which has a `PackageExporter` which the `PackageExporter` for `torch/package/package_exporter` is a subclass of. The same is true for `PackageImporter`. However, do to the long term goals for `torch.package` and `torch::deploy` we want to maintain a relationship such that if python code is serialized with the `PackageExporter` of `torch/package/package_exporter_no_torch` it can be deserialized with the `PackageImporter` of `torch/package/package_importer`.

Steps

1.  In `test/package/test_dependency_api.py` you'll see that we import both `PackageExporter`s and `PackageImporter`s and then make sure that the non-torch versions work and the torch versions work. We do this by creating another unit test suite called `TestDependencyAPINoTorch` which is a subclass of `TestDependencyAPI` but with a changed `PackageImporter` and `PackageExporter`.
2. Create another test suite similar to `TestDependencyAPINoTorch`, but it takes it's `PackageExporter` from `torch/package/package_exporter_no_torch` and `PackageImporter` from `torch/package/package_importer`
3. Repeat Step 2 for all files under `test/package` which have a similar pattern to the one described in step 1. (It should be a copypasta outside of changing the name of the classes with the exception of `test/package/test_dependency_hooks.py` which only uses the `PackageExporter`)
Repository: rust
Issue: [strict provenance] Rationalize "Oxford Casts"
Labels: T-lang,O-wasm,O-AVR,A-strict-provenance

This issue is part of the Strict Provenance Experiment - #95228 

[Oxford Casts](https://github.com/rust-lang/rust/issues/95488) are those that fly in the face of Harvard Architectures, and let you convert between data pointers and function pointers. In my current understanding, this affects both AVR and WASM.

For WASM, function pointers are actually indices into a ~vtable somewhere. This seems to mostly work fine and it's just a matter of "ask bad questions, get bad answers"

For AVR it causes Actual Compiler Problems that the stdlib seems to be actively routing around: 

https://github.com/rust-lang/rust/blob/92804455704cc59d6d8272faf72f442c6125d395/library/core/src/ptr/mod.rs#L1390-L1395

I do not know what "resolving" this looks like. It could involve any of:

* just documenting the current state of affairs
* developing a "coherent" model for what these operations do
* fixing the compiler issues with AVR
* forbidding oxford casts on some or all targets
* introducing new APIs to "do it right"

I can't really help any more than this, because this is all outside my areas of expertese/motivation.
Repository: rust
Issue: [strict provenance] make panic_unwind conform
Labels: O-windows,A-debuginfo,T-compiler,A-strict-provenance

This issue is part of the Strict Provenance Experiment - https://github.com/rust-lang/rust/issues/95228

The [panic_unwind](https://github.com/rust-lang/rust/tree/master/library/panic_unwind/src) component is full of lots of pointer provenance crimes.

In particular, I noticed that dwarf/eh.rs is just a complete hairball of uniformly mixing pointers and integers: https://github.com/rust-lang/rust/blob/bb5c437a2ce9ccf2204c974300c5ea9eb32d3635/library/panic_unwind/src/dwarf/eh.rs#L144-L148

And seh.rs has some sketchy stuff too:

https://github.com/rust-lang/rust/blob/bb5c437a2ce9ccf2204c974300c5ea9eb32d3635/library/panic_unwind/src/seh.rs#L129-L134

I ran into this fairly early, so these seemed like pretty overwhelmingly hard problems at the time, but with a bit of time to sleep on it I think it might be possible to fix a lot of this by just making everything be pointers by default and then if you "notice" something is actually an offset, only cast it to an integer at that point.

In general it's ok for integers to pretend to be pointers "for fun", and if anything is ever `int | ptr` the valid union of these types is `ptr`.
Repository: rust
Issue: [strict provenance] Fix System APIs That Are Liars
Labels: T-libs,O-unix,A-strict-provenance

This issue is part of the Strict Provenance Experiment - https://github.com/rust-lang/rust/issues/95228

Some system APIs (and C FFI in general) like to lie about whether things are pointers, and this makes strict-provenance very sad.

-----

prctl for PR_SET_NAME (says a pointer is unsigned long):

https://github.com/rust-lang/rust/blob/44628f7273052d0bb8e8218518dacab210e1fe0d/library/std/src/sys/unix/thread.rs#L120-L127

clone3(?) (says a pointer is u64):

https://github.com/rust-lang/rust/blob/44628f7273052d0bb8e8218518dacab210e1fe0d/library/std/src/sys/unix/process/process_unix.rs#L185-L198

sigaction (defines sighandler_t (a callback) to be size_t):

https://github.com/rust-lang/rust/blob/44628f7273052d0bb8e8218518dacab210e1fe0d/library/std/src/sys/unix/stack_overflow.rs#L130

------

The "level 1" fix for this is to just change our extern decls so that all of these APIs/types actually say "this is a pointer". In general it's ok for integers to pretend to be pointers "for fun", and if anything is ever `int | ptr` the valid union of these types is `ptr`.

The "level 2" fix for this is to instead come up with some general mechanism for dealing with these kinds that folks can use in the larger ecosystem, like a "this is lies" annotation or [uptr](https://docs.rs/sptr/latest/sptr/int/struct.uptr.html). This kind of thing is especially nasty for people who are "bindgen true believers" and don't want to ever hand-edit generated bindings (so, not us).
Repository: PowerToys
Issue: Mouse wheel scrolling is backwards
Labels: Issue-Bug,External Dependency-WinUI 3,Needs-Triage,Needs-Team-Response

### Microsoft PowerToys version

0.57.0

### Running as admin

- [ ] Yes

### Area(s) with issue?

System tray interaction

### Steps to reproduce

Scrolling direction of the mouse wheel. Every where else in the system scroll wheel behavior is consistent (e.g. pull on the wheel scrolls up) In fact, when Settings is front most, PowerTools (in the background) scrolls correctly! When I bring it forward, it reverses scroll direction

### ✔️ Expected Behavior

Scroll wheel usage is consistent with systems scrolling

### ❌ Actual Behavior

It's the opposite

### Other Software

Windows 10 Pro 21H2
Intel NUC
Razor Naga mouse (using Razor drivers)
Repository: rust
Issue: [strict provenance] Make The strict_provenance APIs Actual Compiler Magic?
Labels: T-compiler,A-strict-provenance

This issue is part of the Strict Provenance Experiment - https://github.com/rust-lang/rust/issues/95228

I left a few little ` FIXME(strict_provenance_magic)` comments around core::ptr to indicate places that *might* want to become a compiler intrinsic for... Reasons. Currently all of these operations *function* but it's possible they can function "better" or somehow power better checking/analysis with builtin support.

In particular you probably want with_addr as some kind of instrinsic because the naive impl does a bunch of faffing around when on most platforms it's `usize as *mut T` and on CHERI this is literally [cheri_address_set](https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-947.pdf#page=28).

https://github.com/rust-lang/rust/blob/bb5c437a2ce9ccf2204c974300c5ea9eb32d3635/library/core/src/ptr/mut_ptr.rs#L197-L205

This discussion is 100% "above my pay grade", I cannot provide any more insight.
Repository: go
Issue: go/parser: SIGSEGV in `(*resolver).resolveList`
Labels: NeedsInvestigation

```
unexpected fault address 0x833a6e1c00000000
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x3 addr=0x833a6e1c00000000 pc=0x19818]

goroutine 203 [running]:
runtime.throw({0x2db0c9?, 0x62778?})
	/workdir/go/src/runtime/panic.go:992 +0x58 fp=0xc000be9070 sp=0xc000be9030 pc=0x45aa8
runtime.sigpanic()
	/workdir/go/src/runtime/signal_unix.go:825 +0x1b8 fp=0xc000be90b0 sp=0xc000be9070 pc=0x5dac8
runtime.convI2I(0xc000f00100?, 0x0?)
	/workdir/go/src/runtime/iface.go:415 +0x38 fp=0xc000be9108 sp=0xc000be90d0 pc=0x19818
go/parser.(*resolver).resolveList(0xc000088000?, 0x109e3c?)
	/workdir/go/src/go/parser/resolver.go:525 +0xb0 fp=0xc000be9170 sp=0xc000be9108 pc=0x120190
go/parser.(*resolver).Visit(0xc000269c80, {0x33fdc8?, 0xc000efa7e0?})
	/workdir/go/src/go/parser/resolver.go:493 +0x1a4 fp=0xc000be99f0 sp=0xc000be9170 pc=0x11d614
go/ast.Walk({0x33f018?, 0xc000269c80?}, {0x33fdc8?, 0xc000efa7e0?})
	/workdir/go/src/go/ast/walk.go:52 +0x74 fp=0xc000be9b08 sp=0xc000be99f0 pc=0x105934
go/parser.resolveFile(0xc000eb3100, 0xc0002296e0, 0x0)
	/workdir/go/src/go/parser/resolver.go:32 +0x404 fp=0xc000be9bb0 sp=0xc000be9b08 pc=0x11c3e4
go/parser.(*parser).parseFile(0xc0001cf400)
	/workdir/go/src/go/parser/parser.go:2897 +0x3a4 fp=0xc000be9cf0 sp=0xc000be9bb0 pc=0x11bd74
go/parser.ParseFile(0xc000116000, {0xc0001c4270, 0x21}, {0x28a080?, 0xc000af5140?}, 0x0?)
	/workdir/go/src/go/parser/interface.go:122 +0x154 fp=0xc000be9dc0 sp=0xc000be9cf0 pc=0x109454
golang.org/x/tools/go/packages.newLoader.func2(0xc0001c4270?, {0xc0001c4270, 0x21}, {0xc000096480?, 0x0?, 0x0?})
	/workdir/gopath/src/golang.org/x/tools/go/packages/packages.go:582 +0x90 fp=0xc000be9e18 sp=0xc000be9dc0 pc=0x2514b0
golang.org/x/tools/go/packages.(*loader).parseFile(0xc000112000, {0xc0001c4270, 0x21})
	/workdir/gopath/src/golang.org/x/tools/go/packages/packages.go:1042 +0x3dc fp=0xc000be9f38 sp=0xc000be9e18 pc=0x2548dc
golang.org/x/tools/go/packages.(*loader).parseFiles.func1(0x69, {0xc0001c4270?, 0x0?})
	/workdir/gopath/src/golang.org/x/tools/go/packages/packages.go:1070 +0x64 fp=0xc000be9f88 sp=0xc000be9f38 pc=0x254f54
golang.org/x/tools/go/packages.(*loader).parseFiles.func2()
	/workdir/gopath/src/golang.org/x/tools/go/packages/packages.go:1072 +0x60 fp=0xc000be9fc0 sp=0xc000be9f88 pc=0x254ee0
runtime.goexit()
	/workdir/go/src/runtime/asm_ppc64x.s:905 +0x4 fp=0xc000be9fc0 sp=0xc000be9fc0 pc=0x78c44
created by golang.org/x/tools/go/packages.(*loader).parseFiles
	/workdir/gopath/src/golang.org/x/tools/go/packages/packages.go:1069 +0x4ec
```

`greplogs --dashboard -md -l -e 'goroutine \d+ \[running\]:\n(.+\n\t.+\n)*go/parser\.\(\*resolver\)\.resolveList' --omit=-n2d`

[2022-03-21T13:26:21-86b02b3-7eaad60/linux-ppc64le-buildlet](https://build.golang.org/log/1d6f6991f006d9701e63bf00bade90ae6e692a95)
[2021-04-28T19:13:50-16b25d2-ad989c7/linux-arm-scaleway](https://build.golang.org/log/48bbb71a6cb675fefd008946e5bdce61e970b2b6)

(CC @griesemer)
Repository: PowerToys
Issue: Make "Find my mouse" draw the background as a gradient that grows brighter towards the mouse
Labels: Idea-Enhancement,Product-Mouse Utilities

### Description of the new feature / enhancement

This way you can tell INSANTANEOUSLY what direction to move your mouse to get it back to where you need it.

I have twelve high resolution monitors, some of which are not in my immediate field of view.  It is very easy to lose the cursor for one reason or another, and the worst case scenario is when it goes out of the field altogether.  I'm a day trader and speed matters.  Seconds matter.  It can literally cost me real money when I can't find my mouse during a big move.

I can only make the cursor so large before it interferes with my ability to work.  And no solution centered on the cursor itself solves the problem where I can't find the cursor in the first place, b/c it's out of my field of view.

"Find My Mouse" is a solid step in the right direction, b/c I can tell in a single glance if all the screens in my field of view are dark, and therefore my mouse is somewhere else.  Before I had to scan 7 monitors before reaching that conclusion.

Going to a gradient would make the rest a one glance affair; i.e. not only the direction of where my mouse is but which direction to move it to get it back where I need it.  Nirvana would finally be achieved.

Thank you for your consideration.

### Scenario when this would be used?

All day while I'm day trading.

### Supporting information

_No response_