sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: transformers
Issue: Adding option to truncation from beginning instead of end, for both longest_first and longest_second
Labels: Feature request

# 🚀 Feature request

<!-- A clear and concise description of the feature proposal.
     Please provide a link to the paper and code in case they exist. -->

The current [truncation strategies](https://huggingface.co/transformers/preprocessing.html#everything-you-always-wanted-to-know-about-padding-and-truncation) only provide truncation from end of the input sentence. This may be enough for most cases, but is not applicable for dialog tasks.

Say, you are concatenating an input dialog context to BERT. If the input length > max_length (256/ 512), then the tokens are truncated from the ending i.e. the most recent utterances in the dialog.

In some cases, you want the most recent utterances to be included in the input and if truncation needs to be done, then the oldest utterances be truncated i.e. truncation from the beginning.

This can be done manually in own code base outside of Transformers library, but it's not ideal.

Truncation outside of model will be done most likely on full words to truncate from beginning and fit them to model max length (say you truncate from beginning and reduce input to 254 words). But, these words will be converted to subwords when fed to BertTokenizer and the final input will be > 256, thus resulting in words being dropped from the last utterance again.

To do this properly outside of the Transformers library, one would need to instantiate the same Tokenizer object, tokenize each input and then truncate from beginning, then convert ids back to tokens and then either reconstruct the input from the truncated tokenized version or skip the tokenizer call inside the Transformers library.

## Motivation

<!-- Please outline the motivation for the proposal. Is your feature request
     related to a problem? e.g., I'm always frustrated when [...]. If this is related
     to another GitHub issue, please link here too. -->

## Your contribution

<!-- Is there any way that you could help, e.g. by submitting a PR?
     Make sure to read the CONTRIBUTING.MD readme:
     https://github.com/huggingface/transformers/blob/master/CONTRIBUTING.md -->
Repository: next.js
Issue: Literal /index prerender route causes error in @vercel/next  
Labels: Navigation

This currently causes an error in the builder due to it being treated the same as `/` when it should instead be treated as `/index/index`. We need to ensure we handle this the same as we do in Next.js locally.
Repository: flutter
Issue: Combine debug+profile run mode for lower friction debugging and performance optimization
Labels: tool,a: debugging,c: proposal,P3,team-tool,triaged-tool

## Use case

I often need to switch back and forth between debug and profile builds as part of my development experience. I use debug builds to iterate on UI using hot reload and debugging tools. Then I switch to profile build to see what the animations look like at 60fps and make sure performance is good. Then I switch back to debug builds to iterate on the UI more. Switching back and forth between debug and profile builds breaks my flow as I have to stop and wait for builds to complete each time I switch.

## Challenges
Building a profile build is slow.
Switching between debug and profile is slow.
Profile builds will never support hot reload, they could support (slow) hot restart.

## Proposal
* Add a `flutter run` mode that deploys an app that can operate in both debug and profile mode.
* Provide an easy way to swap back and forth between the deployed debug and profile builds.
* https://github.com/flutter/flutter/issues/37987 Support hot restart for profile builds so that the debug+profile target can launch as soon as the debug build is ready and can switch to a new profile build if I edit code. This workflow is only useful for me if I can switch to a profile build that matches the current state of my app rather than the state before I started iterating.
* Hot restart for profile builds will be slow as building profile builds are slow but if you have already spent a minute playing around with the debug build of your app, you could probably have a profile build ready if we kicked off profile builds in the background. 
* So that users don't spend a lot of time waiting for profile build compiles, probably need to kick off new profile build compiles after a hot reload. Need cancellable hot reloads.
Repository: react-native
Issue: FlatList wrapping KeyboardAvoidingView prevents scrolling of nested ScrollView on iOS 
Labels: Needs: Triage :mag:

## Description
If you have a KeyboardAvoidingView wrapping a vertical ScrollView you can still scroll the ScrollView while the keyboard is present. This is as expected.

However, if the above setup is rendered as an item inside a FlatList (for example, one being used as a horizontal pager) then you can no longer scroll the vertical ScrollView when the keyboard is present.

This only applies to iOS, you can still scroll the vertical ScrollView on Android (and I've confirmed it's not to do with the differing `behaviour` being set on KeyboardAvoidingView across platforms).

## React Native version:
```
System:
    OS: macOS 10.15.7
    CPU: (8) x64 Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz
    Memory: 122.88 MB / 16.00 GB
    Shell: 5.8 - /usr/local/bin/zsh
  Binaries:
    Node: 10.24.0 - ~/.nvm/versions/node/v10.24.0/bin/node
    Yarn: 1.22.10 - /usr/local/bin/yarn
    npm: 6.14.11 - ~/.nvm/versions/node/v10.24.0/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  Managers:
    CocoaPods: 1.10.1 - /Users/liam.jones/.rbenv/shims/pod
  SDKs:
    iOS SDK:
      Platforms: iOS 14.4, DriverKit 20.2, macOS 11.1, tvOS 14.3, watchOS 7.2
    Android SDK:
      API Levels: 23, 25, 26, 27, 28, 29
      Build Tools: 27.0.3, 28.0.3, 29.0.2, 29.0.3, 30.0.3
      System Images: android-25 | Google APIs Intel x86 Atom, android-25 | Google Play Intel x86 Atom, android-26 | Google Play Intel x86 Atom, android-27 | Google Play Intel x86 Atom, android-29 | Google APIs Intel x86 Atom, android-29 | Google Play Intel x86 Atom
      Android NDK: Not Found
  IDEs:
    Android Studio: 4.1.2 4.1.2
    Xcode: 12.4/12D4e - /usr/bin/xcodebuild
  Languages:
    Java: 1.8.0_282 - /usr/bin/javac
    Python: 3.9.2 - /usr/local/opt/python/libexec/bin/python
  npmPackages:
    @react-native-community/cli: Not Found
    react: 16.13.1 => 16.13.1
    react-native: https://github.com/expo/react-native/archive/sdk-40.0.1.tar.gz => 0.63.2
    react-native-macos: Not Found
  npmGlobalPackages:
    *react-native*: Not Found
```

## Steps To Reproduce
Provide a detailed list of steps that reproduce the issue.

Using the snack/repo below:
1. Tap the TextInput to open the keyboard
2. Attempt to scroll back up the view containing the TextInput while the keyboard is open

## Expected Results
View scrolls vertically. This works on Android but not iOS.

## Snack, code example, screenshot, or link to a repository:
https://snack.expo.io/@liam/github.com-living-with-keyboard-avoiding-view-inside-flatlist-on-ios-bug
https://github.com/living-with/keyboard-avoiding-view-inside-flatlist-on-ios-bug

You can change the `insideFlatList` constant at the top of the App.tsx to see how the behaviour changes once the KeyboardAvoidingView is placed inside a FlatList.
Repository: create-react-app
Issue: Minimum production build memory requirement?
Labels: needs triage

After finally getting to a prod ready state, I tried to run a build on my deployment machine, only to run into the infamous `JavaScript heap out of memory` error when running the build script. ( #8130 #8096 ), on a 1GB RAM VPS, with CRA 4.0.1.

I have tried all of the tricks people have used in those threads but to no avail.

The app itself is fairly small, so I am now wondering if there is there a minimum memory needed for a bare bones build, below which this error is likely?
Repository: go
Issue: x/sys/unix: C->Go type converter does not take integer field sign into account
Labels: NeedsInvestigation,compiler/runtime

I am looking at Linux `statfs` structure that is defined in Linux UAPI as 

```c
/*
 * Most 64-bit platforms use 'long', while most 32-bit platforms use '__u32'.
 * Yes, they differ in signedness as well as size.
 * Special cases can override it for themselves -- except for S390x, which
 * is just a little too special for us. And MIPS, which I'm not touching
 * with a 10' pole.
 */
#ifndef __statfs_word
#if __BITS_PER_LONG == 64
#define __statfs_word __kernel_long_t
#else
#define __statfs_word __u32
#endif
#endif

struct statfs {
	__statfs_word f_type;
	__statfs_word f_bsize;
	__statfs_word f_blocks;
	__statfs_word f_bfree;
	__statfs_word f_bavail;
	__statfs_word f_files;
	__statfs_word f_ffree;
	__kernel_fsid_t f_fsid;
	__statfs_word f_namelen;
	__statfs_word f_frsize;
	__statfs_word f_flags;
	__statfs_word f_spare[4];
};
```

`__statfs_word` is marked as unsigned 32bit at 32bit platforms.

Now let's look at the generated code for a 32bit platform e.g. `arm` (unix/ztypes_linux_arm.go):

```go
type Statfs_t struct {
        Type    int32
        Bsize   int32
        Blocks  uint64
        Bfree   uint64
        Bavail  uint64
        Files   uint64
        Ffree   uint64
        Fsid    Fsid
        Namelen int32
        Frsize  int32
        Flags   int32
        Spare   [4]int32
        _       [4]byte
}
```

Here `Type` field is *signed* int that differs from the UAPI intention.

This causes issues with a compiled code, like this for example:

```go
if statfs.Type != unix.RAMFS_MAGIC {
  // foo bar
}
```

This code fails to compile for *arm* because `unix.RAMFS_MAGIC` is 0x858458f6 and does not match *int32* at the left side.

`statfs.Type` should really be a `uint32` type.
Repository: pytorch
Issue: Find a good namespace home for torch._assert_async
Labels: triaged,module: numpy,module: testing

torch._assert_async was initially written as a one-off, but @gchanan has observed that libraries like Numpy have other assert functions, and so maybe assert_async (NB: which doesn't have a Numpy equivalent, since it only really does something nontrivial on CUDA) should be homed with the rest of them. For now, we have underscored the function in case we do want to move it.

Relevant Numpy functions: https://numpy.org/doc/stable/reference/routines.testing.html

cc @mruberry @rgommers @heitorschueroff
Repository: godot
Issue: Calling has_method on an Android plugin does not return plugin methods
Labels: bug,platform:android,topic:porting,topic:plugin

**Godot version:**
3.2.3

**OS/device including version:**
Android 11 on Galaxy S10e

**Issue description:**
Calling `has_method` in script on an Android plugin singleton will not return valid plugin methods,
 even if they are defined though a `GodotPlugin.getPluginMethods` override.

**Steps to reproduce:**
1. Implement an `GodotPlugin` Android plugin that has methods returned via `getPluginMethods`.
2. Access the plugin singleton through script and call "has_method" for one of the plugin methods. It will return false for valid methods (where it should return true).

**Minimal reproduction project:**
[Testing-HasMethodPlugin.zip](https://github.com/godotengine/godot/files/6085967/Testing-HasMethodPlugin.zip)

To save size, the example project doesn't include the Android custom build template. You will need to regenerate the template after opening the project.  To avoid you needing to build and compile a new Android plugin, the example is using the Android IAR plugin from https://github.com/pschw/InAppReview. Min API level is 21 for IARs (higher than Godots 18). You will need to change this in `config.gradle`.
Repository: vscode
Issue: Secondary search
Labels: feature-request,search,*duplicate

I'd like to be able to search for something, for example `ipad` and then in the files which contain that term, search for something else, for example `terminal`.

IE find files which contain ____ && ____.
Repository: rust
Issue: Tracking Issue for assert_matches
Labels: T-libs-api,C-tracking-issue,disposition-merge,finished-final-comment-period

<!--
Thank you for creating a tracking issue!

Tracking issues are for tracking a feature from implementation to stabilization.

Make sure to include the relevant RFC for the feature if it has one.

If the new feature is small, it may be fine to skip the RFC process. In that
case, you can use use `issue = "none"` in your initial implementation PR. The
reviewer will ask you to open a tracking issue if they agree your feature can be
added without an RFC.
-->

Feature gate: `#![feature(assert_matches)]`

This is a tracking issue for the `assert_matches!()` and `debug_assert_matches!()` macros.

<!--
Include a short description of the feature.
-->

### Public API

<!--
For most library features, it'd be useful to include a summarized version of the public API.
(E.g. just the public function signatures without their doc comments or implementation.)
-->

```rust
// core

macro_rules! assert_matches { .. }
macro_rules! debug_assert_matches { .. }
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [x] Implementation: #82770
- [x] Temporarily move the macro into `std::assert_matches::assert_matches` to avoid breakage: https://github.com/rust-lang/rust/issues/82913
- [x] Final commenting period (FCP)
- [ ] Stabilization PR
   - [ ] Update the `must_use` message on `is_none` (per https://github.com/rust-lang/rust/pull/62431#pullrequestreview-258576936)
   - [ ] Mention this macro in the documentation of `matches!()`

<!--
Once the feature has gone through a few release cycles and there are no
unresolved questions left, the feature might be ready for stabilization.

If this feature didn't go through the RFC process, a final commenting period
(FCP) is always needed before stabilization. This works as follows:

A library team member can kick off the stabilization process, at which point
the rfcbot will ask all the team members to verify they agree with
stabilization. Once enough members agree and there are no concerns, the final
commenting period begins: this issue will be marked as such and will be listed
in the next This Week in Rust newsletter. If no blocking concerns are raised in
that period of 10 days, a stabilization PR can be opened by anyone.
-->

### Unresolved Questions

<!--
Include any open questions that need to be answered before the feature can be
stabilised. If multiple (unrelated) big questions come up, it can be a good idea
to open a separate issue for each, to make it easier to keep track of the
discussions.

It's useful to link any relevant discussions and conclusions (whether on GitHub,
Zulip, or the internals forum) here.
-->

- [x] Add `=> expr` syntax?
  - Nope, too confusing. (See discussion below.)
Repository: kubernetes
Issue: match the kubelet and CRI implementer cgroup drivers
Labels: sig/node,sig/cluster-lifecycle,kind/feature,priority/important-longterm,lifecycle/frozen,triage/accepted

#### What would you like to be added:

 make it possible for CRI implementers and kubelet to match their cgroup drivers via auto-detection.

https://kubernetes.slack.com/archives/C0BP8PW9G/p1614888729200700

the above discussion on slack indicated a couple of options:
1) make the kubelet adapt to the CRI implementer
2) make the CRI implementer adapt to the kubelet

2 seems preferred.

#### Why is this needed:

ideally the two sides should auto-match cgroup drivers, so that we can attempt to hide this detail from user space.

currently, users that install container runtimes and the kubelet need to explicitly configure both to have a matching driver or otherwise the mismatch can cause failures. a lot of users don't know what "cgroup drivers/managers" are and they end up ignoring this important (but low level) detail.
Repository: rust
Issue: Overflow (E0275) on HRTB
Labels: T-compiler,C-bug,fixed-by-next-solver,A-higher-ranked

Hi all,

With @vbarrielle, we're looking at an example of code that fails to compile due to, to the best of our understanding, the type checker infinite-looping.

Minimal code is below:
```rust
use std::ops::Add;

struct Mat<N> {
    a: N,
}

// works if we comment this block /*
impl<'a, N: 'a> Add<&'a Mat<N>> for &'a Mat<N>
where for<'r> &'r N: Add<&'r N, Output=N>,
{
    type Output = Mat<N>;
    fn add(self, rhs: &'a Mat<N>) -> Mat<N> {
        unimplemented!()
    }
}
// */

fn addition<'a, N: 'a>(lhs: &'a Mat<N>, rhs: &'a Mat<N>) -> Mat<N>
where for<'r> &'r N: Add<&'r N, Output=N>,
{
    unimplemented!()
}


fn main() {
    addition(&Mat { a: 2 }, &Mat{ a: 3 }); // also works if we comment this line
}
```
[(playground)](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=a13ffd4aacd5e61f5c23b7d6c8bb1b9c)

My best guess is that the issue looks like this:
- The type checker tries to verify that the bounds for `addition(&Mat<usize>, &Mat<usize>)` are verified (hence why it builds without the call)
- For this, it must find a N such that `for<'r> &'r N: Add<&'r N, Output=N>`
- Here would be the bug in this hypothesis: maybe for some reason it tries to resolve with `N = Mat<O>` where O would be another free variable
- And then it would infinite-loop with the bound on the `Add` implementation, doing the same on each loop.

The weird thing is, replacing `addition` with `Add::add`, which as far as I could tell should require the exact same bounds, does work. Which makes me guess it's something that is implemented differently for traits and free functions, and traits work well but not when there is a free function like `addition` in the call stack. Maybe an heuristic that ends up primed towards addition of `Mat` by the `addition` function?

Does that make sense, or does anyone maybe have a better idea what this may be due to?

(also, this seems to be related to the references, as removing them does solve the issue — however, removing the universal quantifiers does not appear to help)

Cheers, and as always thank you for all you do! :heart:
Repository: PowerToys
Issue: Integrate Keyrate
Labels: Idea-New PowerToy,Product-Tweak UI Design

## Integrate [Keyrate](https://github.com/EricTetz/keyrate)

_What is the expected behavior of the proposed feature?  What is the scenario this would be used?_

I'm an avid user of keyrate by Eric Tetz. It's as simple as it is beautiful. It allows me to increase the cursor type rate (when a key is pressed) to whatever I want beyond OS limits. As a poweruser I even find myself slowed down by the long delay it takes when pressing any key for the keyboard to type continuously. And even then that keyrate is slow. 

I run keyrate with a .bat file on startup with the following settings. But having this as part of powertoys would be way better (nice UI, no need to restart keyrate with new settings etc.)!

```cmd
keyrate.exe 160 1
```

![20210305_004525_keyrate_demo](https://user-images.githubusercontent.com/26190934/110046332-1f3cd900-7d4c-11eb-8e02-bbedd59199c2.gif)

If you'd like to see this feature implemented, add a 👍 reaction to this post.
Repository: rust
Issue: Compile error mixing declarative macros with procedural macros
Labels: A-macros,C-bug

Cross posting with [tokio issue tracker](https://github.com/tokio-rs/tokio/issues/3579).

I know how to work around this (can put parens around the macro variable: `($foo_factory)()`), but I don't think this should be happening in the first place.  Feels like a bug in the macro system.  This is reproducible in the playground:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=fb6d73cfb878547b438d8ec49431a4d2

`concrete_tests2` and `concrete_tests3` compile whereas `concrete_tests1` does not.

I'm producing a declarative macro that takes in an `expr` that is meant to be a closure, and produces a `#[tokio::test]` that invokes that closure.  The compile error is:

```
error[E0618]: expected function, found `Concrete`
  --> src/lib.rs:38:32
   |
14 |             $crate::test_suite::async_test($foo_factory()).await;
   |                                                        -- call expression requires function
...
38 |     crate::use_test_suite!( || crate::Concrete::default() );
   |                                ^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error
```

The code (from the playground link above) is:

```
// /////////////////////////
// Define a trait Foo 
// /////////////////////////
pub trait Foo{}

// /////////////////////////
// Define a test suite suitable for any implementator of Foo
// /////////////////////////
#[macro_export]
macro_rules! use_test_suite {
    ($foo_factory:expr) => {
        #[tokio::test]
        async fn async_test() {
            $crate::test_suite::async_test($foo_factory()).await;
        }
            
        #[test]
        fn sync_test() {
            $crate::test_suite::sync_test($foo_factory());
        }
    }
}

pub mod test_suite {
    pub async fn async_test(_foo: impl crate::Foo) -> u8 { 0 }
    pub fn sync_test(_foo: impl crate::Foo) -> u8 { 0 }
}

// /////////////////////////
// Define an implementaion of Foo and test it
// /////////////////////////
#[derive(Default)]
struct Concrete;
impl Foo for Concrete {}

#[cfg(test)]
mod concrete_tests1 {
    crate::use_test_suite!( || crate::Concrete::default() );
}

#[cfg(test)]
mod concrete_tests2 {
    crate::use_test_suite!( (|| crate::Concrete::default()) );
}

#[cfg(test)]
mod concrete_tests3 {
    crate::use_test_suite!( crate::Concrete::default );
}
```
Repository: godot
Issue: Unexpected pixel jitter when using `2d` stretch mode and `keep` stretch aspect
Labels: topic:core,topic:rendering,needs testing

**Godot version:**
3.2.3.stable.official

**OS/device including version:**
Windows 10 20H2, GTX 1080ti, R7 3800X

**Issue description:**
The bottom and right side of the Godot application jitter when being resized if you enable 2D Stretch mode with Aspect locking. 

This only occurs on the bottom and right side. Left and top work as expected without jitter.

**Steps to reproduce:**
Under DIsplay -> Window:
  Size
    Width: 1280
    Height: 720
  Stretch
    Mode: 2d
    Aspect: keep
(This enables letterboxing like Celeste on ultrawide monitors)

Under Rendering -> Quality:
  2d
    Use Pixel Snap

Drag Window around and look at bottom / right side letter boxing.


**Minimal reproduction project:**
[Demo.zip](https://github.com/godotengine/godot/files/6087819/Demo.zip)

https://user-images.githubusercontent.com/34455502/110059334-66ba6980-7d3a-11eb-8d94-fa748577d81c.mp4

https://user-images.githubusercontent.com/34455502/110059314-5e622e80-7d3a-11eb-9cca-0dc53a3d8b6e.mp4