1 files changed, 118 insertions, 1 deletions
diff --git a/docs/LuaSL-New-scripting-engine.html b/docs/LuaSL-New-scripting-engine.html
index b6f9cfa..b8c730f 100644
--- a/docs/LuaSL-New-scripting-engine.html
+++ b/docs/LuaSL-New-scripting-engine.html
@@ -3,6 +3,14 @@
 <head>
 </head>
 <body bgcolor="black" text="white" alink="red" link="blue" vlink="purple">
+<p>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.</p>
+<p>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.</p>
 <h1> write our own </h1>
 <p>I had considered in the <a href="SledjHamr.html">SledjHamr</a> document writing a new script engine from scratch in Lua. This is what I wrote -</p>
 <p>"I'd love to write a Lua implementation of LSL, I'm sure Alice would want to write a Scheme one."</p>
@@ -36,11 +44,120 @@
 <h2> Design </h2>
 <p>There are a number of ways we can go about this. Do we write the entire scripting engine in Lua, and only interface with C# for those things we really need to in order to get OpenSim to do in world stuff? Do we write a LSL to Lua translation layer that then compiles the Lua? The OpenSim engine I understand does that, translates LSL to C# then compiles that to .NET. Could we start with a higher level of Lua that interfaces with the existing LSL support functions in OpenSim? Can we even rely on those LSL support functions being a stable API? Should we start by experimenting with Lua's meta language features, see how close we can get it to look like LSL syntax? Perhaps concentrate on those parts of the job that don't require interfacing to OpenSim, and hope that SledjHamr can meet it half way to avoid the entire .NET thing?</p>
 <p>I choose to do those last two things - see how far I can get Lua to look like LSL, and concentrate on the parts that don't require interfacing to OpenSim, hoping that I can avoid the entire .NET thing.</p>
+<p>The basic design will be made up as I go along, but so far I have this -</p>
+<p>A parser parses an LSL script, validating it and reporting errors.</p>
+<p>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.</p>
+<p>The Lua source is compiled by the Lua compiler.</p>
+<p>LuaJIT is used as the Lua compiler, library, and runtime.</p>
+<p>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.</p>
+<p>THIS IS WHERE WE ARE RIGHT NOW.</p>
+<p>Should implement embedded Lua somehow.  Probably the best thing to do is
+to have comments like -</p>
+<p>//Lua: local t = {1, 3, 42, x='something', 'something else}</p>
+/*Lua: print(t.x) */</p>
+<p>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.</p>
+<p>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.</p>
+<p>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</p>
+<p>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</p>
+<p>A watchdog thread should be used to make sure no LuaSL script spends
+forever processing any event.</p>
+<p>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.</p>
+<p>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.</p>
+<p>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.</p>
+<p>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.</p>
+<p>Test harness.</p>
+-------------</p>
+<p>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.</p>
+<p>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.</p>
+<p>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.</p>
+<p>Various eina logging domains might be used to handle whisper, say, shout,
+etc.</p>
+<p>Performance testing will have to be done on 5000 scripts, to see how
+that compares against XEngine.</p>
+<p>The test harness became the love world server.</p>
+<p>TODO</p>
+<p>----</p>
+<p>Useful for limiting the amount of time scripts use -
+<p>https://groups.google.com/forum/#!topic/lua-alchemy-dev/3bDPk2aQ8FE</p>
+<p>http://stackoverflow.com/questions/862256/how-can-i-end-a-lua-thread-cleanly</p>
 <p>&nbsp;</p>
 <h1> onefangs implementation ideas </h1>
 <p>I'm gonna write an LSL script engine in Lua and C. At least initially, I'll pretend I can use SledjHamr instead of OpenSim, and see how far I get. The source is at <a href="https://github.com/onefang/SledjHamr">https://github.com/onefang/SledjHamr</a> on the experimental branch.</p>
 <p>&nbsp;</p>
