1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
|
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
|
