sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Tracking Issue for `Duration::as_millis_{f64,f32}`
Labels: T-libs-api,C-tracking-issue

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

This is a tracking issue for
 - `Duration::as_millis_f64`
 - `Duration::as_millis_f32`

### Public API

```rust
impl Duration {
    /// Returns the number of milliseconds contained by this `Duration` as `f64`.
    ///
    /// The returned value does include the fractional (nanosecond) part of the duration.
    ///
    /// # Examples
    /// ```
    /// use std::time::Duration;
    ///
    /// let dur = Duration::new(2, 67_890_000);
    /// assert_eq!(dur.as_millis_f64(), 2678.9);
    /// ```
    pub const fn as_millis_f64(self);

    /// Returns the number of milliseconds contained by this `Duration` as `f32`.
    ///
    /// The returned value does include the fractional (nanosecond) part of the duration.
    ///
    /// # Examples
    /// ```
    /// use std::time::Duration;
    ///
    /// let dur = Duration::new(2, 67_890_000);
    /// assert_eq!(dur.as_millis_f32(), 2678.9);
    /// ```
    pub const fn as_millis_f32(self);
}
```

### Steps / History

- [x] ACP: https://github.com/rust-lang/libs-team/issues/349
- [x] Implementation: https://github.com/rust-lang/rust/pull/122479
- [x] Related lint: https://github.com/rust-lang/rust-clippy/pull/12539
- [ ] Final comment period (FCP)[^1]
- [ ] Stabilization PR

### Unresolved Questions

- [ ] The implementation is using floating-point division; would we be ok with changing it to multiplication-by-reciprocal at the cost of a ½ULP but being faster?  `as_secs_f32` uses division, so maybe not.

[^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html
Repository: pytorch
Issue: Revive libtorch-shared-without-deps flavor
Labels: module: binaries,module: cpp,module: abi,triaged

### 🐛 Describe the bug
~~After v2.1.0 download indices at https://download.pytorch.org/libtorch/cpu stopped updating. The same is true for CUDA versions: https://download.pytorch.org/libtorch/cu121~~ ~~

~~Even worse, all links do not work anymore and have to be fixed (insert `/cpu` or `cu121` subpaths) to make them work:~~

~~Does not work: `https://download.pytorch.org/libtorch/libtorch-shared-without-deps-2.1.0%2Bcu121.zip`~~ 
~~Fixed: `https://download.pytorch.org/libtorch/cu121/libtorch-shared-without-deps-2.1.0%2Bcu121.zip`~~

Strike-through added by @malfet, as this part was fixes by https://github.com/pytorch/test-infra/pull/5296 but I've completely missed 2nd part of the issue about `shared-without-deps` 

I'm especially interested in `https://download.pytorch.org/libtorch/cu121/libtorch-cxx11-abi-shared-without-deps-2.2.1%2Bcu121.zip`, however, the linux `without-deps` versions are sadly not available at all anymore since v2.2.0 or I haven't found them.

### Versions

latest version of https://download.pytorch.org/

cc @seemethere @malfet @osalpekar @atalman @jbschlosser
Repository: deno
Issue: Proposal: --allow-net-fetch (fetch-only net permissions)
Labels: cli,permissions,suggestion

I don't know how the net permissions will be improved in Deno 2.0 (or if they will?) but I would like to make this suggestion:

Add a permission that allows net access via fetch only.

Why?

First, it would cover a large majority of use cases, where code just needs to make HTTP requests. Unlike `--allow-net` it doesn't allow a server to listen (see #16532) and you can't use it to start TELNET session to probe for network services.

