Brief explanation: The BOT system used in LT keeps all application state in a globally accessible index. A browser tools could use this to show lists of object types, objects, behaviours and tags updating in real time and filterable by type and key/value search. This would let new developers browse through state to get an overview of where things are stored and then drill down to watch the objects they are interested in and see how they change over time.
Expected results: A UI for browsing and searching behaviours, objects and tags that updates in real time
Knowledge prerequisites: Familiarity with clojurescript and experience with building interactive HTML apps
Mentor: Jamie Brandon
Brief explanation: Currently, running a daemon for eg background code analysis is painful. See node.cljs for an example of the boilerplate required. The manager will need to handle asking the user for arguments (eg which virtualenv to use), starting a process or connecting to an existing one, piping stdout/stderr into the console, displaying meaningful error messages to the user, displaying restart buttons for failed connections etc
Expected results: Creating a connection to eg tern or ensime is as simple as passing the executable path and arguments. The connection manager handles updating the UI, reporting errors and restarting the connection. Connections that want to override defaults can do so (probably via adding/removing behaviours).
Knowledge prerequisites: Familiarity with clojurescript and experience with async IO in node.js
Mentor: Jamie Brandon
Brief explanation: Currently, writing a plugin for LT requires learning clojurescript. Joshua Cole has written a basic wrapper (ltrap) and a few javascript plugins but manually wrapping the LT core is not a sustainable solution. We need to come up with some standards for communicating between cljs and js that don’t involve converting everything by hand.
Expected results: Developers can write plugins in javascript. This includes defining behaviours/objects, modifying objects and raising triggers. The javascript code is clean and idiomatic (no lt.object.__GT_behavior_name). The bindings do not require constant effort to keep up to date when we modify LT core.
Knowledge prerequisites: Familiarity with clojurescript and javascript.
Mentor: Jamie Brandon
Brief explanation: In the original Light Table videos we showed the ability to edit functions outside of the files that they are stored in. The end result was a ‘codex’ - a kind of virtual document made up of text from multiple different source documents. This idea didn’t make it into the current version of Light Table but it is still regularly requested. CodeMirror (the editor on which LT is based) already has the ability to create linked documents so the remaining work is mostly in parsing function boundaries and exposing an intuitive UI.
Expected results: Users can create a codex and add text from other files. When either the codex or the source file is modified, both are updated immediately. Rather than manually selecting a region of text to add, the user can run an ‘Add function to codex’ command which parses the text around the cursor position to find function boundaries.
Knowledge prerequisites: Familiarity with clojurescript, knowledge of parsing algorithms and experience with building interactive HTML apps
Mentor: Jamie Brandon