sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: transformers
Issue: Add PromptTemplate and allow for default PromptTemplate in model configuration
Labels: Feature request

### Feature request

As a user, I want to be able to load a model and feed it my input in such a way that it matches the prompt template that it saw during training. I want to be able to load the default prompt with few lines of code and without having to look up how the model was trained. Additionally, I want to be able to modify the prompt to be different from the default prompt.

The specific implementation is up for discussion. I imagine something like this:
```
from transformers import AutoModelForCausalLM, AutoTokenizer, AutoPromptTemplate

model_id = "meta-llama/Llama-2-xb-chat-hf"
model = AutoModelForCausalLM.from_pretrained(model_id)
tokenizer = AutoTokenizer.from_pretrained(model_id)
prompt_template = AutoPromptTemplate.from_pretrained(model_id)

inputs = {
   "system_prompt":"You are a helpful assistant",
   "interactions":[
      {"user":"What is the fastest sea mammal?"},
      {"assistant":"The fastest sea mammal is the peregrine falcon"},
      {"user":"the peregrine falcon is not a mammal"}
   ]
}

output = model(**tokenizer(prompt_template(inputs)))
```

### Motivation

The huggingface hub is accumulating many finetuned models, which have been trained with a specific prompt template in mind. However, this prompt template is often difficult to find, and even more often the prompt template is missing entirely from the model card. If the model is invoked with a different template, the model performance can be severely affected. The community would benefit from a PromptTemplate class that can be loaded from the model configuration that handles the prompt templating for the end user.

At this very moment, there are likely many users that are using the `meta-llama/Llama-2-xb-chat-hf` models with a prompting style that differs from how the model is intended to be used.

### Your contribution

I am happy to be a part of the discussion for implementation and testing.
Repository: pytorch
Issue: Registering function that takes const std::vector<c10::SymInt>& to SymInt[] schema gives confusing error message
Labels: triaged,module: dynamic shapes

### 🐛 Describe the bug

```
  what():  Inferred operator schema for a C++ kernel function doesn't match the expected function schema.                                                                         
  operator: fbgemm::jagged_to_padded_dense                                                                                                                                        
  expected schema: fbgemm::jagged_to_padded_dense(Tensor values, Tensor[] offsets, int[] max_lengths, float padding_value=0.) -> Tensor                                           
    registered at fbcode/deeplearning/fbgemm/fbgemm_gpu/src/jagged_tensor_ops/jagged_tensor_ops_cpu.cpp:1601                                                                      
  inferred schema: (Tensor _0, Tensor[] _1, SymInt[] _2, float _3) -> Tensor _0                                                                                                   
    registered at fbcode/deeplearning/fbgemm/fbgemm_gpu/src/jagged_tensor_ops/jagged_tensor_ops_autograd.cpp:867                                                                    reason: Type mismatch in argument 3: int[] vs SymInt[]   
```

### Versions

main
Repository: TypeScript
Issue: potential bug related to generics
Labels: Needs Investigation

# Bug Report

### 🔎 Search Terms
generics
pipe
functional programming

### 🕗 Version & Regression Information

5.2.0-dev
- This is the behavior in every version I tried

### ⏯ Playground Link