Second, when used in combination with `HTTP[S]_PROXY, it would guarantee that all net requests go through the proxy. This is useful if you want to allow net requests, but you need to monitor them and provide additional filtering.

Currently, you can use `HTTP_PROXY` to filter or monitor fetches, but nothing prevents malicious code from bypassing the proxy using `Deno.connect`. With `--allow-net-fetch`, net activity initiated with Deno.connect gets blocked (unless allowed using `--allow-net`).

In other discussions, Deno team members have recommended that Deno be run with its own networking namespace to cover this requirement (https://github.com/denoland/deno/issues/11925#issuecomment-1678594198). However this implies a Linux environment and rules out using this on local machines running Mac or Windows. With `--allow-net-fetch` you don't have to be on Linux (and you don't have to mess with namespaces, which can be prickly).

There are a number of reasons why systems may want to filter net requests beyond what Deno currently allows:

- filter on full URLs: https://github.com/denoland/deno/issues/5242
- SSRF naughtiness https://github.com/denoland/deno/issues/21227
- Any number of other application-specific security issue.

It would be great if Deno could offer a simple cross-platform way to monitor/block fetches.

Thank-you for considering!

✌️
Repository: godot
Issue: HTML5 cache actual implementation is not "dynamic enough".
Labels: bug,platform:web

### Tested versions

3.x

### System information

web

### Issue description

So, this you can catch the cache bug on several instances.

Instance N1:
If one creates a html enabled project, and put on a root node on ready:
OS.alert(X)

and run on brower using the internal localhost debug, it will load.

Then, if one changes from X to Y, and reload:
There is a big chance you will see X on the alert, not Y

SO, mitigations i found:

N1M0:
Just reload the page SEVERAL times

N1M1:
Close and re-start the godot webserver that is serving the localhost 
(does not work very often)

N1M2:
Do or do not do N1M1, AND, open a new guest (incognito does not aways clean itself fully), and load the link
(this AWAYS work)

Instance N2:

On deploy, this behaviour continues, and if one has already loaded a page, it will load the old version again, and again, and again, and i could not find a pattern, but it will load the new page, if one continues.
(But, a curiosity is that the HTML page, the LOADER, is aways the fresh new file, so it must be the PCK that is not being re-downloaded, but if the HTML is detected and re-requested, why not the rest?)

N2M0:
Just reload the page SEVERAL times, but does not work with a pattern. on N1M0 it will aways load the new one serveral consecutives reloads.

N2M1:
This is the same almost as N1M2, juts open the link on a guest profile on your browser, and it will AWAYS load fully and correct.

Instance N3:
on that, in have several isues already reported here:
https://github.com/godotengine/godot/issues/69414
https://github.com/godotengine/godot/issues/84996
https://github.com/godotengine/godot/issues/86099

and its all about progressive web apps and being able to load correct version, work offline, and so on.

The instance is, that on PWA, you cant force a incognito re-load.
And on they too, the new html loader is readly loaded, but the old project data is still being load. The pck(/wasm too?)is not being refreshed as need.

and too, the app wont work without network.



So, all this is making the webmaster work stressfuN and not performant, neither consistent, because i cant determine state of versioning on users, with safety without central autority.

Well, thats the report.




### Steps to reproduce

cited above

### Minimal reproduction project (MRP)

described in body
Repository: tensorflow
Issue: Incorrect result when using tf.norm to conduct p-norm computation on float16 precision
Labels: stat:awaiting tensorflower,type:bug,comp:ops,TF 2.15

### Issue type

Bug

### Have you reproduced the bug with TensorFlow Nightly?

Yes

### Source

source

### TensorFlow version

2.15.0

### Custom code

Yes

### OS platform and distribution

_No response_

### Mobile device

_No response_

### Python version

_No response_

### Bazel version

_No response_

### GCC/compiler version

_No response_

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current behavior?

tf.norm outputs incorrect result under float16 computation when the ord is large. Here is the code to reproduce:

```
import tensorflow as tf
input = tf.constant(1.751, dtype="float16")
p = 144111111
print(tf.norm(input, p))   # tf.Tensor(1.0, shape=(), dtype=float16)
```
Instead, if I change the dtype to 'float32', tf.norm outputs `inf`. It seems that tf.norm overflows during this computation https://github.com/tensorflow/tensorflow/blob/9ce1d5f2f7e5e8866a55633c182cc2dda1a2d6b8/tensorflow/python/ops/linalg_ops.py#L784

Although fixing this issue by letting tf.norm also outputs `inf` in `float16` (which is consistent with the result in `float32`. I am suggesting another possible fix according to this post https://timvieira.github.io/blog/post/2014/11/10/numerically-stable-p-norms/

Indeed, the original implementation may not be numerical stable, a more stable one is to normalize the input before doing the actual computation. Here is the naive implementation of original tf.norm and the numerical stable one as a possible fix:

```
import tensorflow as tf
input = tf.constant(1.751, dtype="float16")
p = 144111111

