lummao 0.4.0

Toolkit for compiling and executing the Linden Scripting Language as Python

Lummao

Lummao is a toolkit for compiling and executing the Linden Scripting Language as Python. It aims to ease testing of LSL code by leveraging Python's existing ecosystem for debugging and testing. Think of it as the less opinionated, stupider cousin of LSLForge's unit testing framework.

The runtime is largely handled by the excellent implementation of LSL's basic operations and library functions from Sei Lisa's LSL-PyOptimizer. See vendor/lslopt for Lummao's vendored copy of LSL-Pyoptimizer.

To see an example input script and its Python output, see the test_resources directory.

Setup

pip install --upgrade pip
pip install lummao

From source

pip install -e .

How

For a real-world example, see https://github.com/SaladDais/SLGraphPather or https://github.com/SaladDais/SickJoke's tests and test coverage reporting.

Along with the python API, a helper lummao script is provided that takes in an LSL file and outputs a python file. It can be invoked like lummao input.lsl output.py.

Why

If you've ever written a sufficiently complicated system in LSL, you know how annoying it is to debug your scripts or be sure if they're even correct. Clearly the sanest way to bring sanity to your workflow is to convert your LSL scripts to Python, so you can mock LSL library functions and use Python debuggers. Hence the name "Lummao".

TODO

• Symbol shadowing behavior is not correct. Python has very different shadowing rules.
• Provide mock helpers for:
• • inter-script communication
• • HTTP
• • auto-stubs for all functions
• • state-aware event queueing

License

GPLv3

Licensing Clarifications

The output of the compiler necessarily links against the GPL-licensed runtime code from LSL-PyOptimizer for functionality, and LSL-PyOptimizer does not provide a library exception in its license. You should assume that any LSL converted to Python by the compiler and any testcases you write exercising them must also be distributable under the GPL.

In short: If or when you distribute your testcases, you must also allow distribution of their direct dependencies (your LSL scripts) under the terms of the GPL. This does not necessarily change the license of your LSL scripts themselves, or require consumers of your scripts to license their own scripts under the GPL. It is perfectly possible to have an otherwise MIT-licensed or proprietary library with a GPL-licensed test suite. No distribution of testcases == no requirement to distribute under the GPL.

Suggested reading to understand your rights and obligations under the GPL when using a GPL-licensed test suite:

• https://www.gnu.org/licenses/gpl-3.0.html
• https://opensource.stackexchange.com/questions/7503/implications-of-using-gpl-licenced-code-only-during-testing
• https://opensource.stackexchange.com/questions/4112/using-gpl-library-in-unit-test-suite-of-open-source-library