Hotpatching Rust code 🔥

[rough sand]

This project looks amazing. Before I write too many more Lua scripts, I'm considering switching over to using all Rust + Hotpatching.

But! The most important thing is that end users can edit the game scripts without having to install a dev environment.

This is currently working with Luau! Players can jump right into modding instantly just by editing the script files, and embedding or compiling Luau is no problem for all target platforms. This is a pretty big feature for my game.

How could this be possible with Rust? How can I ship an embedded Rust compiler, that works on all platforms?

Possible compromises:

• Get rid of the universal modding system, require user to have rustc installed before they start modding
• Don't allow live modding on Android, iOS, Web
• Ship embedded Rust compiler only for desktop platforms

Other possible solution: Switch to C# for scripting

• Mono runtime can be statically linked and compile to WASM:
• https://godotengine.org/article/live-from-godotcon-boston-web-dotnet-prototype/
• https://github.com/godotengine/godot/issues/70796#issuecomment-2855430724
• Can potentially be compiled to native code in the future with NativeAOT
• https://github.com/dotnet/runtimelab/tree/feature/NativeAOT
• https://github.com/dotnet/runtimelab/tree/feature/NativeAOT-LLVM
• https://github.com/MichalStrehovsky/zerosharp

I'm using Lua because I don't have any other options and I'm basically forced to use it.

I really, really would love to use Rust, but I don't see the path forward. Any ideas?

[late stratus]

i doubt theres any possible way it makes sense to ship a Rust compiler for modding. You could probably offer some hooking stuff and loading dynamic libs from a folder, but that's entirely unrelated to hotpatching/subsecond

[median vale]

I recommend you stick with lua.

[quartz whale]

There is something you could do with compiling rustc for wasm (which I think is possible now, but I haven't verified it), and then compiling mod code to wasm and running it through that, but that's all orthogonal to hotpatching

[mellow flint]

Check out #modding-and-scripting, they'll know more 🙂

[static arrow]

IDK if this is really a "bug", but turns out that accidentally running multiple dx serve --hot-patch instances in the same project results in segfaults.

[mellow flint]

Speedup recipe for Linux, for those who are setting up the crate for the first time 🙂

[steep mountain]

But why the linker is set to clang?

[mellow flint]

Mold requires clang IIRC

[steep mountain]

Ah, right, forgot about it!

[pliant helm]

I think this portion isn't needed?

[profile.release]
codegen-backend = "llvm"

[profile.web]
codegen-backend = "llvm"

These should already be "llvm". Only profile.dev has cranelift set

[mellow flint]

release is not needed (good catch), but web is, as bevy run web will inherit from dev

[worldly ether]

can you report this on our repo? hopefully it might already be fixed with the new release, but it might still be an issue

[mellow flint]

@worldly ether while you’re here, did you check your hotpatch time with the repo I linked?

[worldly ether]

Haven't had a chance, my wifi is very bad atm and I couldn't even download a shallow version of your repo haha

[static arrow]

Sure

[mellow flint]

Oooh alright. Yeah, it’s fairly big 😄

[worldly ether]

https://github.com/DioxusLabs/dioxus/releases/tag/v0.7.0-alpha.1

new release out, now also supports arm64 linux binstalls

seems stable in my testing and incorporates all the changes thus far

not all binaries have been uploaded yet (x86 takes longer than arm64)

[lone token]

I think https://github.com/DioxusLabs/dioxus/pull/4225 is going to break asset support for Bevy with dx 😦
at least it breaks it on macos

[worldly ether]

https://github.com/DioxusLabs/dioxus/issues/4223#issuecomment-2922941829

see this issue - but the gist is that you can’t rely on CARGO_MANIFEST_DIR as a runtime concept at all, so dx unsets it even in dev since running executables directly can’t expose all the cargo env vars

That env var is not set on web, iOS, android, or when opening app bundles (appimage, appbundle, msi/exe)

[lone token]

well we had the same discussion and arrived at different conclusions 😄
we rely on the env var to find the asset path while running through cargo, and when it's not present we search for the asset path relative to the current binary. that's easier to not have to package them during development

[warm thistle]

can we inject BEVY_ASSET_ROOT instead?

assuming used via bevy-cli

[lone token]

right I forgot we added that one. yup it takes precedence over other env vars

[worldly ether]

Dioxus runs executables as bundles (.app, .apk, web public folders) and in those environments asset loading is way more complex.

Even on Android, current_exe returns nonsense

[lone token]

we have different asset management for non file systems like bundle, not relying on the cargo env var or the current binary

[worldly ether]

Our thinking was that we want the usecase of ./app.exe to work in dev too since you eventually grow out of cargo.

FWIW dx always assembles a bundle even in dev - is there a way to assume that if CARGO_MANIFEST_DIR is Err, then fallback to using the bundled loader?

[lone token]

not really for now, but maybe that'll push us to improve on that 😄

in the meantime, Charlotte's mention of BEVY_ASSET_ROOT should make it work, with a bit more doc on our side

[calm basin]

Hiiiii! it seems like I'm causing trouble, sorry 🤣

My experience so far has been that most of the custom tooling seems to break for workspaces - i.e. bevy run web and dx serve don't work as expected. I think dx is teeeeeeechnically wrong here as its behaviour differs from the cargo workspace "standard". I'm not sure if this PR brings it closer to or further from the expected behaviour?

Either way my issues are probably not that important as I've just tried hot-patching in a fresh bevy_new_2d repository and it still doesn't work. So probably something "weird" with my setup on Windows 11 🤷‍♂️

[loud narwhal]

What breaks in workspaces for bevy run web?

[calm basin]

This issue https://github.com/TheBevyFlock/bevy_cli/issues/443, although I haven't tried to troubleshoot too hard

[loud narwhal]

Ahh right!

[pliant helm]

@mellow flint You documented "Only functions that exist when the app is launched are considered while hotpatching." as a known limitation, but it seems to work just fine.
Oops I almost forgot that I also cherry-picked Francois' hot-patching PR onto 0.16. Maybe that makes the difference? I'd be a bit surprised as I'm testing it within a call to with_hot_patch

[mellow flint]

That’s a limitation of the vanilla #[hot]. It's very possible that with_hot_patch does not have this limitation.

[opaque mulch]

Does a hot patch restart the bevy loop? (Startup, update, etc)
Or does it stay on the same schedule?

[raven valley]

It restarts the StartupReRunHotreload

In with_hot_patch

But nothing else

[idle stone]

dx serve on macos seems to create and run a macos app

but it doesn't copy bevy's assets folder into the app, so everything fails to load

any workaround known? maybe an argument can be passed to dx serve?

[lone token]

BEVY_ASSET_ROOT="." dx serve

dx always bundle the app while for Bevy we do it only on platforms where that's mandatory. we could probably learn a few tricks from dx there 🙂

[static arrow]

I'm getting some linking errors... there's every chance this is my own fault, but cargo run --example editor works correctly while dx serve --hot-patch --example editor crashes (after almost 10 minutes). Any pointers on how to debug this?

These errors repeat until rust-lld decides "too many errors emitted" and stops

Failed to generate fat binary: rust-lld: error: undefined symbol: Graphic3d_MaterialAspect::Graphic3d_MaterialAspect(Graphic3d_NameOfMaterial)
>>> referenced by XCAFDoc_VisMaterial.cxx
>>>               XCAFDoc_VisMaterial.cxx.o:(XCAFDoc_VisMaterial::FillMaterialAspect(Graphic3d_MaterialAspect&) const) in archive /home/greg/p/games/bevy_anvil/target/x86_64-unknown-linux-gnu/debug/exa>>> referenced by XCAFDoc_VisMaterial.cxx
>>>               XCAFDoc_VisMaterial.cxx.o:(XCAFDoc_VisMaterial::FillMaterialAspect(Graphic3d_MaterialAspect&) const) in archive /home/greg/p/games/bevy_anvil/target/x86_64-unknown-linux-gnu/debug/examples/libdeps-9ebe84b1.a
>>> referenced by XCAFPrs_AISObject.cxx
>>>               XCAFPrs_AISObject.cxx.o:(XCAFPrs_AISObject::XCAFPrs_AISObject(TDF_Label const&)) in archive /home/greg/p/games/bevy_anvil/target/x86_64-unknown-linux-gnu/debug/examples/libdeps-9ebe84b1.a

rust-lld: error: undefined symbol: Graphic3d_MaterialAspect::SetAmbientColor(Quantity_Color const&)
>>> referenced by XCAFDoc_VisMaterial.cxx
>>>               XCAFDoc_VisMaterial.cxx.o:(XCAFDoc_VisMaterial::FillMaterialAspect(Graphic3d_MaterialAspect&) const) in archive /home/greg/p/games/bevy_anvil/target/x86_64-unknown-linux-gnu/debug/examples/libdeps-9ebe84b1.a

It might specifically help to know what $ORIGIN maps to in the verbose output

[mellow flint]

Sounds like a subsecond bug. Could you open an issue on the Dioxus repo? 🙂

[static arrow]

Eh... yes... though I'd rather debug first a bit (in large part so I can then put repos in a place where it makes sense to push them, and link to them in the bug report)

Ok.... can actually reproduce this with minimal changes... filing issue.

[dire stone]

Just left some thoughts on Dioxus wrappers / forks / branding things:
https://github.com/bevyengine/bevy/issues/19296#issuecomment-2928027938

(@worldly ether)

[mellow flint]

Extremely fair assessment imo. The comparison to bevy_reflect is a nice insight, I didn't consider that 🙂

[worldly ether]

Thanks 🙂

I’ll follow up with more tomorrow, and I really appreciate the thoughtful response.

My feelings about the situation revolve around maintenance burden, tracking semver, release schedules, etc. I don’t want us to shoulder the burden of maintaining tools that only bring us GitHub issues. Taffy has worked out well for us - everybody needs layout and it’s great that bevy is involved in keeping it alive.

I hope hotpatching gets approached similarly. We haven’t even gotten our release out yet and are navigating the many wants of the community. The Bevy Reflect story is especially interesting - for keystone stuff like reflection or hotpatching it might be better to “unbrand” the tools?

DX is a lot to maintain and I’d be happy if it ended up taking a Vite-like role in the ecosystem. We’re also fine if everyone wants to keep building their own app runners.

I have more thoughts but I appreciate you jumping in

[languid sable]

My feelings about the situation revolve around maintenance burden, tracking semver, release schedules, etc. I don’t want us to shoulder the burden of maintaining tools that only bring us GitHub issues. Taffy has worked out well for us - everybody needs layout and it’s great that bevy is involved in keeping it alive.
Yep, I really want to be able to send contributors and technical contributions your way (and hopefully some of the folks who are excited about this work turn into Dioxus users / advocates) ❤️ A model like Taffy would be fantastic for that IMO.

I hope hotpatching gets approached similarly. We haven’t even gotten our release out yet and are navigating the many wants of the community. The Bevy Reflect story is especially interesting - for keystone stuff like reflection or hotpatching it might be better to “unbrand” the tools?
Yeah, that's my feeling too. We should consider whether or not to move this (and taffy?) under the Linebender org, since they have broad goals for GUI ecosytem unification.

That said, I love the subsecond name and hope you keep it 🙂 Something like an aggressive "sponsored/developed by Dioxus" in the tooling and repo would be 100% justified IMO, and opens the door to other orgs contributing meaningfully to share billing there

[lone token]

I hope hotpatching gets approached similarly. We haven’t even gotten our release out yet and are navigating the many wants of the community.
Thanks for that, we definitely have many wants and you've been patient with us 🙂

[static arrow]

Incidentally finally figured this out, "ld.so understands the string $ORIGIN (or equivalently ${ORIGIN}) in an rpath specification to mean the directory containing the application executable." - TIL

[dire stone]

I love Linebender's work, but I'm not sure putting it under another large UI project's umbrella is the move (and I could see why that might not be palatable to the Dioxus devs ... but I won't speak for them). That doesn't feel like "neutral ground" to me.

[languid sable]

Yeah; I feel similarly, but it's worth discussing

They really would like to be neutral ground, but it's up to vibes on how well they actually succeed there

[mellow flint]

@worldly ether on a positive note, quite a few Bevy users have reached out in the meantime to say that they really enjoy hotpatching so far 😄 especially for UI work

[quartz whale]

When/if we end up with bevy serve --hot-patch I think it should have a powered with subsecond by Dioxus or something to that effect. It's the same as Cart mentioned about highlighting the big dependencies like wgpu. When you're in a position to effectively do marketing for things you rely on, as giving them visibility makes your dependencies better, which is good for you

[loud narwhal]

I think we'll refrain from integrating hot patching directly into the Bevy CLI alpha until we figure out how to best collaborate here. There seem to be multiple options and opinions on how to proceed, and I don't want to start off on a bad foot already.
I'm confident we'll find a good solution that will be beneficial for all involved parties :)

[wide temple]

