Support for Arrays of Link Objects

According to the HAL Spec, a HAL Link can either be a Link object, or an array of Link objects (https://tools.ietf.org/html/draft-kelly-json-hal-08#section-4.1.1).
It seems that the library does not offer support for these arrays yet.

Thank you for the feedback. I expect to update the documentation as soon as there is a little time for it. This is actually supported (both for serialization and deserialization) - but not shown in the README currently.
To have an array of links, all you need to do is annotate a collection of HALLink with the @Link annotation. E.g.,
@Link
Collection<HALLink> customers;

This should give an output as
{
  "_links": {
    "customers": [ ]
  }
}

You may then initialize the collection with any specific collection you see fit :-)


add service accounts to deployments

This change provides a service account per deployment to allow the use of Consul Connect Inject with ACL's enabled.
While this will enable the Consul service mesh to work it also is probably appropriate to allow configuration of the service bind address to configure proxy only access to the services.  That change is more invasive as there appears to be a gossip port for membership as well as an rpc port.
Any advice on how you'd like that addressed potentially would be good.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Thanks for the contribution - the way our helm charts will be handled going forward will be scoped down to just temporal services. service accounts will be possible to support but in a different way. See this for more details: https://github.com/temporalio/proposals/issues/42


stdin Broken

Goddammit
ls | loop -- "cat $ITEM"

That used to work and now it doesn't, motherfuck.

Or maybe it's not and parsing ls is a bad idea, since cat /tmp/my-list-of-files-to-create.txt | loop 'touch $ITEM' still works


"add-apt-repository ppa:project-calico/calico-3.17" fails on focal

Hello,
Following https://docs.projectcalico.org/getting-started/openstack/installation/ubuntu it works on bionic but not focal.
Expected Behavior

Expected that it would add the repo successfully just as it works on bionic.
Current Behavior

See error below:
$ add-apt-repository ppa:project-calico/calico-3.17
 This PPA contains packages for Calico's 3.17.x release series, mainly to support OpenStack-based systems (although the Felix package can be used stand-alone). It will be updated with patch releases for that series.
 More info: https://launchpad.net/~project-calico/+archive/ubuntu/calico-3.17
Press [ENTER] to continue or Ctrl-c to cancel adding it.

Hit:1 http://nova.clouds.archive.ubuntu.com/ubuntu focal InRelease
Hit:2 http://nova.clouds.archive.ubuntu.com/ubuntu focal-updates InRelease
Hit:3 http://nova.clouds.archive.ubuntu.com/ubuntu focal-backports InRelease
Hit:4 http://security.ubuntu.com/ubuntu focal-security InRelease
Ign:5 http://ppa.launchpad.net/project-calico/calico-3.17/ubuntu focal InRelease
Err:6 http://ppa.launchpad.net/project-calico/calico-3.17/ubuntu focal Release
  404  Not Found [IP: <IP_ADDRESS> 80]
Reading package lists... Done
E: The repository 'http://ppa.launchpad.net/project-calico/calico-3.17/ubuntu focal Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

Possible Solution

Steps to Reproduce (for bugs)

Boot a focal VM
Follow the steps at https://docs.projectcalico.org/getting-started/openstack/installation/ubuntu
Try to add repo "ppa:project-calico/calico-3.17"
Unable to install calico-control

Context

I'm trying to SRU (backport) fixes for nova integration with calico: https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1893263
But it needs to go through focal, then to train and stein.
Your Environment

Calico version
Orchestrator version (e.g. kubernetes, mesos, rkt):
Operating System and version:
Link to your project (optional):

OpenStack. Ubuntu 20.04. Calico 3.17

Yes indeed, we currently only build for Trusty, Xenial and Bionic.
If someone would like to take a look at adding the Focal support, the place for that is https://github.com/projectcalico/packaging/
If you check out that repo and search for bionic, it should be pretty obvious what's needed to add in support for another Ubuntu distro.

Indeed, it is easy and obvious to add the recipe for building focal. I have prepared a PR, but it does not work as networking-calico does not build smoothly in focal. I haven't had time to debug the error. See below:
https://paste.ubuntu.com/p/R7nJ6tYn8B/

After building the package manually (it was missing the dh-python dependency) I was able to test it on Focal. Turns out it doesn't work. When creating VMs, it triggers this error:
https://paste.ubuntu.com/p/jQnJ8CqRMf/
However, that error is due to Python 3.8, which enforces the Runtime error. See https://stackoverflow.com/questions/59216749/runtimeerror-dictionary-keys-changed-during-iteration-when-attempting-to-call
That particular error has an easy fix though, just creating a set() out of the self.cache.get_network_ids() call, as it is being done in other code places.
However, I am not confident about considering the code ready for focal or python3.8 as is with this particular fix and extra dependency. A full test suite and QA should be done to validate whether the rest of the code works on focal and python 3.8.

Hi @rodrigogansobarbieri :wave: , thank you for following up on this. I've chatted with @neiljerram about this and we think your proposed changes (the bug fix and the new dependency) sound about right. If you go ahead and submit the PR as suggested, I can review it :)

A full test suite and QA should be done to validate whether the rest of the code works on focal and python 3.8

We have automated tests that run internally. Once the PR is merged and the tests run, I can paste the screenshots here.

Pushed:
https://github.com/projectcalico/networking-calico/pull/48
https://github.com/projectcalico/packaging/pull/39


SARIF: Don't set result level when it doesn't override rule's level

Expected Behavior
Result level is only set in report output if it overrides the rule's level. If it doesn't, it's redundant and can be removed from the output to cut down on the size of the report output.
Current Behavior
level is set on every result.
Context
Improve SARIF output.

May I clarify, do you mean this part?

Yes. If a result has the same level as the rule's level then setting the level on the results is redundant - it can be removed so it inherits the level from the rule.
These aren't the right terms as far as the SARIF spec goes but hopefully this makes sense.

May I work on this?

Of course, we love external contributions!

@3flex could you explain what you mean with:

Result level is only set in report output if it overrides the rule's level.

