LÖVE

rxi wrote:As far as I know no one has written hotswapping for Lua this way before.

I'm pretty sure that this was done with Concerned Joe (not really sure), but none the less, it's still a great utility!

Zarty55 wrote:Oh, playing a little bit with lurker.postswap I've noticed a kinda strange behavior. When I change lurker.postswap and lurker reloads(The game, not that I changed it inside the lurker.lua), it calls a old version of the postswap function. Any workaround to this?

That does sound strange, would you be able to give me step by step instructions on how to recreate the problem? It seems to work fine when I've tried it out. Are you using the LÖVE console (the one pictured in adnzzzzZ's gif)? If you are not: enable it in your conf.lua file and make sure it isn't reporting any errors when it tries to swap.

davisdude wrote:I'm pretty sure that this was done with Concerned Joe (not really sure), but none the less, it's still a great utility!

I had a little skim of that article and I believe he is not doing what I was referring to as the way no one else has done it. The way I've done things is that when the module is reloaded none of your existing tables are overwritten -- they're all updated (and their metatables) with the new changes so that all your references stay intact -- this means that if you have a metatable which you are using as a class, for example: "Player", when you hotswap the player.lua file, the "Player" class would still be the exact same table it was before, but its content would be updated. This technique also means that even if "Player" was only ever returned by require and was a local variable in each file, after a hotswap the local variables would still reference the correct table.

Is all the code yours or did take some of it from somewhere else ?

My folder is consisted of:
conf.lua
main.lua;
lume.lua
lurker.lua

Lume and lurker is untouched, conf is the default conf file with the console as true. Main.lua is this:
So, try doing the following:

1- Force it to do a swap
2- Change the print to something else, it will swap everything, but the reference will be the old one, so it will call the old function
3- It prints "newFunction" even if you have changed it.
4- Not so much profit. Huh? :p

So for it to call the new function you have to do two swaps, one for it to load the new function and the second for it to call the new function. Which is what I would expect of lurker.preswap. I think it probably will need some magic to make it work :p

What you could do is to, instead of setting "lurker.postswap" to a reference, set it to a string that has the name of the function an and use lume.dostring. haha! :p

this is absolutely awesome. i've used Cupid before (which is really really nice) but it didn't have any functionality to limit how often it checks for modifications - it's also confusing as all hell to read, so i left it the hooked/protected functions thing sounds really interesting. i like how you can reboot the game directly from the cupid error screen.

anyways, i wrote a small threaded implementation of lurker. would be more than happy to upload if you want

@Zarty55

I think you may be misunderstanding what's going on. Here's a step by step of what happens in your example:

• The program starts
• You add your lurker.postswap assignment into the love.update() function
• The change is detected, lurker.preswap is called
• The hotswap occurs, main.lua is loaded and executed -- the new love.update() function (among the others) is set but is not run yet
• The (unchanged) lurker.postswap function is called
• Love enters the next frame and calls the new love.update() function, the assignment to lurker.postswap you added inside this function takes place.

This is the intended behaviour of lurker. To do what you're trying to do you could stick your assignment right in the file's body (outside of any function), that means when the hotswap occurs and the file is loaded and executed the assignment will take place immediately.

Ranguna259 wrote:Is all the code yours or did take some of it from somewhere else ?

Yes, I wrote it myself, you can check out the history, source and tests on the github -- some functions, eg lume.distance() use the standard approach and so are basically the same as nearly every other implementation of a distance function. I'm unsure what the intent of your question was?

MGinshe wrote:this is absolutely awesome. i've used Cupid before (which is really really nice) but it didn't have any functionality to limit how often it checks for modifications - it's also confusing as all hell to read, so i left it the hooked/protected functions thing sounds really interesting.

I had a little play around with using the same wrapping technique cupid uses for catching errors in the love callbacks -- I did have to do a little extra work because of the nature of the hotswapping but it seems to be working well so far! This means that if you introduce an error which only occurs in a call to love.update() the error is caught, if you fix the error the program will continue where it left off, with the new file in place.

Hopefully I can get the feature finished some time this evening and push the updates, I'll make a post to this thread when it's all updated and uploaded.

MGinshe wrote: i wrote a small threaded implementation of lurker. would be more than happy to upload if you want

I was put off using threads as I was unsure of how well hotswapping might work when we bring threads into the mix, I also wanted to keep thing simple and maintain compatibility with both love 0.8.0 and 0.9.0. You should definitely upload your version, it'd be interesting to take a look -- in addition, if you wanted to continue supporting a threaded version, you could fork the lurker repo on github and create a lurker-threaded repo or something to that effect.

It was to congratulate you, nice work

Oh man, I have been dreaming of having a "hotswapping" type of functionality; I will definitely be checking this out

Nice work!

Lurker update

Added a protected mode to lurker, by default this mode is enabled (it can be disabled by setting the lurker.protected variable -- see the readme). Any error which is raised by a love callback function (love.update(), love.draw() etc.) is now caught by lurker and its error state is initialised rather than LÖVE's blue error screen. While lurker is in its error state it is still watching for changed files and will attempt to resume execution of the program again if any changes (and by result, hotswaps) occur.

Not only does this remedy the problem of making mistakes in hotswapped files which while syntactically correct raise errors when they are actually run, but it also allows you to hotswap a fix in for other errors which occur while your game is running.

Lurker's error state calls love.graphics.reset() so your background color, color, transforms etc. will all be reset if an error is raised and caught by it.

Let me know how you get along and whether you encounter any issues or find any bugs.

@Ranguna259 @andmatand
Thanks!

rxi wrote: I was put off using threads as I was unsure of how well hotswapping might work when we bring threads into the mix, I also wanted to keep thing simple and maintain compatibility with both love 0.8.0 and 0.9.0. You should definitely upload your version, it'd be interesting to take a look -- in addition, if you wanted to continue supporting a threaded version, you could fork the lurker repo on github and create a lurker-threaded repo or something to that effect.

this is my first time using github to push, sorry in advance for any mistakes

anyways, i forked your repo and added a little thread block to the top of the script. it seems to work pretty well, and still catches/recovers from errors. it's a little messy, but i really just wanted to get the idea down and see if it would work. i'll keep it up to date with your version, and hopefully add support for 0.8.0's thread system next week.

also, i really like the error screen. it works almost perfectly. the only way i found to break it was to introduce an error into the lurker.lua file, which i don't see being a problem in normal use. my only suggestion is to add a screen/warning for syntax errors, the console notification is nice but sometimes it's easy to miss. aside from that, this is easily my favorite lib now. thanks bro!