I don't think it's possible to get hot reloading of either Löve assets or Lua files 100% right. For the Lua side, files loaded through dofile() or I/O + loadstring() are probably impossible to get right. For the asset side, if your program does something with the data of the assets then it will be wrong when reloaded. For example, some programs post-process the images on load for some purpose (e.g. compositing a background into a canvas using some images), and when the images are reloaded, they won't be re-post-processed. Automatic restart sounds much more feasible.
Also, I'm not fully sold on the benefits of hot reloading of Lua files. It may introduce subtle bugs that will be undetected until the next restart, because I don't think there's a way to remove all possible side effects left behind by the previous version of a file.
I think there are safer ways to debug. Add a quick exit key (say scroll lock) and a mechanism to fast-track going to the desired point of the program. For example, in Thrust II Reloaded the full game state is preserved on save, and it takes a single keypress to instantly go to a previously saved position.
All that said, I haven't seen a hot reloading library that automatically monitors main.lua plus all require()d files, which sounds to me like a bare minimum that such a library should do.
Hot reload plugin that actually works?
- zorg
- Party member
- Posts: 3465
- Joined: Thu Dec 13, 2012 2:55 pm
- Location: Absurdistan, Hungary
- Contact:
Re: Hot reload plugin that actually works?
You'd need to redefine most functions; l.fs.load* and normal lua load* functions included, as well as require, along with remembering to actually wipe package.preload of the files you intend to reload when using require. (I mean, if you wanted to use them, but then again, i am talking about a general solution)
But pgimeno worded it better than how i did, it's as hard as writing a GUI, maybe even moreso.
(Not that i want to deter anyone from coding such a thing, just my 5 cents.)
But pgimeno worded it better than how i did, it's as hard as writing a GUI, maybe even moreso.
(Not that i want to deter anyone from coding such a thing, just my 5 cents.)
Me and my stuff True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.
Re: Hot reload plugin that actually works?
I'd say it can be proved mathematically that it's plain impossible to do it 100% right (halting problem and all that). Say you redefine love.filesystem.load. OK, that way you know what file to monitor, and let's imagine that you also know where to place the result when it changes (more difficult). But should you execute the result? Consider two cases:
1) the file defines functions that you would expect to change on hot-reload,
2) the file does not define any functions; instead it is in itself a simple subprogram that skips to the next level, so you keep it loaded and call it whenever the player completes a level.
Now, should an imaginary 100% right library call it when the file is changed? In the first case, it should; in the second case, it shouldn't. Would monitoring whether it was already executed help? No: it may already have been invoked because the player has already completed a level before the file is changed, and you don't want to change level when the file changes, you just want to modify the level change code for the next time it's needed.
So, basically the imaginary 100% right library should understand what the code does and how it is used, to decide whether it should be executed after reloading it or not, which is impossible.
1) the file defines functions that you would expect to change on hot-reload,
2) the file does not define any functions; instead it is in itself a simple subprogram that skips to the next level, so you keep it loaded and call it whenever the player completes a level.
Now, should an imaginary 100% right library call it when the file is changed? In the first case, it should; in the second case, it shouldn't. Would monitoring whether it was already executed help? No: it may already have been invoked because the player has already completed a level before the file is changed, and you don't want to change level when the file changes, you just want to modify the level change code for the next time it's needed.
So, basically the imaginary 100% right library should understand what the code does and how it is used, to decide whether it should be executed after reloading it or not, which is impossible.
Re: Hot reload plugin that actually works?
So there are issues with Corona reloading? Where have you noticed that or noticed people complaining about that?pgimeno wrote: ↑Fri Jan 26, 2018 9:02 pm I don't think it's possible to get hot reloading of either Löve assets or Lua files 100% right. For the Lua side, files loaded through dofile() or I/O + loadstring() are probably impossible to get right. For the asset side, if your program does something with the data of the assets then it will be wrong when reloaded. For example, some programs post-process the images on load for some purpose (e.g. compositing a background into a canvas using some images), and when the images are reloaded, they won't be re-post-processed. Automatic restart sounds much more feasible.
Also, I'm not fully sold on the benefits of hot reloading of Lua files. It may introduce subtle bugs that will be undetected until the next restart, because I don't think there's a way to remove all possible side effects left behind by the previous version of a file.
You may be right, maybe it's a limitation of love2d. It can't be a limitation of Lua though since they have it working so well in Corona.
- zorg
- Party member
- Posts: 3465
- Joined: Thu Dec 13, 2012 2:55 pm
- Location: Absurdistan, Hungary
- Contact:
Re: Hot reload plugin that actually works?
I'm disagreeing with pgimeno here, in that i don't think the halting problem has anything to do with this IF we are talking about Corona and/or less general ways of hotswapping; in those cases, one could devise a way to do it correctly; but as i said before, Corona, at least looks like it limits you in a few ways, although i never tried it so i can't say whether you need to keep yourself to not using 3rd party scene managers and stuff that might break hotswapping or not.hasen wrote: ↑Sat Jan 27, 2018 1:11 pmSo there are issues with Corona reloading? Where have you noticed that or noticed people complaining about that?pgimeno wrote: ↑Fri Jan 26, 2018 9:02 pm I don't think it's possible to get hot reloading of either Löve assets or Lua files 100% right. For the Lua side, files loaded through dofile() or I/O + loadstring() are probably impossible to get right. For the asset side, if your program does something with the data of the assets then it will be wrong when reloaded. For example, some programs post-process the images on load for some purpose (e.g. compositing a background into a canvas using some images), and when the images are reloaded, they won't be re-post-processed. Automatic restart sounds much more feasible.
Also, I'm not fully sold on the benefits of hot reloading of Lua files. It may introduce subtle bugs that will be undetected until the next restart, because I don't think there's a way to remove all possible side effects left behind by the previous version of a file.
You may be right, maybe it's a limitation of love2d. It can't be a limitation of Lua though since they have it working so well in Corona.
For a general lua solution though, either it's hard(er), or as pgimeno said, literally impossible due to the halting problem; i can't confirm or deny the latter since i haven't thought about it that much, and honestly, i don't plan to.
Also, as we talked about it before as well, there's a difference between hotswapping assets and hotswapping code too.
We may end up talking in circles though, and i sure am not interested in actually looking at corona's source, but i could try to make an implementation of hotswapping in löve, that showcases how hard it is to get it right. (i.e. it will only work if one follows a strict coding format) With ample comments, of course.
Me and my stuff True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.
Re: Hot reload plugin that actually works?
zorg, note I emphasized "100% right". Of course it's possible to have hot reload under the assumption that you stick to a certain workflow. I'm saying it's impossible to do it right for all workflows. So let's disagree to disagree
hasen, I can write a Lua program that no hot reload can get right. I don't know Corona, so I'm not sure if it will work in Corona. I can easily adapt it to Löve, though.
An example of a workflow that will fail: imagine you want more control over the loading process than require() provides, so you make your own instead of using require(), and you do it based on loadfile() (or love.filesystem.load()).
Another example of a workflow that will fail: a module that besides defining some functions, also patches an existing function, so that the original is invoked after your code. If you hot reload that module, you will be chaining to an old version of itself, rather than to the system function. That can cause anything from not fixing what you intended to fix, to utter havoc.
I can think of more examples, but the bottom line is that it can't possibly get every workflow right.
hasen, I can write a Lua program that no hot reload can get right. I don't know Corona, so I'm not sure if it will work in Corona. I can easily adapt it to Löve, though.
An example of a workflow that will fail: imagine you want more control over the loading process than require() provides, so you make your own instead of using require(), and you do it based on loadfile() (or love.filesystem.load()).
Another example of a workflow that will fail: a module that besides defining some functions, also patches an existing function, so that the original is invoked after your code. If you hot reload that module, you will be chaining to an old version of itself, rather than to the system function. That can cause anything from not fixing what you intended to fix, to utter havoc.
I can think of more examples, but the bottom line is that it can't possibly get every workflow right.
Re: Hot reload plugin that actually works?
Well, you can call it that. I call it a limitation of the hot reload library.
Edit: I think I wasn't clear. I'm sure that if I knew Corona, I could write a program that doesn't properly hot-reload in it.
Edit: I think I wasn't clear. I'm sure that if I knew Corona, I could write a program that doesn't properly hot-reload in it.
Last edited by pgimeno on Sat Jan 27, 2018 4:52 pm, edited 1 time in total.
- zorg
- Party member
- Posts: 3465
- Joined: Thu Dec 13, 2012 2:55 pm
- Location: Absurdistan, Hungary
- Contact:
Re: Hot reload plugin that actually works?
Well, if you view more freedom with regards to coding a "problem", then yes, Löve is broken like that.
Me and my stuff True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.
Who is online
Users browsing this forum: No registered users and 4 guests