-<h2> You’re in a maze of twisty little quirks, all different. </h2>
+<h2> You're in a maze of twisty little quirks, all different. </h2>
 <p>LSL is known for being more quirks than features. Some of the quirks are just limitations that we can get rid of. Some we will have to replicate just to be compatible. OpenSim adds it's own quirks on top of those, but one of the points of doing this is to avoid that particular set of quirks. I'll create two variations, using the first line comment hack OpenSim invented to choose between them. The default is to use the quirky one, where an effort is made to replicate the full quirkiness of LSL. The other choice has no quirks at all, and even lets Lua features be mixed in. This Lua flavoured LSL will be the first one to work on, as it will be a lot easier.</p>
 <p>&nbsp;</p>
 <h2> Making Lua look like LSL </h2>

diff --git a/docs/LuaSL-New-scripting-engine.html b/docs/LuaSL-New-scripting-engine.html index b6f9cfa..b8c730f 100644 --- a/docs/LuaSL-New-scripting-engine.html +++ b/docs/LuaSL-New-scripting-engine.html
@@ -3,6 +3,14 @@
3	<head>	3	<head>
4	</head>	4	</head>
5	<body bgcolor="black" text="white" alink="red" link="blue" vlink="purple">	5	<body bgcolor="black" text="white" alink="red" link="blue" vlink="purple">
		6	<p>LuaSL is a Lua based LSL scripting engine that will aim for LSL
		7	compatibility first, then adding Lua extensions. It aims to replace the
		8	woeful XEngine from OpenSim, and at a later stage, be the basis for a
		9	client side scripting engine.</p>
		10	<p>To compile this, you will need Enlightenment Foundation Libraries (EFL)
		11	installed in either /opt/e17 or /usr. These are typical places it get's
		12	installed in. You will also need flex. The rest of the dependencies
		13	are in the ../libraries directory.</p>