def origin_norm(x, p):
  result = tf.math.abs(x)
  result = tf.math.pow(
      tf.reduce_sum(tf.math.pow(result, p), axis=None, keepdims=True),
      1.0 / p)
  return result

def refined_norm(x, p):
  a = np.abs(x).max()
  return a * origin_norm(x/a, p)

print(f"The original tf.norm's output is: ", tf.norm(input, p))
print(f"The naive implementation of tf.norm: {origin_norm(input, p)}, the refined norm: {refined_norm(input, p)}")
```

The `refined_norm` will output correct results (i.e., 1.7509765625) not only for `float16` computation but also for `float32` computation.


### Standalone code to reproduce the issue

```shell
import tensorflow as tf
input = tf.constant(1.751, dtype="float16")
p = 144111111

def origin_norm(x, p):
  result = tf.math.abs(x)
  result = tf.math.pow(
      tf.reduce_sum(tf.math.pow(result, p), axis=None, keepdims=True),
      1.0 / p)
  return result

def refined_norm(x, p):
  a = np.abs(x).max()
  return a * origin_norm(x/a, p)

print(f"The original tf.norm's output is: ", tf.norm(input, p))
print(f"The naive implementation of tf.norm: {origin_norm(input, p)}, the refined norm: {refined_norm(input, p)}")
```


### Relevant log output

_No response_
Repository: next.js
Issue: Problem running installation app due to multiple casing problem
Labels: bug

### Link to the code that reproduces this issue

https://github.com/gsaint12/afiaweb

### To Reproduce

1: Install latest app 
2: Run dev
3: App crashes with error

### Current vs. Expected behavior

It is expecte that the app runs the default template after installation but what happens is that it runs and then crashes with some errors, there are multiple modules with names that only differ in casing for default modules.

affected modules:
\node_modules\next\dist\compiled\@next\react-refresh-utils\dist\loader.js
\node_modules\next\dist\build\webpack\loaders\next-flight-client-module-loader.js
node_modules\next\dist\build\webpack\loaders\next-swc-loader.js??ruleSet[1].rules[14].oneOf[4].use[1]
node_modules\next\dist\shared\lib\utils\warn-once.js

### Provide environment information

```bash
window10
```


### Which area(s) are affected? (Select all that apply)

App Router

### Which stage(s) are affected? (Select all that apply)

next dev (local)

### Additional context

I tried all available methods of installation yet ended up with same problem
Repository: tensorflow
Issue: _pywrap_tensorflow_internal.so library contains RUNPATH entries that look like C++ symbols
Labels: stat:awaiting tensorflower,type:bug,type:build/install,TF 2.16

### Issue type

Bug

### TensorFlow version

2.13 - 2.16

### Python version

3.11, 3.12

### Current behavior?

The RUNPATH in the wheel shared objects is weirdly mangled:

```
$ wget https://files.pythonhosted.org/packages/0d/58/d302d19f06d028ad6c2e33c449ef9813058a16dc35c0ca9580740e0dc9ed/tensorflow-2.16.1-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
$ unzip *.whl
$ objdump -x tensorflow/python/_pywrap_tensorflow_internal.so | grep RUNPATH
  RUNPATH              $ORIGIN/../../_solib_local/_U_S_Stensorflow_Spython_C_Upywrap_Utensorflow_Uinternal.so_Ucclib___Utensorflow:$ORIGIN/_pywrap_tensorflow_internal.so.runfiles/org_tensorflow/_solib_local/_U_S_Stensorflow_Spython_C_Upywrap_Utensorflow_Uinternal.so_Ucclib___Utensorflow:$ORIGIN/../../_solib_local/_Utensorflow:$ORIGIN/_pywrap_tensorflow_internal.so.runfiles/org_tensorflow/_solib_local/_Utensorflow:$ORIGIN/:$ORIGIN/..:$ORIGIN/../../nvidia/nccl/lib:$ORIGIN/../nvidia/nccl/lib:$ORIGIN/../../tensorflow/tsl/python/lib/core