Crossposting from #jam, this is a nixpkgs overlay for the up to date dioxus cli #jam message

[elder heart]

forget..this works on clang?

or doesnt :o

[mellow flint]

works

[mellow flint]

yeah I think that's fair

[celest magnet]

Got a lot faster compile times with the nigthly rust (sub 1 second 😉 )

but I noticed if a Plugin adds observers (which is inside with_hot_patch, the observers are never triggered:

 app.with_hot_patch(|app: &mut App| {
  app.add_systems(StartupRerunHotPatch, setup);
  app.add_plugins(GameplayPlugin);
});

(if you add any observer inside the GameplayPlugin those will never get triggered, even if you make a normal build).

I assume its a similar issue with EventReader?

[mellow flint]

The only thing that with_hot_patch was built to respect are add_systems. Everything beyond that may work, but probably doesn't.
It will also reset all Locals, which includes EventReader.
Vanilla #[hot] (so without rerun_on_hot_patch or hot_patch_signature) will work with everything you throw at it, at the cost of flexibility

to be explicit, #[hot] works if you slap it on an observer and also works fine if you use it with Locals, including EventReader 🙂

[mellow flint]

Published a new release targetting the new alpha.1 release of dx

This is basically the same as the git rev we manually used before

But now we can do cargo add bevy_simple_subsecond_system and cargo install [email protected] again

[arctic osprey]

Any idea what is going wrong here? (Windows)

[mellow flint]

Are you on the newest version? This was supposed to be fixed IIRC

[arctic osprey]

of subsecond or the cli?

[mellow flint]

both 😄

[mellow flint]

huh, then you're on the newest

@worldly ether wasn't there a PR that fixed this? 🤔

on a completely different note: https://github.com/bevyengine/bevy_editor_prototypes/blob/f0a501b53382b533d41b52ee1ab5f56fafb92a81/crates/bevy_proto_bsn/examples/bsn_macro.rs exists and could work very nicely with hotpatching, if someone wants to experiment 👀

Who's ready for

fn ui() -> impl Scene {
    pbsn! {
        Node {
            width: Val::Percent(100.0),
            height: Val::Percent(100.0),
            align_items: AlignItems::Center,
            justify_content: JustifyContent::Center,
            flex_direction: FlexDirection::Column,
            row_gap: px(5.0),
        } [
            (Node, {Name::new("BasicButton")}, :button("Basic")),
            (Node, :button("Rounded"), rounded),
            (Node { border: px_all(5.0) }, BorderColor(RED_500) :button("Thick red"), rounded),
            (Node, :button("Merged children"), rounded) [(
                Node {
                    width: px(30.0),
                    height: px(30.0),
                },
                BackgroundColor(BLUE_500),
                {BorderRadius::MAX}
            )],

            (:button("Click me!")) [
                On(|_: Trigger<Pointer<Click>>| {
                    info!("Clicked me!");
                })
            ],
        ]
    }
}

[dire stone]

Thanks. Yeah please leave this on pause until you hear otherwise 🙂

[mellow flint]

Good call on locking the issue on GH

[dire stone]

Just gave the latest dx alpha a try with https://github.com/bevyengine/bevy/pull/19309. I'm getting 1 second hot patches with mold + dynamic linking

Pretty sweet 🙂

[lone token]

try with nightly and cranelift 😄

[dire stone]

On it 🙂

[lone token]

I'm at ~900ms in Bevy repo with the default macos linter, ~700ms with cranelift and nightly, and pulling an example in another repo that only enables the Bevy features it needs I can get down to under 500ms

[dire stone]

Will the config.toml profiles here work?
https://github.com/rust-lang/rustc_codegen_cranelift

[lone token]

yup

I didn't try all the settings, but look at the readme of https://github.com/TheBevyFlock/bevy_simple_subsecond_system/blob/main/readme.md, click on "steps to get maximum performances"

[languid sable]

To me the really big workflow improvement isn't the faster recompiles: it's being able to persist game state during experimentation 🙂

[lone token]

yes! but also being able to really go "subsecond" is very cool

[dire stone]

With cranelift and nightly I'm getting an average of about 980ms instead of an average of about 1008ms

[lone token]

meh...

well that's still subsecond 😄

[dire stone]

Eh not actually closer to 990 with cl + nightly

[lone token]

anyway mold is so 2024, the linker to use is wild now

[dire stone]

Do they do incremental linking yet? Very excited for that space

[idle stone]

is that with -Zshare-generics=y -Zthreads=8?

[dire stone]

Nope!

Testing that now

Also with the other recs like incremental = true and less debug info

[lone token]

no... they're working on it as stated at rustweek. but looks very cool

[elder heart]

me over here with 7s hot patching punching air cuz it's still so easy to edit particular scenes

[lone token]

yes, even a few seconds to hotpatch is a very good improvement over rebuilding and rerunning from start

[half pasture]

are the "big" differences just due to hardware or does it grow a lot with project size?

[dire stone]

Still averaging about 990 with the other changes

[lone token]

saying that as someone who did fast experimentation on projects that I can rebuild in less than 5 seconds. keeping states is a very big improvement

[dire stone]

Depends on how the project is structured and what you are changing, but larger projects do increase the potential for longer build times

Ex: Hot patching changes to the example code is quick because its only rebuilding the top level example. Hot patching a change to, say, bevy_ecs internals, would take much longer

[half pasture]

i see ye makes sense

[mellow flint]

@dire stone while you're here: I believe you've said that this BSN prototype is somewhat similar to what you're planning.
If so, am I understanding it correctly that using a syntax like this with hotpatching enabled is somewhat representative of how working day-to-day with BSN will be like? Minus all the asset integration part ofc, I'm mainly talking about designing a UI

Maybe not representative, but at least a kind of sneak-peek 🙂

[dire stone]

Yup! That is the general shape of things! Inheritance and observers as the primary UI event handlers are the things most up in the air at the moment.

[mellow flint]

Very nice 😄

[dire stone]

I'm pretty bullish on using observers in this context, but there are also advocates for one shot systems instead

[mellow flint]

I'm curious to try the prototype BSN crate + hotpatching after the jam, it looks very ergonomic 🙂

[dire stone]

hot patching + BSN would be so cool!

[mellow flint]

Oh really? I kinda almost forgot about them existing since we have observers 😄

[dire stone]

The argument is that they are easier to pass around as arguments / share

[mellow flint]

aaah that makes sense

thx

[lone token]

future is looking good 🙂

[mellow flint]

absolutely!

[dire stone]

I think observers are the better fit for "event handlers" in general / that is what they exist for, so it would be odd not to use them in this context. I think the reusability and passability issues are both solvable

[quartz whale]

I've seen trivial (almost empty) examples range from 500ms to 4-7s, so there's definitely a big range for hardware. But I think some people seeing ~1s for the trivial example see ~5s for big projects

[mellow flint]

Yep, I do! 0.5 s for toy examples, 3.5 seconds for Foxtrot

[worldly ether]

https://www.phoronix.com/news/TPDE-Faster-Compile-Than-LLVM

[quartz whale]

I hope the people who see 4 seconds on an example don't see 16 seconds on foxtrot, because that would mean they get 16s compile times normally, which doesn't sound too fun 😅

[quartz whale]

It seems like it would basically be a drop-in replacement for llvm? That's kinda sick

[raven valley]

yeah, seems like we just need someone to wire it up

[trim quest]

To show the flexibility of our framework and its benefits for JIT compilation, we also implement a back-end for Cranelift IR [6, 9 ] in the context of Wasmtime [8 ] to compile WebAssembly code, where our TPDE-based back-end was able to outperform Cranelift’s fast compilation mode in compile-time and run-time performance.

The TPDE-based back-end compiles 4.27x faster than Cranelift and 2.68x faster than Cranelift with its fast register allocator
https://arxiv.org/pdf/2505.22610

Which is crazy since cranelift is really fast ime

(at least with the language I was working on, I was getting compile times around ~4ms from start to execution, idk how it fares with rust)

[mellow flint]

Can confirm, my CI when from 16 mins to 6 mins after switching to compiling everything with cranelift

[idle stone]

it doesn't seem to make much of a difference when opt-level = 0, though

[dire stone]

@lone token Just wrapped up a review of your 'initial hotpatching support" PR . I think its good to merge after some minor tweaks https://github.com/bevyengine/bevy/pull/19309#pullrequestreview-2893805489

[mellow flint]

Note: it seems like the newest dx release breaks for me when using asset hot reloading / embedded asset reloading. Can someone else confirm?

specifically, I need to disable these two features or I get "asset not found" errors when hotpatching

[lone token]

done!

[dire stone]

Looks good. Merging!

[worldly ether]

We swapped from passing CARGO_MANIFEST_DIR="" to not setting it altogether. A more sane default could be to just set it in the way cargo run would, but there are a lot of variables to set for it to be consistent

[lone token]

we could ask the cargo team for a cargo gimme-env command that would give the env as cargo would set it up, and nothing more 😄

[mellow flint]

So to restore the previous behavior, I just need to set that env var?

[lone token]

no, dx is actively unsetting it. but bevy has another env var that it reads and takes precedence over cargo vars. you can set BEVY_ASSET_ROOT

[mellow flint]

I'm doing that already

BEVY_ASSET_ROOT="." dx serve --hot-patch

note that works

But just until I hotpatch with hot reloading enabled

[languid sable]

I bet they'd provide this

[calm basin]

I get a panic when I use BEVY_ASSET_ROOT=".":

[windows] thread 'notify-rs debouncer loop' panicked at ...rustup\.cargo\registry\src\index.crates.io-1949cf8c6b5b557f\bevy_asset-0.16.1\src\io\file\file_watcher.rs:56:9:
[windows] FileWatcher::get_asset_path() failed to strip prefix from absolute path: absolute_path=G:\code\spellfire\.\.\target\debug\.fingerprint, root=.
18:38:35 [windows] stack backtrace:
18:38:35 [windows] note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

It compiles if I specify the full path:

$env:BEVY_ASSET_ROOT="g:/code/spellfire" ; dx serve --hot-patch

Is this a bevy bug?

[mellow flint]

Ah, thanks for the workaround!
@lone token do you know whether this is on Bevy or on subsecond?

[lone token]

windows 😄

but probably Bevy

[mellow flint]

No, I get the same on Fedora

This is the file_watcher issue I mentioned earlier

[lone token]

still windows fault. microsoft is way too powerful

[mellow flint]

Fair enough! 🥷

[lone token]

there's probably somewhere for file watcher where we don't cannonicalize the path correctly

[mellow flint]

I hate it when the Microsoft lobby introduces bugs into Bevy smh

[mellow flint]

I'll double check whether this really is the exact same issue on Fedora

[calm basin]

I think I got hot reload working in Windows! https://github.com/DioxusLabs/dioxus/discussions/4249

I have no idea what linker my windows is using if I don't specify one lol

It takes a minute to hot-patch though with a fairly basic app https://github.com/will-hart/spellfire/tree/feat/ui 😭

[loud narwhal]

And thus, lukewarm patching was born
(Still very cool though!)

[calm basin]

I'm getting the same on MacOS too but the workaround above doesn't help 🤔

[quartz whale]

A minute?! What are your normal hot compile times like?

[obtuse sparrow]

sorry for the noise but does anyone happen to have a link to an issue/FR for dioxus' dx to not modify your local cargo.toml with new profiles, so I can subscribe to it? my search keywords are no joy so far but I thought it was this thread where I first saw it

[lone token]

https://github.com/DioxusLabs/dioxus/issues/4168

but not sure that will be changed before Bevy provide its own CLI for subsecond... dx is dioxus CLI, if this behaviour makes sense for them, they may not want to change it

[obtuse sparrow]

thanks!

[worldly ether]

was thinking about making the profile generation lazy, but we'd still like to isolate profiles on desktop (which we don't do currently)

we do it so you can build two binaries simultaneously of the same target without locking the target dir, and to provide a better out-of-the-box experience with rust-analyzer locking the target dir. also some env vars we set that might cause cargo to dump its cache if you don't pass them when running cargo check/build

[mellow flint]

Can confirm that this is not Windows-specific

[loud narwhal]

What we do in the Bevy CLI is to create the profiles with --config flags to cargo when they are not already defined in the toml. It's more "magic", but I think it works well for us so far :)

[mellow flint]

The workaround does work on Fedora however

Probably should put it in the readme

[lone token]

use BEVY_ASSET_ROOT="`pwd`" instead of BEVY_ASSET_ROOT="."?

[loud narwhal]

See https://github.com/TheBevyFlock/bevy_cli/blob/main/src%2Fweb%2Fprofiles.rs

[mellow flint]

that may be due to how fish expands params, though

[worldly ether]

oooooh will borrow this!

[obtuse sparrow]

env BEVY_ASSET_ROOT="$PWD" dx serve --hot-patch is roughly equivalent and shell-agnostic but works happily on fish, or if you wanted fish specific syntax it'd be BEVY_ASSET_ROOT=(pwd)