6	<h1> write our own </h1>	14	<h1> write our own </h1>
7	<p>I had considered in the <a href="SledjHamr.html">SledjHamr</a> document writing a new script engine from scratch in Lua. This is what I wrote -</p>	15	<p>I had considered in the <a href="SledjHamr.html">SledjHamr</a> document writing a new script engine from scratch in Lua. This is what I wrote -</p>
8	<p>"I'd love to write a Lua implementation of LSL, I'm sure Alice would want to write a Scheme one."</p>	16	<p>"I'd love to write a Lua implementation of LSL, I'm sure Alice would want to write a Scheme one."</p>
@@ -36,11 +44,120 @@
36	<h2> Design </h2>	44	<h2> Design </h2>
37	<p>There are a number of ways we can go about this. Do we write the entire scripting engine in Lua, and only interface with C# for those things we really need to in order to get OpenSim to do in world stuff? Do we write a LSL to Lua translation layer that then compiles the Lua? The OpenSim engine I understand does that, translates LSL to C# then compiles that to .NET. Could we start with a higher level of Lua that interfaces with the existing LSL support functions in OpenSim? Can we even rely on those LSL support functions being a stable API? Should we start by experimenting with Lua's meta language features, see how close we can get it to look like LSL syntax? Perhaps concentrate on those parts of the job that don't require interfacing to OpenSim, and hope that SledjHamr can meet it half way to avoid the entire .NET thing?</p>	45	<p>There are a number of ways we can go about this. Do we write the entire scripting engine in Lua, and only interface with C# for those things we really need to in order to get OpenSim to do in world stuff? Do we write a LSL to Lua translation layer that then compiles the Lua? The OpenSim engine I understand does that, translates LSL to C# then compiles that to .NET. Could we start with a higher level of Lua that interfaces with the existing LSL support functions in OpenSim? Can we even rely on those LSL support functions being a stable API? Should we start by experimenting with Lua's meta language features, see how close we can get it to look like LSL syntax? Perhaps concentrate on those parts of the job that don't require interfacing to OpenSim, and hope that SledjHamr can meet it half way to avoid the entire .NET thing?</p>
38	<p>I choose to do those last two things - see how far I can get Lua to look like LSL, and concentrate on the parts that don't require interfacing to OpenSim, hoping that I can avoid the entire .NET thing.</p>	46	<p>I choose to do those last two things - see how far I can get Lua to look like LSL, and concentrate on the parts that don't require interfacing to OpenSim, hoping that I can avoid the entire .NET thing.</p>
		47
		48	<p>The basic design will be made up as I go along, but so far I have this -</p>
		49
		50	<p>A parser parses an LSL script, validating it and reporting errors.</p>
		51
		52	<p>A translator takes the result of the parse, and converts it into Lua
		53	source. Each LSL script becomes a Lua state. LSL states are handled as
		54	Lua tables, with each LSL state function being a table function in a
		55	common metatable. LL and OS functions are likely to be C or Lua
		56	functions. Careful testing should be done with LuaJIT FFI, sandboxing,
		57	and performance testing.</p>
		58
		59	<p>The Lua source is compiled by the Lua compiler.</p>
		60
		61	<p>LuaJIT is used as the Lua compiler, library, and runtime.</p>
		62
		63	<p>Luaproc is used to start up operating system threads and hand Lua states
		64	between them. Luaproc messaging is also being used, but might need to
		65	change to edje messaging. Note - luaproc has been extensively rewritten
		66	for this project, mostly converting it to use EFL. That rewrite
		67	substantially shrunk the source code. Then it was all rewritten again
		68	to use EFL threads, and cooperative multitasking.</p>
		69
		70	<p>THIS IS WHERE WE ARE RIGHT NOW.</p>
		71
		72	<p>Should implement embedded Lua somehow. Probably the best thing to do is
		73	to have comments like -</p>
		74
		75	<p>//Lua: local t = {1, 3, 42, x='something', 'something else}</p>
		76	/Lua: print(t.x) /</p>
		77
		78	<p>The LSL parser picks these up and stores them in the AST as Lua
		79	snippets, then the compiler output functions just inserts them in the
		80	Lua code it is generating. Obviously these Lua snippets can access the
		81	rest of the generated Lua code. They should also be able to access
		82	skang and thus do proper GUI stuff on viewers that support skang.</p>
		83
		84	<p>Nails will be used to pump commands in and out of the LuaSL system.
		85	Incoming commands invoke LSL events via the LuaSL state metatable. LL
		86	and OS functions that impact the world will be converted to nails
		87	commands sent to the command pump.</p>
		88
		89	<p>Initially, since this is the first thing being written, a nails command
		90	pump client needs to be installed into OpenSim's C# stuff. Though it
		91	might be possible to talk directly to ROBUST instead. Think I'll try
		92	the ROBUST route, see how far I can get. That's the general principle
		93	applying in all of this - try to avoid C# and see how for we can get.
		94	lol</p>
		95
		96	<p>On the other hand, might be better to leverage the existing C#
		97	implementations of LSL functions, just to get things up and running
		98	quickly. To that end, a protocol involving exchanging snippets of Lua
		99	over a network socket has been developed, and the next step is to write
		100	the C# side. sigh</p>
		101
		102	<p>A watchdog thread should be used to make sure no LuaSL script spends
		103	forever processing any event.</p>
		104
		105	<p>Some form of serialization will need to be created for saving script
		106	state during shutdowns, passing script state to other threads /
		107	processes / computers. Apparently Lua is good at this.</p>
		108
		109	<p>There will have to be a MySQL (and maybe SQLite) client in the system,
		110	so we can talk directly to the local sim database. Esskyuehl may be
		111	suitable, though it's still in the prototype stage.</p>
		112
		113	<p>Email, HTTP, and XML-RPC might need to be dealt with by us. A ROBUST
		114	client will be needed to. Azy might be suitable, but it's also in
		115	prototype.</p>
		116
		117	<p>An object is a file system directory, full of LSL scripts as text files,
		118	notecards as text files, animations as BVH (or later BVJ) files, etc.
		119	There will be some sort of metadata in place. This could be created by
		120	our own OpenSim compatible cache module.</p>
		121
		122
		123	<p>Test harness.</p>
		124	-------------</p>
		125
		126	<p>I'll build a test harness. It will be based on EFL Edje Lua, with
		127	buttons for triggering LSL events, SL style dialogs, and other goodies.</p>
		128
		129	<p>The initial goal will be to run standard MLP scripts. They have minimal
		130	interface to the world, and exercise quite a bit of the rest of LSL.
		131	They are also quite common, and sometimes responsible for a lot of the
		132	script running load.</p>
		133
		134	<p>Later I should add stock standard OpenCollar scripts from SL. They are
		135	a bitch to get working under OpenSim, so would be good compatability
		136	tests.</p>
		137
		138	<p>Various eina logging domains might be used to handle whisper, say, shout,
		139	etc.</p>
		140
		141	<p>Performance testing will have to be done on 5000 scripts, to see how
		142	that compares against XEngine.</p>
		143
		144	<p>The test harness became the love world server.</p>
		145
		146
		147	<p>TODO</p>
		148	<p>----</p>
		149
		150	<p>Useful for limiting the amount of time scripts use -
		151	<p>https://groups.google.com/forum/#!topic/lua-alchemy-dev/3bDPk2aQ8FE</p>
		152	<p>http://stackoverflow.com/questions/862256/how-can-i-end-a-lua-thread-cleanly</p>
		153
		154
		155
