proj-oot-ootLiveCodingNotes1

Difference between revision 5 and current revision

No diff available.

http://en.wikipedia.org/wiki/Live_coding

--

http://yaxu.org/tidal/

https://github.com/yaxu/Tidal/blob/master/doc/tidal.md

does Tidal allow encapsulation in the form of 'function definitions'? Is it Haskell or does it just look like Haskell, e.g. can you partially apply fns the same way as in Haskell?

---

can we make a 'musical keyboard' using live programming to make a musical system?

some keys would be notes, perhaps arranged in a convenient multi 'string' manner like a guitar rather than a linear manner like a piano, and others would do things like start/stop recording of notes, and then select prior recordings and cause them to repeat, and reassign keys, execute programs, and switch modes (e.g. a keyboard and also a sequencer).

---

i just read http://www.aleph.se/Nada/Game/Countdown/alien.html

can we generalize the musical keyboard to a system to create nonlinear dynamical system simulations? Could such a thing be used as a method for interacting with external nonlinear dynamical systems such as the stock market in a practical and wholistic manner, e.g. to allow us to successfully interact with such external systems without having well-founded reductionist understanding of them first?

---

would have to have something like Tidal (see above), as well as a 'reverse tidal' for recognition of external patterns

(combine with FRP and Glitch?)

a tool like Tidal would have to be augmented with common nonlinear dynamics simulation elements, e.g. positive and negative feedback with stable and unstable attractors, specify linear forces by a matrix, and also relevant control theory elements, e.g. PID controller, etc

also grammars, and meta-grammars for system specification language, e.g. lagramge

just as MIDI has banks of MIDI instruments, this tool might have a 'systems bank' with widely known systems (e.g. the logistic equation) that can be composed. This would include various famous chaotic systems, not just non-chaotic ones, and the system should make it easy to compose chaotic systems into useful things.

---

Live music programming in Haskell

http://arxiv.org/pdf/1303.5768.pdf

---

paper on tidal which also cites a bunch of similar systems:

https://raw.githubusercontent.com/yaxu/Tidal/master/doc/farm/farm.pdf

---

algorithmic composition

generative music

---

ableton and the ableton Push:

http://www.engadget.com/2013/03/24/ableton-push-review/ http://createdigitalmusic.com/2015/11/ableton-push-2-hands-on-test/ https://www.google.com/search?q=Ableton

---

" First class code hot-loading support would be a huge boon for game developers. The majority of game code is not particularly amenable to automated testing, and lots of iteration is done by playing the game itself to observe changes. I’ve got something hacked up with dylib reloading, but it requires plenty of per-project boilerplate and some additional shenanigans to disable it in production builds. "

" > First class code hot-loading support would be a huge boon for game developers. The majority of game code is not particularly amenable to automated testing, and lots of iteration is done by playing the game itself to observe changes. I’ve got something hacked up with dylib reloading, but it requires plenty of per-project boilerplate and some additional shenanigans to disable it in production builds.

Lua is a great fit here and interops with Rust(and just about everything else) very well. "

---

" While the ubiquity of global side-effects in CL is very bad, the facts that all objects that matter are addressable by a path from some global namespace and that live redefinition is actively supported makes debugging and maintaining long-lived systems with in-image persistent data more doable (see again CLOS's update-instance-for-redefined-class). This is in contrast with the Racket IDE which drops live data when you recompile the code, which is fine for student exercises, but probably wrong for live systems. CL is one of the few languages that takes long-term data seriously (though not quite as seriously as Erlang). "

---

" Observability is the property (whose name I coined in my PhD? thesis) whereby you can interrupt the execution of the program and observe it at the level of abstraction of your language (in this case, the GVM ((Gerbil Scheme Virtual Machine)). This already allows Gambit to migrate processes from one machine to the other, even though the machines may be using completely different backends (C on ia32, C on AA64, JS, PHP, Java, etc.) For my thesis, I want to generalize observability from the GVM to arbitrary virtual machines written on top of it for arbitrary languages, with plenty of cool implications (including e.g. Erlang-style robustness; see said thesis "