I prefer using the existing envvar over a subshell but it's nitpicky as hell

[mellow flint]

thanks, that's perfect!

I'll add that line to the readme later 🙂

[obtuse sparrow]

I tried doing some crimes with a bacon task to do zellij run --in-place ... dx serve ... and it was very jamming-the-stick-into-my-own-spokes when it blew up

the default restart behavior of bacon spawned about a hundred copies of dx before I saw my CPU cores lighting

and the compilation artifacts were garbled and a total loss

[obsidian pebble]

I wanted to try hotpatching so I checked out main and tried building the example, is this a known issue? Am I missing something?

https://github.com/smol-rs/async-process/pull/96 Seems it's been fixed in an unreleased version of async-process. Why am I hitting the issue if others aren't though

The PR author wrote

Yes, it makes a difference if you update to async-process 2.3.1 without also updating to async-signal 0.2.11 (for whatever reason).

So I just added async-signal = "0.2.11" to dev deps in Bevy without actually using it and now it builds lol

[mellow flint]

Weird

[obsidian pebble]

I also went from 850ms to 25 sec if I used anything other than the default linker 🫠

Still super neat to see hot patching. Can adding new systems ever work?

[calm basin]

I've got it down to <3s hot compile on Mac (and 6s on Windows with compilation optimisations on).

Getting hot-patch to work on Windows for me seems to require disabling a bunch of optimisation like bevy/dynamic and faster linkers (although from what I can gather from cargo --timing, the linker isn't really that important to compilation performance for me).

The killer I think is setting codegen_units = 1 to account for https://github.com/DioxusLabs/dioxus/issues/4191. I could potentially play around with the number there but as each config loop is 10 minutes of watching the compiler work I've kind of had enough haha 😅

In general dx serve seems to be 10-20% slower for both hot and cold compiles on Windows.

[woven narwhal]

You can use the "app.with_hot_patch" api for this. There is an open PR in the repo to update the docs for it. Basically you put the add_system calls inside the with_hot_patch closure and they just work 🙂

[dire stone]

With some elbow grease (and potentially some rearchitectures) I suspect we can hot reload new systems defined in plugins as well

Idk if we can do that for the main function though, as that isn't defined in a way that is repeatable / granular

[quartz whale]

That's what's been concluded in this thread as well. In fact the with_hotpatch_systems already supports a Plugin::build function, so Bevy could actually internally make that happen pretty easily

[raven valley]

yeah basically, so i added the with_hotpatch trait which lets you do it. Once we rearchitect how plugins work in plugins v2 then we will be able to have all plugins hot-reloadable

so just .add_plugins any systems that u add within that plugin would work, in theory

[vernal widget]

Does hot reloading work for render graph nodes? I suspect not, but also that it wouldn't really matter

[dire stone]

Its not currently wired up, but that feels like one of the more doable ones, as they're behind a dynamic interface, just like Systems

If you're interested in wiring it up, you could take a look at the system PR and mirror that pattern. Pretty straightforward

Actually maybe a bit different as the hot reloaded function is directly implemented on the Node impl, rather than being encapsulated by a higher level type

That could cause issues. Idk

Also thats only for hot reloading the run function. Hot reloading graph topology changes is a more complicated beast

[languid sable]

Huh that's neat: if I kill the dx process at just the wrong time it holds onto the lock for cargo

And I had to restart to unlock

[raven valley]

[languid sable]

Not a big deal at all, but worth noting down in case some poor soul needs troubleshooting help in the future

[wide temple]

Running to linker errors when making certain changes, a fresh build fixes it, but building the whole project again from scratch including what rust analyzer needs is painful. It'd be good to know if I could clear out a smaller part of the target build

09:45:45 [dev] Failed to generate fat binary: Undefined symbols for architecture arm64:
  "_anon.2bc38321b9af013d9a96996407b01000.2.llvm.10126651586654183498", referenced from:
      _$LT$abiogenesis..particles..spawner..SpawnerPlugin$u20$as$u20$bevy_app..plugin..Plugin$GT$::build::h65dbcb9e82a82191 in abiogenesis-800be1bce00ca90e.0e3u2irune93zyab0l8v4jmvv.0w4shup.      abiogenesis::app_systems::h6fe889b145184c01 in abiogenesis-800be1bce00ca90e.1zguzll01k5p3fwzapf9crjzy.0w4shup.rcgu.o

[mellow flint]

try cargo clean -p <name_of_your_crate>

[wide temple]

No dice

[mellow flint]

:/

[wide temple]

Which is weird, because it's clearly referencing objects from that package

  "_anon.2bc38321b9af013d9a96996407b01000.2.llvm.10126651586654183498", referenced from:
      _$LT$abiogenesis..particles..spawner..SpawnerPlugin$u20$as$u20$bevy_app..plugin..Plugin$GT$::build::h65dbcb9e82a82191 in abiogenesis-800be1bce00ca90e.0e3u2irune93zyab0l8v4jmvv.1xd0vvm.      abiogenesis::app_systems::h6fe889b145184c01 in abiogenesis-800be1bce00ca90e.1zguzll01k5p3fwzapf9crjzy.1xd0vvm.rcgu.o
      _$LT$abiogenesis..ui..UIPlugin$u20$as$u20$bevy_app..plugin..Plugin$GT$::build::hec76d73ea9799e17 in abiogenesis-800be1bce00ca90e.42yuc1b69ktgi3mtyf9pxtqnw.1xd0vvm.rcgu.o
      abiogenesis::ui::respawn_ui::h83beb11e0df7a500 in abiogenesis-800be1bce00ca90e.42yuc1b69ktgi3mtyf9pxtqnw.1xd0vvm.rcgu.o
      bevy_app::app::App::add_systems::h4abfb80de5ab1a1c in abiogenesis-800be1bce00ca90e.4xrz5nkx0d09i3zed9cdct9f5.1xd0vvm.rcgu.o
      bevy_app::app::App::add_systems::h637e760c7d1eb422 in abiogenesis-800be1bce00ca90e.4xrz5nkx0d09i3zed9cdct9f5.1xd0vvm.rcgu.o
      bevy_app::app::App::add_systems::h922d67f53b04fb90 in abiogenesis-800be1bce00ca90e.4xrz5nkx0d09i3zed9cdct9f5.1xd0vvm.rcgu.o

Unless they're getting stored elswhere 🤔

Wait, found them in target/aarch64-apple-darwin/debug/incremental

I wonder why cargo clean -p abiogenesis doesn't touch them 🤔

rm -rf target/aarch64-apple-darwin/debug/incremental/abiogenesis* solves the issue

[mellow flint]

huh, good to know

[quartz whale]

Might want to turn off incremental, it seems quite prone to breaking

[obtuse sparrow]

CARGO_INCREMENTAL=0 per https://doc.rust-lang.org/cargo/reference/environment-variables.html if you want to limit it to affecting the dx command without hard coding the config file. AFAIK separate builds with and without will generate non-overlapping intermediate artifacts and so use up more disk space than usual.

[fathom spruce]

How are y'all dealing with TypeId's changing between compilations when hot patching code? I'm doing something a bit different, but typeids not being stable has been a bit of a PITA.

[raven valley]

That's actually been a benefit for me

[fathom spruce]

wdym? When querying something and the typid changes, it will no longer match after a reload

[raven valley]

Yeah, but i dont wanna query for things that have been modified because their in memory repr will be dirfernet and cause a segfault.

So if u modify a component then the old ones sit around in memory not getting queried

Its an incredibly useful happy accident

[fathom spruce]

Unfortunately it means state for unchanged types that you want to query just doesn't work.

[raven valley]

hmmm, i don't actually run into that issue often 🤔 it doesn't change the type id on my machine unless the struct's inner fields change

i wonder why it's working differently on our computers

🤔

like, as proof here

[fathom spruce]

I'm seeing issues with things like stdlib typids changing

[raven valley]

https://youtu.be/fo6FXxeP0Wg?si=Ncito00p2srFVf2c&t=355

timestamped

i change the pipe's query direction and it, changes, its typeids don't change

none of them do that are accessed by the ecs through this whole video

[raven valley]

damn

[fathom spruce]

I'm working in a prod codebase with a more complex crate structure for a binary

idk if that is related

[raven valley]

ooo

maybe!

[fathom spruce]

I'm also dylinking other stuff to make sure other things don't break. It's great when it works, but it's super brittle and limited.

[languid sable]

@autumn lark what's the status of a stable type id alternative?

[autumn lark]

In terms of bevy_reflect or Rust in general?

For bevy_reflect I want to eventually move away from TypeId except as an optimization

Since they don’t really facilitate runtime-defined types well

And so far all we have that works well enough is TypePath

[languid sable]

for bevy_reflect 🙂

and thus bevy_ecs

[autumn lark]

Ah yeah just TypePath

It’s unfortunately not as lightweight or performant as TypeId though haha

[languid sable]

I guess we could cfg flag something that uses TypePaths exclusively for hot patching development workflows 🤔

[autumn lark]

We could help performance by precomputing the hash when deriving

Oh but we’d have to expose a way to get that in the trait 🤔

I wonder if we should instead rely on Type for things with TypeId being optional and an optional precomputed hash constructor?

[opaque lily]

Just tried out reflect auto registration with hotpatching - it seems to be working. Only needed to add running register_derived_types on hotpatch event.

[celest magnet]

Not sure if anything similar has been reported, but #hot failed for me on a system with more than 10 or more paramters.

[wide temple]

I've found that it leaks build artefacts as target/{target-tripple}/build/deps/{package-name}*, I've run out of disk space several time during the jam and found 100,000s of files in there

So now I've combined cleaning that out with starting the build which keeps it under control

[opaque mulch]

got it nuke the target folder every 20 min/j

[wide temple]

Not the whole folder, then you'll be building from scratch, just the files that start with your package name

I assume it's because the file name includes a hash of some kind that changes each build and never gets cleaned up

[obtuse sparrow]

cargo clean -p mybinary probably/hopefully looks in the target-triple subfolders too?

[wide temple]

It unfortunately doesn't

It cleans out target/debug/ instead

[obtuse sparrow]

must be a dioxus-supplied target dir argument, i guess

[wide temple]

Yeah I suspect so

[obtuse sparrow]

(which was a reasonable design decision, no criticism implied)

[wide temple]

It's actually quite hard to do anything but delete the enitre deps directly because there are so many files, file globbing stops working

[wide temple]

cargo clean --target-dir target/{target-tripple} -p {package_name} works

[ember venture]

fd -x using https://github.com/sharkdp/fd would likely work

[quartz whale]

I'm watching the RustNL talk on wild, and he mentioned that wild intends to support hot code reloading as well, which might make this even even faster, and also maybe more stable in some cases

[late stratus]

might be worth sending an issue to the dioxus repo about this, i couldn't find one just now

[wide temple]

Yeah there’s that and another one about par_iter causing sigbus faults, I just have been really busy at work since the jam finished. Hoping to get to it early next week

[wide temple]

It’s not a bug exactly, but there probably be a first party workaround for it

[late stratus]

ehhh, i think it'd be fine to consider it a bug. after all, ideally the same hash should apply for most hotpatch builds

[wide temple]

The blowup in size is entirely all the builds from your own package piling up, so it’s “working as intended”

I did have my project setup as a cargo workspace, maybe that’s the issue?

[lean wren]

subsecond doesn't support workspace i think for now ? there's a issue for it

[wide temple]

It worked for me all jam other than the space leak stuff

[quartz whale]

It has minimal support for workspaces, but only allows hotpatching of the top-level crate, not the other crates in the workspace

[wide temple]

What do you mean by top level crate?

[obtuse sparrow]

in a workspace you can also have a package in the workspace root / declared in the repo root Cargo.toml

[mellow flint]

In a nutshell, the crate that contains the main.rs

[calm basin]

I have a workspace working with hot patch, just needed to move the default member to /src/main.rs

Or I could be mixing my metaphors, there were a few issues with workspace support in the various tools 😄

[crude jackal]

That's a binary crate, not a top-level crate

[mellow flint]

fair 🙂

[mellow flint]

@languid sable you'll be happy about this: https://github.com/DioxusLabs/dioxus/pull/4155

[dire stone]

Very nice!

[languid sable]

@worldly ether thanks! Are you planning to spin this out into its own repo (no preference for Dioxus org or not) at some point BTW? Mild preference for it (mostly to avoid hammering your monorepo with tangential issues), but this is really encouraging

[worldly ether]

That's the goal, will likely end up moving dx entirely out once we can figure out how to untangle a few deps (like our rsx auto-formatter and rsx-hotreload).

the multi-platform build +hotpatch engine we have is pretty isolated to a few files which could also be split out into its own crate if there was a desire

[languid sable]

No immediate desire for that from our end, but other users might care.

We'd also be interested in reducing dependency count / weight for the CLI tool to improve time-to-first-hot-patch

[worldly ether]

the tool is quite fat (1200 deps) but I think 600 come from tauri-bundle :/

[languid sable]

Yeah 😦 Being able to split that out for the libs that don't need tauri would be good

[worldly ether]

I don't think they update that crate's cargo.toml frequently and there's lots of duplicates in the graph

[languid sable]

I love windows: give me more copies of windows

[worldly ether]

we want to move off of it anyways and do things like macos codesigning ourself

our team is interested in adding plugin support to dx and then just making the rsx stuff a plugin, but we haven't figured out distribution yet

[languid sable]

Ship it on Steam /j

Oh also @worldly ether, once you have a clean-ish code base and good docs for your hotpatching, you should request a meeting with the lang/compiler teams. They will be very interested in a) how it works and b) how they can make it better

