Live data from Hacker News

Praxis – A live coding environment based on Lua, Lisp and Forth

github.com

11–20 of 22 posts

Re: Praxis – A live coding environment based on Lua, Lisp and Forth

#11
post #8

So far all of the live coding demos were about graphics. I wonder if it's possible to do something similar with something of a much less interactive nature - say, number crunching, compilers, linkers, etc.

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 visualizatio…

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).

Re: Praxis – A live coding environment based on Lua, Lisp and Forth

#12
post #11

Earlier quoted context omitted.

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 visualizatio…

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.

Re: Praxis – A live coding environment based on Lua, Lisp and Forth

#13
post #7

Earlier quoted context omitted.

Your render loop looks like: while true: renderP() Now, renderP will get executed afresh each time. Assuming no static data, if you want any state at all it must be global to the loop; e.g. var state = initValue while true: renderP(ref state) Immediate-mode UIs suffer from the same constraint, and really, the author is getting most of their liveness by being immediate.

What about the old let-over-lambda? do var state = init fn renderP() ... end end 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.

Re: Praxis – A live coding environment based on Lua, Lisp and Forth

#16
post #7

Earlier quoted context omitted.

What about the old let-over-lambda? do var state = init fn renderP() ... end end 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.

Re: Praxis – A live coding environment based on Lua, Lisp and Forth

#17

More often than not, these interactive / interpreted environments feel like Smalltalk by installment.

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.

Re: Praxis – A live coding environment based on Lua, Lisp and Forth

#18

Earlier quoted context omitted.

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 = deb…

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).

Re: Praxis – A live coding environment based on Lua, Lisp and Forth

#19

More often than not, these interactive / interpreted environments feel like Smalltalk by installment.

This is actually a law:

Whenever someone brings up any kind of interactive programming environment, no matter how much it does not resembles Smalltalk or Lisp, someone will always say it completely resembles Smalltalk or Lisp with no significant improvement. We call it the "smug smalltalk/lisp weenie" syndrome.

BTW, Smalltalk supports hotswapping without the liveness of course. There is nothing in smalltalk that allows the code to re-execute in its proper context without execution coming back to the code in a refresh loop setup by the user.

Re: Praxis – A live coding environment based on Lua, Lisp and Forth

#20
post #8

So far all of the live coding demos were about graphics. I wonder if it's possible to do something similar with something of a much less interactive nature - say, number crunching, compilers, linkers, etc.

I absolutely think so.

My ideal environment would have the ability to pause at a certain point, saving the state. Then I want to run to a another point (maybe only a few lines to a couple dozen lines down) and see the variable values and results in between.

Basically I want to live code with some defined input to section off parts of the program and still be able to iterate quickly by seeing results every time what I am typing will compile.

I also want to be able to visualize more data than just single values. I want to be able to see results of flat arrays, and write custom visualizers for more complex data structures. I have actually done a lot in this area, essentially by having a window in a separate thread that I can pass closures to (that run openGL functions on their data to draw it). This works incredibly well to let you see your software run. I don't know how I would have been able to write and debug some very difficult programs without it.

Post reply on HN