1. 02 Jun, 2014 1 commit
    • Christian Schulte zu Berge's avatar
      Further work on Lua scripting console: · f1b3cd9a
      Christian Schulte zu Berge authored
      * Implemented one single gloabel Lua VM for the entire CampVisApplication instead of one VM for each pipeline.
      * The global Lua VM has a "pipelines" table/array, holding the pointers to each loaded pipeline
      * ScriptingWidget support cycling through last executed commands via the arrow keys
      * LuaVmState supports redirecting Lua's print() function to a custom one that uses tgt::Logmanager for printing (just as proof-of-concept). This shall later be extended to pass all Lua output to the scripting console.
  2. 31 May, 2014 1 commit
    • Christian Schulte zu Berge's avatar
      Started implementation of a Lua console in campvis-application. · a33ee468
      Christian Schulte zu Berge authored
      With scripting enabled, the main window now has an additional scripting widget that allows to interact with a Lua VM. The current proof-of-concept implementation creates a Lua VM for every instantiated CAMPVis pipeline while the console just interacts with the first pipeline's one.
      However, the Lua VM concept has to be reiterated later anyway. It may make more sense to have just a single central Lua VM for the entire application, which is shared by each pipeline.
  3. 11 May, 2014 1 commit
    • Artur Grunau's avatar
      Improve documentation of LuaPipeline and related classes · dc76b535
      Artur Grunau authored
      Glue classes that live in the `scripting/glue` directory were mostly
      undocumented, and the documentation of LuaPipeline was incomplete.
      Improve the documentation of LuaPipeline and LuaVmState. Document
      LuaTable, RegularLuaTable and GlobalLuaTable from the `scripting/glue`
      References #1
  4. 10 May, 2014 2 commits
    • Artur Grunau's avatar
      Guard accesses to Lua state with a mutex · a337b188
      Artur Grunau authored
      Now that support for signals and slots has been added to Lua pipelines,
      each Lua state has to be protected with a mutex because it's not
      thread-safe and different threads (running LuaPipeline or a processor
      attached to it) may try to access it simultaneously.
      The mutex needs to be recursive due to the fact that Lua code can
      trigger the emission (or copying) of signals that have slots defined it
      Lua connected to them. This in turn causes the state to be accessed from
      a thread that, unbeknownst to it, already holds a lock on the mutex.
      A pointer to the mutex is stored in the state's registry; this way code
      that accesses Lua state directly (e.g. connections between sigslot's
      signals and slots defined in Lua) can retrieve and lock it when
      References #1
    • Artur Grunau's avatar
      Add several helper classes for accessing Lua state · 4e87e812
      Artur Grunau authored
      Interacting with Lua using its low-level C API quickly becomes cumbersome
      and error-prone. In such cases introducing an object-oriented glue layer
      makes accessing Lua state considerably easier.
      This commit adds several helper classes to campvis-scripting. The abstract
      LuaTable and its concrete sub-classes RegularLuaTable and GlobalLuaTable
      should make working with Lua tables more pleasant by reducing common
      operations to a single method call. LuaVmState's task is to simplify the
      management of Lua VM's state with various high level methods that do
      automatic error checking.
      The new classes are largely undocumented. This will be fixed in a future
      References #1