From 7341af59640b65d409a09bec1ff891bd9e40b8ca Mon Sep 17 00:00:00 2001 From: David Walter Seikel Date: Thu, 18 Feb 2016 13:24:40 +1000 Subject: Shift some docs around, and link to them. --- docs/README.LuaSL | 121 ------------------------------------------------------ 1 file changed, 121 deletions(-) delete mode 100644 docs/README.LuaSL (limited to 'docs/README.LuaSL') diff --git a/docs/README.LuaSL b/docs/README.LuaSL deleted file mode 100644 index 7556bf7..0000000 --- a/docs/README.LuaSL +++ /dev/null @@ -1,121 +0,0 @@ -Refer to - LuaSL_New_scripting_engine.html - -LuaSL is a Lua based LSL scripting engine that will aim for LSL -compatibility first, then adding Lua extensions. It aims to replace the -woeful XEngine from OpenSim, and at a later stage, be the basis for a -client side scripting engine. - -To compile this, you will need Enlightenment Foundation Libraries (EFL) -installed in either /opt/e17 or /usr. These are typical places it get's -installed in. You will also need flex. The rest of the dependencies -are in the ../libraries directory. - - -Design. -------- - -The basic design will be made up as I go along, but so far I have this - - -A parser parses an LSL script, validating it and reporting errors. - -A translator takes the result of the parse, and converts it into Lua -source. Each LSL script becomes a Lua state. LSL states are handled as -Lua tables, with each LSL state function being a table function in a -common metatable. LL and OS functions are likely to be C or Lua -functions. Careful testing should be done with LuaJIT FFI, sandboxing, -and performance testing. - -The Lua source is compiled by the Lua compiler. - -LuaJIT is used as the Lua compiler, library, and runtime. - -Luaproc is used to start up operating system threads and hand Lua states -between them. Luaproc messaging is also being used, but might need to -change to edje messaging. Note - luaproc has been extensively rewritten -for this project, mostly converting it to use EFL. That rewrite -substantially shrunk the source code. Then it was all rewritten again -to use EFL threads, and cooperative multitasking. - -THIS IS WHERE WE ARE RIGHT NOW. - -Should implement embedded Lua somehow. Probably the best thing to do is -to have comments like - - -//Lua: local t = {1, 3, 42, x='something', 'something else} -/*Lua: print(t.x) */ - -The LSL parser picks these up and stores them in the AST as Lua -snippets, then the compiler output functions just inserts them in the -Lua code it is generating. Obviously these Lua snippets can access the -rest of the generated Lua code. They should also be able to access -skang and thus do proper GUI stuff on viewers that support skang. - -Nails will be used to pump commands in and out of the LuaSL system. -Incoming commands invoke LSL events via the LuaSL state metatable. LL -and OS functions that impact the world will be converted to nails -commands sent to the command pump. - -Initially, since this is the first thing being written, a nails command -pump client needs to be installed into OpenSim's C# stuff. Though it -might be possible to talk directly to ROBUST instead. Think I'll try -the ROBUST route, see how far I can get. That's the general principle -applying in all of this - try to avoid C# and see how for we can get. -lol - -On the other hand, might be better to leverage the existing C# -implementations of LSL functions, just to get things up and running -quickly. To that end, a protocol involving exchanging snippets of Lua -over a network socket has been developed, and the next step is to write -the C# side. sigh - -A watchdog thread should be used to make sure no LuaSL script spends -forever processing any event. - -Some form of serialization will need to be created for saving script -state during shutdowns, passing script state to other threads / -processes / computers. Apparently Lua is good at this. - -There will have to be a MySQL (and maybe SQLite) client in the system, -so we can talk directly to the local sim database. Esskyuehl may be -suitable, though it's still in the prototype stage. - -Email, HTTP, and XML-RPC might need to be dealt with by us. A ROBUST -client will be needed to. Azy might be suitable, but it's also in -prototype. - -An object is a file system directory, full of LSL scripts as text files, -notecards as text files, animations as BVH (or later BVJ) files, etc. -There will be some sort of metadata in place. This could be created by -our own OpenSim compatible cache module. - - -Test harness. -------------- - -I'll build a test harness. It will be based on EFL Edje Lua, with -buttons for triggering LSL events, SL style dialogs, and other goodies. - -The initial goal will be to run standard MLP scripts. They have minimal -interface to the world, and exercise quite a bit of the rest of LSL. -They are also quite common, and sometimes responsible for a lot of the -script running load. - -Later I should add stock standard OpenCollar scripts from SL. They are -a bitch to get working under OpenSim, so would be good compatability -tests. - -Various eina logging domains might be used to handle whisper, say, shout, -etc. - -Performance testing will have to be done on 5000 scripts, to see how -that compares against XEngine. - -The test harness became the love world server. - - -TODO ----- - -Useful for limiting the amount of time scripts use - -https://groups.google.com/forum/#!topic/lua-alchemy-dev/3bDPk2aQ8FE -http://stackoverflow.com/questions/862256/how-can-i-end-a-lua-thread-cleanly -- cgit v1.1