[Playground link with relevant code](https://www.typescriptlang.org/play?ts=5.2.0-dev.20230727#code/KYDwDg9gTgLgBDAnmYcBiBXAdgYzgXjgAoA6MgfQC44BDLRAbQF0BKAgPjmwGssIB3LAG4AUCNCRYCZKgCqWGlEQAeAJJYwGGABo4AeS2aYnQkSpx1Rtvk4GYR0ePDR4SFHAAqNAJYAbZQAycKAwwFgAJgDOXFi8AljMJnBBIWFRInBwUMA04RBYvohwDDx8grpkJN5YAGbAUMlefkxwAPyNPr4ZcNQBjm5yCkpoWMoAgroASklENNRj1pyTogNwY1AA5spoSWjBIKER0fKKiCPK1XUNEzFxgpztYz1wWMAAbvUrMnCTwJHbu32hyicBOw1GdEQuku9R+Dx+z1eHyg-W+ADUaL5vOEAMIQAC2kEiwG2AEZdGgAExJX7-NCkzipI7EdZbKmcAA+cAAClACd5ieNNttqew2O16d1qLNNvNhfSxRw1vLqaj3BiseFud4UNsAMq7PVAtLRBgwhr06G1WFUipkc0-P4wJjddoMDXYvGEiCCy3oal2kgerU6kkMW1wSq053sF2ZahoPWOCQuOA4fKReBgUMEODbaJMkGYXCJIiZSo1SLUYPa3VoSKKmxwADeAF8xERlB4KVhjcyiCBqB5Fi8MPiAEb1dhEGoJrAj5vddNYTNwDa5gdDkcgUSZZergAWG-Mw6VpN3cGzKCIG10NRYQkyAHon54DwK194PtEaNJs1h13qPkoBIbor2AG9dAPB9n1fDx32ifhoG4aIamqYBQNbB8gA)

### 💻 Code

```ts
export type Func = (..._: any[]) => unknown;

export type Unary<Input, Output> = (_: Input) => Output;

export type Tail<L extends unknown[]> = L extends
  readonly [unknown, ...infer LTail] ? LTail
  : L;

type UnaryFn<A, R> = (a: A) => R;
type Arg<F> = F extends UnaryFn<infer A, unknown> ? A : never;
type Res<F> = F extends UnaryFn<any, infer R> ? R : never;

type ValidCompose<F1, F2> = Res<F1> extends (Arg<F2> | Promise<Arg<F2>>) ? F1
  : (arg: Arg<F1>) => Arg<F2>;

type ValidPipe<FS> = FS extends [infer F1, infer F2, ...infer Rest]
  ? [ValidCompose<F1, F2>, ...ValidPipe<[F2, ...Rest]>]
  : FS;

export const pipe = <Fs extends Func[]>(  ...fs: ValidPipe<Fs>) => {}

(<T, Fn extends (x: T) => number>(f: Fn) => {
  const g = (x: T) => x;
  const h = (_: T) => 1;
  pipe(g, f);  // This gives a typing error.
  pipe(g, h);  // This works fine.
});
```

### 🙁 Actual behavior

The first `pipe` invocation results in a typing error.

### 🙂 Expected behavior

None should have an error, because the generic typing ensures everything is in order.
Repository: pytorch
Issue: bc-linter false positive with TypeAliases
Labels: triaged,module: devx

### 🐛 Describe the bug

The BC-linter warned on my PR even though the actual type has not changed from `Dict[str, Any]`. In actuality, I just introduced a TypeAlias called StateDict for clarity. 

https://github.com/pytorch/pytorch/pull/105953#issuecomment-1653715848

### Versions

main

cc @ZainRizvi @kit1980 @huydhn @clee2000
Repository: pytorch
Issue: `export(..., pre_dispatch=True)` for model in eval mode still inserts autograd ops
Labels: triaged,pre_dispatch tracing,oncall: export

Support for `export(..., pre_dispatch=True)` was added to make sure autograd (and autocast) functionality (e.g. `torch.no_grad`) continue to work on exported graphs. This is needed for training on an exported model. The way this works is it inserts these `torch._C._set_grad_enabled` ops [into the graph](https://github.com/pytorch/pytorch/blob/646fa36875821f2bcf4fbfbf669c1f4f9f69700d/torch/fx/experimental/proxy_tensor.py#L517-L536).

We have a use case where we want to use `export(..., pre_dispatch=True)` for models in eval mode. However, I just tried this out and looks like I'm still seeing these `torch._C._set_grad_enabled` ops in the graph. This may lead to unexpected behavior during eval, where some gradients may be computed but we actually don't need them.

**Minimal repro:**
```
import torch
import torch._dynamo

class ToyModel(torch.nn.Module):
    def __init__(self):
        super(ToyModel, self).__init__()
        self.linear1 = torch.nn.Linear(10, 10)
        self.linear2 = torch.nn.Linear(10, 5)

    def forward(self, x):
        x = self.linear1(x)
        with torch.no_grad():
            x = self.linear2(x)
        return x

example_inputs = (torch.randn(10, 10),)
m = ToyModel().eval()
m, _ = torch._dynamo.export(
    m,
    *example_inputs,
    aten_graph=True,
    pre_dispatch=True,
)
print(m)
```

**Output:**
```
def forward(self, x):
    arg0, = fx_pytree.tree_flatten_spec(([x], {}), self._in_spec)
    _param_constant0 = self._param_constant0
    _param_constant1 = self._param_constant1
    linear_default = torch.ops.aten.linear.default(arg0, _param_constant0, _param_constant1);  arg0 = _param_constant0 = _param_constant1 = None
    _set_grad_enabled = torch._C._set_grad_enabled(False)
    _param_constant2 = self._param_constant2
    _param_constant3 = self._param_constant3
    linear_default_1 = torch.ops.aten.linear.default(linear_default, _param_constant2, _param_constant3);  linear_default = _param_constant2 = _param_constant3 = None
    _set_grad_enabled_1 = torch._C._set_grad_enabled(True)
    return pytree.tree_unflatten([linear_default_1], self._out_spec)
```
Repository: rust
Issue: Tracking Issue for linked_list_retain
Labels: T-libs-api,C-tracking-issue

<!--
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 `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(linked_list_retain)]`

This is a tracking issue for `LinkedList::{retain, retain_mut}`

<!--
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
// alloc::collections

pub struct LinkedList;

impl LinkedList {
    pub fn retain_mut<F>(&mut self, mut f: F)
    where
        F: FnMut(&mut T) -> bool;

    pub fn retain<F>(&mut self, mut f: F)
    where
        F: FnMut(&T) -> bool;
}
```

### 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: #114136 
- [ ] Final comment period (FCP)[^1]
- [ ] Stabilization PR

<!--
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 comment period
(FCP) is always needed before stabilization. This works as follows:

A library API 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
comment 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.
-->

- None yet.

[^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html


<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"TennyZhuang"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: pytorch
Issue: Sparse COO indices are torch.Int64 -- is this necessary?
Labels: module: sparse,triaged

### 🚀 The feature, motivation and pitch

```
import torch
import numpy as np

a = np.eye(10)
t = torch.Tensor(a).to_sparse_coo()
print(t.indices().dtype)
```
returns:
```torch.int64```

A 64-bit int seems excessive for storing coordinate indices, especially given the main intent of sparse formats is size reduction. Perhaps a torch.int32 would suffice? 

### Alternatives

_No response_

### Additional context

_No response_

cc @alexsamardzic @nikitaved @pearu @cpuhrsch @amjames @bhosmer
Repository: stable-diffusion-webui
Issue: [Feature Request]: Option to set a directory to save pre-hires (etc) images to
Labels: enhancement

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What would your feature do ?

I'd like to have the option to specify a directory in which images "created" by "Save a copy of image before ..." (located under Settings/Saving images/grids) get saved to.

### Proposed workflow

1. Go to Settings
either a)
2. Press Saving images/grids
3. Below the option "Save a copy of image before applying color correction to img2img results"
    a text field with the description: "Directory to save copies to: (Defaults to txt2img/img2img respectively)"
or
2. Press Paths for saving
3. A new field with the description: "Directory to save copies to: (Defaults to txt2img/img2img respectively)"


### Additional information

In the unlikely (I hope) event that I just missed something: Just let me know. :)
Repository: rust
Issue: rust-lldb encounters an error displaying local variables
Labels: A-debuginfo,C-bug,WG-debugging,S-needs-repro

<!--
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've loaded a (test) binary into `rust-lldb` via:
```
$ rust-lldb target/debug/deps/<mylib>-<hash>
```
then I stepped through a few lines of code and tried to list the local variables in the current stack frame:
```
(lldb) fr v
```
and encountered this error:
```
Traceback (most recent call last):
  File "/nix/store/r7hh9v94avlha6yrgv5a1dfwgfvkcyhl-rustc-1.70.0/lib/rustlib/etc/lldb_providers.py", line 516, in get_child_at_index
    idx = self.valid_indices[index]
IndexError: list index out of range
Traceback (most recent call last):
  File "/nix/store/r7hh9v94avlha6yrgv5a1dfwgfvkcyhl-rustc-1.70.0/lib/rustlib/etc/lldb_providers.py", line 516, in get_child_at_index
    idx = self.valid_indices[index]
IndexError: list index out of range
Traceback (most recent call last):
  File "/nix/store/r7hh9v94avlha6yrgv5a1dfwgfvkcyhl-rustc-1.70.0/lib/rustlib/etc/lldb_providers.py", line 516, in get_child_at_index
    idx = self.valid_indices[index]
IndexError: list index out of range
Traceback (most recent call last):
  File "/nix/store/r7hh9v94avlha6yrgv5a1dfwgfvkcyhl-rustc-1.70.0/lib/rustlib/etc/lldb_providers.py", line 516, in get_child_at_index
    idx = self.valid_indices[index]
IndexError: list index out of range
```
it did display all of the local variables though.

I expect the debugger to show all of the local variables _without_ encountering an error.

### 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`:
```
rustc 1.70.0 (90c541806 2023-05-31) (built from a source tarball)
binary: rustc
commit-hash: 90c541806f23a127002de5b4038be731ba1458ca
commit-date: 2023-05-31
host: aarch64-apple-darwin
release: 1.70.0
LLVM version: 16.0.1
```
Repository: TypeScript
Issue: Migrate `String` to `StringPrototype`, `Number` to `NumberPrototype`, etc
Labels: Suggestion,Awaiting More Feedback

# Suggestion

<!--
  Please fill in each section completely. Thank you!
-->

## 🔍 Search Terms

<!--
  💡 Did you know? TypeScript has over 2,000 open suggestions!
  🔎 Please search thoroughly before logging new feature requests as most common ideas already have a proposal in progress.
  The "Common Feature Requests" section of the FAQ lists many popular requests: https://github.com/Microsoft/TypeScript/wiki/FAQ#common-feature-requests

  Replace the text below:
-->

string prototype object number stringprototype

## ✅ Viability Checklist

<!--
   Suggestions that don't meet all these criteria are very, very unlikely to be accepted.
   We always recommend reviewing the TypeScript design goals before investing time writing
   a proposal for ideas outside the scope of the project.
-->
My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).


## ⭐ Suggestion

We're always seeing people writing `String`, `Number`, `Object`, and so on, in places where they should be writing their primitive equivalents.

We should mark these as `@deprecated` so that they show up with strikethroughs in the editor, and make new global interfaces named e.g. `StringPrototype` so it's more clear what they're for.

```
/**
 * @deprecated Use `string` when working with strings, or use `StringPrototype` to declare new string methods
 */
interface String {
```

For back compat, possibly forever, we'll need to declare these as
```ts
interface StringPrototype extends String { }
```
so that existing references to `String["charAt"]` continue to work and so that other merges continue to function.

## 📃 Motivating Example
![image](https://github.com/microsoft/TypeScript/assets/6685088/0c12ba7a-3a59-41c3-bef5-cabfb8877413)

![image](https://github.com/microsoft/TypeScript/assets/6685088/983de15f-1c47-4ea2-a7fd-308f5aca0478)

<!--
  If you were announcing this feature in a blog post, what's a short explanation that shows
  a developer why this feature improves the language?
-->

## 💻 Use Cases

 * New users coming to TS
Repository: TypeScript
Issue: TS intelisense crashes during import
Labels: Needs More Info


Type: <b>Bug</b>

Open a .ts file that includes Prisma 5 client (@prisma/client). Intellisense does not load TypeScript definitions and keeps crashing from time to time.

VS Code version: Code 1.80.1 (Universal) (74f6148eb9ea00507ec113ec51c489d6ffb4b771, 2023-07-12T17:20:23.298Z)
OS version: Darwin x64 22.1.0
Modes:

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i5-1038NG7 CPU @ 2.00GHz (8 x 2000)|
|GPU Status|2d_canvas: enabled<br>canvas_oop_rasterization: disabled_off<br>direct_rendering_display_compositor: disabled_off_ok<br>gpu_compositing: enabled<br>metal: disabled_off<br>multiple_raster_threads: enabled_on<br>opengl: enabled_on<br>rasterization: enabled<br>raw_draw: disabled_off_ok<br>video_decode: enabled<br>video_encode: enabled<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled<br>webgpu: enabled|
|Load (avg)|3, 4, 5|
|Memory (System)|16.00GB (1.19GB free)|
|Process Argv||
|Screen Reader|no|
|VM|0%|
</details><details><summary>Extensions (7)</summary>

Extension|Author (truncated)|Version
---|---|---
vscode-tailwindcss|bra|0.9.11
vscode-eslint|dba|2.4.2
EditorConfig|Edi|0.16.4
dotenv|mik|1.0.1
vscode-xml|red|0.26.1
vscode-yaml|red|1.14.0
pretty-ts-errors|yoa|0.4.1


</details><details>
<summary>A/B Experiments</summary>

```
vsliv368cf:30146710
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
vserr242:30382549
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscorecescf:30445987
vscod805:30301674
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593:30376534
pythonvs932:30410667
vsclangdf:30486550
c4g48928:30535728
dsvsc012:30540252
pynewext54:30695312
azure-dev_surveyone:30548225
vsccc:30610678
3biah626:30602489
f6dab269:30613381
a9j8j154:30646983
showlangstatbar:30737416
vsctsb:30748421
03d35959:30757346
24365598:30736109
pythonfmttext:30731395
pythoncmv:30756943
fixshowwlkth:30771522
hideindicator:30785051
pythongtdpath:30769146
i26e3531:30792625
gsofa:30797621
pythonnosmt12:30797651
pythonnoceb:30797650
e537b577:30795824
dsvsc013:30795093
dsvsc014:30797589

```

</details>

<!-- generated by issue reporter -->
Repository: flutter
Issue: Decide on an Android device testing policy for flutter/packages
Labels: team,team-ecosystem,P2,triaged-ecosystem

Historically we did not have emulator support for tests for Android in flutter/packages, so all Android integration testing was done on device via FTL. Now that we have emulator tests (other than camera; see https://github.com/flutter/flutter/issues/130987) it's not clear what the physical device testing strategy should be:
- Eliminate them completely?
- Make them post-submit only?
- Keep the duplicate testing everywhere?
- Pare it down to a limit set of plugins and/or tests?

In the short term, since we don't have any data about the relative ability of integration tests vs device tests to catch issues for us in practice, we're going to keep duplicate tests. The main `android_platform_tests` tasks will run emulator (along with all the other standard platform tests, like build and native unit), and a new set of tasks will be brought up to run just the FTL tests.

After we have a few months of data comparing its effectiveness to emulator tests, we should revisit if/how we want to continue the use of FTL. (In the meantime, this does mean we'll double our exposure to integration test flake for Android, and integration tests are—across platforms—by far the flakiest of tests.)
Repository: ollama
Issue: Please don’t clutter the user home directory
Labels: feature request

Currently Ollama is writing into a directory in the user home, `~/.ollama`.

However, the user home directory should be under the *user’s* control, and applications may only write into it if explicitly instructed to do so by the user. Settings etc. belong in OS-specific locations; in particular, under `~/Library` on macOS, under `%AppData%` or `%LocalAppData%` on Windows and, by convention, in directories following the [XDG basedir specification](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) on Linux.
Repository: godot
Issue: Export variables' tooltips need a scene refresh to show up (eg. move to another scene and come back)  
Labels: bug,topic:gdscript,topic:editor

### Godot version

v4.1.stable.official [970459615]

### System information

Godot v4.1.stable - Windows 10.0.19045 - Vulkan (Compatibility) - Intel(R) HD Graphics 4600 (Intel Corporation; 20.19.15.4531) - Intel(R) Core(TM) i5-4200M CPU @ 2.50GHz (4 Threads)

### Issue description

When I make an exported variable, and give it a custom tooltip, It doesn't automatically show up, no matter how long I wait.
But if I were to reload the _node_ (eg. restart the editor, or inspect another node and come back) or save the script then it does show up. This also happens when you change the tooltip.

On its own, there is nothing wrong with this. However, if I were to make another export variable, for example, it WOULD show up without a manual reload, or a save. As such, the issue is simply that it's inconsistent; why would adding a new export variable show up, but a simple tooltip need a reload or a save?

I presume this is an easy fix: Just update the tooltip at the same time as when you update export variables.

### Steps to reproduce

Easiest way to reproduce:
Make a new Node (Type: Node)
Add a script.
Paste:
```
extends Node
## Wow! Tooltips!
@export TEST: bool
```
Hover over the exported variable.
You shall see there is no description despite you typing one.
But if you make a new scene for a moment, return to the old one, and hover over the variable, it'll show up.

You can also change the tooltip again, and see it won't update unless you save the script.

### Minimal reproduction project

N/A