8 ms·

I have tried jurigged and I like how lightweight it is. It does not seem to reload changes that relate to other parts of code though. For a given code: a = 1

I have tried jurigged and I like how lightweight it is. It does not seem to reload changes that relate to other parts of code though. For a given code: a = 1 b = a + 2 Changing a = 5 will not update b which will still be equal to 3. The same goes to relations between files. Whether it is a flaw or feature it depends on the situation and codebase I guess. Also it seems like it is not possible to reload currently executing functions (re-entering the function is needed).

chii 4y ago
i wonder how you would make the update to `b` work in this case? If you have a white listed set of pure operations (like the `+` operation), then you can check if the hot-reloaded code has any dependencies which could be re-executed (like the b=a+2 case). You wouldn't want to re-execute code that has a side-effect upon hot reloading imho.
- kwazar90 4y ago
  Reloadium executes a module in a sandbox environment until it reaches the modules top most frame location (to prevent getting into a loop or other entrypoint and being stuck) and looks for changes. For code that should be executed only once you have to add # reloadium: no_reload (blocks of code can be ignored as well, more details here https://reloadium.io/documentation/decorators https://reloadium.io/documentation/decorators)
breuleux 4y ago
Yeah, we are using different strategies I think. My approach is to not re-run anything that has not changed, so if you change the code of a function in a module, the module's global state will remain untouched, and if you change the code of a decorated function, the decorator will not be re-run (the function inside will be fudged directly). I wouldn't say either approach is intrinsically better, in either case there are situations where it won't do what you want. I think I prefer mine because it is, in a way, a bit more predictable: if e.g. I add a print statement to some function, then the next time I call it, it will print. I know that it won't reset any global state anywhere or re-run anything expensive, regardless of what else there is in the module. Usually, that's what I want. The develoop feature (which I am rewriting right now) sort of does the reloading of currently executing functions, in the sense that you can pick one or more focus functions that are run in a loop and aborted/restarted when the source changes. At some point I looked into changing functions during a breakpoint and continuing in the new code, but I couldn't see any way to do it in pure Python, except maybe through some ctypes voodoo.

chii 4y ago

i wonder how you would make the update to `b` work in this case? If you have a white listed set of pure operations (like the `+` operation), then you can check if the hot-reloaded code has any dependencies which could be re-executed (like the b=a+2 case). You wouldn't want to re-execute code that has a side-effect upon hot reloading imho.

kwazar90 4y ago
Reloadium executes a module in a sandbox environment until it reaches the modules top most frame location (to prevent getting into a loop or other entrypoint and being stuck) and looks for changes. For code that should be executed only once you have to add # reloadium: no_reload (blocks of code can be ignored as well, more details here https://reloadium.io/documentation/decorators https://reloadium.io/documentation/decorators)

breuleux 4y ago

Yeah, we are using different strategies I think. My approach is to not re-run anything that has not changed, so if you change the code of a function in a module, the module's global state will remain untouched, and if you change the code of a decorated function, the decorator will not be re-run (the function inside will be fudged directly). I wouldn't say either approach is intrinsically better, in either case there are situations where it won't do what you want. I think I prefer mine because it is, in a way, a bit more predictable: if e.g. I add a print statement to some function, then the next time I call it, it will print. I know that it won't reset any global state anywhere or re-run anything expensive, regardless of what else there is in the module. Usually, that's what I want. The develoop feature (which I am rewriting right now) sort of does the reloading of currently executing functions, in the sense that you can pick one or more focus functions that are run in a loop and aborted/restarted when the source changes. At some point I looked into changing functions during a breakpoint and continuing in the new code, but I couldn't see any way to do it in pure Python, except maybe through some ctypes voodoo.