Hot patching systems with subsecond

[mockersf]

Objective

• Enable hot patching systems with subsecond
• Fixes Support hotpatching systems #19296

Solution

• First commit is the naive thin layer
• Second commit only check the jump table when the code is hot patched instead of on every system execution
• Depends on subsecond: Typed HotFn pointer DioxusLabs/dioxus#4153 for a nicer API, but could be done without
• Everything in second commit is feature gated, it has no impact when the feature is not enabled

Testing

• Check dependencies without the feature enabled: nothing dioxus in tree
• Run the new example: text and color can be changed

[github-actions]

It looks like your PR has been selected for a highlight in the next release blog post, but you didn't provide a release note.

Please review the instructions for writing release notes, then expand or revise the content in the release notes directory to showcase your changes.

[janhohenheim]

Consider adding the documentation on how to setup your system (i.e. download CLI, change linker, etc.) from https://github.com/TheBevyFlock/bevy_simple_subsecond_system :)

[jakkos-net]

Just tried this on Linux with 2 of my existing projects. All I had to do was enable the feature and run with dx serve --hot-patch and all systems would hot-patch. Great stuff!

[janhohenheim]

Little update: https://github.com/TheBevyFlock/bevy_simple_subsecond_system now supports changing the signatures of systems at runtime. Would be nice if this PR did so too, but I'm also fine with leaving that for a follow-up :)

[MrGVSV]

The future is now

[bushrat011899]

A couple notes more than anything else. Really awesome to see this working, this will be a massive selling point of 0.17

[bushrat011899]

Is there a particular blocker that made exclusive systems harder to implement?

[mockersf]

no, mostly I wanted to make sure we wanted to go in this direction before doing more work.

it should also be a todo that can be picked up by anyone among the many other things that can be continued if we get this first step in

[bushrat011899]

Suggested change

	/// Refresh the inner pointer based on the latest hot patch jump table
	fn refresh_hotpatch(&mut self);
	/// Refresh the inner pointer based on the latest hot patch jump table
	#[cfg(feature = "hotpatching")]
	fn refresh_hotpatch(&mut self) {}

If we provide a default implementation (no-op), we can safely feature-gate this method while keeping features purely additive. I think this is desirable, as the inner implementation for a user's refresh_hotpatch might only make sense when the feature is enabled, potentially forcing them to add their own gate within the body of the function.

Alternatively, could this function be modified to be more general? E.g., refresh?

[mockersf]

I didn't want to cfg-gate all the functions in all the implementation of that trait, but it makes sense...

Before trying to find a more general version, let's wait for systems as entities

[bushrat011899]

Perfection. Should probably try to improve this before it's merged tho.

[akimakinai]

subsecond seems to provide hot-reload handler, could it be used here?

use dioxus_devtools::{connect_subsecond, subsecond::register_handler};

...
        connect_subsecond();
        register_handler(Arc::new(move || {
            sender.send(HotPatched).unwrap();
        }));

[janhohenheim]

Update again: I added an opt-in to rerun hot-patched systems to the prototype. This makes it way nicer to edit UIs live, as it means we can just rerun regular setup systems that are typically in OnEnter or Startup. Which breaks their run contracts, but I think that's fine as long as it's opt-in per function.
Not sure if we want to land that in the MVP, just pointing out that this possibility exists :)