Live coding
Monkey Forums/Monkey Programming/Live coding
| ||
| I am new to Monkey and understand that given the source-to-source translation workflow, that live-coding isn't likely doable at this point. But, perhaps I'm happily mistaken? The workflow is pretty quick for HTML5 target but for say GLFW it takes about 10s to rebuild and relaunch. That can add up after a while. I'd love to be able to tweak a variable's value and have it reflected in the running app almost instantly, without a full rebuild. |
| ||
| i've been thinking about this as well. i think this is possible with html5, but the challenge is to know how to modify the trans to compile incrementally and where to inject the code. i can look into this when i have free time. |
| ||
| You can change values using reflection on the fly. However as of yet there is not a simple console or so that allows this, would be fairly straightforward to create I think. Has been on my mind tough to create one. It certainly would be handy sometimes to get/set values in run-time for debug & develop purposes. |
| ||
| One way would be to embed a server component in running programs via a livecoding module. Perhaps there could be a checkbox in Ted like "enable live coding" which if checked automatically adds the livecoding module to the final app and somehow auto-starts the server. Ted* would need to be updated to: - add a preference to enable/disable live-coding - automatically add the (non-existent) livecoding module to the app if livecoding pref is enabled - determine the variables that are live-codable - after launching the user's Monkey program, connect to the server therein over the network - show a GUI (panel, window, whatever) with a widget per live-codable variable (e.g. slider for Int) - on changes to the widget(s), send messages to the running program using a simple message protocol - disconnect when the target program is no longer running or the live-coding GUI is closed The livecoding module would need to: - auto-start a TCP server - accept connections from Ted - decode protocol messages as sent by Ted - use the reflection module to update live-codable values - if a function like "OnLiveCodingChange" is found, call it, passing the variables that were altered * One could replace Ted with a command-line tool that has a shell. On launch, this shell would connect to your running program's embedded server. You would enter commands which caused messages to be sent to your running program. TCP client/server code? Use mnet. How to determine which variables are live-codable? 1) simply expose all globals 2) globals marked up with a #livecode pragma 3) globals marked up with a 'livecode comment on the same line Why only globals? Due to the reflection module. At first blush, I'd use GetGlobal("name").SetValue(updatedValueFromRemote)What about updating code? I am not sure how to handle this as I do not see a way to serialize code and have it evaluated on the server/app to replace an existing function. This might be possible for say the HTML5 target however. It certainly won't work for iOS and Android. It could work on GFLW on hosts that support loadable code in the form of shared objects but that would require core support from Trans to create shared objects per module or something similar... Not likely. |
| ||
| I did livecoding with ImpactJS (I'll make a tutorial and post sourcecode when I have time); it's not very hard and I think the same method can apply to the HTML5 target in Monkey. I'll do some experiments, but I think for the HTML5 you can get somewhere. It's not entirely *live* though for Monkey because you'll always need to compile. But at least your changes will be immediately visible without refreshing. I know that works and it will work fine for Monkey as well, at least the HTML5 target. In the end I think someone needs to write a Monkey interpreter in Monkey though. I said it before; I feel that's the biggest thing missing from Monkey; the ability to script in Monkey. It would allow livecoding and fast testing. When you are happy about what you did, you just save it and compile it for full speed. But making an interpreter for Monkey will be a lot of work obviously. |
| ||
| Bah, you young whippersnappers don't know what slow compiles are. HTML practically *is* live coding for me. |
| ||
| Yeah, that is true. Begin 80's I swapped Z80 machines during compiles which took sometimes hours; and then more often then not your computer would hang because you did something stupid. I still have my development stack which I used then; 4 Philips NMS 8255 machines with a monitor switch and my homebrew keyboard/joystick/mouse switch to make software. Monkey is very fast compared :) But unfortunately you get used to things and REPLs like Clojure/Ruby/Python are things I really miss here. To be able to just test stuff out quickly is really something which you cannot replace with deep thinking upfront. And every few minutes compiles do add up especially when it's to test / try out something trivial... |
| ||
| interesting article on interpreters: http://www.gamedev.net/page/resources/_/technical/general-programming/design-tradeoffs-for-customized-script-interpreters-r3019 |
| ||
| +1 for the Monkey runtime interpreter, it would open up the door for native debugging in monkeycode, which in addition to live coding would greatly speed up the development process. |
| ||
| I normally code and test on html5 then when it works test on the target, although realtime testing would be cool but I do think it will be lots of work and many headaches |
| ||
| Same as EdzUp for me - though I occasionally use GLFW when I need a bit of proper debugging. |
| ||
| [deleted] said something which was already said above. Someone please make the interpreter for Monkey. |
   |