I'm not sure if this can be done, but this has been done with Ruby before.
What I want is a live REPL to the lua instance that is being run on the player.
I should get a normal REPL like "lua" on command line does, and I should be able to run code, make changes to the elements, and they should be executed live on the player.
Example in Ruby: Pry/IRB (Ruby REPLs) can be invoked dynamically from within code, starting an interactive session. In runs great on Ruby on Rails.
I can find some video demos of the Ruby ones if anyone is interested
People call me "underscore".
Comments
Dislikes: Yan
Also, I watched your tutorial videos for the first time and I hadn't realised until now that your live coding was influenced by Bret Victor. When I first found Gideros I realized it has potential for this sort of coding and posted this message on Increasing the Awesome. I have to say that with Zero Brane Studio we are getting even closer to total awesomeness.
So here are a couple of ideas for ZBS, just in case you can see any way to make them a reality with Gideros.
1) I'd like to be able to do programming in the debugger. I come from a Smalltalk background and over there this goes on all the time. There are two reasons to do this.
The first is to fix code as you are debugging. One problem with game programming is that, quite often, one has to do a lot of work to set up a test scenario. If, while you are debugging, you then come across a simple problem you want to be able to fix it without having to restart the whole program and have to go through the setup scenario again. I think in MSVC they call this Edit and Continue. I've already tested this out somewhat in ZBS and it seems you can change functions at runtime by assigning them in the Remote Console. The real trick, however, would be to recompile the method that you are in right now (the one in the top stack frame) and then restart it.
Once you can do this, you can also do some other cool stuff. In Smalltalk you can flesh out an entire program like this by programming in the debugger. Basically, the idea is that you start writing your code, calling functions that don't yet exist. When you then run the code and it hits one of these errors, instead of quitting, it brings up the debugger at that point on the stack. At that point you can write the missing code (possibly even calling more methods that don't yet exist). You then hit Continue and wait till you come across another bit that needs implementing. When you no longer hit non-existent methods calls, your app is finished!
This is an incredibly quick way to develop and works really well with Test Driven Design. And one of the great things about it is that, while you are editing these non-existent methods in the debugger you have the entire calling context available to you; you can see exactly what parameters a function should expect because they are there on the stack!
2) The next suggestion is: can we somehow get the Live Coding working with Gideros? I'm not exactly sure how it would work. I guess you are just looping around the live code repeatedly and allowing the programmer to interact with it via sliders etc. Since we already have an inherent display loop in a Gideros app there would be no need for an additional one.
So, I'm thinking that you might just allow the user to select one or more functions to be "live functions" during a particular debugging run. Using the programming in the debugger idea above, these functions could be continuously recompiled as they are edited in your Live Code pane or as sliders are moved. If an error occurs in compilation then the original (non-live) copy could be temporarily substituted back to things keep moving.
So how would this help? It would allow the sort of program exploration that Bret Victor mentions. Tweaking aspects of a game dynamically can reveal new things about the way the interactions work. Also, if you have a physics game that relies on positioning of objects these positions can be experimented with directly in the live game without having to restart each time. Even if you just have your screen layouts set up in various methods this Live Coding would be able to replace much of the need for an external layout editor. It would also make for an extremely groovy video demonstration.
Just some ideas to keep you busy. I look forward to the next version of ZBS - tomorrow perhaps? ;-)
best regards
best regards
If your data structure is large, you can do "=variable" or "=expression" to pretty-print it in a block format.
When you do "print(...)" in the remote console, it's printed to the "output" window, but it may be buffered, so you don't see it immediately. You may want to add "io.stdout:setvbuf('no')" to your script (or run this expression in the console) to eliminate the delay.
Your post on live coding and total awesomeness warrants some experimentation . I've tried live coding in the Player when I first came across Gideros, but it didn't work; I think I now have a better idea what to try to make it work. Will update shortly.
Let's take Sleeping Bodies example. If I change the onTimer function, I need to re-register the event, and this is where I run into problems. You can try this yourself, maybe you can suggest me the right way to do this.
Run the example under the debugger and pause somewhere (for example, inside the onEnterFrame function). Then run the following commands in the remote console (from the attached file):
> resetListeners(initialized)
Essentially, I remove and add back the same listener. When I continue the script, it crashes somewhere inside the Player and I get these two messages:
AL lib: ALc.c:2325: exit(): closing 1 Device
AL lib: ALc.c:2247: alcCloseDevice(): destroying 1 Context(s)
All I do there is to re-register the same listener. It seems to be crashing in the player before entering onEnterFrame.
Interestingly enough, if you pause inside onEnterFrame and then run this command -- world:createBody{type = b2.DYNAMIC_BODY, position = {x = math.random(0, 320), y = 56}} -- it crashes the player right away, which may be a clue. It seems like there are some modifications to the world caused by createBody/destroyBody or addEventListener/removeEventListener that crash the player when executed in the debugger.
If you can help me with getting this to work, I think we can get the live coding working. Thanks.
This is the code I experimented with (I replaced some local functions with globals to allow them to be recreated dynamically without resetting the state). Pasting "main.lua" here as I couldn't uploaded it ("uploaded file type is not allowed").
Your object structure is quite complex (with keys/values being tables and userdata), so I'm not ruling out possible issues with the debugger, but it has already been used/tested with various engines without (known) issues. Any help would be appreciated. Thank you.
And these lines on remote console
Also I've changed the last part of Sleeping Bodies example as:
I really wonder why the crashing occurs on your side. (Currently I'm on Windows, should I try on Mac also?)
@atilim, not sure either; I'm also on Windows at the moment. I'll give your suggestions a try shortly (good idea with the wrapper). Thanks for looking into this.
<pre lang="lua">
</pre>
Here are my exact steps:
1. Opened the original Sleeping Bodies example.
2. Changed onEnterFrame function from local to global
3. Pressed pause: it breaks at the first line of onEnterFrame
4. Entered these lines on remote console
I suspect that it may be a Windows/Android issue?
best regards
Likes: atilim
btw, when I start debugging, it always breaks at the require('mobdebug').start() line and then I need to press continue. do you think it is normal?
@atilim, it's a feature, but it may be possible to disable that; would you prefer to run immediately? it would require you to have a breakpoint or to use "break" to stop in the app.
The video lost the audio, so I actually deleted it from the post but you must have got in first. Let me try the stuff you've checked in now.
And I can change onTimer and onEnterFrame on the fly. It's amazing! :O
best regards
Likes: atilim
@bowerandy, @atilim, have you noticed I included auto-complete for Gideros API too?
I think we are good for now; I'll go work on a couple of blog posts .