sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: svelte
Issue: Distinguish between properties and attributes on custom elements
Labels: feature request,custom element

### Describe the problem

One of the many reasons custom elements are a pain in the neck is that it's often rather ambiguous what's supposed to be an attribute and what's supposed to be a property. Some custom elements 'reflect' attributes back to properties and vice versa, but there's no universally agreed upon convention. If you're doing low-level DOM manipulation you can decide whether you want to do `element.setAttribute(name, value)` or `element[name] = value`, but everyone stopped writing code like that a decade ago.

It's a messy, flawed design, and different frameworks deal with it in different ways. [Preact](https://preactjs.com/guide/v10/web-components/) and Svelte both treat something as a property if `prop in node`, and an attribute otherwise. Vue [does the same thing](https://vuejs.org/guide/extras/web-components#passing-dom-properties) but additionally gives you a way to force something to be a prop (I don't think you can force something to be an attribute) with some interesting syntax choices:

---

<img width="704" alt="image" src="https://github.com/user-attachments/assets/dbb5e098-d5ee-492a-a818-865aba32fe16">

---

Lit [leans even harder](https://lit.dev/docs/templates/expressions/) into syntax, with `?` and `.` and `@` prefixes for boolean attributes, properties and event handlers respectively:

---

<img width="751" alt="image" src="https://github.com/user-attachments/assets/6afddb24-0c19-44ce-892e-2a14290a2531">

---

I think the explicit control is a good thing, but I think we can provide it more naturally.

### Describe the proposed solution

#7925 and #12479 point the way. We're moving to a world in which quoted props on components are stringified:

```svelte
<script>
  let object = { a: 1, b: 2, c: 3 };
</script>

<!-- in Svelte 6, this will mean `data="[object Object]"` -->
<Thing data="{object}" />
```

(The reason the quotes are ignored today is historical: in the distant past before Svelte editor extensions, when components were typically written in `.html` files, it avoided crazypants syntax highlighting.)

What if we did something similar for custom elements?

```svelte
<foo-bar someprop={somevalue} someattribute="{someothervalue}"></foo-bar>
```

In other words if something is quoted, it's an attribute, otherwise it's a prop. We might need to change some Prettier defaults, but other than that this should be a relatively straightforward change. (I don't see any need to distinguish between 'boolean attributes' and properties like Lit does — they're all just properties.)

It is, of course, a breaking change. We would need to decide whether to do this in 5.0, or have a bunch of warnings and change it in 6.0. Ordinarily the conservative thing to do would be to delay the breaking change, but since it's not currently possible to differentiate properties and attributes I think there's a reasonable case for doing it sooner. As such I've given it a 5.0 milestone for now.

### Importance

nice to have
Repository: PowerToys
Issue: Performance tune Settings app for startup time
Labels: Idea-Enhancement,Help Wanted,Product-Settings

### Description of the new feature / enhancement

Settings app is slow to boot which also affects OOBE and Quick launch.

### Scenario when this would be used?

Quick Launch / instant starting on lower spec machines

### Supporting information

_No response_
Repository: deno
Issue: `specs::publish::invalid_import_esm_sh_suggestion` is flaky
Labels: flaky

We should not have tests relying on real servers.

```
---- specs::publish::invalid_import_esm_sh_suggestion ----
command /home/runner/work/deno/deno/target/release/deno publish --token 'sadfasdf' --dry-run
command cwd /home/runner/work/deno/deno/tests/specs/publish/invalid_import_esm_sh_suggestion
output path /home/runner/work/deno/deno/tests/specs/publish/invalid_import_esm_sh_suggestion/invalid_import_esm_sh_suggestion.out
-- OUTPUT START --
Download http://esm.sh/react-dom@18.2.0/server
Download https://esm.sh/react-dom@18.2.0/server
error: Import 'https://esm.sh/react-dom@18.2.0/server' failed: 520 <unknown status code>
    at file:///home/runner/work/deno/deno/tests/specs/publish/invalid_import_esm_sh_suggestion/mod.ts:1:8
```
Repository: pytorch
Issue: [export] Schematize nn_module_stack serialization
Labels: good first issue,export-triaged,oncall: export

### 🐛 Describe the bug

We should schematize nn_module_stack serialization so that we're not [splitting based on commas / characters](https://github.com/pytorch/pytorch/blob/f901b020666a3cf239fbb9070e3317d453256df7/torch/_export/serde/serialize.py#L570-L585) as this is error prone.

An example is https://fb.workplace.com/groups/1075192433118967/permalink/1471290750175798/ which fails during deserialization [here](https://github.com/pytorch/pytorch/blob/f901b020666a3cf239fbb9070e3317d453256df7/torch/_export/serde/serialize.py#L2154-L2158) due to nn_module_stack containing commas:
```
{L__self__,,torch.nn.modules.container.Sequential;
fn,L['fn'],torch.nn.modules.container.Sequential;
fn_0,getattr(L['fn'], '0'),torch.nn.modules.container.Sequential;
fn_0_0,getattr(getattr(L['fn'], '0'), '0'),on_device_ai.application_profile_runs.sweeper_run.Conv2dBNReLU;
getattr_getattr_L__fn_____0_____0___core,getattr(getattr(L['fn'], '0'), '0').core,torch.nn.modules.container.Sequential;
getattr_getattr_L__fn_____0_____0___core_0,getattr(getattr(getattr(L['fn'], '0'), '0').core, '0'),torch.nn.modules.conv.Conv2d}
```

### Versions

main

cc @avikchaudhuri @gmagogsfm @zhxchen17 @tugsbayasgalan @suo @ydwu4 @penguinwu
Repository: TypeScript
Issue: Change quick fix JSDoc Import
Labels: Suggestion,Awaiting More Feedback

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->

When adding a JSDoc comment within a `.js` file, such as `/** @type {Entity} */`, using the quick fix feature will promptly import the `Entity` module using the standard ECMAScript Module (ESM) syntax. However, I recommend that, when within the JSDoc comment, the import be handled using the newly released `@import` statement for better compatibility and clarity.

**Example**:

![image](https://github.com/user-attachments/assets/2a4eb9bf-c582-4aa0-88cc-621c0eb38172)

![image](https://github.com/user-attachments/assets/64d4967a-adbc-4121-a8f9-a09126c4cab9)

Will result in:
![image](https://github.com/user-attachments/assets/60876aa3-420c-4cfe-b14b-7d01c245cae2)

Result that would be nice:
![image](https://github.com/user-attachments/assets/e43c70b6-a69e-4e71-ae41-029ce6cd1fce)
Repository: PowerToys
Issue: Running power toys as normal user and trying to update using an elevated account fails and
Labels: Issue-Bug,Area-Setup/Install,Needs-Triage

### Microsoft PowerToys version

0.81.1

### Installation method

PowerToys auto-update

### Running as admin

No

### Area(s) with issue?

Settings

### Steps to reproduce

Running Power Toys as a normal user and using an elevated account to update it when notified leads to a disappearing update screen and a messy situation that Power Toys don't start up and when they do after several trials it still shows the old version and a question to update. When switching to an elevated account to perform the update the window does not even appear and again after serveral stops and starts it finally show up. 

### ✔️ Expected Behavior

Start the update, ask for an elevated account, perform the update and report success, restart powertoys in the new version and say that the update succeeded. 

### ❌ Actual Behavior

Running Power Toys as a normal user and using an elevated account to update it when notified leads to a disappearing update screen and a messy situation that Power Toys don't start up and when they do after several trials it still shows the old version and a question to update. When switching to an elevated account to perform the update the window does not even appear and again after serveral stops and starts it finally show up. 

### Other Software

Microsoft and Adobe.
Repository: godot
Issue: CSV file doesn't open in script editor when double-clicked in the Import dock
Labels: bug,topic:editor,confirmed,usability

### Tested versions

Godot v4.2.2.stable

### System information

macOS 14.5.0 - GLES3 (Compatibility) - Apple M2 Pro - Apple M2 Pro (10 Threads)

### Issue description

Sorry if this is intended behaviour or it was reported before – I haven't found an issue on it.

1. When I try to open a CSV file the output logs the following:
```
Failed loading resource: res://translation.csv. Make sure resources have been imported by opening the project in the editor at least once.
editor/editor_node.cpp:1227 - Condition "!res.is_valid()" is true. Returning: ERR_CANT_OPEN
```
2. I assume it was imported correctly, because a `translation.csv.import` and `translation.en.translation` were created
3. I would have expected that the CSV opens in the script editor (like .md-files) like it's common other text/code editors (e.g. VSCode)

### Steps to reproduce

1. Create or download a CSV file
2. Import it and double click it

### Minimal reproduction project (MRP)

[translation-test.zip](https://github.com/user-attachments/files/16396782/translation-test.zip)
Repository: pytorch
Issue: TORCH_COMPILE_CPROFILE=1 broken (strobelight might always be on internally?)
Labels: triaged,oncall: pt2,module: dynamo,module: startup-tracing-compile

Repro: `TORCH_COMPILE_CPROFILE=1 python foo.py`
on
```py
import torch

@torch.compile
def f(x):
    return x.sin()

x = torch.randn(3, device="cuda")
f(x)
```
gives the following stack trace:
```
Traceback (most recent call last):
  File "/home/rzou/dev/opt-cuda3/pt-opt-cuda3/foo.py", line 8, in <module>
    f(x)
  File "/home/rzou/dev/opt-cuda3/pt-opt-cuda3/torch/_dynamo/eval_frame.py", line 448, in _fn
    return fn(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^
  File "/home/rzou/dev/opt-cuda3/pt-opt-cuda3/torch/_dynamo/convert_frame.py", line 1171, in __call__
    return self._torchdynamo_orig_callable(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/rzou/dev/opt-cuda3/pt-opt-cuda3/torch/_dynamo/convert_frame.py", line 980, in __call__
    result = self._inner_convert(
             ^^^^^^^^^^^^^^^^^^^^
  File "/home/rzou/dev/opt-cuda3/pt-opt-cuda3/torch/_dynamo/convert_frame.py", line 500, in __call__
    return _compile(
           ^^^^^^^^^
  File "/home/rzou/dev/opt-cuda3/env/lib/python3.12/contextlib.py", line 81, in inner
    return func(*args, **kwds)
           ^^^^^^^^^^^^^^^^^^^
  File "/home/rzou/dev/opt-cuda3/pt-opt-cuda3/torch/_dynamo/convert_frame.py", line 878, in _compile
    raise InternalTorchDynamoError(str(e)).with_traceback(
  File "/home/rzou/dev/opt-cuda3/pt-opt-cuda3/torch/_dynamo/convert_frame.py", line 851, in _compile
    guarded_code = compile_inner(code, one_graph, hooks, transform)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/rzou/dev/opt-cuda3/pt-opt-cuda3/torch/_dynamo/utils.py", line 272, in time_wrapper
    r = func(*args, **kwargs)
        ^^^^^^^^^^^^^^^^^^^^^
  File "/home/rzou/dev/opt-cuda3/pt-opt-cuda3/torch/_utils_internal.py", line 85, in wrapper_function
    return StrobelightCompileTimeProfiler.profile_compile_time(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/rzou/dev/opt-cuda3/pt-opt-cuda3/torch/_strobelight/compile_time_profiler.py", line 129, in profile_compile_time
    return func(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/home/rzou/dev/opt-cuda3/pt-opt-cuda3/torch/_dynamo/convert_frame.py", line 334, in profile_wrapper
    retval = prof.runcall(func, *args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/rzou/dev/opt-cuda3/env/lib/python3.12/cProfile.py", line 109, in runcall
    self.enable()
torch._dynamo.exc.InternalTorchDynamoError: Another profiling tool is already active
```

cc @ezyang @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng @amjames @oulgen @jamesjwu @aorenste @anijain2305 @laithsakka
Repository: godot
Issue: Barriers after return in some compute shaders
Labels: bug,topic:rendering

### Tested versions

All released version of 4.x including the soon to be released 4.3

### System information

All systems

### Issue description

In many of our compute shaders we utilize memory barriers to synchronize threads before proceeding. Barriers must be uniform in terms of control flow, which means that they cannot be used in situations where one thread in a group may not reach them. 

A common way where one thread may not reach a barrier in a group is if the barrier is behind an if statement and the condition is non-uniform. Another common way is if the shader returns before the barrier conditionally (non-uniform). 

The latter is a common pattern in Godot. We do an early return for threads which won't contribute to the output of the shader. 

The consequence of returning non-uniformly is that it is possible for the shader to crash, fail to run, or hang indefinitely. We first encountered this problem while working on HDDAGI and testing it on Intel devices. 

This problem is likely responsible for a lot of the "Device Lost" errors that we get and should be remedied as soon as possible. 

The solution is to move the non-uniform control flow statements to after all the barriers have been executed. For example, for the jumpflood stage of SDFGI, we could take the return here:

https://github.com/godotengine/godot/blob/607b230ffe120b2757c56bd3d52a7a0d4e502cfe/servers/rendering/renderer_rd/shaders/environment/sdfgi_preprocess.glsl#L377-L384

And simply move it to be after the barrier.



### Steps to reproduce

Run Godot with one of the following effects:
1. Auto Exposure
2. SDFGI
3. TAA
4. Glow
5. VoxelGI
6. SSAO, SSR, SSIL, DoF
7. GPUParticles

### Minimal reproduction project (MRP)

The problem is internal to Godot
Repository: pytorch
Issue: Distributed tests failing on Amazon2023 AMI
Labels: triaged

### 🐛 Describe the bug

Something about the new Amazon2023 AMI is making some distributed tests fail, particularly tests that take nccl dumps during timeouts.

Failure 1: https://github.com/pytorch/pytorch/actions/runs/10047579686/job/27770963175
```
FAILED [90.0880s] distributed/test_c10d_nccl.py::NCCLTraceTestDumpOnTimeout::test_timeout_dumps_timing_enabled_False - AssertionError: None mismatch: None is not -6
```

Failure 2: https://github.com/pytorch/pytorch/actions/runs/10047579686/job/27770963494

```
____ NCCLTraceTestTimeoutDumpOnStuckRanks.test_timeout_dumps_on_stuck_ranks ____
Traceback (most recent call last):
  File "/var/lib/jenkins/workspace/test/distributed/test_c10d_nccl.py", line 4214, in test_timeout_dumps_on_stuck_ranks
    self.assertEqual(self._wait_process(0, timeout=90), -6)
  File "/opt/conda/envs/py_3.10/lib/python3.10/site-packages/torch/testing/_internal/common_utils.py", line 3721, in assertEqual
    raise error_metas.pop()[0].to_error(
AssertionError: None mismatch: None is not -6
```

Failure 3:
https://github.com/pytorch/pytorch/issues/129539

# Repo steps
Here’s the minimal PR to repro (just 3 lines). With it you can see the results in CI and ssh into those machines. 

https://github.com/pytorch/pytorch/pull/131479/files
Repository: PowerToys
Issue: PowerRename does not appear in Windows 11's default context menu
Labels: Issue-Bug,Product-PowerRename,Needs-Triage,Area-Context Menu

### Microsoft PowerToys version

0.82.1

### Installation method

WinGet

### Running as admin

No

### Area(s) with issue?

PowerRename

### Steps to reproduce

![image](https://github.com/user-attachments/assets/aa5bbb6c-0b40-4e3a-9e6b-9910adf90fcb)

1. I right clicked a folder
2. Apps that relies on the new context menu on Windows 11 don't show up (which is apparently a normal behavior)
3. Right click the folder again and apps like Windows Terminal, Winrar show up, except for PowerRename

### ✔️ Expected Behavior

PowerRename should appear in default context menu on Windows 11.

### ❌ Actual Behavior

PowerRename doesn't show up in default context menu at all. I had to use the extended one.

![image](https://github.com/user-attachments/assets/b9ce7fd2-d1af-4142-a689-599b04d9895a)


### Other Software

_No response_

Edit: Added the bug report

[PowerToysReport_2024-07-27-00-08-13.zip](https://github.com/user-attachments/files/16397322/PowerToysReport_2024-07-27-00-08-13.zip)
Repository: flutter
Issue: Consider making `flutter drive` default to using `dart test` as the runner script
Labels: tool,t: flutter driver,c: proposal,P3,c: tech-debt,p: requires breaking change,team-tool

As of 2024-07-26, we discovered, that due to how the `dart` CLI has evolved, it's now possible to opt-in to using the `dart test` runner (instead of running a given driver script as a standalone Dart executable).

This allows, among other things, to customize the reporter and file reporter. For example: 

```sh 
# Old behavior, runs `dart test/main_test.dart`.
flutter drive

# Opt-in behavior, runs `dart test test/main_test.dart`
flutter drive --test-arguments="test"

# An example of using this behavior to customize the reporter
flutter drive --test-arguments="test --reporter=expanded"
```

I personally believe that using a mature test runner like `dart test` is a better long-term outlook for the tool, versus asking users to opt-in to it, or provide their own tooling by default, so I'd like to see us _flip_ the behavior, for example:

```sh
# Uses dart test
flutter drive

# Opts-out of using dart test (flag TBD)
flutter drive --custom-test-runner
```

However, this would be a breaking change, and we should prioritize this accordingly.
Repository: ollama
Issue: JSON Schema conformity using Llama.cpp Grammar generation for Tool Calling
Labels: feature request

First thanks to the ollama Team, it's a pleasure to use!

I was looking into the Topic of Schema and Grammar from the tools' perspective.

I assume:

- the tool arguments json schema, only inserted into the Prompt by ollama
- no grammar is used to enforce the json schema for tool arguments
- (only the json grammar is used)
- the json-schema is not used for validation after parsing as well

Since Multiple pull request for the Topic of JSON schema and Grammars are open, I would like to address that by suggesting closing them.
For the few people that actually need Grammar support, using llama.cpp without ollama seem appropriate, since using grammars is already very low level.

ollama could focus to support tools calling with JSON Schema conformity.

One would need to combine all possible Tools into one JSON Schema.
A bit like in this https://github.com/ggerganov/llama.cpp/issues/7703 example.

Then the model can be constrained to comply to the correct tool use.
The problem is the exact tool support output depends on the model:

https://github.com/ollama/ollama/blob/f5e3939220e9cd3d7a636708bc9df031ebfd4854/server/testdata/tools/llama3-groq-tool-use.out#L14

vs 

https://github.com/ollama/ollama/blob/f5e3939220e9cd3d7a636708bc9df031ebfd4854/server/testdata/tools/firefunction.out#L17

vs


https://github.com/meta-llama/llama-models/blob/e51c73ac639a38877da9bdfaecb4cb07dc8ba6d0/models/llama3_1/api/tool_utils.py#L16



How to deal with the:

--"functools" in firefunction
--"<tool_call>" token in llama3-groq
--"<function=****>" for llama 3.1

is not clear for me jet, since I think it would be best to leverage the JSON-Schema to grammar functionality in llama.cpp.

@mxyng What do think about that?

Should I spend time working or that, or is there no chance to be merged into ollama?


This should address:

https://github.com/ollama/ollama/issues/5976
https://github.com/ollama/ollama/issues/1507
https://github.com/ollama/ollama/pull/5348
https://github.com/ollama/ollama/pull/830
https://github.com/ollama/ollama/pull/565
https://github.com/ollama/ollama/pull/1606
https://github.com/ollama/ollama/pull/4525
https://github.com/ollama/ollama/pull/2404

on the consumer side:
https://github.com/thmsmlr/instructor_ex/issues/11
Repository: pytorch
Issue: Layer normalization on Nested Tensor ragged dimension fails when `lengths is not None`
Labels: triaged,module: nestedtensor

### 🐛 Describe the bug

Performing layer normalization along the ragged dimension on a nested tensor with holes (`lengths is not None`) is currently incorrect but does not throw an error:
```
import torch

device, dtype = "cpu", torch.float32
lengths = torch.randint(5, 10, (20,), device=device)
offsets = torch.zeros((21,), device=device, dtype=torch.int)
torch.cumsum(lengths, dim=0, out=offsets[1:])
values = torch.randn(
    (offsets[-1].item(), 10, 30),
    device=device,
    dtype=dtype,
)

nt_with_holes = torch.nested.nested_tensor_from_jagged(
    values,
    offsets,
    lengths=offsets.diff() - 2,  # arbitrary subtraction to create holes
)

out = torch.nn.functional.layer_norm(
    nt_with_holes, normalized_shape=(-1, 10, 30),
)
```

### Versions

fbcode H100 7/26/24

cc @cpuhrsch @jbschlosser @bhosmer @drisspg @soulitzer @davidberard98 @YuqingJ
Repository: flutter
Issue: [engine/framework] opaque platform views.
Labels: c: new feature,P3,team-engine,triaged-engine

Most platform views (webview, ads, google maps) have little or no transparency. If the engine knew that the platform view or views it is compositing did not have transparency, it could optimize rendering in a number of common scenarios:

1. The entire background frame is occluded by a platform view (google maps). We can skip rendering or presenting the background view entirely. 

2. There are multiple platform views and/or overlapping UI elements. All overlays can be combined into one and pulled forward. We can clip out any interleaved Flutter UI. 


* Changes: add a `bool opaque = true` to all platform view constructors and send a breaking change notice. Update platform view slicing logic to account for this flag.