```

It's not just that one, almost every SO is affected, see:
```
find tensorflow/ -name *.so -exec objdump -x {} \; | grep RUNPATH
```

Under a custom NixOS build, this mess seems to further confuse follow-on patchelf invocations, which is requiring additional hackery to correct. Possibly related to #34991; the objdump in that ticket shows the same kind of RUNPATH.

### Standalone code to reproduce the issue

```shell
Download any wheel from PyPI, examine the `so`s contained within for their RUNPATH values.
```


### Relevant log output

_No response_
Repository: godot
Issue: Control Node jumps to right by screen width when building the game
Labels: bug,needs testing,topic:gui,topic:animation

### Tested versions

Produced in both 4.2.1 and 4.3d4 Mono versions

### System information

Godot v4.2.1.stable.mono - Windows 10.0.22631 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 2060 (NVIDIA; 31.0.15.5152) - AMD Ryzen 5 3500X 6-Core Processor (6 Threads)

### Issue description

I have structure like this.

MainScene (2D Node) -> Canvas Layer -> [ Control -> Panel ]
Brackets part above is a scene of its own, and has other unrelated nodes both under the Control and Panel nodes.

When I'm in the control scene and change Panel position and anchor it to top right and start the game, no problems occur. When I change the scene to the main one and then I start the game, position for the panel changes. (position in the control .tscn file changes as soon as I hit F5)

This change is always in the X axis, and is the width of the default viewport width I set in the project settings, in my case 628px.

I have my AnimationTree that controls only the size of the panel, but I disabled it just in case. Still the same.

[Here is a video of the problem](https://youtu.be/KmJ1t5wInMs)

**Update:** I found out that the problem was actually caused by the animations, even if my AnimationTree is disabled. Problem still persists of course, for some reason. I just tried recreating the same panel from beginning, everything was working until I made the collapse animation, which only changes the size property of the panel. When I created this animation, panel started jumping again.

I added position, anchor and other properties I tought my be the problem to the RESET track, nothing changed. Still the same problem.

### Steps to reproduce

I could not produced the problem when I created a new project with the same version. So I'll just leave the repository for the project, which is really small as I just began. Just clone the repo, go to prefabs/WorldGenUI.tscn, move the "PlayerInfoBox" to top right if jumped again, then go to scenes/MainScene.tscn, hit F5 and you'll see.



### Minimal reproduction project (MRP)

[Direct link to the project files](https://github.com/godotengine/godot/files/14593295/Godot.UI.bug.project.MRP.zip)
Repository: ollama
Issue: add fuyu-8b from hugging face
Labels: model request

https://huggingface.co/adept/fuyu-8b

I attempted to convert this model myself but ran into issues with both the convert and the convert hf scripts

![Screenshot 2024-03-13 at 1 39 49 PM](https://github.com/ollama/ollama/assets/2474027/efee9c76-0d38-41ca-81d5-fcaa2166e0a6)
![Screenshot 2024-03-13 at 1 39 56 PM](https://github.com/ollama/ollama/assets/2474027/d9061c03-49c6-4349-92b9-b42c3b1327df)

happy to help debug further to try to get this available for all
Repository: rust
Issue: impl_trait_in_fn_trait_return / impl_trait_in_assoc_type doesn't resolve future correctly
Labels: T-compiler,A-inference,C-bug,F-impl_trait_in_fn_trait_return,F-impl_trait_in_assoc_type

I tried this code:

```rust
#![feature(impl_trait_in_fn_trait_return)]
#![feature(impl_trait_in_assoc_type)]