[half pasture]

i think that would be optimal for us to integrate it into the bevy alpha cli thanks for all the effort!

if there are easy low hanging fruits maybe we can help too

[worldly ether]

The reason it's not the first approach is because the whole module is pretty monolithic and opionated and I'm sure folks will have many a comment on it haha

[ember venture]

(FYI: discussion on tauri-bundler also interacts with tauri-plugins, which contains a huge amount of functionality which I am keen to make available to the wider Rust ecosystem and which I believe currently depends on tauri's build system)

[fair knoll]

I could write an elaborate message but I've been sleep deprived for the past three hours with no real progress

All I can say is: help 💀

[mellow flint]

I see you’re on macOS, so I assume you did not change the linker or anything? macOS should not require any setup beyond installing the CLI.
@lone token do you think you could help?

[fair knoll]

Im on macOS but im using nix

So I’m provinging my own linker from nixpkgs @mellow flint

But it’s ld anyway

And cargo run works just fine, so the linker is working

Im just so frustrated due to the lack of an error 🥲

dx basically just says: fuck you, I don’t want to work

[fair knoll]

if I set the linker=ld in config.toml I get this instead

which I assume signals it is in fact using ld, but is now using unsupported params for the ld version

maybe I should be using another linker instead of ld on macos?

[mellow flint]

I think macOS uses ld64? Not sure

[fair knoll]

yes it does

however the binary is called ld

[fair knoll]

tried using lld

doesn't seem to work either

out of ideas besides dropping nix altogether for getting it to work

[mellow flint]

me too :/

[fair knoll]

is there really no way to get any more logs?

imma try to use gcc instead of clang idfk

and after that imma just give up at least for now

[mellow flint]

you can press v to get more logging, and there was also an "extra debug" level that I forgot the keybinding for. t for trace perhaps? d for debug?

Press / and you should see it in there

[fair knoll]

yeah, those just give me the run command, but no real error message besides the file not found

besides, if I was to pursue this

where should I even open the issue?

in the dioxus github?

[mellow flint]

yep

[fair knoll]

because it seems absoulutely on the side of dioxus, as bevy is working just fine

[mellow flint]

that's where subsecond issues currently go

put "Subsecond" in the title to make searching easier 🙂

Maybe ping @worldly ether

[fair knoll]

The output with tracing and verbose debug enabled

not helpful at all

yeah it gives me the env vars and arguments but...

these don't tell me anything weird either

[mellow flint]

heck

Yeah, looks like a bug then

[fair knoll]

the only thing that looks a bit weird to me is
"-Wl,-rpath,@executable_path/../Frameworks",

just because of the Frameworks folder

but Idk

everything looks sus to me at this point

[fair knoll]

https://github.com/DioxusLabs/dioxus/issues/4372

lets see if someone with forbidden knowledge happens to stumble upon the issue

[ember venture]

FWIW, the CLI not passing through error messages properly is on our radar. Ive also run into this quite a bit.

[fair knoll]

is there no workaround?

[west trail]

anyone know if there's a specific rust version that dioxus is happy with? i'm having problems getting it working on windows with latest stable or nightly

[west trail]

i've been deep diving in logs and such and there's just so many different forms of seemingly-catastrophic errors no matter what i try, for example:

emitted by dx serve --hot-patch:

Linker warnings: Linker error: 
lld is a generic driver.
Invoke ld.lld (Unix), ld64.lld (macOS), lld-link (Windows), wasm-ld (WebAssembly) instead

have tried fixing this one every way i could find (my project files and target dir are both just under C:\ root):

Build failed: I/O Error: The filename or extension is too long. (os error 206)

when running the exact cargo rustc command that dx is trying to run:

error: unrecognized subcommand '@C:\\Users\\Runi\\AppData\\Local\\Temp\\rustck9bk4I\\linker-arguments'\n\nUsage: dx.exe [OPTIONS] <COMMAND>\n\nFor more information, try '--help'.\n

when running the exact dx.exe linker command cargo's apparently trying to run:

error: unrecognized subcommand 'C:\Users\Runi\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\bin\rustc.exe'

[west trail]

ugh, actually nevermind, i figured it out. the argument list dioxus is passing to my rust-lld.exe is too long

35k characters is too much for windows

[quartz whale]

When looking at linker invocations for C++ I've seen them pass a .params file, which actually contains the parameters, maybe dx needs to do something like that?

[west trail]

yeah, you can see the windows equivalent up there error: unrecognized subcommand '@C:\\Users\\Runi\\AppData\\Local\\Temp\\rustck9bk4I\\linker-arguments'

still no idea why that error is there but if dx sent an @file instead of passing everything via Command::args then it'd probably work

workin on an issue

[calm basin]

I did a bunch of mucking about here https://github.com/DioxusLabs/dioxus/discussions/4249. Basically for those errors you need -Zshare-generics=n otherwise the linker command breaks. In the end all the limitations on the compiler settings meant it was much faster on windows not to hot-patch

ah sorry you also want codegen-units = 1 in your Cargo.toml

[ember venture]

I don't suppose you have a reference for how to do this? Seems like the obvious solution if supported.

Oh, looks like it's above

[ember venture]

@worldly ether Looks like this might be the solution for the windows command line length limit issue.

[quartz whale]

Looks like it's this in msvc: https://learn.microsoft.com/en-us/cpp/build/reference/linking?view=msvc-170#linker-command-files

[ember venture]

Thanks!

[pliant helm]

Pressing r to rebuild/restart is not reflecting changes I'm making inside startup systems. I end up having to restart dx serve entirely. Is this a known issue?

[quartz whale]

Yes, there's a lot of discussion on it, but it's becausr they only run on Startup, but when you hotpatch your code, you're not restarting it, so there's no reason they should be rerun. If you do want it to happen anyway you can search back in the history.
But it's usually better to for example spawn things when entering a certain State

[pliant helm]

No no, I'm not being that silly :p
I'm talking about restarting the app entirely. Even when the startup systems run again the changes I'm making are not reflected until I restart the dx serve command

Oh, curious. If I don't close the app and let the startup system get hotpatched, and then restart the app it works

Which means the so called "Full rebuild" is a lie :P

[quartz whale]

Oh, how do you rerun your startup systems? And just to check, do you have #[hot] on them?

[pliant helm]

I'm restarting my app, and I'm not using bevy_simple_subsecond_system at the moment. Instead I've cherry-picked Francois' PR onto 0.16.1

[languid sable]

Hey @jolly bone, I saw this comment on Reddit about difficulties getting hotpatching for egui working

We've had good luck, and if y'all have questions please feel free to reach out to us and/or @worldly ether for some advice 🙂

I think bevy_egui is working with hotpatching, but admittedly I never tried changing any of the egui code in my experimental project

[idle rose]

just a random question, I had the impression this whole hotpatching stuff is very experimental and easily breaks left and right. Is it really planned to be shipped on 0.17?

[opaque lily]

It's completely optional and I didn't have much problems (besides existing dx related ones) with the upstreamed implementation. Although inability to change system parameters makes it slightly less useful than bevy_simple_subsecond_system (with which I've had problems when I tried to integrate it with existing project)

[languid sable]

We won't get improvements unless people can start playing with it

Some features can be improved by engine devs alone, but this is not one of them

[idle rose]

makes sense, you can't imagine what people do with bevy

[worldly ether]

Just heads up, I'm changing how dx handles CARGO_MANIFEST_DIR and other cargo variables so the BEVY_ASSET_ROOT="." dx serve workaround will no longer be necessary

We will try to be as cargo-like as possible

[fair knoll]

Probably won't help with my problem, but that's great to hear ❤️

can't wait to have hot-reloading fully working

it literally obliterates one of the biggest pain ponits of rust

[worldly ether]

Once our release is out I'll also spin out dx/subsecond into its own repo - probably 2-3 weeks from now

[mellow flint]

very exciting! @weary vigil would that be enough to consider adding it to the CLI? 🙂

[languid sable]

FYI, around that time I'm going to want your review on our release notes about hotpatching ❤️

[mellow flint]

that's great to hear as well 😄

[half pasture]

i think that was one of the key points Tim was waiting for so there is a clear path on how we will integrate it

[mellow flint]

Summoning @loud narwhal

[loud narwhal]

I have been summoned

I mostly want to ensure that we use DX/sub second in a way that also works with the dioxus developers.
We should ask them how they want us to use it and how/where they want to be credited for their work!

At first, hot patching will likely be an unstable feature of the CLI, so I'm less worried about the technical side. We can probably hack around whatever interface is available to us :D

[worldly ether]

I think we might also release/maintain a smaller version of subsecond that's just the cargo subcommand, but I think you guys would just want the library format

[loud narwhal]

Especially at the start, either works!

[loud narwhal]

How would you and the team like to be credited?
In the UI of the CLI hotpatch interface, in the help output, in the CLI book, somewhere else?
Is there something else we should pay attention to when integrating sub second?

[worldly ether]

Good question, need to think about it. Probably just on a github readme or website somewhere. And mostly just want to lean into the subsecond name/brand more than dioxus so it's more neutral. Ultimately just want people to use it / integrate Subsecond so Rust itself is seen as a better choice for app/UI/game dev

[loud narwhal]

I'm definitely hoping that we can also give back to subsecond in the process if you are accepting contributions, so we can make it the best possible experience for everyone!

[mellow flint]

@worldly ether FYI I've directed people to always use words like "subsecond" or "hotpatching" in their issue descriptions so that you can better port them to the new repo in time 🙂

[loud narwhal]

I remember you were interested in the way we avoid modifying the cargo toml to add custom profiles etc, has that been implemented yet?
Otherwise I can take a stab at porting it over when I have time :)

[worldly ether]

Yes! Much nicer too

[loud narwhal]

@mellow flint is there an overview somewhere on what is needed to use subsecond with a Bevy app? Does it work out of the box or is some kind of configuration needed?

[mellow flint]

Our readme here: https://github.com/TheBevyFlock/bevy_simple_subsecond_system

Which could also be upstreamed. Last time I asked about it, the answer was "not yet, as it may change"

But I don't think it's going to change much

[mellow flint]

To be clear, upstreamed into the Bevy readme somewhere, or the Bevy book

[lone token]

it will be upstreamed as part of the release notes I think

[languid sable]

Open a PR to the new book please

[languid sable]

please no more docs in the release notes 😂

[mellow flint]

Can do, sec

[lone token]

I mean, in the process of writing the release notes, not necessarily in them

[languid sable]

oh lol

[loud narwhal]

Excellent!
I'm currently working on the web multi threading in the CLI, but after that I can take a look at the hotpatching. Definitely seems to have a huge impact!

[mellow flint]

Also, https://github.com/TheBevyFlock/bevy_simple_subsecond_system/pull/28 allows Wasm hotpatching

Might want to upstream that into Bevy

[mellow flint]

In which dir / section ?

[languid sable]

development-practices/hot-reloading

I'm planning to split that page by assets and code, since new users won't care about the difference

And I want to talk about when to use each one

[loud narwhal]

Would be kinda funny to get hotpatching before hot asset reloading on web apps lol

[languid sable]

Yes please to PR

[mellow flint]

Ping @haughty moon 🙂

[weary vigil]

Hmmm I just realized: if we release v0.4.0 without releasing a new version of the CLI, the CLI won't auto-install the latest version of the linter

Since right now we hardcode both the linter version number and Rust toolchain into the CLI

Ooo wait this is the wrong channel, sorry!

😅

[celest magnet]

Just FYI Egui (through bevy_egui) works flawlessly with hotpatching.

Tested it in a non trivial prototype with complex UI.

[dire stone]

Yeah immediate gui is kind of the subsecond posterchild, as it is "stateless" / "just works"

[pliant helm]

Speaking of immediate mode. That made me realize we have a greater motivation now to add a way to access Gizmos without needing to add a system parameter, since bevy now supports hot reloading the bodies of systems

A bit too late in the release train to add now, but should be perfectly doable as a third-party crate for 0.17

[late stratus]

Does the main branch version of hotpatching somehow exclude systems which are scheduled for OnEnter(SomeState::Blah)? I've been trying to use switching between states on EventReader<HotPatched> to hot-patch and re-run setup systems, (with DespawnOnExitState) and while the setup function runs, none of the hot-patching changes seem to get applied, even after multiple hot-patches (in case somehow the state switches before hot-patching applies)

Ohhhhhhh i think i figured it out. Hotpatching only happens if the event exists the same frame the system runs

that means that not only does it not work for my state transition system, because it seems the event doesn't persist long enough, but also it won't work, or at least won't work consistently, with any kind of system which doesn't run each frame.

i'm gonna fix that, i'm quite sure i already know how

[late stratus]

okay update: i was somwhat wrong. Hotpatching seems to happen before its decided whether a system should run. What isn't beeing handled is when a whole Schedule isn't run for long enough for the events to disappear

[lone token]

yup, systems check themselves if they have been hotpatched, but to avoid doing it for every system every frame there's a tiny cache... I though I covered most cases where it needs to be invalidated, seems you found one I forgot

[languid sable]

🎟️

[late stratus]

I just got my fix working (after having to do something else for a bit) - PR incoming. (i'm using changed ticks to check for the need to update instead of the event)

bonus with doing i this way: observers don't need to patch themselves every run anymore

[late stratus]

actually gonna have to delay a bit i found another place hotpatches weren't being applied: World::run_system_with

[late stratus]

PR done: https://github.com/bevyengine/bevy/pull/20202

nice number, 20202

[lone token]

@late stratus I don't know why CI is stuck on your PR... but there's a conflict with main, do you mind fixing it and pushing that to see if it triggers CI?

love your idea to use a resource! I was out most of the day but after your message I thought about using ticks manually, change detection is even better

[late stratus]

oh i know what happened, i usually have origin as my fork and upstream as the main project, but in this case i didn't do that

so i was accidentally on a really old commit

[late stratus]

welllll i kinda have to at least check it manually as basically everywhere the checks happen is outside the context of a system

[mellow flint]

@restive geode neat state retention you got there 🎉

[restive geode]

Thanks!

[warm thistle]

i gasped when i saw the checkbox stay checked

[open flicker]

Hello! I was redirected here from another thread. So, I copied the example from https://github.com/bevyengine/bevy/blob/main/examples/2d/tilemap_chunk.rs to a local project using: ```toml
[workspace.dependencies.bevy]
git = "https://github.com/bevyengine/bevy"
rev = "f858c0d"
features = [
"hotpatching",
"default_font",
"wayland",
"dynamic_linking",
"file_watcher",
]

running via `dx serve --hot-patch` I get: `00:41:02 [linux] 2025-07-22T22:41:01.501377Z ERROR bevy_asset::server: Path not found: /home/mogambro/projects/game_dev/test_bevy_017/target/dx/test_bevy_017_client/debug/linux/app/assets/array_texture.png` Should this be fixed in the commit mentioned above? Or is that a known problem?

It's a workspace project (!)

Works fine if I do BEVY_ASSET_ROOT=/home/mogambro/projects/game_dev/test_bevy_017/client dx serve --hot-patch

[warm thistle]

@open flicker seems like this is going to be fixed soon. although otheres can speak to whether the current workaround works for workspace projects

[open flicker]

It's wonderful that's actually working for me... great work to everyone involved! I am using the mold linker and for dioxus the hotpatching didn't work on my archlinux system 😄

maybe they fixed it on their side as well, gotta try. But I wasn't expecting it to "just work" here... absolutely fantastic!

[worldly ether]

Most recent alpha (0.7.0-alpha.3) should have the cargo emulation stuff merged. I think you might be able to drop the BEVY_ASSET_ROOT override now

[mellow flint]

thanks! I don't have time to check it right now, but this is great news 😄

[fair knoll]

Imma try the new alpha just in case the issue with nix-darwin got resolved

magically

aight compiling, here goes nothing

heh

🥲

I hope I can troubleshot this whenever the logging of errors gets enhanced

[worldly ether]

Turn on verbose or tracing mode

I hid cargo build script error output in alpha 3 but just undid that since it started swallowing too many errors

[fair knoll]

it has been like that in alpha 2 too

with verbose and tracing the error is basically the same

it just tells me the arguments to the link command and what the environment variables were

but that's it

oh wait

you are actually right, there's some error now

this wasn't here in alpha 2

[worldly ether]

Is the code for the problematic project public?

[fair knoll]

yeah, not a problem, although I highly doubt this problem is related to my project code

it is a single main file with some bevy systems

it is surely related to nix

[worldly ether]

what OS are you using?

ah

[fair knoll]

Nix in MacOS

the problem is 100% due to nix providing the linker

instead of it being the one that comes bundled with the OS

[worldly ether]

is the "cc" env var set for you?

[fair knoll]

it should be yeah

let me check the logs

yup

there it is

[worldly ether]

we do enable linker logging in trace mode, you might see some warnings from clang somewhere

[fair knoll]

🤔 somewhere?

[worldly ether]

in the dx output, we emit warnings from the linker

[fair knoll]

let me try to find "WARN"

[worldly ether]

is clang in your path? derp yes it is

[fair knoll]

yeah haha

I've been through the easy steps already

but I'm down to trying them again 😂

no warnings from the linker it seems

this is the whole execution output

all I see are warnings from my own project

and btw I'm pretty positive this error is going to happen with any MacOS nix user

so I'd love to try solving it

[worldly ether]

RUSTFLAGS=-Zshare-generics=y
hmmmm can you try disabling this?

[fair knoll]

the recompilation is gonna take a bit

but yeah ofc

this is my config.toml

iirc these come from bevy recomendations

[worldly ether]

apple's built-in linker (ld64) is quite fast, might not need to use clang

[fair knoll]

imma try to set it up to use ld then

[worldly ether]

direnv: export +AR +AR_FOR_BUILD +AS +AS_FOR_BUILD +CC +CC_FOR_BUILD +CONFIG_SHELL +CXX +CXX_FOR_BUILD +DEVELOPER_DIR +HOST_PATH +IN_NIX_SHELL +LD +LD_DYLD_PATH +LD_FOR_BUILD +MACOSX_DEPLOYMENT_TARGET +NIX_APPLE_SDK_VERSION +NIX_BINTOOLS 

etc

some of these flags (ar, cc, nm, objcopy) could be overriding the ones that get autoselected by clang

what are the logs at the end of the cargo build? I don't see anything regarding the "fat link" phase

with --trace enabled (or press t) you should be able to look for:

Output from fat linking:

in the dx output

[fair knoll]

sorry I had to leave for a second

I'm compiling with linker="ld" now without any flag

if the output is still the same Ill try clearing the environment first

🙂

[fair knoll]

regarding this... I don't think I've seen anything else

but Ill check now

with linker="ld"

in config.toml

I get an error regarding the use of -Wl, -force_load

just made an empty project and the error is in fact the same yeah

now I can compile instantaneously

okay on a completely empty dependencyless with clang I'm getting this

00:36:48 [dev] Failed to generate fat binary: ld: file too small (length=0) file '/Users/aitor/personal/mad-birbs/dioxus-cli-test-nixdarwin/target/aarch64-apple-darwin/desktop-dev/libdeps-7b790ad9.a' for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation)

as soon as I add any library (rand in this case) to the project we're back to the original error

so lets asume that's an edgecase for an empty project

[worldly ether]

force_load is a flag that ld should have... if I man ld I can find the force_load flag in the help menu. what ld are you using? you can use ld -version_details to get this output:

❯ ld -version_details
{
    "version": "1167.4.1",
    "architectures": [
        "armv6",
        "armv7",
        "armv7s",
        "arm64",
        "arm64e",
        "arm64_32",
        "i386",
        "x86_64",
        "x86_64h",
        "armv6m",
        "armv7k",
        "armv7m",
        "armv7em"
    ],
    "lto": {
        "runtime_api_version": 29,
        "static_api_version": 29,
        "version_string": "LLVM version 17.0.0"
    },
    "tapi": {
        "version": "17.0.0",
        "version_string": "Apple TAPI version 17.0.0 (tapi-1700.0.3.4)"
    }
}

[fair knoll]

a bit older than yours it seems

[worldly ether]

don't set a linker at all, just let the the system do its thing. technically you can't use ld directly as a linker - it has to go through clang

[fair knoll]

that just takes us back to square one

imma try to clear env vars one by one and see if something sticks

[worldly ether]

the error is probably happening a little bit earlier than that

or collect_assets is failing in some weird way

[fair knoll]

if it's happening earlier there is no output about it

that's for sure

[worldly ether]

you can skip asset collection with --skip_assets true

[fair knoll]

ill try that now too

[worldly ether]

oh, you might not have codesign in your path?

[fair knoll]

im setting it up as minimal as possible in order for a reproduction to be viable

[fair knoll]

it is probably not in my path

is that needed?

[worldly ether]

on apple-darwin it usually is. dioxus collects assets from our manganis crate by walking custom entries emitted by linker sections, but if you aren't using our asset system you don't need to run that particular step. codesign is used to properly adhoc sign the binary after we've updated the metadata in the binary

[fair knoll]

HOLY SHIT

THAT WAS IT

[worldly ether]

I can add a check that disables it

[fair knoll]

I would have probably died before arriving to that conclussion

fuck me

how did you man

[worldly ether]

usually we check if tools exist before using them but with mac-only tools we are a bit looser with it

wonder why nix doesn't ship with codesign in the path

[fair knoll]

yeah because usually mac users aren't as autistic as I am

I mean, codesign is in fact in my mac zsh og path

but in order to not have anything outside of nix interfere with my shells and environments

I unset everything that mac provides

and just add it wherever I need it

it's kind of the nix mindset

always start from 0 and don't assume you'll have something

[worldly ether]

your entire /usr/bin should be in path though

which codesign is /usr/bin/codesign for me

[fair knoll]

not in nix

I mean yeah I could

but then I would have to deal with programs using binaries that I havent declared

just like rn

if this hasn't happened dioxus-cli would be using an undefined version of codesign

now I know it will use the one I provide it

and it's explicitly declared as so

[worldly ether]

I mean we could also just manually specify /usr/bin/codesign so I don't really see the purpose

[fair knoll]

yeah that's the problem that usually hapens

[worldly ether]

just seems like it makes life harder to unset system tools from path

[fair knoll]

when programs hardcode paths things break

[fair knoll]

at times yeah it makes life harder

but the reward is that

when something works

it will work forever

on any machine

sorry pal, I dont want to try to sell you my nix agenda

just commenting since it's relevant to the point in question

🙂

Imma try and see if now it's working with the previous flags

[fair knoll]

and btw, for me it is:

because nix is providing the executable for my environment 😀

it is working 🥰

thank you so much @worldly ether

I'll close the issue I opened in github and provide what was needed for it to work

as this will probably happen to someone else in the future

🙂

and maybe try to be a bit more descriptive with the missing dependencies in the errors?

[worldly ether]

I'm working on a PR that adds two things

• better error messages about tools not being in path
• and then calling "which" on all the tools we call out to in dx doctor to make it easier to debug

[fair knoll]

it would help people not pull all of their hairs off their head, or at least not give up on trying out the lib ❤️

[fair knoll]

that sounds amazing

[fair knoll]

that IS amazing

it's going to help so many people

mostly in unusual setups like mine

https://github.com/DioxusLabs/dioxus/issues/4372

issue resolved 🙂

[fair knoll]

btw @worldly ether the hot-patching seems to fail if I do not pass the --skip-assets param that you mentioned here

don't know if that's also due to my setup

however with that param it works perfectly

[fair knoll]

just saw the latest PR with the PATH changes, you're the goat 😀

[mellow flint]

While we are chatting about problems, I believe that mold is still not supported quite correctly. Want some logs, Jon?

[worldly ether]

Sure, if you have them. I had sold installed at some point but never tested it out

[cold anchor]

hello sir did you find a way to do this

[raven valley]

hello individual who i have no known prior connection with

nah it's not possible well yet

[cold anchor]

rip

[raven valley]

the best you can get is my thing where i build a new schedule

and swap out the schedule everytime

std::mem_swap

it's in the .with_hotpatch closure

anything added to Update has that magic done to it

there is work on that front however! not finished yet but work is being done to make schedules more, dynamic and editable

[cold anchor]

so you build a new Update schedule with the changes and mem swap it in?

[raven valley]

well

specifically i create a new schedule

[cold anchor]

is that something you clone and edit or uh, idk how these things work

[raven valley]

called HotPatchUpdate

and i create a new app inside the hotpatch closure

and i take all the things added to update

and i swap out the original apps HotPatchUpdate with that

and then i run hotpatchupdate inside of the original app's update

the code to do so is open source

[cold anchor]

ah ok

[raven valley]

https://github.com/TheBevyFlock/bevy_simple_subsecond_system/blob/main/src/hot_patched_app.rs

this file is where it goes down

it's a bit complicated to work around limitations

but it works!

pretty well

[cold anchor]

I see I see, wild solution lol cool that it works

[raven valley]

[open flicker]

Bah, I need to check whether using another linker but mold actually works.

Because it turns out: when I started with hot patching bevy it worked like a charm out of the box, despite being on archlinux and using mold as my default linker. But some changes later I can't get it to work on the same project anymore, even if I clear my target folder and remove all .cargo/cache stuff.

Incredible tech with some rough edges to smooth out

[fair knoll]

working with linkers is a PITA

if you're willing to use nix (not the distro but the package manager) you can probably get it to work pretty easily in archlinux @open flicker

some guy commented on this channel that he made a shell for it in linux

I've got mine but it's for MacOS and I'm not sure what could be missing in linux

[late stratus]

1. how did you set up mold as the default linker before?
2. what did you try for -fuse-ld= in you rustflags?

[pallid dragon]

#[hot(rerun_on_hot_patch = true)] is not working correctly for me I think. It doesn't despawn anything that's being spawned inside that function (should it?). I keep on getting inconsistent states. It seems that after some hot reloads things might actually be cleared but that makes it less usable than not using it at all.

[open flicker]

In my .cargo/config.toml like so ```toml
[target.x86_64-unknown-linux-gnu]
linker = "clang"
rustflags = ["-C", "link-arg=-fuse-ld=/usr/bin/mold"]

[mellow flint]

Nope, it just reruns the system. Nothing is despawned for you. Also, that option breaks all Local, so we didn’t upstream it

[late stratus]

hmm aight, that looks like it should work

[open flicker]

mold isn't officially supported the last time I checked. It was with dioxus itself though and there were open issues.

[late stratus]

you shouldn't need the full path in -fuse-ld

thats part of what i fixed when i PRed dioxus to actually use -fuse-ld

[open flicker]

may be, I haven't touched my Cargo config.toml in months 😄

[half pasture]

Tried hotpatching for the first time yesterday because i needed to do some ui work and its such a gamechanger. Doing ui no longer feels as exhausting! Thanks a lot for all the effort cant wait for 0.17 where its also built in

Workspace support would be super neat so i dont have to create a „ui development“ project but regardless its so neat!

[hushed wave]

I suggest making a function in main then just shoving everything like a module (but inside a function)
with the top level function taking in world, using world.run_system_cached then world.flush() to run normal functions until you have it battle tested

[celest magnet]

Will hotpatching still be possible for systems that run on startup/enter state?

In the crate currently we can do: #[hot(rerun_on_hot_patch = true)]

but I coudln't find anything in bevy 0.17 yet

[lone token]

startup, no
on enter, kinda. you can make a system that reacts to the hotpatch event to re-enter the state

you can hotpatch that system if you change the state you work on often 😄

or make something generic that reads the current state I guess

the Bevy built in hotpatch doesn't introduce anything new

[celest magnet]

so the crate will still work after 0.17 for those which use it?

[lone token]

maybe with some updates, but I don't see why not

[celest magnet]

Is it known that a hashmap creation in a hot patches system crashes bevy with a

Application [macos] exited with error: signal: 10 (SIGBUS)

(Its currently also the case on current bevy main)

for example:

fn update_text(mut text: Single<&mut Text>) {
    // Anything in the body of a system can be changed.
    // Changes to this string should be immediately visible in the example.
    let mut hashmap: HashMap<String, String> = HashMap::new();
    hashmap.insert("cat".to_string(), "meow".to_string());

    text.0 = format!("times");
}

this crashes when a hot reload happens for me on MacOS.

Haven't tested yet on linux.

[trim quest]

so is it the heap allocation, the hash rng, or something else 😅

[celest magnet]

would a vec! go on the heap as well?

[trim quest]

yes if you put something in it

[celest magnet]

ok let me check

[trim quest]

I think to_string() is also doing an allocation fwiw
(it would be pretty surprising if that was the issue unless the hot reloaded allocator was different than the initial one)

[celest magnet]

Vec with string seems fine

[trim quest]

Which HashMap is this?

[celest magnet]

std::collection::HashMap

[trim quest]

Could try just:

use std::hash::{Hash, Hasher};
let mut s = std::hash::DefaultHasher::new();
("test").hash(&mut s);
let h = s.finish(); // Do something with h if you have opt so the compiler actually runs this code

Are you running in debug or release, with or without opt?

[celest magnet]

running debug,

running the hotpatching_systems.rs example with the indicated:

dx serve --hot-patch --example hotpatching_systems --features hotpatching

[celest magnet]

    use std::hash::{Hash, Hasher};
    let mut s = std::hash::DefaultHasher::new();
    ("test").hash(&mut s);
    let h = s.finish();
    text.0 = format!("timsesss {}", h);

this works without issue

[trim quest]

does RUST_BACKTRACE=full show anything?

[celest magnet]

It doesn't crash when I actiavet that

How can RUST_BACKTRACE=full prevent the crash?

ok got it crashing

[trim quest]

hmm.. maybe it's not actually related to the hashmap and it's a system ordering ambiguity thing or some other UB

[celest magnet]

Up to now its the only time I had issues with hotpatching, still have only tested it on MacOS for now.

Ok just tested on linux, and it seems it don't get the same error.

[celest magnet]

Tested now also on Windows, and up to now could not reproduce it.

Ok good news is even on mac if I replace std::collections::HashMap with use bevy::platform::collections::HashMap; I don't get the crash (on MacOS).

[celest magnet]

Found an interesting workaround for re-running systems which are scheduled for startup/OnEnter.

pub fn system_for_testing(
    mut commands: Commands,
    mut hot_patch_event: EventReader<HotPatched>,
    hot_reloads: Query<Entity, With<DestroyOnHotReload>>,
) {

    for _ in hot_patch_event.read() {
        debug!("Hot reloading");
        for hot_reload in hot_reloads.iter() {
            commands.entity(hot_reload).despawn();
        }
        let system_id = commands.register_system(show_end_combat_screen);
        commands.run_system(system_id);
    }
}

This allows me to prototype and experiment with UI etc. even without the #[hot(rerun_on_hot_patch = true)].

[idle rose]

it still would be nice if you could reliably trigger the error and document it enough for others to do so this can be investigated

[celest magnet]

Was ab out to write down the issue and after a fresh restart I can't reproduce it anymore.

So not sure it is helpful at the current time to create an issue, if I can't reproduce it anymore?

[idle rose]

yeah if you cannot reproduce it there is no point

[idle stone]

you should be able to do commands.run_system_cached(show_end_combat_screen) instead of register followed by run?

[celest magnet]

If I did that, it will run the previous system

[idle stone]

ah okay, i see

[celest magnet]

(like before the hotpatch)

[idle stone]

need to force a re-register

[celest magnet]

Wonder if that should be also added to the hotpatch sample.

Its a very common usecase, especially for UI, scene setup etc. 🤔

[idle stone]

would be cool if you could mark the one-shot system entity with DestroyOnHotReload as well, to avoid leaking an entity with each hot patch

not that that's a big deal imo

i think commands.entity(system_id).insert(DestroyOnHotReload) would work EDIT: or system_id.to_entity() or w/e

[celest magnet]

would unregistering the system destroy the entity?

[idle stone]

yes

currently iirc unregistering == despawning

[celest magnet]

Maybe that would be more ergonomic? I can see it either way 🤔

[celest magnet]

let system_id = commands.register_system(show_end_combat_screen);
commands.entity(system_id.entity()).insert(HotReloadCombat);
commands.run_system(system_id);

the good part about this is that you don't need to keep a local var etc. so that feels better.

[lean wren]

hello ! is there a tracking issue for workspace support ? is there a workaround ? thanks

[mellow flint]

There’s an issue on the Dioxus repo IIRC, and I'm not aware of a workaround besides not using workspaces

I personally have a dedicated separate project for UI prototyping with hotpatching support

[lean wren]

couldn't find it

[lean wren]

I'll do a UI prototyping project then yeah thanks

[mellow flint]

hmm you're right, I must have misremembered

[lone token]

there's https://github.com/DioxusLabs/dioxus/issues/4160 that's the same problem

[late marsh]

oh thats why hot reloadings not working for my dioxus UI.. >.>

[scenic pond]

when bevy/embedded_watcher feature is enabled, this happens

01:55:11 [linux] thread 'notify-rs debouncer loop' (284400) panicked at /home/username/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/bevy_asset-0.16.1/src/io/file/file_watcher.rs:56:9:
01:55:11 [linux] FileWatcher::get_asset_path() failed to strip prefix from absolute path: absolute_path=/var/home/username/RustroverProjects/asdfghjkl/././.idea/workspace.xml, root=.

[lean wren]

hello !
i have this ~/.local/share/cargo/config.toml

[unstable]
codegen-backend = true

[profile]
incremental = true

[profile.dev]
codegen-backend = "cranelift"
debug = "line-tables-only"

[profile.dev.package."*"]
codegen-backend = "llvm"

[profile.test.package."*"]
codegen-backend = "llvm"

[profile.release]
codegen-backend = "llvm"

[profile.web]
codegen-backend = "llvm"

[target.x86_64-unknown-linux-gnu]
linker = "clang"
rustflags = [
  # "-Clink-arg=-fuse-ld=lld",
  "-Clink-arg=-fuse-ld=mold",
  # "-Clink-arg=--ld-path=wild", # not compatible with dioxus hot reload
  # Nightly
  "-Zshare-generics=y",
  "-Zthreads=8",
]

for faster compile time.
works well on development, but it doesn't work when doing a debug wasm32-unknown-unknown build as cranelift doesn't support wasm.
i tried adding

[profile.dev.target.wasm32-unknown-unknown]
codegen-backend = "llvm"

but didn't work, its still using cranelift.
is there a way to make the two setup co exist ?

[mellow flint]

Yep: https://gist.github.com/janhohenheim/5731c11e91736bab5e9ef58c2a982c36

[lean wren]

thanks. its just using the web profile instead of using dev profile ?

[obsidian pebble]

Ever have problems with this profile?

[mellow flint]

Oh yep, sorry forgot to tell you about that detail. This uses the Bevy CLI alpha, which uses the web profile when running bevy run web

[mellow flint]

Hotpatching is flaky with mold. So I temporarily disable mold when using subsecond. Other than that, the config works for me 🙂

[lean wren]

oh but im using wasm-pack, i can't use a custom profile with it if using wasm-opt

[worn spear]

That is the primary reason why I changed away from wasm-pack

[lean wren]

how do you build your app and import it in a website ?

[mellow flint]

bevy build web --bundle

[lean wren]

ohh didn't know bevy cli added that :) super cool, ill try to migrate to it, wasm-pack is mostly abandoned.

[mellow flint]

Come say hi in #1278871953721262090 if you run into issues 🙂

[obsidian pebble]

Should sccache work in dev mode with your config? Seems to not make cacheable artifacts when I look at sccache stats output

[mellow flint]

yeah can confirm that I never got it to work properly

But, like, in general with Rust 😅

So I have it enabled as a "hmm maybe it does something idk"

but yeah good point

I should probably remove that line

[obsidian pebble]

I think I read sccache cant cache incremental

Release builds look like they are more cacheable

[late stratus]

yeah, i have repeatedly said that sccache does nothing for this but just never bothered to make a pr to remove it...

[gray heath]

Hello, sorry if this is the wrong place to ask, but I cannot get the bevy hotpatching_systems example to work for me.
I only did git clone https://github.com/bevyengine/bevy.
Running it is fine, but when I edit the file and it tries to rebuild I get an error. What am I doing wrong?

[open flicker]

Could it be, that you have to set BEVY_ASSET_PATH or BEVY_ASSETS before? (Same line of dx command)

That's what I have to do locally for my project

Can't check right now, what the env variable is called.

[toxic light]

Hi, quick question: Does the subsecond crate really guarantee subsecond hot reloads or is it just the name and reloads will take longer with bigger projects?

[half pasture]

Its the name its no guarantee

maybe @mellow flint has some experience with how it scales with bigger projects

[mellow flint]

It takes longer the bigger your project is. So I use it with a dedicated slim UI prototyping project. There, I really do get subsecond reloads (800 ms), but I also have a fairly powerful setup

[gray heath]

I'm not sure what would I set it to in this case as the example is a single file, so I'm assuming ./examples/ecs/ is fine.
Setting BEVY_ASSET_PATH produced the exact same output line for line.
Setting BEVY_ASSETS changed the output very slightly, it now has a new "Ignoring file change" before the cargo execution and build completion messages, however, the rest of the output was still the same.

[idle stone]

it heavily depends on your CPU as well

[late stratus]

also, on other compile time optimisations. you should look at the example .cargo/config.toml in the bevy_simple_subsecond_system repo

[open flicker]

We are talking about this one, right? https://github.com/TheBevyFlock/bevy_simple_subsecond_system/blob/main/.cargo/config_faster_builds.toml @late stratus

[mellow flint]

Yeah just ignore the sccache line

[gusty patio]

Can someone give me a rundown of how to use hotpatching?

I've installed dioxus-cli, enabled the hotpatching feature, but I can't get it to run (with dx serve --hot-patch and then I tried also BEVY_ASSET_ROOT="." dx serve --hot-patch), getting an issue about failing to open a file (no idea what file it's trying to open), and then an error about application exiting with status 1

[gray heath]

Just for completion, I did manage to solve the issue, I got my answer from this:
https://users.rust-lang.org/t/cannot-find-ld-when-using-lld/47420

So after doing sudo ln -s /usr/bin/ld /usr/bin/ld.lld I managed to finally run the bevy example

[gray heath]

Maybe try what I just tried

I managed to run the bevy /examples/ecs/hotpatching_systems.rs after a fresh clone with:
dx serve --hot-patch --example hotpatching_systems --features hotpatching

[lean wren]

log pls

maybe strace or ltrace i dont remember which one to see which file is being opened

[gusty patio]

So something like
strace dx serve --hot-patch?

I'll try that later today

[indigo arch]

What's the limitations on workspaces for 0.17 for this?

[gusty patio]

I cannot use strace

I literally do not have enough disk space to hold the log file

[lean wren]

lol, maybe the low disk space might be why dx fails

use grep to filter only the "open" calls to not have a lot of logs

on my side the strace dx log is 16K

how do you not have enough space

[gusty patio]

I ran it for about a minute before killing it and the log was already 250MB

Update: I am a moron

So here's the log file:

Now...

because I am absolutely stupid

I put it at the workspace root

I looked at the trace if there's anything useful I could send here and I found out

that 99.9% of the file is just the following syscall over and over forever:

statx(AT_FDCWD, "[workspace]/trace.txt", AT_STATX_SYNC_AS_STAT, STATX_ALL, {stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=[number that goes up], ...}) = 0

it entered an infinite loop of checking for changes on a file that changes whenever it looks for changes in a file

Anyway this is the terminal output:

19:35:28 [dev] -----------------------------------------------------------------
                Serving your app: bevy_cycle_permutation_puzzle! 🚀
                • Press `ctrl+c` to exit the server
                • Press `r` to rebuild the app
                • Press `p` to toggle automatic rebuilds
                • Press `v` to toggle verbose logging
                • Press `/` for more commands and shortcuts
               ---------------------------------------------------------------- 
19:37:03 [dev] Build completed successfully in 95181ms, launching app! 💫 
19:37:04 [linux] Could not open : No such file or directory (os error 2)
19:37:04 [dev] Application [linux] exited with error: exit status: 1 
╭──────────────────────────────────────────────────────────────────────────────── /:more ╮
│  App:     ━━━━━━━━━━━━━━━━━━━━━━━━━━  🎉 96.5s     Platform: Linux                     │
│  Bundle:  ━━━━━━━━━━━━━━━━━━━━━━━━━━  🎉 0.3s      App features: ["dev_native"]        │
│  Status:  Serving bevy_cycle_permutation_puzzle    Server at: no server address        │
╰────────────────────────────────────────────────────────────────────────────────────────╯

I believe this is the trace of the problematic call

Now I just gotta find what file descriptor is 24

ohhh

nvm 24 seems to be tty

UPDATE:

I am even bigger dum dum

So the failure was caused by the app crashing on startup

or well, it exited with code 1

Now the reason is that our application has a special switch, and if it's provided command line arguments, it does something other than just starting the game

now, for whatever reason, starting the game with dx serve causes it to recieve two arguments:
first argument is the application name
second argument is an empty string:

19:52:57 [linux] Could not open : No such file or directory (os error 2)
19:52:57 [linux] Args { inner: ["<target_folder>/dx/<long path to app>", ""] }

Since the second argument is usually a level that is supposed to be loaded for testing, it likely causes an error therein

I have no idea why the app recieves an empty string argument though.

[lean wren]

yeah i had the same issue about dx passing a empty arg to the binary. i added --args='-a' to the dx command to pass a real arg instead of empty. in my case -a is just auto connect to local server, which i use in development anyway

dunno if its a bug or intentional ?

[worn spear]

It is a bug, and it was easy to fix: https://github.com/DioxusLabs/dioxus/pull/4695

[gusty patio]

Awesome, thanks.

[languid sable]

https://github.com/bevyengine/bevy/issues/21264

[languid sable]

https://github.com/bevyengine/bevy/pull/21368

[celest magnet]

hotpatching worked when I used subsecond + cranelift, but with bevy 0.17 I get the following error:

[cargo] error: #[link_section = "__mod_init_func"] is not supported: unsupported section type mod_init_funcs

had anyone a similar issue?

[celest magnet]

It seems to have been reported already:

https://github.com/bevyengine/bevy/issues/20785

So my compile times went from sub 1s to over 10s... I guess I have to stay on 0.16 until that is resolved, unless there is a workaround?

[celest magnet]

I managed to use cranelift if I disable the default features of bevy-reflect.

But I did not manage to get the bevy types to register.

I have the follwoing cargo.toml:

bevy = { version = "0.17", default-features = false, features = [
    "std",
    "async_executor",
    "android-game-activity",
    "android_shared_stdcxx",
    "animation",
    "bevy_asset",
    "bevy_audio",
    "bevy_color",
    "bevy_core_pipeline",
    "bevy_post_process",
    "bevy_anti_alias",
    "bevy_gilrs",
    "bevy_gizmos",
    "bevy_gltf",
    "bevy_input_focus",
    "bevy_log",
    "bevy_mesh_picking_backend",
    "bevy_pbr",
    "bevy_picking",
    "bevy_render",
    "bevy_scene",
    "bevy_image",
    "bevy_mesh",
    "bevy_camera",
    "bevy_light",
    "bevy_shader",
    "bevy_sprite",
    "bevy_sprite_picking_backend",
    "bevy_sprite_render",
    "bevy_state",
    "bevy_text",
    "bevy_ui",
    "bevy_ui_picking_backend",
    "bevy_ui_render",
    "bevy_window",
    "bevy_winit",
    "custom_cursor",
    "default_font",
    "hdr",
    "ktx2",
    "multi_threaded",
    "png",
    "reflect_auto_register_static",
    "smaa_luts",
    "sysinfo_plugin",
    "tonemapping_luts",
    "vorbis",
    "webgl2",
    "x11",
    "wayland",
    "debug",
    "zstd_rust",
    "hotpatching",
    "experimental_bevy_ui_widgets",
    "experimental_bevy_feathers"
] }

main.rs

fn main() -> AppExit {
    bevy::reflect::load_type_registrations!();
    my_game::run()
}

and a lib.rs

pub fn run() -> AppExit {
    App::new().add_plugins(AppPlugin).run()
}

and I set the env variable:

[env]
BEVY_REFLECT_AUTO_REGISTER_STATIC = "1"

is there anything else needed?

[elder heart]

I've never gotten mold to work across two machines running linux

same error:

 mold: ./elf/output-chunks.cc:1766: void mold::elf::DynsymSection<E>::copy_buf(mold::elf::Context<E>&) [with E = mold::elf::X86_64]: Assertion `esym.st_bind != STB_LOCAL || i < this->clang: error: unable to execute command: Aborted (core dumped)

huh. maybe it's cuz my mold is old

[opaque lily]

There should be a new subdirectory in target with all type registrations in that case. If it didn't appear try cargo clean and compiling again. That being said, I don't known if the static approach works with hotpatching and also it puts a lot of pressure on the linker which will probably dwarf any wins you get from cranelift anyway.

[opaque lily]

I've managed to make mold work, but it did require getting a newer version

[elder heart]

mold -> mnew solved it

[celest magnet]

There is a new subdirectory, but only for the types I defined, the bevy types seem not to be created. (Like Transfrom, GlobalTransform, Children)

And even if I run it without hotpatching the bevy types aren't there.

[opaque lily]

cargo clean and recompile should generate those types then

[celest magnet]

I have run cargo clean multiple times, still with the same result 🤔

[opaque lily]

is BEVY_REFLECT_AUTO_REGISTER_STATIC = "1" available at the time everything is compiling? Does BEVY_REFLECT_AUTO_REGISTER_STATIC=1 cargo build --features bevy/reflect_auto_register_static work?

Also I guess I'd recommend not disabling the default reflect_auto_register but instead just compiling with reflect_auto_register_static feature enabled, which will override the first one.

[celest magnet]

I created a simple repro:

https://github.com/occuros/bevy_0_17_type_registry

if I run the bevy for auto registration example from the bevy repo it works as expected.

But if I create a new project, the bevy types aren't registered somehow.

[opaque lily]

The only difference I see is that reflect_auto_register_static is defined in Cargo.toml instead of as an arg. Maybe it's because rust-analyzer gets to it first (which runs without the env var)?

[celest magnet]

I tried with both, passing it as an arg, and how it is now, both result in the same, children and global transform don't exist but the ones from the project work.

[opaque lily]

Is this with ra active? If yes, maybe try cargo clean and cargo build without it?

[celest magnet]

ra?

[opaque lily]

rust-analyzer

[celest magnet]

I build both in the same way, how would I disable the ra?

[opaque lily]

In vscode it's "stop server" command, in other ides I'm not sure

[celest magnet]

same result, on your machine you have children and globatransform working?

(if you clone the repo)

[opaque lily]

Doesn't seem like it. Weird, it should work

It seems to only register them when bevy is referenced by path for some reason.

Ah, I see, the working directory is different for the crates that are compiled outside of the workspace. That'll need to be fixed

[celest magnet]

Shall I make an issue for it?

[opaque lily]

I've made one: https://github.com/bevyengine/bevy/issues/21444

[spiral bobcat]

Sorry, if this has been asked before, but I'm trying to set up hotpatching for my app on windows.

I couldn't get it to work with rust-lld, so i disabled it, and not with the dynamic_linking feature either.

That's fine, and hotpatching now works, but it takes 50 seconds to hotpatch even on a machine that's quite beefy, as opposed to just rebuilding the same change with my old setup which takes ~15 seconds.

That means hotpatching doesn't offer that much over just doing cargo watch -cx run. But it does keep context though.

Is this the expected performance right now?
Is there something I can do for quicker reloads?
Is it faster on other platforms?

[celest magnet]

On mac a relative small project takes over 10s to compile for me with hotpatch, and a lot less with normal compilation.

But if I enable cranelift, its around 1s. so cranelift provides over a 10x improvement for me, but it doesn't work with the new autoregistration.

Maybe if you manage to get cranelift working on windows you will get similar improvements?

[mellow flint]

you mean reflection autoregistration? That works with cranelift for me

[celest magnet]

On Mac? The inventory crate doesn’t compile with crane lift for me.

[mellow flint]

Linux

Using rustc 1.92.0-nightly (dc2c3564d 2025-09-29)

[celest magnet]

On Linux it works, but it’s still problematic on Mac, and I have to disable it for now. But I rather manually register components than eat 10x compile times…

[west trail]

you ran into the same issues i did, i've got them both documented: dynamic linking, rust-lld

and yes, it is much, much faster on linux due to not having to disable those two (and also because of mold)

[spiral bobcat]

Thanks! Looks like I'll be going back to Linux for a while 🙂

[indigo arch]

So if I have a workspace, what do I need to do to make a binary crate "the" hotpatchable crate?

Or should I just remove my binary from the workspace

[celest magnet]

@mellow flint would the subseconds crate be able to work with bevy 0.17?

[celest magnet]

Systems run with command.run_system_cached won't be hotpatched... need to remind myself of that.

[mellow flint]

It would be a simple bump, yeah

Do you need it?

[elder heart]

honestly, the .with_hot_patch method was really cool and awesome and good

oh, and the ability to change the parameters of systems

[mellow flint]

then I'll publish a new release 🙂

I'll do the rename while on it

I think we discussed bevy_hotpatching_experiments?

[celest magnet]

Need is maybe too strong… desire would be more fitting ☺️

[mellow flint]

Give me 30 mins or so 🙂

[celest magnet]

No hurry at all, plenty of things to work on, but I’m glad there will be a release for 0.17

[mellow flint]

I can do a little release train anyways today, since Avian 0.4 is out

[mellow flint]

@lone token or @languid sable could one of you rename https://github.com/TheBevyFlock/bevy_simple_subsecond_system to bevy_hotpatching_experiments pls? 🙂

[languid sable]

https://github.com/TheBevyFlock/bevy_hotpatching_experiments

[mellow flint]

thx

[raven valley]

[lean wren]

have your binary crate not using the library crate. usually, main.rs use lib.rs to init the game. here you need to not use the lib.rs. personally ive pushed everything down one module in app, with a init function. lib.rs re-export it. main.rs call it. lib.rs and main.rs need to re declare the mod with mod app since they are separated.
and i have that in my cargo toml dont remember if its needed or not. probably the crate-type need to be scoped only to the lib.

[lib]
name = "libgame_client"         # prepend lib to not conflict with binary target
path = "src/lib.rs"
crate-type = ["cdylib", "rlib"]

to start: BEVY_ASSET_ROOT="." dx serve --hot-patch --package game_client

[mellow flint]

Updated the crate to 0.17! Had to wrangle the proc_macros, meh. But it works!
Look for bevy_hotpatching_experiments now, I renamed the crate, but kept the versioning schema. So its bevy_hotpatching_experiments = "0.3" 🙂

Ping @celest magnet

[worn spear]

I have been meaning to test it out, but the workspace limitation really hurts my projects. Do you know of any workarounds, like making a small crate that isn't part of the workspace but has dependencies that are, or running from inside the crate folder even if it's part of a workspace?

[lone token]

making a toy project with just the systems you want to experiment on, and everything else in other crates, that way you get even better "subsecond" times

or making one mega project that's just one crate 😄

[mellow flint]

Exactly what Francois says. I personally have a mini bevy project that I use to prototype UI on. It's just a 2D cam, UI, and some boilerplate to replace the UI on hotpatching

Hotpatching is most valuable IME for UI, so I use it to create the UI in its own little project, then copy-paste the code into my real projects

Also, I have the priviledge of working on singleplayer stuff, so I can just have everything in one crate 🙂 But I still don't hotpatch that crate because yeah, the bigger the project, the longer the hotpatching takes

With some exceptions of course, every now and then I do hotpatch it to tweak some random constant like movement speed at runtime

[worn spear]

I have recently had to debug UI problems that not only required recompilation, but also to be run in the browser 🫠 I'll try to add a test crate and see if I can get a better workflow with the new release

[mellow flint]

the hotpatching experiments crate supports Wasm!

Could upstream that part, but no one has spearheaded it yet 🙂

Open call for contributions: plz upstream the Wasm functionality, thx

[worn spear]

How does it work if I normally move the wasm file inside a larger typescript project? Maybe I can symlink for development 🤔

[mellow flint]

no clue

[worn spear]

If I can get that to work that would be the biggest DX upgrade since syntax highlighting was invented

[indigo arch]

Oh that would do it. I'll try this later.

[indigo arch]

This worked! Thank you :)