39	<p> </p>	156	<p> </p>
40	<h1> onefangs implementation ideas </h1>	157	<h1> onefangs implementation ideas </h1>
41	<p>I'm gonna write an LSL script engine in Lua and C. At least initially, I'll pretend I can use SledjHamr instead of OpenSim, and see how far I get. The source is at <a href="https://github.com/onefang/SledjHamr">https://github.com/onefang/SledjHamr</a> on the experimental branch.</p>	158	<p>I'm gonna write an LSL script engine in Lua and C. At least initially, I'll pretend I can use SledjHamr instead of OpenSim, and see how far I get. The source is at <a href="https://github.com/onefang/SledjHamr">https://github.com/onefang/SledjHamr</a> on the experimental branch.</p>
42	<p> </p>	159	<p> </p>
43	<h2> You’re in a maze of twisty little quirks, all different. </h2>	160	<h2> You're in a maze of twisty little quirks, all different. </h2>
44	<p>LSL is known for being more quirks than features. Some of the quirks are just limitations that we can get rid of. Some we will have to replicate just to be compatible. OpenSim adds it's own quirks on top of those, but one of the points of doing this is to avoid that particular set of quirks. I'll create two variations, using the first line comment hack OpenSim invented to choose between them. The default is to use the quirky one, where an effort is made to replicate the full quirkiness of LSL. The other choice has no quirks at all, and even lets Lua features be mixed in. This Lua flavoured LSL will be the first one to work on, as it will be a lot easier.</p>	161	<p>LSL is known for being more quirks than features. Some of the quirks are just limitations that we can get rid of. Some we will have to replicate just to be compatible. OpenSim adds it's own quirks on top of those, but one of the points of doing this is to avoid that particular set of quirks. I'll create two variations, using the first line comment hack OpenSim invented to choose between them. The default is to use the quirky one, where an effort is made to replicate the full quirkiness of LSL. The other choice has no quirks at all, and even lets Lua features be mixed in. This Lua flavoured LSL will be the first one to work on, as it will be a lot easier.</p>
45	<p> </p>	162	<p> </p>
46	<h2> Making Lua look like LSL </h2>	163	<h2> Making Lua look like LSL </h2>