Live coding environments typically include a text editor. Sometimes as in the case of Praxis, its possible to change the behaviour of the text editor while you use it.
I wrote it for myself mainly, so a lot of the features are undocumented and hidden away. But you can have a look at fnkeys.lua, editor.lua and keymap.lua to get a general idea. These are in prods/syntax2015continued. You can bring these up in praxis and make whatever changes you like to the live system.
I like the idea of making it keyboard and buffer driven to an extreme, like the Commodore 64. For example, one simple technique I like is to "inject" code into the current buffer to place objects:
function makeCamPosSaver()
local x,y,z = getCamPos()
x = math.floor(x)
y = math.floor(y)
z = math.floor(z)
local s = "setCamPos("..x..","..y..","..z..")"
print2(s)
end
Then calling makeCamPosSaver injects a bit of code that will move the camera back where it was when you called it.
Another example: pressing F3 creates a new buffer where you are supposed to fill in a string with what you are searching for. When you run that buffer, it will switch to the old one that spawned it, and move the cursor to the next occurrence of the search string.
There are more creative ways to use this that others could come up with I'm sure.
I love live coding environments, and yours looks really fun.
Being so easy to embed, Lua is perfect for basing a live coding environment on. Here is one I made that is also based on Lua, as well as an assortment of other embeddable languages: https://github.com/createuniverses/praxis
Being able to change the universe/game while its running is why I made this.
Wow, this is very cool. It shares a lot of the underlying motivation I had in making my own game, but it's much more abstract--I wanted to make it a game specifically in order to get my kids interested, but the same underlying sense of fluidity and hackability is what I'm trying to convey in my game.
That feeling is what can make programming particularly exhilirating and rewarding, and I'm hoping to capture it in the medium of a space game whereas your project seems to be more about exploring programming for the sake of programming and seeing where it takes you.
FWIW my future plans do include embedding other languages in the game. Right now it's just Lua (and Unix, to a degree), but I'm hoping to make it so that you can discover other civilizations built on wildly different technology--at least Scheme and Forth; possibly a DOS-like system thrown in there for giggles depending on how much work it turns out to be. At first you interact with these OSes as they are installed in space stations you encounter, but eventually you learn how to load them into your own ship (virtualization) so you can take advantage of certain in-game technologies built around them.
Biologically speaking we are wired to produce kids, as such many people find deep meaning and satisfaction by raising a family. Of course this isn't for everyone, but I put it down as a driver for why people behave they way they do.
Because it's more rewarding than what almost any of us do at work. And in some ways raising a child with your values is a vote for the future direction of the world.
I certainly had Smalltalk and Lisp Machine environments in mind when I made this, the central idea being to be able to query and manipulate every part of the system while its running, to be able to fix faults and continue.
The whole thing is a repl with a graphical and audio engine at your disposal to use as you see fit. As well as writing your program iteratively in the "socratic" repl style, you are free to fluidly create whatever visualizations you wish along the way to help you. As well as this, if you split the process you have implemented into frames (a simple way is with coroutines or closures) you can make whatever visualization you prefer of your number crunching. For example, throw in some yield() calls in your program and every update() do a coroutine.resume(). In render() visualize the state of your program how you wish. The great thing about this is, as you change your program, the effect of your change will be reflected in what is rendered.
Interesting, it's something to think on. Creating such visualisations manually may be prohibitively complicated, but I can imagine some cases where they can be derived automatically (e.g., for compiler passes, an example IR can be displayed before and after).
You might also want to check out live programming, which focuses on interactive debugging rather than the improvised problem solving (as well as live performance) of live coding. Once you get to live programming, techniques like time travel become viable, which otherwise don't make much sense with live coding. You can then better tackle traditional programming problems with better live feedback.
I need to make a video demonstrating the midi recording functionality (its implemented entirely in Lua). I need to keep it short, write a script that is succinct and to the point, use a decent microphone, keep it short, actually narrate the thing and most importantly, keep it short.
Depending on what you wanted the state for, I think it satisfies most of the properties you'd be missing with a persistent, not-in loop state. It wipes itself on refresh, it has a distinct owner, it can be individually refreshed just by re-evaluating everything inside the do-block, etc.
You actually don't want to wipe on refresh; i.e. if you are doing a physics simulation using a standard stepped based integrator. You'd be surprised how many artists want to live code particle simulations.
I've wrangled a crazy way to have your cake and eat it too.
do
local state = 0
function render()
drawLine(0,5,0, 0,5,50*math.sin(state))
state = state + math.pi * 0.03
end
end
To fiddle with the "state" variable from the outside:
name,val = debug.getupvalue(render, 1)
print(name) -- state
print(val) -- state's value
debug.setupvalue(render, 1, 0) -- set state to 0
To find out how many upvalues are available:
dt = debug.getinfo(render)
print(dt.nups)
If you want to redefine render without disturbing state, you need to backup state and make a new closure with the new definition of render and the restored state:
do
local savedstate = {debug.getupvalue(render,1)}
local state = savedstate[2]
function render()
local h = 5
drawLine(0,h,0,50 * math.sin(state), h,0)
state = state + math.pi * 0.06
end
end
I don't think its possible (or I don't know how) to redefine a function inside a closure. So just make a new closure and restore its state.
Well, there are many hacks around it; see the immediate-mode programming frameworks like Sol. My own personal take on this problem is to make "refresh" a first-class part of the programming model (rather than something managed by the programmer), and then to define encapsulated state that is preserved on refresh (by the programming model). You can read about it in my paper. (http://research.microsoft.com/apps/pubs/default.aspx?id=2112...)
The trick is to generate stable IDs to represent the state, then you can think of it as a global map:
var map = new Map()
def render():
var x = map[0x138293]
...
map[0x13244] = y
This resembles your last solution above. The trick is then automatically reproducing those IDs when render is called again (not to mention tearing down any side effects no longer performed, but that is another kettle of fish).
I can't help feeling that this attempt to render a previously excellent course more commercially viable by making it more superficially appealing for students is directly linked to this story: http://news.ycombinator.com/item?id=4785246
If everything is always forced to justify itself commercially, then everything will implode into a hideous, hollow caricature of itself. Everything becomes a flashy excercise in deceit and con artistry if it wants to survive. Quality and substance can never hope to win against marketing.
https://github.com/createuniverses/praxis
I wrote it for myself mainly, so a lot of the features are undocumented and hidden away. But you can have a look at fnkeys.lua, editor.lua and keymap.lua to get a general idea. These are in prods/syntax2015continued. You can bring these up in praxis and make whatever changes you like to the live system.
I like the idea of making it keyboard and buffer driven to an extreme, like the Commodore 64. For example, one simple technique I like is to "inject" code into the current buffer to place objects:
Then calling makeCamPosSaver injects a bit of code that will move the camera back where it was when you called it.Another example: pressing F3 creates a new buffer where you are supposed to fill in a string with what you are searching for. When you run that buffer, it will switch to the old one that spawned it, and move the cursor to the next occurrence of the search string.
There are more creative ways to use this that others could come up with I'm sure.