Didn't have to add the stuff to the toml

though now I need to re-work my "re-enter states on hotpatch" logic because it's not properly re-entering states & substates.

re-entering the state in-game shows the hotpatched behaviour though.

[indigo arch]

Ah, so identity transitions are not what I expected. That's a bit frustrating.

[languid sable]

I would be open to revisiting this decision upstream

[indigo arch]

I didn't need it until hotpatching 😅 I'm currently pulling in the custom transitions example manually

[languid sable]

Yeah, but this is a good reason to tip the decision

[indigo arch]

Will need to update this to account for nixing scoped entities too, hrm.

[lone token]

that's why I opened https://github.com/bevyengine/bevy/pull/19363, as a companion to hot patching

I work around that by having a Reload variant of my enum state that just takes the previous state and re-enter it on enter

[languid sable]

Requested changes!

[chilly crypt]

How do I run bevy with hotpatching?
I followed the 0.17 post and installed dx, but then when trying to run BEVY_ASSET_ROOT="." dx serve --hot-patch --features "bevy/hotpatching" I get and error that it doesn't exist
I tried adding cargo run before but the hotpatching doesn't work
Maybe it's a Windows thing?

[west trail]

there are a few windows-specific bugs that make hotpatching not very usable right now, see here: #1374187654425481266 message