use std::future::Future;

trait Kind {
    type Func<I, R>;
    
    fn stub<I, R>() -> Self::Func<I, R>;
}

struct A;

impl Kind for A {
    type Func<I, R> = Box<dyn Fn(I) -> impl Future<Output = R>>;
    
    fn stub<I, R>() -> Self::Func<I, R> {
        Box::new(|_| async { unimplemented!() })
    }
}

struct Owner<K: Kind> {
    k: K,
}

impl<K: Kind> Owner<K> {
    fn run<I, R>(&self, _func: K::Func<I, R>) {
        // do stuff with func
    }
}

fn main() {
    let o = Owner { k: A };
    o.run(Box::new(|_| async {
        // Do stuff
    }));
}
```

This almost compiles. If you remove the `o.run` call it otherwise compiles. It seems that rust isn't able to determine that the async block impls the Future trait in main (but does work in the stub!). Think it's related to https://github.com/rust-lang/rust/issues/106527. cc @compiler-errors 

```rust
error[E0308]: mismatched types
  --> src/main.rs:34:24
   |
15 |       type Func<I, R> = Box<dyn Fn(I) -> impl Future<Output = R>>;
   |                                          ----------------------- the expected future
...
34 |       o.run(Box::new(|_| async {
   |  ________________________^
35 | |         // Do stuff
36 | |     }));
   | |_____^ expected future, found `async` block
   |
   = note: expected opaque type `<A as Kind>::Func<_, _>::{opaque#0}`
            found `async` block `{async block@src/main.rs:34:24: 36:6}`
```

### 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.78.0-nightly (3b1717c05 2024-03-10)
binary: rustc
commit-hash: 3b1717c052de4a2dbdd3badb0e7a885f40a8ad9e
commit-date: 2024-03-10
host: x86_64-unknown-linux-gnu
release: 1.78.0-nightly
LLVM version: 18.1.0
```
Repository: flutter
Issue: Consider including `flutter.js.map` in the build output folder
Labels: tool,platform-web,c: proposal,a: build,P2,team-web,triaged-web

Since we include `flutter.js` in the output build directory, it might be worthwhile to also include `flutter.js.map` by default.
Repository: go
Issue: runtime: 2.04% regression in Tile38QueryLoad p50-latency-sec at 24070cf
Labels: Performance,NeedsInvestigation,compiler/runtime

Discovered a regression in p50-latency-sec of 2.04% for benchmark Tile38QueryLoad at 24070cf.