As far as I can see on our tests we don't set the "rule's `level". So I'm not sure what you mean with that.

Sorry I can't recall all the details, only that it's redundant for the output to contain level on every result if it's already set as the rule level.
I'd fix it myself but it's not a priority.

if it's already set as the rule level.

That's the problem. I can't find where it is defined at the rule level. And I can't fidn that either on the SARIF Spec.

Hi all
Please let me know if you come to a consensus

Oh, now rules don't have severity level...
Instead of default error there's null
Why?


Add moduleLocation to mkFlake argument

This PR adds moduleLocation argument to mkFlake, allowing the user to set the module key by hand, addressing https://github.com/hercules-ci/flake-parts/pull/156#issuecomment-1540165822

@roberth  Would you mind if I reopen #156 and rebase onto this PR, so that we don't have to break inputs.self in order to call mkFlake twice.

#157 is worth solving, but unless we know that we have a complete solution, we're probably just making a mess out of mkFlake.
We already have a "95%" solution of the problem and I am confident that a full solution of #157 is within reach. For this reason, I'm not going to accept a solution that solves a different 95%, and for the sake of maintainability I won't accept a 96% solution either, because that solution will not come with a proof that it leads towards the 100%. If it does come with such a proof, then it's already a 100% solution.
I've already stretched my schedule a lot by responding to your suggestions. I won't be responding quickly for some time, but that won't be too bad, because you can test changes yourself (see e.g. the dev directory) and you can validate the requirements or better understand them by applying your solution in multiple repositories. I'm sorry that I won't be quite as helpful for now, but I have to prioritize.

This PR does not aim to directly solve #157. Instead, it is a workaround for #148. I understand the best solution of #148 is https://github.com/NixOS/nix/pull/4154. But we probably would not get https://github.com/NixOS/nix/pull/4154 very soon because it is inactive.
I think it would be a net benefit to limit the use of self.outPath until https://github.com/NixOS/nix/pull/4154 gets landed, not only because it prevents double mkFlake, but also because it would produce obscure error messages about infinite loop due to #148 in other use cases, including flake-parts's own tests.

I'd like to keep it simple, so I'm going for the root cause.

Blocked on https://github.com/NixOS/nix/pull/8908 (or similar)

root cause.

Blocked on

Rabbit hole too deep as that issue is itself blocked on another issue.
I think I've found an extended solution that's easier to use.

#192

I'm not sure if it (automatically) solves all the problems you intended to solve, but it should solve

#185

Looks good to me


fix(analytics): generate fallback userToken

Summary

Result

With the RFC on decoupling (or using v3) we'll likely not need this. Should we close @Haroenv?


Unsound usages of unsafe implementation from [u8] to __m128i

Hi, I am scanning the crc32fast in the latest version with my own static analyzer tool.
Unsafe conversion found at: src/specialized/pclmulqdq.rs:198:35: 198:69
unsafe fn get(a: &mut &[u8]) -> arch::__m128i {
    debug_assert!(a.len() >= 16);
    let r = arch::_mm_loadu_si128(a.as_ptr() as *const arch::__m128i);
    *a = &a[16..];
    return r;
}

This unsound implementation would create a misalignment issues. If the [u8] size is smaller than the __m128i, it would potentially lead to access out-of-bound in the memory.
This would potentially cause undefined behaviors in Rust. If we further manipulate the problematic converted types, it would potentially lead to different consequences. I am reporting this issue for your attention.

Hi, thanks for the report!
I've double checked, and believe this is likely a false positive in from your tool. You mention two issues specifically:

Misalignment: The _mm_loadu_si128 is a function specifically designed to perform unaligned loads from the memory address. As you can read here in the docs: "mem_addr does not need to be aligned on any particular boundary."

Out of bounds access: The function is marked unsafe specifically because the caller needs to ensure that a is at least 16 bytes long. The debug assert is not load bearing, instead you need to check for where get is called. There are three places where get is called, all of which ensure that the slice passed to it is at least 16 bytes long.

Happy to discuss and be convinced otherwise!


Expectation count in spec summary

Hello,
Minitest provides a nice statistic regarding number of passed assertions:
% ruby -Ilib:test test/minitest/test_minitest_test.rb
Run options: --seed 37685

# Running:

...................................................................... (etc)

Finished in 0.107130s, 1446.8403 runs/s, 2959.0217 assertions/s.

155 runs, 317 assertions, 0 failures, 0 errors, 0 skips

here I'm referring to 317 assertions.
is there an analogue way in RSpec to show the number of passed expectations?
Thanks!

We don't currently, but it has been suggested before over in rspec/rspec-core#740 I'm closing this as a duplicate at that, but I'd love further discussion over on that issue


Fix broken link

May should I use DocfyLink ?

Writing Markdown link in the following page seems to work so I mimic the same path
https://raw.githubusercontent.com/josemarluedke/docfy/master/packages/ember/docs/writing-demos.md


220 notifications not displayed on mobile

In this PR I've fixed issue with background in mobile menu and color pagination

getting error while building image
=> ERROR [rair-front build 7/7] RUN yarn build                                                                                32.4s

[rair-front build 7/7] RUN yarn build:
0.528 yarn run v1.22.22
0.567 $ tsc --target ES2020 && vite build
32.11 src/components/DemoMediaUpload/PopUpChangeVideo/PopUpChangeVideo.tsx(192,13): error TS2783: 'customClass' is specified more than once, so this usage will be overwritten.
32.11 src/components/DemoMediaUpload/PopUpChangeVideo/PopUpChangeVideo.tsx(200,13): error TS2783: 'customClass' is specified more than once, so this usage will be overwritten.
32.11 src/components/nft/PersonalProfile/PersonalProfileMyNftTab/ResaleModal/ResaleModal.tsx(316,21): error TS18048: 'chainData.viem' is possibly 'undefined'.
32.21 error Command failed with exit code 2.


Unified DXVK/VKD3D lag timebomb in most games if compiled from git

There's a literal "lag timebomb" when pulling the latest git versions of DXVK and VKD3D and compiling them. These lag timebombs are unified, meaning that they happen in both DXVK git and VKD3D git, and they trigger after roughly ~25 to ~40 minutes of gameplay and generally only trigger if the user is providing input to the game. This problem exists since roughly 2 months and I felt like it would be good to report it here. Since the problem is unified (happens on both DXVK and VKD3D) I actually didn't know where to report it.
Affected games mostly use Unreal Engine. Insomniac Engine games, for example, didn't seem to be affected.
Using a "Release" version of DXVK + a "Release" version of VKD3D seems to solve the problem.
More specifically, the game is smooth before the "timebomb" triggers, then consistent and repeated heavy stutters begin to happen. If needed, I can record a video.
EDIT: We have found out that, when this triggers, it only happens when moving the mouse.
Software information
Any game that uses DXVK or VKD3D pulled from git and compiled, this problem is unified and common in both DXVK and VKD3D
System information

GPU: Most likely any GPU, both NVIDIA and AMD (tested: 4070 SUPER, 4080 SUPER, 7900XTX)
Driver: Most likely any driver
Wine version: Tried multiple Proton versions, including GE and LFX2
DXVK version: straight from git

Apitrace file(s)

Can provide if needed, but this problem can easily be reproduced on any machine

Log files

Again I can provide this if it's really necessary, but this can be easily reproduced on any machine

We have found out that, when this triggers, it only happens when moving the mouse, I'll be posting a video soon.

Does this also happen with the builds that ship with Proton Bleeding Edge or downloaded from GitHub CI or only with self compiled?

DXVK does not interact with mouse input in any way, I strongly doubt it's even remotely possible that this is our bug.
Also haven't seen anything like this on my machine even in extended play sessions.

DXVK does not interact with mouse input in any way, I strongly doubt it's even remotely possible that this is our bug.
Also haven't seen anything like this on my machine even in extended play sessions. As for Unreal Engine titles, I ran Hellblade and Days Gone for ~an hour not too long ago to test some unrelated changes.

I understand that they don't interact with mouse input, but when I run a game that natively uses Vulkan (ie. Quake 2 Remastered, Saints Row) they're not affected by this problem.
Switching to any of your releases paired with a vkd3d release completely fixes this mouse problem. I'm not any more expert than you, but the only thing dxvk and vkd3d have in common is dxgi.
I don't know if I'm being helpful but I can post a video on YouTube or logs.

Well what I'm saying is that this functionally doesn't make any sense and I can't reproduce it.
First step would probably be to provide detailed info about your build environment, including compiler version, MinGW version if applicable, and the exact command lines you're using to build the whole thing.

Well what I'm saying is that this functionally doesn't make any sense and I can't reproduce it.
First step would probably be to provide detailed info about your build environment, including compiler version, MinGW version if applicable, and the exact command lines you're using to build the whole thing.
Another question would be what kind of environment you're running on as well, any sort of input issue points more towards wine/compositor issues than us.

I'm using fully updated Arch Linux, MinGW 13.1.0-1.
I tried with X11, X11 + gamescope, Wayland and Wayland + gamescope. Same problem happens after roughly 25 to 40 minutes of gameplay.
There's an intermittent heavy stutter that runs at its own pace, but only when playing with keyboard and mouse apparently, and it gets worse if you move your mouse once the "timebomb" triggers.
I'm using your package-release.sh script to build dxvk, using vkd3d's package-release.sh script to build vkd3d as well. Nothing goes wrong while compiling. Switching to "old" versions of vkd3d + dxvk completely gets rid of the issue.
Running a game that natively uses Vulkan or OpenGL never triggers this problem.
I'm going to upload a video of the problem on YouTube (recorded by a friend of mine) in order to showcase the problem.

Does this also happen with the builds that ship with Proton Bleeding Edge or downloaded from GitHub CI or only with self compiled?
Also are you able to bisect with commit it started with?

I'm using fully updated Arch Linux, MinGW 13.1.0-1.

This is precisely what the release builds are from. MinGW stuff hasn't been updated in a year or so, so the past couple of stable releases were compiled using exactly this in release mode.

Switching to "old" versions of vkd3d + dxvk completely gets rid of the issue.

Does "old versions" include self-compiled builds of stable releases?
I'm not running anything special here, just plain old KDE Wayland with (generally) no Steam overlay and (generally) no Gamescope, and RADV on a 6900XT. If this is an issue that supposedly affects any (UE4) game on any setup then what exactly is it that makes my system the special snowflake that this doesn't happen on?

I'm using fully updated Arch Linux, MinGW 13.1.0-1.

This is precisely what the release builds are from. MinGW stuff hasn't been updated in a year or so, so the past couple of stable releases were compiled using exactly this in release mode.

Switching to "old" versions of vkd3d + dxvk completely gets rid of the issue.

Does "old versions" include self-compiled builds of stable releases?
I'm not running anything special here, just plain old KDE Wayland with (generally) no Steam overlay and (generally) no Gamescope, and RADV on a 6900XT. If this is an issue that supposedly affects any (UE4) game on any setup then what exactly is it that makes my system the special snowflake that this doesn't happen on?

Yes, to also answer @Blisto91 the "old versions" included my own self-compiled. I have self-compiled versions of both dxvk and vkd3d saved, but I don't know where to start, honestly, maybe we can guess something:

21st of July 2024
23rd of July 2024
26th of July 2024
27th of July 2024
30th of July 2024
10th of August 2024
16th of August 2024
22nd of August 2024
30th of August 2024
9th of September 2024
10th of September 2024
19th of September 2024
21st of September 2024
25th of September 2024
1st of October 2024
6th of October 2024
12th of October 2024
16th of October 2024
18th of October 2024
6th of November 2024
7th of November 2024
Today

For the sake of having a complete background, I'm actually going to test this whole thing without using ecores on intel and by using only one ccx on amd. It's probably unrelated and nonsensical but it doesn't harm me to test, my boyfriend is also testing with me. We've been trying to troubleshoot this for days to no avail.

could you send a log with DXVK_LOG_LEVEL=debug

could you send a log with DXVK_LOG_LEVEL=debug
also could u try windowed mode

Yes, I'll attempt both things after testing the ecores/ccx thingy.

Can you try https://github.com/doitsujin/dxvk/tree/no-occlusion?

could you send a log with DXVK_LOG_LEVEL=debug
also could u try windowed mode

Yes, I'll attempt both things after testing the ecores/ccx thingy.
Edit: I'm sorry because these tests take a very long time, it's 25 to 40 minutes per-test. Yet, reproducibility should be easy (not timewise of course) as long as you're playing with a mouse and a keyboard on newly compiled dxvk + vkd3d.

funny story, I can't reproduce it either

Can you try https://github.com/doitsujin/dxvk/tree/no-occlusion?

I'm building it while my boyfriend is testing without ecores.

could you send a log with DXVK_LOG_LEVEL=debug
also could u try windowed mode

Yes, I'll attempt both things after testing the ecores/ccx thingy.
Edit: I'm sorry because these tests take a very long time, it's 25 to 40 minutes per-test. Yet, reproducibility should be easy (not timewise of course) as long as you're playing with a mouse and a keyboard on newly compiled dxvk + vkd3d.

funny story, I can't reproduce it either

Is it actually git cloned and compiled or just picked from releases? If nobody can reproduce this here, it could actually be related to a change that affects ecores (to-be-confirmed since my boyfriend is still testing, he's playing since 31 minutes without the problem triggering as of now).

For the sake of having a complete background, I'm actually going to test this whole thing without using ecores on intel and by using only one ccx on amd. It's probably unrelated and nonsensical but it doesn't harm me to test, my boyfriend is also testing with me. We've been trying to troubleshoot this for days to no avail.

Does not seem to be the problem. Will try no-occlusion straight away @doitsujin

Can you try https://github.com/doitsujin/dxvk/tree/no-occlusion?

Timebomb triggered at 33 minutes with this fork. Some walls and corners were invisible.  Make a list of more things that I should try and I'll do it right after waking up (I don't have work so I'm free the whole day).

Well, that rules out the only DXGI change since 2.4.1, so....

Well, that rules out the only DXGI change since 2.4.1, so....

Could it be a shared change between DXVK and VKD3D? Because we don't experience that problem with neither Proton GE and Experimental, yet we used to not have that problem at all and I always compiled the latest git releases for both of us.
I strictly believe that, at some point in time, something changed, and it affected both dxvk and vkd3d, and specifically "mouse handling" (probably not the right term) somehow.
It's weird that anything that runs on native API (Vulkan / OpenGL) does not suffer from this issue on any Proton prefix, yet the moment we try using git compiled dxvk + vkd3d this starts triggering.
It's interesting that games that run, for example, on Insomniac Engine and its forks, don't even suffer from this issue, while other games (notably Unreal Engine) have this timebomb as long as they use DXVK or VKD3D and as long as you play them with a mouse and keyboard.
My boyfriend will provide debug logging until the problem starts happening, and if you can 100% conclude that this is certainly not a DXVK + VKD3D issue, I'll have to look somewhere else. Most worrying scenario would be this problem affecting the majority of people but they have no idea. We really need more people testing this.

Been playing Hogwarts Legacy for around 110 mins now but haven't been able to reproduce.
Proton Experimental Bleeding Edge (the beta branch), Ryzen 7950x, RTX 4080, KDE X11, Steam overlay turned on and even obs open in the background.

Been playing Hogwarts Legacy for around 110 mins now but haven't been able to reproduce. Proton Experimental Bleeding Edge (the beta branch), Ryzen 7950x, RTX 4080 (driver is 565.57.01), KDE X11, Steam overlay turned on and even obs open in the background.

That's not exactly the steps, I meant manually compiling dxvk and vkd3d straight away and putting them in a compatibility tool.

I asked above if the issue shows with the builds in Proton Bleeding Edge or from the CI.

I would like to try the ones you have compiled yourself to test with. Just package them up and attach here

I would like to try the ones you have compiled yourself to test with. Just package them up and attach here

All.tar.gz

I've got to sleep now, I'll keep myself updated when I wake up. File attached in the previous message.

Played Hogwarts Legacy for 90 minutes more, this time with the Bleeding Edge DLLs replaced with the vkd3d-proton, dxvk and dxvk-nvapi ones from your archive

since you can build your own dxvk and know that the issue has been happening for 2 months, why don't you bisect it?

Played Hogwarts Legacy for 90 minutes more, this time with the Bleeding Edge DLLs replaced with vkd3d-proton, dxvk and dxvk-nvapi from your archive. Still nothing sadly

My boyfriend actually tried experimental bleeding edge overnight (without my DLLs) and the timebomb triggers there as well.  The problem only seems to happen when using m+k.

since you can build your own dxvk and know that the issue has been happening for 2 months, could you bisect it?
See my message above where I list my older compiled dxvk+vkd3d combos, I don't know where to start. If you have an idea, maybe a date, I can start from there and test.

You say affected games mostly use Unreal Engine. Did you reproduce it with non-UE games? When you say, you don't have this issue with OpenGL/Vulkan, again those probably don't use UE?
Moving the mouse in Wine/Windows has the side-effect of changing the timer resolution of the scheduler, to react quicker. I observed this behavior when using the default c++ stdlib Sleep() function instead of specific Windows targeted Sleep(), maybe something to think about.

Yes. I rarely play with anything else.
Let's try to get a bisect going even if we won't find the commit in one day. Just try to test with the builds i send when there is time.

Yes. I rarely play with anything else.
Let's try to get a bisect going even if we won't find the commit in one day. Just try to test with the builds i send when there is time. Does the issue happen with this dxvk build? dxvk d85cabe4571fbc1862f5176f88feeaf49aa2f01f.tar.gz

We will test this ASAP.

You say affected games mostly use Unreal Engine. Did you reproduce it with non-UE games? When you say, you don't have this issue with OpenGL/Vulkan, again those probably don't use UE?
Moving the mouse in Wine/Windows has the side-effect of changing the timer resolution of the scheduler, to react quicker. I observed this behavior when using the default c++ stdlib Sleep() function instead of specific Windows targeted Sleep(), maybe something to think about.

That is true, but how is it that it acts like a literal timebomb? AFAIK the problem should appear immediately.

Did you check your RAM and VRAM usage? When RAM/VRAM gets full over time, lags are usually the consequence.

Did you check your RAM and VRAM usage? When RAM/VRAM gets full over time, lags are usually the consequence.

They look fine, but this still doesn't exclude that there could be a leak somewhere, so you might have a point as well.

Yes. I rarely play with anything else.
Let's try to get a bisect going even if we won't find the commit in one day. Just try to test with the builds i send when there is time. Does the issue happen with this dxvk build? dxvk d85cabe4571fbc1862f5176f88feeaf49aa2f01f.tar.gz

Yes, it happened. I attached logs. When the timebomb ticked, he left the game open for further 40 seconds before closing it.
game_dxgi.log
game_d3d11.log

Thanks!
Next build for when you have time: dxvk 899f48bc43a6e75f039cf999f1421bb8cccc571a.tar.gz

Thanks!
Next build for when you have time: dxvk 899f48bc43a6e75f039cf999f1421bb8cccc571a.tar.gz

We just tested regular Proton Experimental again without changing anything and the timebomb just happened there as well, it just took 1 hour instead of the usual 25-40 minutes. I'll be attaching logs here. Knowing that regular Proton Experimental shows this problem as well, should I still try that dxvk version? As before, the timebomb triggers and then the game lags only when moving mouse, there are literal fps drops as well, basically as shown in the last YT video I linked.
Which path should I take from now? The problem is affecting 3 different system by the way and we're crushing our heads on the wall trying to understand what's wrong. We can run Vulkan games for 6 hours straight on the same compatibility tools (GE, LFX2, Experimental, etc.) and this timebomb NEVER triggers
Here are Proton Experimental logs if you can make use of them:
game_dxgi.log
game_d3d11.log
I'm so clueless at this point. Do I try the next build or do I take a different path?

Thanks!
Next build for when you have time: dxvk 899f48bc43a6e75f039cf999f1421bb8cccc571a.tar.gz

We just tested regular Proton Experimental again without changing anything and the timebomb just happened there as well, it just took 1 hour instead of the usual 25-40 minutes. I'll be attaching logs here. Knowing that regular Proton Experimental shows this problem as well, should I still try that dxvk version? As before, the timebomb triggers and then the game lags only when moving mouse, there are literal fps drops as well, basically as shown in the last YT video I linked.
Which path should I take from now? The problem is affecting 3 different system by the way and we're crushing our heads on the wall trying to understand what's wrong. We can run Vulkan games for 6 hours straight on the same compatibility tools (GE, LFX2, Experimental, etc.) and this timebomb NEVER triggers
Here are Proton Experimental logs if you can make use of them: game_dxgi.log game_d3d11.log
I'm so clueless at this point. Do I try the next build or do I take a different path?
Edit note just to reiterate: some games are not affected, like Horizon Zero Dawn Remastered, Ratchet: Rift Apart, Saints Row The Third Remastered and some more games are NOT affected by this, somehow. It's mainly Unreal Engine games that seem to be problematic and have this weird lag timebomb after X minutes.

You try the next build... Otherwise the idea of a bisect is useless

Thanks!
Next build for when you have time: dxvk 899f48bc43a6e75f039cf999f1421bb8cccc571a.tar.gz

We just tested regular Proton Experimental again without changing anything and the timebomb just happened there as well, it just took 1 hour instead of the usual 25-40 minutes. I'll be attaching logs here. Knowing that regular Proton Experimental shows this problem as well, should I still try that dxvk version? As before, the timebomb triggers and then the game lags only when moving mouse, there are literal fps drops as well, basically as shown in the last YT video I linked.
Which path should I take from now? The problem is affecting 3 different system by the way and we're crushing our heads on the wall trying to understand what's wrong. We can run Vulkan games for 6 hours straight on the same compatibility tools (GE, LFX2, Experimental, etc.) and this timebomb NEVER triggers
Here are Proton Experimental logs if you can make use of them: game_dxgi.log game_d3d11.log
I'm so clueless at this point. Do I try the next build or do I take a different path?
Edit note just to reiterate: some games are not affected, like Horizon Zero Dawn Remastered, Ratchet: Rift Apart, Saints Row The Third Remastered and some more games are NOT affected by this, somehow. It's mainly Unreal Engine games that seem to be problematic and have this weird lag timebomb after X minutes.

You try the next build... Otherwise the idea of a bisect is useless

I was eating, sorry for the late response.
My boyfriend was now testing the game without gamescope and using regular Proton Experimental (not Bleeding Edge) to rule out a Proton Experimental + Gamescope combo glitch (probably useless, but he's 31 minutes in already so the timebomb should trigger in a very bit), then I'll proceed and let him place the next dxvk build and as always I'll provide results and logs ASAP.
For reference, we're always using the same game in order to obtain coherent results.

Definitely, it's a Mouse + Keyboard input problem that only happens on DXVK + VKD3D
Once the timebomb triggers (25 to 40 minutes for Bleeding Edge and latest git dxvk+vkd3d on ANY proton version; 1 hour for unmodified Proton Experimental -> not bleeding edge <-), every keyboard input or mouse input causes the game to stutter regardless, you can clearly see it up on the mangohud overlay in the following video as well (ignore my boyfriend's voice if you can hear it):
https://www.youtube.com/watch?v=e_Qqgy3ET4M

Thanks!
Next build for when you have time: dxvk 899f48bc43a6e75f039cf999f1421bb8cccc571a.tar.gz

Trying this build right away, I'll report back with logs.

Thanks!
Next build for when you have time: dxvk 899f48bc43a6e75f039cf999f1421bb8cccc571a.tar.gz

@Blisto91 Same issue.
Video: https://www.youtube.com/watch?v=Bl_ZIOmIY0k
Video with my boyfriend actually illustrating the issue when it triggers: https://www.youtube.com/watch?v=dHJmVYjw4zE
Logs:
game_dxgi.log
game_d3d11.log
No idea what to try next.

After extensive testing and troubleshooting, I've decided to take a step back from Linux gaming for the time being. While I'll continue using Linux for my professional work, I plan to revisit gaming only after a considerable period, perhaps in a few weeks or months, hoping these issues will be resolved by then.
This very specific problem has become quite frustrating. I've found out that this now seems to happen even with regular Proton 9. I've tested this across three different hardware configurations, including a complete system reinstall, and unfortunately, the same issue persists. What's particularly concerning is that this problem always happens across various setups, including a full AMD system, and remains present regardless of whether I'm using X11, Wayland, or Gamescope in both of them.
While I totally respect that others might not be experiencing these issues, my experience tells me that this is not possible. At this point, rather than continuing to waste time, I'll be stepping away until there's a proper solution from the whoever caused this, whether that's from Arch Linux, DXVK/VKD3D, or other involved devs. It's particularly BAD to encounter identical issues even after a fresh installation across multiple systems with different configurations, it's just not right.
I appreciate your efforts, but for now, I need to take a break from this thing and wait until this is all resolved.

If this was an easy to reproduce problem, you'd find more post about it online in various forums. I've never seen any such reports though and also never experienced this issue myself.

If this was an easy to reproduce problem, you'd find more post about it online in various forums. I've never seen any such reports though and also never experienced this issue myself.

I have reinstalled Arch Linux from scratch and this happens out of the box. Full AMD system. It just takes 25-40-50 minutes of mouse and keyboard input to trigger it. No chance that it can't be reproduced. I'll be out for the time being until developers find a solution, maybe 2 or 4 weeks, and then check back. Either Arch Linux devs did a whoopsie or dxvk+vkd3d did a whoopsie, I'm tired of endlessly troubleshooting this problem that I can't get rid of. I just tested now after a clean install and KovaaK started stuttering after 42 minutes.

If it also happens with older Proton versions then i am going to guess that it is this old issue https://github.com/doitsujin/dxvk/issues/2371
It is something we have heard reports of from time to time (Source 1 games being an example) but it isn't something we have ever been able to reproduce on our setups, not for a lack of trying, so it is hard to debug.
A maybe guess is that there is some overlay involved that starts to act up after a while with dxvk E.g Steam overlay or similar. But it is hard to say without some proper debugging which would require a dev or tester reproducing it.

If it also happens with older Proton versions then i am going to guess that it is this old issue #2371 It is something we have heard reports of from time to time (Source 1 games being an example) but it isn't something we have ever been able to reproduce on our setups, not for a lack of trying, so it is hard to debug. A maybe guess is that there is some overlay involved that starts to act up after a while with dxvk E.g Steam overlay or similar. But it is hard to say without some proper debugging which would require a dev or tester reproducing it.

It happens even without any Vulkan layer attached and, after triggering, only lags when sending mouse/keyboard input. This is all I can say. I have just wasted time on fully reinstalling vanilla Arch Linux on a full AMD machine just to see the exact same issue happening again.

If it also happens with older Proton versions then i am going to guess that it is this old issue #2371 It is something we have heard reports of from time to time (Source 1 games being an example) but it isn't something we have ever been able to reproduce on our setups, not for a lack of trying, so it is hard to debug. The best guess is that there is some overlay involved that starts to act up after a while with dxvk E.g Steam overlay or similar. But it is hard to say without some proper debugging which would require a dev or tester reproducing it.

If YOU cant debug it, maybe give advice to those already having the issue on how to debug it???

but NOT if the game uses Vulkan or OpenGL as API.

Does this include Windows games using those APIs like Doom 2016 or Eternal? Because otherwise it would be conceivable that this is a Wine issue.

but NOT if the game uses Vulkan or OpenGL as API.

Does this include Windows games using those APIs like Doom 2016 or Eternal? Because otherwise it would be conceivable that this is a Wine issue.

Vulkan games and OpenGL games running on any version of Proton don't have this problem. I and my boyfriend are experiencing this issue only in DXVK and VKD3D at the same time, everything else is completely fine under the same compatibility layers.

If YOU cant debug it, maybe give advice to those already having the issue on how to debug it???

Note that i am not a dev but "just" a tester.

There was actually a "stutter after 40min" issues that sounds similar caused by the steam overlay a long time ago: https://github.com/ValveSoftware/steam-for-linux/issues/7505
LD_PRELOAD= %command% would work around it by completely disabling the steam overlay. Not sure why this ancient issue would resurface now though, and why almost no one else seems affected.

There was actually a "stutter after 40min" issues that sounds similar caused by the steam overlay a long time ago: ValveSoftware/steam-for-linux#7505
LD_PRELOAD= %command% would work around it by completely disabling the steam overlay. Not sure why this ancient issue would resurface now though, and why almost no one else seems affected.

I have had this issue in the past where the frame pacing completly tanks after about the same time when using gamescope or mangohud for no reason

yes, better use dxvk overlay for these sort of tests, as you may as well run into a mangohud bug.

This happens even without any overlay. I'm currently testing with LD_PRELOAD="".

maybe this bug needs high fps to trigger?

It's funny how this gets a "can't reproduce" tag when all it takes is a clean Arch Linux install.

I'm on Arch and can't reproduce it at all either, I think everybody is already trying their best and nobody is even dismissing your issue.

maybe this bug needs high fps to trigger?

Nope, also happens capped at 60 fps.

It's funny how this gets a "can't reproduce" tag when all it takes is a clean Arch Linux install.

I'm on Arch and can't reproduce it at all either, I think everybody is already trying their best and nobody is even dismissing your issue.

I maintained a professional tone until I clean reinstalled Arch Linux on a full AMD system just to see the same issue pop again. It's not really "my" issue when a clean distro installation doesn't get rid of the problem.

I would really like to be able to try and reproduce the problem, trust me. But if we include the issue i linked above then i have tried several times through the years on probably 3-4 different setups by now, so i just really don't know what more to try.
Afaik all on the team use Arch (correct me if i am wrong)

I would really like to be able to try and reproduce the problem, trust me. But if we include the issue i linked above then i have tried several times through the years on probably 3-4 different setups by now, so i just really don't know what more to try. Afaik all on the team use Arch (correct me if i am wrong)

I'll be able to tell you whether the LD_PRELOAD="" method works in 20 minutes, either way.

btw I also use arch, and I guess if that LD_PRELOAD thing doesn't work you can maybe try profiling proton and to see what's going on. (I haven't done this before, so you will probably have to look through some documentation and figure it out)

Believe it or not, using LD_PRELOAD="" actually fixed the problem for me, even when adding mangohud and OBS game capture to the vulkan layers through VK_LOADER_LAYERS_ENABLE. I'm more than 1 hour in playing KovaaK using Proton Experimental Bleeding Edge and it's still buttery smooth.
Now my question is, what is Steam LD_PRELOADING into the game then? I digged a bit and found nothing.
My theory is that this "Record your game" thing on Steam somehow injects even without your overlay being active. Would that explain this whole "timebomb" situation and the timing? This is just a theory, but, as far as I'm concerned, this whole thing really just started happening around the time they implemented this new feature. Even though it's disabled on my side, I think that's what was causing the issue.
I could probably close the issue but, if anything, I'd like to know what Steam sets LD_PRELOAD to when launching my games. Do you know a reliable way to do that? Plus, my bf really just wants to first see this with his own eyes.

Now my question is, what is Steam LD_PRELOADING into the game then? I digged a bit and found nothing.

Probably some stuff for steam input, which would maybe explain why it's related to mouse input. You can check what steam sets LD_PRELOAD to when a game is running by looking at /proc/$PID_OF_THE_GAME/environ.

I could probably close the issue but

Yes, but please open a new issue about it referencing this one over at https://github.com/ValveSoftware/steam-for-linux/issues

Now my question is, what is Steam LD_PRELOADING into the game then? I digged a bit and found nothing.

Probably some stuff for steam input, which would maybe explain why it's related to mouse input. You can check what steam sets LD_PRELOAD to when a game is running by looking at /proc/$PID_OF_THE_GAME/environ.

I could probably close the issue but

Yes, but please open a new issue about it referencing this one over at https://github.com/ValveSoftware/steam-for-linux/issues

This is the only entry showing in LD_PRELOAD when launching the game with default settings:
LD_PRELOAD=/tmp/pressure-vessel-libs-4PFQW2/${LIB}/gameoverlayrenderer.so

For reference, my Steam overlay is completely disabled.

What if you also manually disable steam input for the game? Maybe it also (intentionally or not?) load the overlay stuff even if you disable it.

What if you also manually disable steam input for the game? Maybe it also (intentionally or not?) loads the overlay stuff even if you disable it.

Steam Input was already turned off because that game is an aim trainer, so I turned it off to not add useless layers on top of the game.

Yes, but please open a new issue about it referencing this one over at https://github.com/ValveSoftware/steam-for-linux/issues

I probably won't do it until tomorrow because I'm strained by all these days of troubleshooting and I just don't want to deal with more log grabbing and stuff. You can feel free to post an issue, or wait until I do it, it's the same to me.

Greetings, I've encountered this bug playing Holdfast: Nations at War via Gamescope's DRM backend, launched from TTY.
After sometime any mouse movement causes stuttering, no stuttering while the mouse is still.
System Specs: Tumbleweed, 6.11.5-lqx1-1-liquorix, AMD zen2 3500x, GTX1650 - 656 drivers, 16gb ram
I'm extremely dumb but I think its related to this:
https://github.com/labwc/labwc/issues/2290
https://github.com/labwc/labwc/issues/2229#issuecomment-2452988139
Im too dumb to figure out how to pull the patch from the kernel mailing list in the last link. If someone could walk me through it I will try to build a kernel with the patch and test it
PS as the name implies, im tarded and could be starting a wild goose chase, forgive me

I'm closing this specific issue because it's caused by Steam's LD_PRELOADs, thanks everybody who helped me find the culprit.
I will probably open an issue at https://github.com/ValveSoftware/steam-for-linux/issues tomorrow, but you can feel free to do so as well.

Actually, I just played overwatch 2 and did run into the same issue.

Actually, I just played overwatch 2 and did run into the same issue.

Were you able to fix it with the LD_PRELOAD method?
LD_PRELOAD="" %COMMAND%

If you need mangohud:
LD_PRELOAD="" VK_LOADER_LAYERS_ENABLE=VK_LAYER_MANGOHUD_overlay_x86_64 %COMMAND%

Haven't tried yet, but I'll probably play again today, have already setup LD_PRELOAD="" in the launch parameters.
I wonder how long this bug has been around, probably not for too long, since it's the first time I experienced it, but haven't been playing for a month or so previously.
Thanks for being persistent in trying to solve this issue, as it's definitely a rough one.

Haven't tried yet, but I'll probably play again today, have already setup LD_PRELOAD="" in the launch parameters. I wonder how long this bug has been around, probably not for too long, since it's the first time I experienced it, but haven't been playing for a month or so previously.
Thanks for being persistent in trying to solve this issue, as it's definitely a rough one.

For me, it definitely started around the same time Valve implemented the "Record your game" thingy on Steam.

Ran into the same issue about 3 days ago as well - Thanks for the LD_PRELOAD fix!

When you say your overlay is completely disabled, how do you mean? Have you taken any steps for that other than using the UI option in the Steam client to disable the overlay?

When you say your overlay is completely disabled, how do you mean? Have you taken any steps for that other than using the UI option in the Steam client to disable the overlay?

Completely disabled through Steam's UI.

Can confirm I have also been experiencing the same issue, but only since upgrading to Fedora 41. Couldn't find anything online and was thinking I was going crazy. Thanks for making the thread.

Having the same issue, stuttering occurred in Saitsfactory.  Thought it was gamescope but turning gamescope off didn't resolve it.  Happened in DX12 and Vulkan mode.  Disabled steam overlay.  Switched from Proton Experimental to GE-Proton-9-16
It initially seems to have been resolved by adding LD_PRELOAD="" to my launch commands.
Went stuttering in Satisfactory every 30-40m on mouse input that required a reboot of the game, to playing for almost an hour and half last session after adding the command without issue (wasn't able to test further).

Thank you so much guys this issue was driving me crazy!
LD_PRELOAD=""

Setting LD_PRELOAD="" seems to introduce input lag for me in Borderlands 2

Alan Wake 2 too had been showing some weird mouse lags recently (past month) on both Nobara 40 and Mint 22. It happens only if at least 15 minutes has passed. It simply will not happen sooner. I noticed this issue here, and tried to run the game on Lutris to see if lags go away and it was definitely fixed. I did not use LD_PRELOAD workaround for neither Steam nor Lutris.
I never compiled anything though... playing with default Proton 9/Experimental versions on both Steam and Lutris. I shall now try other games on Steam to see if they too have this mouse lag bug after 30 mins (tried Remnant 2 yesterday but I always rage quit it before 10 mins passed, despite trying hard not to. Now going to try Empire of the Ants and possibly Hellblade 2).

Ah! And god of war Ragnarok also has this problem!!

I had this issue with Guild Wars 2. I want to also add what temporary fixed the time bomb was using the release version of DXVK. However this was my experience 2 weeks ago, now there is mouse cursor lag unrelated to DXVK at least for me in Guild Wars 2 which is immediate and not after 40 minutes. My cursor lag is related to Proton that is not compiled from Value tree's.

I had relief knowing this  issue was made clear when noticed in CS2 massive lag spikes after  playing 30 min , warframe too when doing nothing but not in Space Engineers (maybe because crashes before experiencing this lag).
Testing currently
LD_PRELOAD="/usr/lib/libgamemodeauto.so.0" VK_LOADER_LAYERS_ENABLE=VK_LAYER_MANGOHUD_overlay_x86_64 gamemoderun %COMMAND%

I had relief knowing this issue was made clear when noticed in CS2 massive lag spikes after playing 30 min , warframe too when doing nothing but not in Space Engineers (maybe because crashes before experiencing this lag). Testing currently LD_PRELOAD="/usr/lib/libgamemodeauto.so.0" VK_LOADER_LAYERS_ENABLE=VK_LAYER_MANGOHUD_overlay_x86_64 gamemoderun %COMMAND%

Did you mean Counter Strike 2 or Cities Skylines 2?
I seem to have a similar issue that after around 40-60 minutes of gameplay suddenly the game starts stuttering. Not sure if its thsi but Im gonna try LD_PRELOAD="" as well.

Having same issue with Star Trek Online

Also happens in Path of Exile 2 with its Vulkan renderer, which would mean this is unrelated to dxvk?

I am seeing this also on Manjaro KDE running Fallout76 using GE-Proton9-20. The game runs perfectly smooth for about exactly 30 minutes or so then the jitter line in mangohud just goes crazy and the only fix is to restart the game.
Currently using this launch parameter:
gamemoderun mangohud %command%

I will try some of the above fixes and report back.

I can report that after over an hour it has not returned. The only thing added to the run command was LD_PRELOAD="" for a total command of:
LD_PRELOAD="" gamemoderun mangohud %command%
Mangohud works and so does gamemoderun without anything additional.

This was occurring to me in Path of Exile 2 with both DX12 and Vulkan.
With Steam overlay disabled, LD_PRELOAD="" did not work
With Steam overlay enabled, LD_PRELOAD="" worked
However, I did not test steam overlay enabled without LD_PRELOAD, so I cannot say whether that or enabling Steam overlay (or both) did the trick.

I had this issue with armored core 6 when I use gamescope to send it to my TV. But steam input doesn't seem to work as i can't use my controller with LD_PRELOAD in the launch command. Is there something I can do to force this?

Don't you need to add strings inside " " to point to which files to preload
otherwise it preloads nothing.
On Wed, Dec 11, 2024, 5:32 AM Jeremy @.***> wrote:

I can report that after over an hour it has not returned. The only thing
added to the run command was LD_PRELOAD="" for a total command of:
LD_PRELOAD="" gamemoderun mangohud %command%
Mangohud works and so does gamemoderun without anything additional.
—
Reply to this email directly, view it on GitHub
https://github.com/doitsujin/dxvk/issues/4436#issuecomment-2535867001,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APUWVMVH5HECYUSU5WV22K32FAWG3AVCNFSM6AAAAABROFOZSCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZVHA3DOMBQGE
.
You are receiving this because you commented.Message ID:
@.***>

Don't you need to add strings inside " " to point to which files to preload otherwise it preloads nothing.
…
On Wed, Dec 11, 2024, 5:32 AM Jeremy @.> wrote: I can report that after over an hour it has not returned. The only thing added to the run command was LD_PRELOAD="" for a total command of: LD_PRELOAD="" gamemoderun mangohud %command% Mangohud works and so does gamemoderun without anything additional. — Reply to this email directly, view it on GitHub <#4436 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/APUWVMVH5HECYUSU5WV22K32FAWG3AVCNFSM6AAAAABROFOZSCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZVHA3DOMBQGE . You are receiving this because you commented.Message ID: @.>

The empty LD_PRELOAD prevents gameoverlayrenderer.so (both 32/64) from being loaded.

I add "/usr/lib/libgamemode.so" (64bit) Helps with gamemode than without
it.
On Wed, Dec 18, 2024, 8:35 AM jeisom @.***> wrote:

Don't you need to add strings inside " " to point to which files to
preload otherwise it preloads nothing.
… <#m_-7229722878671354874_>
On Wed, Dec 11, 2024, 5:32 AM Jeremy @.> wrote: I can report that
after over an hour it has not returned. The only thing added to the run
command was LD_PRELOAD="" for a total command of: LD_PRELOAD="" gamemoderun
mangohud %command% Mangohud works and so does gamemoderun without anything
additional. — Reply to this email directly, view it on GitHub <#4436
(comment)
https://github.com/doitsujin/dxvk/issues/4436#issuecomment-2535867001>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APUWVMVH5HECYUSU5WV22K32FAWG3AVCNFSM6AAAAABROFOZSCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZVHA3DOMBQGE
https://github.com/notifications/unsubscribe-auth/APUWVMVH5HECYUSU5WV22K32FAWG3AVCNFSM6AAAAABROFOZSCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZVHA3DOMBQGE
. You are receiving this because you commented.Message ID: @.>
The empty LD_PRELOAD prevents gameoverlayrenderer.so (both 32/64) from
being loaded.
—
Reply to this email directly, view it on GitHub
https://github.com/doitsujin/dxvk/issues/4436#issuecomment-2551635444,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APUWVMXDYLX4K2QEH7PBJQ32GGI43AVCNFSM6AAAAABROFOZSCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJRGYZTKNBUGQ
.
You are receiving this because you commented.Message ID:
@.***>

Just started following this thread. I have a similar issue:

Start playing a DX11 Game
30 Min Pass -> Game Stutters based off KBM movement

It doesn't matter if I use Steam Overlay, mangohud, or vkbasalt. I always end up getting stutters around the 30 min mark.
I have played a few DX12 and OGL games 30-Min-Stutter does not kick in. I will play a few other games and see if the same problem happens outside of DX11 games.
I have not tried the LD_PRELOAD= yet. I will read up on this some more and see if it works.
I bought a new GPU because a few peeps from the Bazzite Reddit suggested my low VRAM 4GB GPU was causing issues. I got a 12GB 7700XT and got the same 30-Minute-Stutters. Tried different BIOS settings and same issue has been popping up for a while now.
Hopefully this gets sorted soon.

Also having this issue here.
That bug has been driving me crazy for some time now...
Thankfully LD_PRELOAD=" " %command% solves the issue
That Game Recording update is definitely broken

The thing is steamoverlay.so is used by steam for everything these days,
you just can't disable it from running.
Just make sure that overlay option is turned off in options.
That option actually is a preload option and most likely preloading
steamoverlay.so by default, and resolves issues for certain folks in
certain situations.
On Sun, Dec 22, 2024, 9:25 AM joranm1 @.***> wrote:

Also having this issue here.
That bug has been driving me crazy for some time now...
Thankfully LD_PRELOAD=" " %command% solves the issue
That Game Recording update is definitely broken
—
Reply to this email directly, view it on GitHub
https://github.com/doitsujin/dxvk/issues/4436#issuecomment-2558509345,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APUWVMSRLPF7VYBP63BXOXT2G3RWVAVCNFSM6AAAAABROFOZSCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJYGUYDSMZUGU
.
You are receiving this because you commented.Message ID:
@.***>

The thing is steamoverlay.so is used by steam for everything these days, you just can't disable it from running. Just make sure that overlay option is turned off in options. That option actually is a preload option and most likely preloading steamoverlay.so by default, and resolves issues for certain folks in certain situations.
…
On Sun, Dec 22, 2024, 9:25 AM joranm1 @.> wrote: Also having this issue here. That bug has been driving me crazy for some time now... Thankfully LD_PRELOAD=" " %command% solves the issue That Game Recording update is definitely broken — Reply to this email directly, view it on GitHub <#4436 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/APUWVMSRLPF7VYBP63BXOXT2G3RWVAVCNFSM6AAAAABROFOZSCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJYGUYDSMZUGU . You are receiving this because you commented.Message ID: @.>

Well, that's where thing get funny:
Steam Overlay was already disabled in options because of [https://github.com/ValveSoftware/steam-for-linux/issues/11479](this bug)

Actually, I just played overwatch 2 and did run into the same issue.

Were you able to fix it with the LD_PRELOAD method?
LD_PRELOAD="" %COMMAND%

If you need mangohud:
LD_PRELOAD="" VK_LOADER_LAYERS_ENABLE=VK_LAYER_MANGOHUD_overlay_x86_64 %COMMAND%

If you also need gamemode for some reason:
LD_PRELOAD="/usr/lib/libgamemodeauto.so.0" VK_LOADER_LAYERS_ENABLE=VK_LAYER_MANGOHUD_overlay_x86_64 gamemoderun %COMMAND%

(you still need gamemoderun for gamemode to actually trigger)

Does anyone know if this will be fixed soon since I would really love to have the Steam overlay's browser so I can just search stuff up while I queue for Helldivers 2 matches :)

Actually, I just played overwatch 2 and did run into the same issue.

Were you able to fix it with the LD_PRELOAD method?
LD_PRELOAD="" %COMMAND%

If you need mangohud:
LD_PRELOAD="" VK_LOADER_LAYERS_ENABLE=VK_LAYER_MANGOHUD_overlay_x86_64 %COMMAND%

If you also need gamemode for some reason:
LD_PRELOAD="/usr/lib/libgamemodeauto.so.0" VK_LOADER_LAYERS_ENABLE=VK_LAYER_MANGOHUD_overlay_x86_64 gamemoderun %COMMAND%

(you still need gamemoderun for gamemode to actually trigger)

Does anyone know if this will be fixed soon since I would really love to have the Steam overlay's browser so I can just search stuff up while I queue for Helldivers 2 matches (using this workaround disables the overlay)

Have you tried enabling the overlay while disabling GPU accelerated rendering in web views?
Tell us if it works for you

Actually, I just played overwatch 2 and did run into the same issue.

Were you able to fix it with the LD_PRELOAD method?
LD_PRELOAD="" %COMMAND%

If you need mangohud:
LD_PRELOAD="" VK_LOADER_LAYERS_ENABLE=VK_LAYER_MANGOHUD_overlay_x86_64 %COMMAND%

If you also need gamemode for some reason:
LD_PRELOAD="/usr/lib/libgamemodeauto.so.0" VK_LOADER_LAYERS_ENABLE=VK_LAYER_MANGOHUD_overlay_x86_64 gamemoderun %COMMAND%

(you still need gamemoderun for gamemode to actually trigger)

Does anyone know if this will be fixed soon since I would really love to have the Steam overlay's browser so I can just search stuff up while I queue for Helldivers 2 matches (using this workaround disables the overlay)

Have you tried enabling the overlay while disabling GPU accelerated rendering in web views?
Tell us if it works for you

Can confirm it does

Actually, I just played overwatch 2 and did run into the same issue.

Were you able to fix it with the LD_PRELOAD method?
LD_PRELOAD="" %COMMAND%

If you need mangohud:
LD_PRELOAD="" VK_LOADER_LAYERS_ENABLE=VK_LAYER_MANGOHUD_overlay_x86_64 %COMMAND%

If you also need gamemode for some reason:
LD_PRELOAD="/usr/lib/libgamemodeauto.so.0" VK_LOADER_LAYERS_ENABLE=VK_LAYER_MANGOHUD_overlay_x86_64 gamemoderun %COMMAND%

(you still need gamemoderun for gamemode to actually trigger)

Does anyone know if this will be fixed soon since I would really love to have the Steam overlay's browser so I can just search stuff up while I queue for Helldivers 2 matches (using this workaround disables the overlay)

Have you tried enabling the overlay while disabling GPU accelerated rendering in web views?
Tell us if it works for you

That only delayed the inevitable and when it came, the issue was even worse

Just adding to the list the two games I have encountered this exact same issue in. Same symptoms: game runs absolutely perfect then suddenly starts stuttering and the frame times go out of whack. The stutter is constant while moving the mouse, and less frequent while moving the player character with WASD; no stutter when no user input is being provided, i.e. NPC and background animations, player character idle anim etc. all fine. Using keyboard and mouse, no gamepad.

Ship Graveyard Simulator 2 (Steam/Proton): stutter after 40-45 minutes depending on activity, in both in DX11 and DX12 modes. LD_PRELOAD="" workaround solved it.
Shadow of the Tomb Raider (Steam/both native and Proton): stutter after 45-60 minutes. The issue was definitely present there in early September. The above workaround solved this as well, played 4 hours of it today with no stutters.

I think I'm seeing this issue in Grey Zone Warfare, but instead of small stutters, it locks up almost entirely, and causes the amdgpu driver to timeout over and over until the entire system freezes up, or the game crashes.
(entire chunk of the following log here - the large time jumps are probably points I restart the game)

Dec 27 17:13:03 corais kernel: amdgpu 0000:0b:00.0: amdgpu: ring gfx_0.0.0 timeout, but soft recovered
Dec 27 17:13:04 corais kernel: amdgpu 0000:0b:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:3 pasid:32793)
Dec 27 17:13:04 corais kernel: amdgpu 0000:0b:00.0: amdgpu:  in process GameThread pid 209492 thread vkd3d_queue pid 209888)
Dec 27 17:13:04 corais kernel: amdgpu 0000:0b:00.0: amdgpu:   in page starting at address 0x00008002cb6ea000 from client 10
Dec 27 17:13:04 corais kernel: amdgpu 0000:0b:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00301030
Dec 27 17:13:04 corais kernel: amdgpu 0000:0b:00.0: amdgpu:          Faulty UTCL2 client ID: TCP (0x8)
Dec 27 17:13:04 corais kernel: amdgpu 0000:0b:00.0: amdgpu:          MORE_FAULTS: 0x0
Dec 27 17:13:04 corais kernel: amdgpu 0000:0b:00.0: amdgpu:          WALKER_ERROR: 0x0
Dec 27 17:13:04 corais kernel: amdgpu 0000:0b:00.0: amdgpu:          PERMISSION_FAULTS: 0x3
Dec 27 17:13:04 corais kernel: amdgpu 0000:0b:00.0: amdgpu:          MAPPING_ERROR: 0x0
Dec 27 17:13:04 corais kernel: amdgpu 0000:0b:00.0: amdgpu:          RW: 0x0
Dec 27 17:13:13 corais kernel: traps: steamwebhelper[206896] trap invalid opcode ip:7f29d0ecabcf sp:7ffca7fc8da0 error:0 in libcef.so[66c9bcf,7f29ccbed000+a36d000]
Dec 27 17:13:14 corais kernel: amdgpu 0000:0b:00.0: amdgpu: Dumping IP State
Dec 27 17:13:14 corais kernel: amdgpu 0000:0b:00.0: amdgpu: Dumping IP State Completed

... (a lot of the same thing)

Dec 27 17:53:13 corais kernel: amdgpu 0000:0b:00.0: amdgpu: ring gfx_0.0.0 timeout, but soft recovered
Dec 27 17:53:13 corais kernel: amdgpu 0000:0b:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:7 pasid:32793)
Dec 27 17:53:13 corais kernel: amdgpu 0000:0b:00.0: amdgpu:  in process GameThread pid 270525 thread vkd3d_queue pid 271334)
Dec 27 17:53:13 corais kernel: amdgpu 0000:0b:00.0: amdgpu:   in page starting at address 0x000080023ac76000 from client 10
Dec 27 17:53:13 corais kernel: amdgpu 0000:0b:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00701030
Dec 27 17:53:13 corais kernel: amdgpu 0000:0b:00.0: amdgpu:          Faulty UTCL2 client ID: TCP (0x8)
Dec 27 17:53:13 corais kernel: amdgpu 0000:0b:00.0: amdgpu:          MORE_FAULTS: 0x0
Dec 27 17:53:13 corais kernel: amdgpu 0000:0b:00.0: amdgpu:          WALKER_ERROR: 0x0
Dec 27 17:53:13 corais kernel: amdgpu 0000:0b:00.0: amdgpu:          PERMISSION_FAULTS: 0x3
Dec 27 17:53:13 corais kernel: amdgpu 0000:0b:00.0: amdgpu:          MAPPING_ERROR: 0x0
Dec 27 17:53:13 corais kernel: amdgpu 0000:0b:00.0: amdgpu:          RW: 0x0
Dec 27 17:53:24 corais kernel: amdgpu 0000:0b:00.0: amdgpu: Dumping IP State
Dec 27 17:53:24 corais kernel: amdgpu 0000:0b:00.0: amdgpu: Dumping IP State Completed

@DrymarchonShaun a GPU hang is a completely unrelated issue and also probably not a DXVK bug, more likely a driver bug. Report it here using the 'radeon vulkan' template https://gitlab.freedesktop.org/mesa/mesa/-/issues, also check out https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/docs/drivers/amd/hang-debugging.rst?ref_type=heads to gather more info.

@DrymarchonShaun a GPU hang is a completely unrelated issue and also probably not a DXVK bug, more likely a driver bug.

Hmm, alright. If that's the case, then I must have multiple things happening at the same time. I'm seeing a bunch of the symptoms described on the issue on the steam-for-linux repo that came about from and links to this issue, and the hangs seem to only happen when the steam overlay is loaded.

None of these things seem to fix ffxvi s stuttering issues. But I have to
account for its poor optimizations of being a ported console game.
Star Trek Online however continues to experience stuttering issues after
running smoothly  for 30-45 min even after applying these env variables.
On Sun, Dec 29, 2024, 3:18 AM DrymarchonShaun @.***>
wrote:

@DrymarchonShaun https://github.com/DrymarchonShaun a GPU hang is a
completely unrelated issue and also probably not a DXVK bug, more likely a
driver bug.
Hmm, alright. If that's the case, then I must have multiple things
happening at the same time. I'm seeing a bunch of the symptoms described on
the issue on the steam-for-linux repo that came about from and links to
this issue, and the hangs seem to only happen when the steam overlay is
loaded.
—
Reply to this email directly, view it on GitHub
https://github.com/doitsujin/dxvk/issues/4436#issuecomment-2564677675,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APUWVMXSJU5YFFEDIUNKQI32H7EARAVCNFSM6AAAAABROFOZSCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRUGY3TONRXGU
.
You are receiving this because you commented.Message ID:
@.***>


Parameter local_files_only not working

When I execute
python generate.py --score_model=None --share=False --local_files_only=True --base_model='llama'
I get the following output:

Auto set langchain_mode=LLM.  Could use MyData instead.  To allow UserData to pull files from disk, set user_path or langchain_mode_paths, and ensure allow_upload_to_user_data=True
No GPUs detected
Using Model llama
Prep: persist_directory=db_dir_UserData exists, using
Starting get_model: llama
/home/h2ouser/miniconda3/envs/h2ogpt/lib/python3.10/site-packages/transformers/models/auto/configuration_auto.py:995: FutureWarning: The use_auth_token argument is deprecated and will be removed in v5 of Transformers.
warnings.warn(
Could not determine --max_seq_len, setting to 2048.  Pass if not correct
BEGIN get url https://huggingface.co/TheBloke/Llama-2-7B-Chat-GGML/resolve/main/llama-2-7b-chat.ggmlv3.q8_0.bin

Although I use --local_files_only=True a file of several GB (llama-2-7b-chat.ggmlv3.q8_0.bin) is downloaded.
Instead h2oGPT shout output an error message that no model is available.
If you think the current behavior is correct and the meaning of --local_files_only is different from what I expect please add an option to disable all downloads (so that it simulates a offline mode).

In order to make that work you will need to point to a model that has already been downloaded and point --base_model to the path.
For example here is what mine looks like:
python generate.py --base_model='/home/ryanc/.cache/huggingface/hub/models--h2oai--h2ogpt-4096-llama2-13b-chat/snapshots/4a1968218a334323d847ed2fcf6cb661b74b5e68/' --prompt_type=llama2 --local_files_only=True
Pointing to the cache directory where something was previously downloaded or wherever you have placed the files should work. Right now setting --base_model='llama' it doesnt have a local file to point to so it goes to huggingface. We could maybe improve this behavior by looking in the default cache directory or throwing an error instead of trying to download anyway.

Thanks for the description how to use generate.py with a local model directory. But what I wanted to say is: The parameter local_files_only is not working in all situations, in particular it is not working in the described situation (no matter if the command was right or wrong), From my understanding of --local_files_only=True no download should happen but a download did happen.

For general offline, see updates here: https://github.com/h2oai/h2ogpt/blob/main/docs/README_offline.md from https://github.com/h2oai/h2ogpt/pull/877


Can not be training. CUDA error: an illegal memory access was encountered

Hello!
Thank you for your amazing job!
But, when I tried to reproduce your work, similar this issue, I met this error which blocked training:
python main.py --config configs/image.yaml input=data/test_rgba.png save_path=ckpt

/home/xxx/ProgramFiles/anaconda3/envs/dgs/lib/python3.10/site-packages/numba/np/ufunc/parallel.py:371: NumbaWarning: The TBB threading layer requires TBB version 2021 update 6 or later i.e., TBB_INTERFACE_VERSION >= 12060. Found TBB_INTERFACE_VERSION = 12050. The TBB threading layer is disabled.
  warnings.warn(problem)
[INFO] load image from data/test_rgba.png...
Number of points at initialisation :  5000
[INFO] loading zero123...
Keyword arguments {'trust_remote_code': True} are not expected by Zero123Pipeline and will be ignored.
Loading pipeline components...: 100%|███████████████████████████████████████████████████████████████████| 6/6 [00:00<00:00, 22.92it/s]
[INFO] loaded zero123!
  0%|                                                                                | 0/500 [00:00<?, ?it/s]

---------------------------------------------------------------------------------------------------------------------------------------------------------------
Traceback (most recent call last):
  File "/media/xxx/DATA/Processing/OFFICE/CodingFactory/PosWorkShop/dreamgaussian/main.py", line 917, in <module>
    gui.train(opt.iters)
  File "/media/xxx/DATA/Processing/OFFICE/CodingFactory/PosWorkShop/dreamgaussian/main.py", line 893, in train
    self.train_step()
  File "/media/xxx/DATA/Processing/OFFICE/CodingFactory/PosWorkShop/dreamgaussian/main.py", line 270, in train_step
    loss = loss + self.opt.lambda_zero123 * self.guidance_zero123.train_step(images, vers, hors, radii, step_ratio=step_ratio if self.opt.anneal_timestep else None, default_elevation=self.opt.elevation)
  File "/media/xxx/DATA/Processing/OFFICE/CodingFactory/PosWorkShop/dreamgaussian/guidance/zero123_utils.py", line 156, in train_step
    noise_pred = self.unet(
  File "/home/xxx/ProgramFiles/anaconda3/envs/dgs/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1518, in _wrapped_call_impl
    return self._call_impl(*args, **kwargs)
  File "/home/xxx/ProgramFiles/anaconda3/envs/dgs/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1527, in _call_impl
    return forward_call(*args, **kwargs)
  File "/home/xxx/ProgramFiles/anaconda3/envs/dgs/lib/python3.10/site-packages/diffusers/models/unet_2d_condition.py", line 1075, in forward
    sample, res_samples = downsample_block(
  File "/home/xxx/ProgramFiles/anaconda3/envs/dgs/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1518, in _wrapped_call_impl
    return self._call_impl(*args, **kwargs)
  File "/home/xxx/ProgramFiles/anaconda3/envs/dgs/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1527, in _call_impl
    return forward_call(*args, **kwargs)
  File "/home/xxx/ProgramFiles/anaconda3/envs/dgs/lib/python3.10/site-packages/diffusers/models/unet_2d_blocks.py", line 1159, in forward
    hidden_states = resnet(hidden_states, temb, scale=lora_scale)
  File "/home/xxx/ProgramFiles/anaconda3/envs/dgs/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1518, in _wrapped_call_impl
    return self._call_impl(*args, **kwargs)
  File "/home/xxx/ProgramFiles/anaconda3/envs/dgs/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1527, in _call_impl
    return forward_call(*args, **kwargs)
  File "/home/xxx/ProgramFiles/anaconda3/envs/dgs/lib/python3.10/site-packages/diffusers/models/resnet.py", line 764, in forward
    hidden_states = self.conv1(hidden_states, scale) if not USE_PEFT_BACKEND else self.conv1(hidden_states)
  File "/home/xxx/ProgramFiles/anaconda3/envs/dgs/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1518, in _wrapped_call_impl
    return self._call_impl(*args, **kwargs)
  File "/home/xxx/ProgramFiles/anaconda3/envs/dgs/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1527, in _call_impl
    return forward_call(*args, **kwargs)
  File "/home/xxx/ProgramFiles/anaconda3/envs/dgs/lib/python3.10/site-packages/diffusers/models/lora.py", line 358, in forward
    return F.conv2d(
RuntimeError: CUDA error: an illegal memory access was encountered
CUDA kernel errors might be asynchronously reported at some other API call, so the stacktrace below might be incorrect.
For debugging consider passing CUDA_LAUNCH_BLOCKING=1.
Compile with `TORCH_USE_CUDA_DSA` to enable device-side assertions.

The environment is as same as requirements.lock.txt, each step is following readme.md, but this error came out.
I also tried install by  requirements.txt, same error...
I tested torch2.1 and cuda12.1, they worked normally.
Could you tell me how to fix this?
Thank you in advance!

ubuntu 22.04
python 3.10
others are as same as requirements.lock.txt


New version of @types/react causing type errors with a new yarn.lock

Hey remote-ui team 👋. This issue is going to look very similar to https://github.com/Shopify/remote-ui/pull/151, but it's brand new as of last night.
TL;DR: Type checking is broken in this repository with a fresh yarn.lock file because of a new version of @types/react.
Steps to reproduce:

Check out a clean copy of the main branch
Delete yarn.lock
Run yarn install
Run yarn type-check

tsc reports many errors of this type:
'RemoteImage' cannot be used as a JSX component.
  Its element type 'ReactElement<any, any> | Component<ReactPropsFromRemoteComponentType<RemoteComponentType<"Image", { src: string; }, true>>, any, any> | null' is not a valid JSX element.

Yesterday (April 7) version 18.0.0 of @react/types was published to NPM. The @types/react-reconciler package (for all versions) requests "@types/react": "*", so as soon as the new version came out it started pulling it in for new installs. Here's what the dependency tree looks like:
% npm list @types/react
<EMAIL_ADDRESS>/Users/ericfrank/stripe/remote-ui/packages/react
├──<EMAIL_ADDRESS>├─┬<EMAIL_ADDRESS>│ └──<EMAIL_ADDRESS>deduped
└─┬<EMAIL_ADDRESS>  └──<EMAIL_ADDRESS>
You can see that react-reconciler has it's own version of @types/react pinned to version 18. remote-ui does not support React 18 yet, so the mismatch in types causes the errors. I'm not familiar with how those type libraries get generated on DefinitelyTyped and I don't have a great solution to this at the moment. We're advising our developers to add a resolutions property to their package.json files as a workaround:
{
  "resolutions": {
    "@types/react": "17.0.2"
  }
}

I'm continuing my research, but let me know if you have an idea how we can solve this one. Thanks!

I ran into this the other day, too

Yeah, sorry we can't offer anything better, I think resolutions are the best any kind of project generator can do if they want to output a React 17-supporting TypeScript project :(


Bug: Import command causes application to hang

System: macOS Big Sur 11.6
JDK: 11
The application window hangs after entering the command word import. Shows the spinny pinwheel.
System log:

Tagging @zhenghanlee and @Zhou-Jiahao-1998, please see if the problem is due to platform/machine specific issues.

I can confirm, it hangs when I run import.


Make user/group/uid/gid configurable with docker --build-arg

Parameterize the user/group name, uid and gid of the Jenkins user.
We are using this docker image for our Jenkins master, but have had to clone-and-patch it to make sure we get the proper UID and GID for the Jenkins user when volume-binding /var/jenkins_home.
This PR adds two ARG parameters in the dockerfile that lets you customize uid/gid when building the image. This does require Docker 1.9 or newer for building.

Thank you for this pull request! Please check this document for how the Jenkins project handles pull requests.

thanks!


Allow overriding path to server executable

Intended as a workaround for issue #18 such that the path to the server executable can be manually overridden in production. If no serverPath is included with config defaults to original path.

Looks good, thanks for the work around :) If you have any additional information on how to setup the fix manually, please document on #18. Thanks.

@sancarn will do. Was the workaround not included in 0.1.0 or did you maybe just forgot to rebuild? I tried updating but the serverPath is not part of the configs.

@sancarn will do. Was the workaround not included in 0.1.0 or did you maybe just forgot to rebuild? I tried updating but the serverPath is not part of the configs.

Oh shoot you're probably right, I forgot to rebuild!


Why is the difference between the protobuf I generated and the demo，and then how can I use the protobuf message's field

This is my question
at first,this is my protobuf file that is same as demo.
syntax = "proto3";

message CustomResponse {
    bool isSuccess = 1;
    int32 code = 2;
    string message = 3;
}

1.Compile Protobuf for Custom Response
python -m grpc_tools.protoc --proto_path=./proto/ --python_out=./proto/    --grpc_python_out=./proto/ ./proto/response.proto

the content of my requeirement.txt   is as follows

aiohttp==3.8.5
aiosignal==1.3.1
async-timeout==4.0.3
attrs==23.1.0
bleach==6.0.0
certifi==2023.7.22
charset-normalizer==3.2.0
cloudevents==1.9.0
colorama==0.4.6
dapr==1.10.0
dapr-ext-grpc==1.10.0
deprecation==2.1.0
docutils==0.20.1
environs==9.5.0
filelock==3.12.3
frozenlist==1.4.0
fsspec==2023.9.0
grpcio==1.56.0
grpcio-tools==1.56.0
huggingface-hub==0.16.4
idna==3.4
importlib-metadata==6.8.0
jaraco.classes==3.3.0
Jinja2==3.1.2
keyring==24.2.0
markdown-it-py==3.0.0
MarkupSafe==2.1.3
marshmallow==3.20.1
mdurl==0.1.2
more-itertools==10.1.0
mpmath==1.3.0
multidict==6.0.4
networkx==3.1
numpy==1.25.2
packaging==23.1
pandas==2.1.0
Pillow==10.0.0
pkginfo==1.9.6
protobuf==4.21.12
pydantic==1.10.12
Pygments==2.16.1
pymilvus==2.3.0
python-dateutil==2.8.2
python-dotenv==1.0.0
pytz==2023.3.post1
pywin32-ctypes==0.2.2
PyYAML==6.0.1
readme-renderer==41.0
regex==2023.8.8
requests==2.31.0
requests-toolbelt==1.0.0
rfc3986==2.0.0
rich==13.5.2
safetensors==0.3.3
sentencepiece==0.1.99
six==1.16.0
sympy==1.12
tabulate==0.9.0
tenacity==8.2.3
tokenizers==0.13.3
torch==2.0.1
torchaudio==2.0.2
torchvision==0.15.2
towhee==1.1.1
towhee.models==1.1.1
tqdm==4.66.1
transformers==4.33.1
twine==4.0.2
typing_extensions==4.7.1
tzdata==2023.3
ujson==5.8.0
urllib3==2.0.4
webencodings==0.5.1
yarl==1.9.2
zipp==3.16.2

and this is pb2 file that is my protobuf generate.this file is different from demo,for example  my file has not the content of from google.protobuf import message as _message from google.protobuf import reflection as _reflection so how can I use the message data of getter or setter? Help me ,Thank u!
# -*- coding: utf-8 -*-
# Generated by the protocol buffer compiler.  DO NOT EDIT!
# source: response.proto
"""Generated protocol buffer code."""
from google.protobuf import descriptor as _descriptor
from google.protobuf import descriptor_pool as _descriptor_pool
from google.protobuf import symbol_database as _symbol_database
from google.protobuf.internal import builder as _builder
# @@protoc_insertion_point(imports)

_sym_db = _symbol_database.Default()

DESCRIPTOR = _descriptor_pool.Default().AddSerializedFile(b'\n\x0eresponse.proto\"B\n\x0e\x43ustomResponse\x12\x11\n\tisSuccess\x18\x01 \x01(\x08\x12\x0c\n\x04\x63ode\x18\x02 \x01(\x05\x12\x0f\n\x07message\x18\x03 \x01(\tb\x06proto3')

_globals = globals()
_builder.BuildMessageAndEnumDescriptors(DESCRIPTOR, _globals)
_builder.BuildTopDescriptorsAndMessages(DESCRIPTOR, 'response_pb2', _globals)
if _descriptor._USE_C_DESCRIPTORS == False:

  DESCRIPTOR._options = None
  _globals['_CUSTOMRESPONSE']._serialized_start=18
  _globals['_CUSTOMRESPONSE']._serialized_end=84
# @@protoc_insertion_point(module_scope)

I cannot help with generic protobuf questions. Maybe you should file this against the protobuf or grpc libraries instead?
This is not the right place for protobuf help. I can only help with the implementation of our own SDK.

Not sure which demo you are referring to, but maybe take a look at the examples/grpc_proxying sample instead.

The example https://github.com/dapr/python-sdk/tree/master/examples/grpc_proxying should have everything you need. Please adjust your code accordingly to match the name of your proto request and response classes.

Not sure which demo you are referring to, but maybe take a look at the examples/grpc_proxying sample instead.

Yes, I was referring to the demo you mentioned examples/grpc_proxying. and I found

The example https://github.com/dapr/python-sdk/tree/master/examples/grpc_proxying should have everything you need. Please adjust your code accordingly to match the name of your proto request and response classes.

The proto generated by your code is significantly different from the proto generated by my code.And Your code generation seems to be more accurate than me,so I want to know how your proto was generated. Is it related to the version of protobuf? Although I can still solve it through this method req.ParseFromString(request.data)


Implement L50: Objective-C Interceptor

Design doc: https://github.com/grpc/proposal/pull/140

Test failures are #18967

Test failures are #18967.


Windows-mingw-w64 nsis GUI installer: Parameters to install tesseract in a specific location in silent mode

Current Behavior
tesseract-ocr-w64-setup-<IP_ADDRESS>41111.exe /S
Expected Behavior
tesseract-ocr-w64-setup-<IP_ADDRESS>41111.exe /S  /D=C:\tesseract
such as /D
Suggested Fix
sorry, I don't know the param of silent mode installation params.
I asked at here but no one to help me..
https://groups.google.com/g/tesseract-ocr/c/biZbztxEbv8
I tried /? /h /H and get nothing, still open the gui program.
Sorry, I'm newbie of rust, I don't know c++.
tesseract -v
tesseract v<IP_ADDRESS>41111
leptonica-1.85.0
libgif 5.2.2 : libjpeg 8d (libjpeg-turbo 3.0.4) : libpng 1.6.44 : libtiff 4.7.0 : zlib 1.3.1 : libwebp 1.4.0 : libopenjp2 2.5.2
Found SSE4.1
Found libarchive 3.7.7 zlib/1.3.1 liblzma/5.6.3 bz2lib/1.0.8 liblz4/1.10.0 libzstd/1.5.6
Found libcurl/8.11.0 Schannel zlib/1.3.1 brotli/1.1.0 zstd/1.5.6 libidn2/2.3.7 libpsl/0.21.5 libssh2/1.11.0
Operating System
Windows 11
Other Operating System
Windows 11 Professional  22H2
uname -a
No response
Compiler
No response
CPU
No response
Virtualization / Containers
No response
Other Information
No response

Related: #3095.
Citing the documentation on /D: "Must be the last parameter on the command line and must not contain quotes even if the path contains blank spaces." In your case it was the last parameter, but you used quotes!

Related: #3095.
Citing the documentation on /D: "Must be the last parameter on the command line and must not contain quotes even if the path contains blank spaces." In your case it was the last parameter, but you used quotes!

Sir, I tried, but it still did not work.

Right, this looks like an issue in the NSIS configuration. Maybe it should not set MULTIUSER_INSTALLMODE_INSTDIR because this setting overrides the command line value.

Right, this looks like an issue in the NSIS configuration. Maybe it should not set MULTIUSER_INSTALLMODE_INSTDIR because this setting overrides the command line value.

Thank you, Sir, it seems there are no answers for now. I'll continue to pay attention to this issue.


[Strategy Room] Quest flowchart

Implement Quests tab on strategy room that will contain quest flowchart and completion statuses

Feature added on b6d37036eac6770b4c27537c2fd30f1304110bce


Adding WebUSB API

I have added WebUSB API definitions, based on the draft.
I am not sure if I even want this merged right now - the draft is still a draft, and it's supported only on Chrome/ium and only either via "trial mode" or via special flag in Chrome/ium settings.
But I am still making this PR - either for merging, or for tracking progress; as you wish.
The definition is rewritten directly from the draft - partly by hand, partly by webidl tools.

I cannot fix the travis issues now, because for some reason flow is not building on my PC, so I cannot repeat the tests (for fixing all those line shifting issues).

Yeah, it seems a little early to merge. Putting stuff in the libdefs isn't exactly free at the moment, since every time Flow starts up it has to recheck the libdefs. We do plan on moving as much of the libdefs to flow-typed at some point.
Is that cool with you?

I am not really sure how, technically, add this to a separate file, when this defines navigator.usb and navigator is defined in bom.js.
Also, I am not sure under which name this should be added to flow-typed :) you don't have lidefs there right now, right?
I am completely ok with you not merging this, the standard is draft after all.

We don't currently have any way to extend an already defined class, other than redeclaring it. Ideally you'd be able to add your own libdef saying "Navigator also has this property" without completely redefining Navigator. It's been a todo for awhile :/

Hm, it's a pity that there is no way to have this in flow right now :/ ok anyway


pip python pdftotext installation  for windows ?

please help me in fixing this issue Cannot open include file: 'poppler/cpp/poppler-document.h': No such file or directory while installing pdftotext . I only have this option because pdfminer extracts text but does not match properly even for the tested templates

I suggest asking about the pdftotext project in their respective support forum, rather than here.


panzoom not available on npm

404 Not Found: @panzoom/panzoom@latest

Thanks for the issue. The first release under the new name has not gone out yet, but I'll release as soon as I get time to check a few more things. For now, the master branch is in good shape.
I'll leave this issue open as this is a common question right now.

@timmywil While we all wait for a released version, do you have instructions on how to compile panzoom for those not familiar with TypeScript?

Sure, clone the repo then run
$ yarn # or npm install
$ yarn build # or npm run build

That will put compiled files in the dist/ folder.

Btw since there is no clear information about the state of the library I will ask here: is it an alpha/beta/rc stage? It would be great if it is available on npm ;)

Not trying to be unclear. It is close to release. You can call it rc if you want.

I want to accompany this first release with a blog post, which I still need to write. Other than that, I think it's ready to go.

Looking forward to the blog post and release!

Released! Available at @panzoom/panzoom.


Issues with resize, focus and blur event.

So since these are basic events, I am thinking this is more a question than an issue but I can't find enough resources online to help me figure this out. I'm on a Mac using Yosemite and iTerm. I can't seem to be able catch the terminal window's resize, focus or blur events. The keyboard press works fine. Am I missing something?
Here is the code:
var blessed = require('blessed');

var Willem = function() {
    var self = this;

    this._screen = blessed.screen({
        smartCSR: true,
        debug: true
    });

    this._screen.title = "Willem";

    this._screen.key(['q'], function (ch, key) {
        return process.exit(0);
    });

    ['resize', 'keypress', 'focus', 'blur'].forEach(function(event) {
        self._screen.on(event, function(){ self._screen.log(1, '[SCREEN]: '+event); });
    });

    this._screen.render();
}();

Hmm, I just realized you're right about the focus/resize events. It's sort of awkward to enable them from Screen:
self._screen.program._currentMouse.sendFocus = true;
self._screen.program.enableMouse(program._currentMouse);

Or
self._screen.program.write('\x1b[?1004h');

I'll add an option for it. NOTE: I'm not sure focus events work with iTerm2, and they definitely don't work if you're using tmux.
As far as resize events, I have no idea why you're not getting them. Node handles resize events and sends them to the stream, so blessed can't really fix that if it's not working. This is probably an OS/node issue.
You could try:
process.on('SIGWINCH', function() {
  self._screen.emit('resize');
});

As a workaround.

Of course, SIGWINCH makes complete sense and works. I haven't tested the new  focus option you added yet. I will later on today and report back.

All good.


Maint/@types dev deps and npm audit fix

This MR moves two @types packages in regular dependencies to devDependencies to keep consumers from having to install them unnecessarily.
It also runs npm audit fix on the library. I don't think any of the security "issues" flagged by NPM are real, but the updates don't seem problematic and it might save a complaint/support request from someone later.
I should say I was unable to run the tests locally with npm run test from the repo root, so I haven't checked that this didn't break something somehow. I got this error:
 ~/Documents/forks/react-flow  on<EMAIL_ADDRESS>.............................................................................................................................. INT  took 6m 18s  at 23:21:32
> npm run test

><EMAIL_ADDRESS>test
> BROWSER=none npm run dev:wait test:chrome

><EMAIL_ADDRESS>dev:wait
> start-server-and-test start:testserver http-get://localhost:3000 "test:chrome"

1: starting server using command "npm run start:testserver"
and when url "[ 'http-get://localhost:3000' ]" is responding with HTTP status code 200
running tests using command "npm run test:chrome"

><EMAIL_ADDRESS>start:testserver
> npm run build && npm run start:examples

><EMAIL_ADDRESS>build
> rollup -c --environment NODE_ENV:production && postcss src/*.css --dir dist

src/index.ts → dist/ReactFlow.js, dist/ReactFlow.esm.js...
Created bundle ReactFlow.js: 443.82 kB → 93.92 kB (gzip)
Created bundle ReactFlow.esm.js: 439.62 kB → 93.57 kB (gzip)
created dist/ReactFlow.js, dist/ReactFlow.esm.js in 10.9s

src/index.ts → dist/nocss/ReactFlow-nocss.js, dist/nocss/ReactFlow-nocss.esm.js...
Created bundle ReactFlow-nocss.js: 438.37 kB → 92.54 kB (gzip)
Created bundle ReactFlow-nocss.esm.js: 434.16 kB → 92.2 kB (gzip)
created dist/nocss/ReactFlow-nocss.js, dist/nocss/ReactFlow-nocss.esm.js in 10.6s

><EMAIL_ADDRESS>start:examples
> cd example && npm start

><EMAIL_ADDRESS>start
> react-scripts start

sh: react-scripts: command not found
Error: server closed unexpectedly
    at ChildProcess.onClose (/Users/spencer/Documents/forks/react-flow/node_modules/start-server-and-test/src/index.js:75:14)
    at ChildProcess.emit (node:events:390:28)
    at maybeClose (node:internal/child_process:1064:16)
    at Process.ChildProcess._handle.onexit (node:internal/child_process:301:5)

Hey @SpencerWhitehead7
thanks for your PR. The test command doesn't run because you need to do npm install in the example folder.


[Removal]:

Hotspot Name
Urban Canvas Jay
Hotspot b58 Address
112de8UnW3nRu7GefmWp5kSCzWP25THdAkzm2r66ckYHjGuw3Kig
Discord Handle
No response
Hotspot Manufacturer
PantherX
Removal Reason
I help of installed equipment is the first suppliers, then thought that VPN is cheating, no to use VPN. The other day about the supplier's reason, the original antenna was he altered, are now change back. Please test data, help me to delete the blacklist. We didn't mean to cheat, please
Modifications
No
Extra forwarders
No
Extra antennas
Yes
Additional Information
No response

https://github.com/helium/denylist/issues/7771#issuecomment-1255907939


[Do not merge] [Raising to trigger CI for external contributor] Fix typo in layout code

remove extra closing div tag from the layout example code

You can preview this change here:
Built with commit 628f6db3b311ff9131c4081e5b14fae7f42ce65a
https://deploy-preview-258--govuk-design-system-preview.netlify.com


Remove configuration from request

RequestManager and FillManager data should be removed from the request payload.
https://github.com/beamer-bridge/beamer/pull/249#discussion_r817686642

This has become irrelevant after the latest big refatorings.


New sct_example_data and batch_processing

These new data were acquired with more optimized parameters on the Prisma scanner.

pls do not merge yet, I would like to try with other data


[otbn] "Subtract with borrow" vs. "Subtract with carry"

Currently the OTBN specification follows the subtract with carry definition for bn.sub and bn.subm instructions. Software, however, expects the subtract with borrow method.
See here for a definition of the two.
Assuming, subtraction is y=a-b, then for the subtract with carry method the c flag is c_flag = b>a and for subtract with carry it is c_flag = ~(a < b). This has to be considered when using the bn.cmp and bn.cmpb instructions which are just bn.sub/bn.subb but discarding the arithmetic result and only setting the flags.
As long as used in bn.sub and bn.subm context, SW is agnostic to this (w.r.t. to the arithmetic result).
We have to decide which method we want to use. If we decide to go for subtract with carry the next question would be if subb is still the right mnemonic for the instruction or if we should change this to subc then.
@GregAC @imphil @rswarbrick

This is new to me! I'd be interested to know what Greg and Philipp think about the relative implementation costs. That article makes it look like the "carry" method would be cheaper to implement. If the SW doesn't care either way, I guess we should pick whatever is more convenient for implementation.
If both implementations are similar, I suppose I'm slightly leaning towards the "borrow" version, because the explanation of the semantics doesn't need to explain 2's complement signed representations(!), but I don't think that's a very strong argument.

The current (well mock RTL I'm about to use) implementation implements subtraction through the  a+not(b)+1 method so I think I'd tend towards subtract with carry as the carry bit generation will be identical for subtract/add as will the logic for feeding it into the adder (a + b + C for add a + not(b) + C for sub). Going for the subtract with borrow method looks like it'll require more logic. I would certainly switch the mnemonic to subc if we do this.

Hmm though looked at the table in wikipedia the different in logic may be minimal, what I'm not 100% on is how the borrow bit is generated from the carry bit you get out of the add, I think it's just simply the inverted version?

@GregAC Yes, as I understand it, if you invert the carry (both input and output from the perspective of the instruction implementation) but you actually do subtract with carry in the RTL, it looks from programmer's model like subtract with borrow. Also I think the input carry/borrow can be included in the inversion you do anyways. So I think the additional logic is a single bit inversion.
This is the RTL I used in the bignum PoC, I think it does exactly this IIRC. There might be a more elegant solution to this of course.

I think lets leave it as subtract with borrow for now then. The added logic is minimal and (probably) isn't on the critical path so avoiding change seems like the best option.

We still have to fix the spec though. I suggest that I prepare a PR on the spec (for subtract with borrow) and then let's take the final decision

We can close this, right?
To summarize

We decided to stick with "subtract with borrow" principle
It is implemented in the ISS now
It is covered in the doc

I agree!


Invariant Violation: nodeHandle expected to be non-null

I am calling
ref.reload()

But I am getting Invariant Violation: nodeHandle expected to be non-null. Also, this error is only on Android for me.
I am showing local html file
source={{
                uri: isAndroid
                  ? 'file://' +
                    dirs.DocumentDir +
                    '/bundled-assets/assets/ChannelTemplates/' +
                    pub.channelsArray[0].channelViewTemplate
                  : newURI,
              }}

Library version used     "react-native-webview": "^11.17.2",

I haven't seen that before and without a sample repro it's hard to know what's happening, but if you search you'll find a few past mentions of that error that may be related to your situation, such as #1828.

I was replacing my current screen using navigation.replace('screenName').
I was getting error when I was reloading the webView and replacing current screen simultaneously. I applied check like this
if (ref && ref.webViewRef && ref.webViewRef.current) {
        ref.reload();
      }


Use the image size information provided by the API instead of making head requests

Blocked by https://github.com/WordPress/openverse-catalog/issues/521
Blocked by https://github.com/WordPress/openverse-api/issues/711
Problem

Currently, we are making a head request to the image source to get the image dimensions if they are not available in the API response. After the changes in the linked issues, we will get all the information from the API.
Description

We will need to delete the code that makes a head request to the image provider to get the image dimensions 🎉

The frontend already uses the value from the API:
https://github.com/WordPress/openverse/blob/1cf6c6ad555a0afca4ed766fe7fa9480ceb38173/frontend/src/pages/image/_id/index.vue#L197
Closing.