you can get it working by disabling dynamic linking and rust-lld but that makes hotpatching drastically slower than just normal recompiles with those settings

[chilly crypt]

oof

Nevermind then, I'll wait
Thanks!

[late stratus]

I can highly recommend developing on linux if you can, its not just that these features work better, bevy also just compiles faster without changing any settings

Dualbooting is pretty easy if you can get a spare ssd. If you want to try but don't know what distro to choose, go with CachyOS

[chilly crypt]

Do you know if it would work on WSL?

[late stratus]

Work? yes. But it won't bring much benefit, as WSL is a whole virtual machine with the associated overhead, especialy for CPU-heavy tasks

[cloud rune]

the main problem with WSL is getting GPU working. CPU-wise is fine.

I wasn't able to get AMD GPU working with WSL

but if you wanna know more, there are a lot of discussion about wsl on #windows

[lean wren]

for my case using rerun_on_hot_patch = true + for ui despawning existing node works for everything 🙂

[lean wren]

wsl is faster or on par than windows for a lot of use cases i think, dunno for compiling

[fair knoll]

is it possible to make subsecond share the build cache with cargo?

or does it build it on a somehow different way?

right now I have two completely different folders for builds, and I'm not sure whether it is intended or am I doing something wrong

[late stratus]

kiiinda, it does definitely create files which cargo cant use but whether that would case issues when merged i don't kneo