[Results.](https://perf.golang.org/dashboard/?benchmark=Tile38QueryLoad&unit=p50-latency-sec#commit24070cf747d8b3f4487f1ca7247dcdf0ac266e8c)
Repository: tensorflow
Issue: How to plugin a PJRT/common runtime device to Tensorflow?
Labels: stat:awaiting tensorflower,type:support,comp:core,TF 2.13

### Issue type

Support

### Have you reproduced the bug with TensorFlow Nightly?

Yes

### Source

source

### TensorFlow version

2.13.1

### Custom code

Yes

### OS platform and distribution

_No response_

### Mobile device

_No response_

### Python version

_No response_

### Bazel version

_No response_

### GCC/compiler version

_No response_

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current behavior?

Hi all, I am trying to plugin a PJRT device to tensorflow. I saw https://github.com/tensorflow/tensorflow/blob/v2.16.1/tensorflow/python/framework/load_library.py#L160, but that seems to be for the StreamExecutor C API.

I also took a look at https://github.com/tensorflow/tensorflow/blob/6c20138314183635f70dfff454d065f25e833ff1/tensorflow/core/common_runtime/pluggable_device/pluggable_device_plugin_init.cc#L75, which is what I think is what want to call. Is there a python binding for this function or am I supposed to call it directly?

Jax has something like this listed in step 3 here: https://github.com/openxla/xla/blob/b3745173ea3d15306663c8a6f2124da8efea4289/xla/pjrt/c/docs/pjrt_integration_guide.md
Is there something similar for TensorFlow?

Thanks for the help.

### Standalone code to reproduce the issue

```shell
import tensorflow as tf #If I understand correctly a properly plugged in library should be able to be detected on import.
```


### Relevant log output

_No response_
Repository: stable-diffusion-webui
Issue: [Bug]: Help please, cmd window instantly closes, no errors
Labels: bug-report

### Checklist

- [X] The issue exists after disabling all extensions
- [X] The issue exists on a clean installation of webui
- [ ] The issue is caused by an extension, but I believe it is caused by a bug in the webui
- [X] The issue exists in the current version of the webui
- [X] The issue has not been reported before recently
- [ ] The issue has been reported before but has not been fixed yet

### What happened?

It used to work. I tried reinstalling stable diffusion after having resetted my windows installation completely, and connecting my E: Drive with all my old files. After having tried reinstalling stable diffusion completely new, on a different drive and everything, running webui-user.bat only leads to a black screen with no errors:
![Capture](https://github.com/AUTOMATIC1111/stable-diffusion-webui/assets/133919497/eeb1eb07-661e-46ac-b30b-7769fc119f04)
![Capture](https://github.com/AUTOMATIC1111/stable-diffusion-webui/assets/133919497/30e696fc-228a-492b-8e9c-1942ab908318)
![Capture](https://github.com/AUTOMATIC1111/stable-diffusion-webui/assets/133919497/a84f5c8d-0a4a-49f7-ac94-93312af2e3b3)


### Steps to reproduce the problem

1. Open webui-user.bat
2. Get a black screen with no errors

### What should have happened?

It should open, or at least give me an error.

### What browsers do you use to access the UI ?

Mozilla Firefox

### Sysinfo

As I cannot open webui, I can only say it is definitely not a lack of compute.
rtx 4080
i9 9000ks
128 gb ram

### Console logs

```Shell
Already up to date.
```


### Additional information

I use pyenv as my python manager, but also installed it normally.
Repository: deno
Issue: Internal - Deprecate usage of itest
Labels: good first issue,tests,chore

We'd like to deprecate the usage of itest and move the tests over to https://github.com/denoland/deno/tree/main/tests/specs

- [ ] bench_tests.rs
- [x] bundle_tests.rs
- [ ] cache_tests.rs
- [ ] cert_tests.rs
- [x] check_tests.rs
- [ ] compile_tests.rs
- [x] coverage_tests.rs
- [x] doc_tests.rs
- [x] eval_tests.rs
- [x] flags_tests.rs
- [ ] fmt_tests.rs
- [x] info_tests.rs
- [ ] init_tests.rs
- [ ] inspector_tests.rs
- [ ] install_tests.rs
- [ ] js_unit_tests.rs
- [x] jsr_tests.rs
- [x] jupyter_tests.rs
- [x] lint_tests.rs
- [ ] lsp_tests.rs
- [x] node_compat_tests.rs
- [ ] node_unit_tests.rs
- [ ] npm_tests.rs
- [ ] pm_tests.rs
- [ ] publish_tests.rs
- [ ] repl_tests.rs
- [x] run_tests.rs
- [ ] shared_library_tests.rs
- [x] task_tests.rs
- [ ] test_tests.rs
- [ ] upgrade_tests.rs
- [ ] vendor_tests.rs
- [ ] watcher_tests.rs
- [x] worker_tests.rs