---

sigstoat 7 days ago [-]

> Unlike with common lisp or clojure, with racket if you make changes to your code you have to restart the REPL, which destroys your state.

that's a different issue. i believe matthias has commented on the mailing list (some years back) that the semantics associated with doing something like that are a mess, and that's why they weren't interested in implementing it.

reply

lottin 6 days ago [-]

> trivial utilities for interactive use from the shell command-line with an "instantaneous" feel

Last time I checked CL images were huge though. Something like 24MB for a "hello world" executable, even bigger with some compilers.

reply

flavio81 6 days ago [-]

You need to consider that Common Lisp includes a runtime, and this is a essential part of the goods of Common Lisp. Whenever you create a Common Lisp program, you also "embed" the runtime, and the runtime allows you to do wonderful stuff within the running code, like for example, compile code on the fly, replace function with new version (while the program is running), replace class instances with new versions of the class (while the program is running), all sorts of enforcements of the required data type for actual data* (while the program is running),

and,

it has the wonderful "conditions/restart" system. The combination of the latter with all the former, allows you to 'correct' or 'patch' a running program without really needing to recompile the whole program or even restart the running program. Famous story of usage of this feature is using it to patch a bug on the Common Lisp program for the autopilot of the NASA Deep Space One spaceship. The NASA engineers were able to debug and then fix the program while having the DS1 in space with the code running.

So, the FASL (fast load) file is basically similar to the memory file created whenever you put a laptop into "hibernation" mode; it allows you to quickly load the whole runtime, plus your code, *plus the instances of your objects or data, if needed, just straight into memory. This is how "fast load" is achieved.

Actual RAM usage of Lisp will vary with implementations; again, as I mentioned in another post, you pick the implementation that suits your particular needs.

reply

---

farray 7 days ago

parent [-]on: Why I haven't jumped ship from Common Lisp to Rack...

Executing fasls is cool, but they will start from a new empty image, and loading fasls is actually kind of slow, so if you use lots of libraries rather than write a trivial example, that may consume hundreds of milliseconds before the program actually starts. Then again, this supposes you compiled everything into a single .fasl (which ASDF makes easy). But that will be a big fasl for each program; if you want to load from libraries, then there's also the overhead of setting up and using ASDF itself, which can also be in the hundreds of milliseconds. I can imagine many ways to improve the situation, but none are cheap (e.g. implement a background daemon to serve ready executables and/or watch the source registry for modified source; or break compatibility with the entire ASDF setup, angrying the entire community).

reply

---

dnautics 2 hours ago [-]

This is basically why erlang's hot code reloading would be impossible as a general solution in a statically typed language

reply

kobeya 56 minutes ago [-]

You mean like this:

http://hackage.haskell.org/package/hotswap

Or this:

http://hackage.haskell.org/package/dyre

reply

tree_of_item 42 minutes ago [-]

15 commits 4 years ago, 121 commits 8 months ago

If these things are so good why does no one use them? EVERYONE using Erlang is using the same hotswapping facility. This sort of dynamism is just fighting against the language in an environment like Haskell.

reply

naasking 6 minutes ago [-]

Because Haskell isn't used in the same domains as Erlang, and hot patching full Haskell semantics either isn't needed, or the program is likely already using a DSL for the parts needing well defined dynamism, like the Yi editor, and so hot patching the runtime isn't needed.

reply

---

people say that you can't have hotswapping of new code if there is static typing, but i think that's not exactly true. I think that:

Static types can coexist with hotswapping/live programming provided the runtime supports dynamic typing

what i mean is that static types can have different uses:

if you only use static types for the first of these, safety/proving correctness, but still use boxed type-annotated objects and dynamic dispatch during actual execution/at runtime, then you still get to use type annotations for safety, just not for program optimization, and then you can hotswap code.

the only wrinkle that i can see is that the program correctness that will be proved is just for the current version of the program, not for some amalgamation between the previous version and the current version, which is what will be running after you hotswap. Solutions include just living with that problem, or having first-class migrations in the type system.

---