[fair knoll]

so the answer is... I either make space for the builds or I shall prepare for a headache 😅

[hushed wave]

In the bsn fork of 0.17 is the bsn macro hot reloadable? (Can’t check as not on 0.17)

I know the file is not in 0.17 fork. I just noticed 0.17 mention macro reloading

[dire stone]

Nope! It is supported on this branch, which is out of date https://github.com/cart/bevy/pull/36

Ooh but @restive geode did update it relatively recently

[hushed wave]

Thank you!

[restive geode]

Yeah it should be fairly up-to-date! At least post 0.17 release, haven’t merged the latest stuff yet

[fluid ermine]

i was trying to write an extract function but it seems liek that wasnt being hot patched, was it just a bug on my end, bevy's end or is it intentional?

[tulip cave]

https://github.com/DioxusLabs/dioxus/releases/tag/v0.7.0

[celest magnet]

If I use hotpatching in combination with egui, for me it crashes since bevy 0.17, with the hotpatch crate and bevy 0.16 this wan't the case for me. Has anyone else had the same?

OS is MacOS so could be related to that.

@mellow flint with your subseconds crate and bevy 0.17 the crash doesn't happen.

[mellow flint]

huh, weird

[celest magnet]

So thank you for keeping it updated for the latest release 😊

[mellow flint]

