Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix issues #570, #575 #576

Merged
merged 7 commits into from
Mar 3, 2024
Merged

Fix issues #570, #575 #576

merged 7 commits into from
Mar 3, 2024

Conversation

John-Nagle
Copy link
Contributor

@John-Nagle John-Nagle commented Feb 26, 2024

Checklist

  • CI Checked:
    • cargo fmt has been ran
    • cargo clippy reports no issues
    • [partial] cargo test succeeds (2 failures - scene-viewer tests need two.gltf files not present in the project, same as before.
    • cargo rend3-doc has no warnings
    • cargo deny check issues have been fixed or added to deny.toml
  • Manually Checked:
    • relevant examples/test cases run
    • changes added to changelog
      • Add credit to yourself for each change: Added new functionality @githubname.

Related Issues

Description

Issue #570 required a mechanism to allow the application to override the default action of requesting a redraw immediately after redrawing each frame. So a new function, handle_redraw_done, was added to the App trait in rend3_framework. The default implementation of the trait mantains old behavior by requesting another redraw at the end of each redraw. Applications where the platform does not give non-redraw events priority over redraw events (this includes Windows executables running under Wine) can override the default behavior and redraw only when the event loop is about to wait.

Issue #575 was fixed by removing some dead code which imported "reqwest", pulling in but not using "tokio".

Also fixed the framework to allow the logger to be initialized more than once. This allows "cargo test" to run without panics.

@John-Nagle
Copy link
Contributor Author

CI is failing because CI is using an old Rust compiler:

error: package `bumpalo v3.15.3` cannot be built because it requires rustc 1.73.0 or newer, while the currently active rustc version is 1.72.1
Either upgrade to rustc 1.73.0 or newer, or use
cargo update -p [email protected] --precise ver
where `ver` is the latest version of `bumpalo` supporting rustc 1.72.1

Checking Bumpalo, here's the change that broke it: Fix MSRV in Cargo.toml; bump to version 3.15.1

Current stable Rust is rustc 1.76.0. Github continuous integration for Rend3 uses 1.72.

So the CI file needs an update.

…1.76 so 'bumpalo' will work"

This reverts commit 89c1d1b.
Can't change CI rules, not owner.
@John-Nagle
Copy link
Contributor Author

I can't fix the CI problem. I don't have permission to modify the CI workflow.

@cwfitzgerald
Copy link
Member

@John-Nagle you can likely fix it, I just need to manually approve the CI run - this only happens on your first PR. On your second PR, CI will run automatically

@John-Nagle
Copy link
Contributor Author

I got a Git permissions error trying to commit "@John-Nagle
Increase Rust version in continuous integration from 1.72 to 1.76 so". I don't fully understand the restrictions on that.

@John-Nagle
Copy link
Contributor Author

CI for mac is stuck waiting for a runner, for 23 hours now. All other runs finished in the first minute. Is that normal?

@John-Nagle
Copy link
Contributor Author

How can I get this un-stuck? The mac CI waited 24 hours for a runner and then Github aborted the job.

@cwfitzgerald
Copy link
Member

I can't push to your branch as it's trunk - but will merge this and fix it.

@cwfitzgerald cwfitzgerald merged commit b9bd37a into BVE-Reborn:trunk Mar 3, 2024
5 of 6 checks passed
@cwfitzgerald cwfitzgerald mentioned this pull request Mar 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

"reqwest", "tokio", etc. pulled in by rend3-framework but not used Very slow event processing (seconds)
2 participants