41–50 of 102 posts
Earlier quoted context omitted.
> fyi, "hot reload" is a native part of every operating system (consider, even trivially, forking & reforking). Can you expand on this?
https://en.wikipedia.org/wiki/Dynamic_loading
Earlier quoted context omitted.
One problem is that modern software architectures are highly coupled and stateful, such that it isn't possible to hot reload a component. It would require the host (e.g. when using a DLL) to detect a change, save state, unload, reload, load state. Multi-threading may also make things more difficult, requiring more synchronization during changes. I agree with your sentiment, but it's really hard to communicate it to t…
well, i think the issue is as least as much that the developers who create these architectures do not start from this pov --- consider how these architectures would be designed if must-have condition was sub-100ms iteration -- which should be trivial all-but-for codebases of at least 1mil+ lines; them, well, maybe it's 200ms. This design isnt hard -- what's hard about save_frame(), save_state(), or w/e, and restore_s…
1. Come in, get coffee, check out latest code from Visual SourceSafe. 2. Hit F5 to start debugging. 3. Edit and Continue in Visual Studio 6.0 all day long. 4. Hit shift-F5 to stop debugging at the end of the day. 5. Go home.
Between that and the OG Pix for Xbox, the development experience has been all downhill from there. A lot of kids these days tried GDB once or twice and then grew up without even understanding the value of debuggers at all. And, by "kids" I mean "graduated 10 or less years ago" :P
I'm sure keeping that workflow working was a fair bit of work. But, it was worth it!
It's pretty good. Epic added it as part of Unreal Engine to replace their previous hot reload system, which was more similar to the alternatives that people are mentioning here. That previous hot-reload didn't work as well as live coding, was less stable. Simple dll reloading can work great if you separate state from logic, like shown in handmade hero. If you cannot enforce that then live++ is a good alternative. Too…
Live++ ("Live Coding" in Unreal) can still cause these problems if you leave the Reinstancing option on. For anyone doing C++ in Unreal, please please please read this [1] and at the very least make sure to not use the older Hot Reload.
[1] https://landelare.github.io/2023/01/07/cpp-speedrun.html#com...
Reminds me of this[0] post on NullProgram about how to apply hot reloading to C. [0]: https://nullprogram.com/blog/2014/12/23/
Earlier quoted context omitted.
well, i think the issue is as least as much that the developers who create these architectures do not start from this pov --- consider how these architectures would be designed if must-have condition was sub-100ms iteration -- which should be trivial all-but-for codebases of at least 1mil+ lines; them, well, maybe it's 200ms. This design isnt hard -- what's hard about save_frame(), save_state(), or w/e, and restore_s…
Way back in the 2000-2004 timeframe, I worked along side a team making a game for the OG Xbox that had a daily workflow like: 1. Come in, get coffee, check out latest code from Visual SourceSafe. 2. Hit F5 to start debugging. 3. Edit and Continue in Visual Studio 6.0 all day long. 4. Hit shift-F5 to stop debugging at the end of the day. 5. Go home. Between that and the OG Pix for Xbox, the development experience has…
To my surprise, this was seen as a pretty amazing feature at the time. I never understood why many/most of the other MUDs at the time didn't utilize this.
fyi, "hot reload" is a native part of every operating system (consider, even trivially, forking or https://en.wikipedia.org/wiki/Dynamic_loading ). It's a sign of how bad developer tooling has been that live reload is sold as an add-on feature. DX seems always to see-saw between bill gate's c. 1990 demo of VB, and the compile-time speeds of a N' Wirth. At a guess, when the internet happened, all DX had to be thrown a…
exec() doesn't hot reload either.
Dynamic loading doesn't hot reload either, more like hot load.
Debuggers might hot-patch code to insert breakpoints, but that's not the same thing as replacing running code. Sure, the debugger might execute scripts you associate with breakpoints, but that's also not exactly the same thing as replacing the running code. Mind you, debuggers do have to make sure that such hot-patching is atomic, or they have to stop all threads.
Hot reloading has a ton of considerations:
- threading -- you need to quiesce all threads at points where they are not executing the code to be reloaded _or_ you need to load the new code and hot-patch either calls to old code and/or old code function entrypoints to jump to the new code, but if the latter then you need to make sure it's ok to have a mix of threads executing old code while the new code comes online
- data structure compatibility -- if structures have changed you may not be able to hot-reload, but you need to at least be able to detect incompatible changes, and at best you need to plan how the hot-reloaded code will upgrade extant data structures on the fly
- and more
Sure, if you atomically hot-patch all the calls to old code or old code entry points, then threading issues on the side of the hot-reloading library go away, but you still have to think about how old and new code running concurrently will deal with each other.
Now, I don't know that much about this subject, and I've seen how old Lisp and Smalltalk systems could hot-patch/reload all the live long day with no problems, but I suspect all the systems where it was ever easy were a) single-threaded, b) written in high-level languages, c) still had some reloading considerations for the authors of the code being reloaded.
Maybe I'm just old and grumpy, but the subscription business model just puts me off. Nowadays when I read about some development tool (or just any product), I start with the price page. If there are only subscriptions available I stop reading and go on with my life.
Earlier quoted context omitted.
well, i think the issue is as least as much that the developers who create these architectures do not start from this pov --- consider how these architectures would be designed if must-have condition was sub-100ms iteration -- which should be trivial all-but-for codebases of at least 1mil+ lines; them, well, maybe it's 200ms. This design isnt hard -- what's hard about save_frame(), save_state(), or w/e, and restore_s…
Way back in the 2000-2004 timeframe, I worked along side a team making a game for the OG Xbox that had a daily workflow like: 1. Come in, get coffee, check out latest code from Visual SourceSafe. 2. Hit F5 to start debugging. 3. Edit and Continue in Visual Studio 6.0 all day long. 4. Hit shift-F5 to stop debugging at the end of the day. 5. Go home. Between that and the OG Pix for Xbox, the development experience has…
Folks interested in this should absolutely look at the open source Cling project, which uses Clang/LLVM to JIT compile C++ in-process. https://github.com/root-project/cling I'm using Cling, as part of jank, a native Clojure dialect on LLVM, with C++ interop. This allows me to have truly interactive, dynamic programming, while still reaching into native code. jank source compiles to C++, which is then JIT compiled by…