hehe glad it's proven useful!

[pallid dragon]

Finally tried the builtin hotpatching for 0.17.2 (before I had only used subsecond). Now things hot reload in 2 seconds. Before it was more like 10+ seconds. Not sure what happened (except for updating Rust to 1.91.0 so I got LLD by default and using dx 0.7.0). Also now I don't have to annotate the functions for hot reloading anymore??? This is so amazing. It went from meh to an actual productive tool in just a couple of months. I'm having a hard time even believing it. 😆

The crazy thing is last time I tried it I was already using nightly Rust with the parallell frontend and LLD. So I'm not sure how this happened. Somebody somewhere must have really cooked.

[restive geode]

It's great isn't it!? I am often getting actual subsecond (< 1s) patches now on MacOS

[pallid dragon]

I heard people say that before but I was a bit skeptical considering how long it took for me (with a mid range desktop) but now I can totally believe it. I wonder how it scales to larger projects. This is just the breakout example.

[restive geode]

A workaround is to just register the types you need manually

I keep reflect_auto_register_static enabled since simply disabling reflect_auto_register didn't seem to get rid of the inventory dep.
But I don't actually use the static auto registration (as I understand it might affect linking times)

Instead I just have this big function to register types, and simply append types when I encounter them.
I'll attach it for anyone on MacOS needing a starting point

[restive geode]

I guess technically, one could generate a file like this by just compiling with reflect_auto_registration (without cranelift), and dumping every path from the TypeRegistry to a file

[celest magnet]

Any additional configuration you use apart from crane lift?

I currently am at around 3-4s hot patching time, as the project has grown quite a bit.

Would be ideal to get back below 1s

[restive geode]

Nightly toolchain
bevy/dynamic_linking not enabled (have not tested how it affects compile times though, I disabled it when I was debugging some linker crashes and forgot to re-enable)

dx --version dioxus 0.7.0-rc.3

Cargo.toml:

[profile.dev]
opt-level = 1

[profile.dev.package."*"]
opt-level = 3
codegen-units = 1

config.toml:

[unstable]
codegen-backend = true

[profile]
incremental = true

[profile.dev]
codegen-backend = "cranelift"
debug = "line-tables-only"

[profile.dev.build-override]
# These were recommended by Jon Kelley for macro-heavy codebases to optimize the invocations, _may_ help if using a lot of bsn! in the future, but not using for now
# opt-level = 3
# codegen-units = 1
opt-level = 1

[profile.dev.package."*"]
codegen-backend = "llvm"

[target.aarch64-apple-darwin]
rustflags = [
    # Nightly
    "-Zshare-generics=y",
    "-Zthreads=0",
]

[restive geode]

Oh! And I also recently added VSCode (I run dx from the code terminal) under system Settings > Privacy & Security > Developer Tools
See: https://nnethercote.github.io/2025/09/04/faster-rust-builds-on-mac.html

Entry level MBA M4

[half pasture]

is it known if there are plans to make it possible to implement your own subsecond server? The docs hint at it with:

To actually load patches into your application, a third-party tool that implements the Subsecond compiler and protocol is required

[pallid dragon]

I actually realized that dynamic linking is what made the big difference for me. Without it, it's as slow as it was. So yeah dynamic linking seems critical.

[restive geode]

Hmm, interesting... Maybe I'll have to experiment a bit more 🤔

[scenic pond]

in 0.17 does hotpatching no longer duplicate entities when a system is re-ran that spawns them?

[restive geode]

No, it will simply replace the system with the new code. What happens inside is up to you.

There is a HotPatched event (message) you can listen to to detect a hot patch. There’s also a resource I don’t remember the name of, which will be Changed after hot patching

Simplest way is to just despawn and respawn the entities again

[scenic pond]

im asking because before 0.17 when using this crate you could rerun the system like that
but now there's no macro so im not sure if there's a way to do that

[mellow flint]

Upstream does not have all features that crate has

but you can still depend on it

[scenic pond]

okay i'll just use the crate then hope nothing breaks

[restive geode]

Another trick to get something to re-run on hot patch is to wrap it inonce! 😄 I used that before I realized HotPatched was a thing. Can be useful if you only need part of the system to re-run I guess...

Obviously won't work for SetupStartup systems though

[mellow flint]

oh wow that's a neat trick 👀

[restive geode]

Here's what I'm doing now:

use bevy::{
    ecs::{schedule::ScheduleLabel},
    prelude::*,
};

#[cfg(not(feature = "hotpatching"))]
pub fn hot_patch_plugin(_app: &mut App) {}

#[cfg(feature = "hotpatching")]
pub fn hot_patch_plugin(app: &mut App) {
    use bevy::ecs::HotPatched;

    app.init_schedule(HotStartup)
        .add_systems(Startup, |world: &mut World| {
            world.run_schedule(HotStartup);
        })
        .add_systems(
            First,
            |mut hot_patched_reader: MessageReader<HotPatched>,
             mut commands: Commands| {
                if hot_patched_reader.read().next().is_some() {
                    info!("Hot patch detected, running HotStartup schedule");
                    commands.run_schedule(HotStartup);
                }
            },
        );
}

/// Schedule that runs on startup, and then re-runs on every hot patch.
#[cfg(feature = "hotpatching")]
#[derive(ScheduleLabel, Debug, Clone, PartialEq, Eq, Hash)]
pub struct HotStartup;

/// Schedule that runs on startup, and then re-runs on every hot patch.
#[cfg(not(feature = "hotpatching"))]
pub type HotStartup = Startup;

Then I just add any setup that should re-run to the HotStartup schedule:

app.add_systems(HotStartup, refresh_scene);

[undone temple]

should I expect somewhat similar hotpatch compilation time between the example and a larger game if I'm making a similar sized change? That is... if switching "before" to "after" in the example takes 2 seconds... is it weird that it takes 20 seconds to change a number from 400 to 40 in my game?

[dire stone]

I'm unsure on this from the actual hotpatching perspective, but its still doing linking in the same way. Does it take ~20 seconds to do an incremental build of the same change?

If so, are you using bevy's dynamic linking feature and a fast linker?

[undone temple]

yes

[undone temple]

yes, I was using bevy dynamic and mold... but I disabled both and still saw it behave that way 🤔

[lean wren]

hey ! did you manage to fix it ?

[open flint]

no

[rugged igloo]

I think long term it would be nice now that we can remove systems from a schedule to have a proper dynamic or hot reloadable plugin

there could be equivalent spawn commands, etc that are tracked so all the side effects could be torn down and rebuilt

although it definitely gets a bit hard to define correct behavior when the plugins introduce new components or changes to existing ones

[quartz whale]

Workspace hotpatching support in Dixous! https://github.com/DioxusLabs/dioxus/commit/33159f366adf7d877c6e5a2987172e3f9992b6f7
(I discovered it from https://www.reddit.com/r/bevy/s/ySAsFzqCOH)