Hmm yeah. So far it seems like making our own local variable system is the way to go...<div><br></div><div>It'd be good to test it out with a handful of scripts and see what it does... if it's a big improvement, then we could apply it to everything else. It'd just take some grunt work. :)<br>
<br><div class="gmail_quote">On Tue, Jul 6, 2010 at 9:46 PM, Andrew Church <span dir="ltr"><<a href="mailto:achurch%2Baquaria@achurch.org">achurch+aquaria@achurch.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Okay, never mind all that. It looks like Lua resolves global variable<br>
references in functions when the function is compiled, not when it's<br>
called, so you can't set up a nested thread environment and have the<br>
functions use that. (Well, you can, but it requires even more hacks.)<br>
It worked in my original version only because I was always loading the<br>
script after creating the thread.<br>
<br>
Best laid plans, as they say...<br>
<div><div></div><div class="h5"><br>
--Andrew Church<br>
<a href="mailto:achurch@achurch.org">achurch@achurch.org</a><br>
<a href="http://achurch.org/" target="_blank">http://achurch.org/</a><br>
<br>
>Well, the way Lua threads work (as I understand it, anyway) is that each<br>
>thread is sort of a "lightweight" lua_State, in the sense that when you<br>
>create it, it shares the global table of the original lua_State you<br>
>created it from. But it's still a separate state block, so you can set<br>
>a new environment table and the thread will then use that instead of the<br>
>original.<br>
><br>
>Since Lua also lets you link tables together using the "index"<br>
>metamethod (see under <a href="http://www.lua.org/manual/5.1/manual.html#2.8" target="_blank">http://www.lua.org/manual/5.1/manual.html#2.8</a>),<br>
>you can nest environments by setting the thread environment's index<br>
>metamethod to the original global table -- that way the thread can read<br>
>from both its own environment and the shared globals, but it can't write<br>
>to the shared globals so it won't interfere with any other instances of<br>
>the same script.<br>
><br>
>It looked convenient to me, anyway. (:<br>
><br>
> --Andrew Church<br>
> <a href="mailto:achurch@achurch.org">achurch@achurch.org</a><br>
> <a href="http://achurch.org/" target="_blank">http://achurch.org/</a><br>
><br>
>>I suppose I don't understand the thread method very well, so that may be<br>
>>hampering my ability to see the advantages/disadvantages to either. :)<br>
>><br>
>>On Tue, Jul 6, 2010 at 6:59 PM, Andrew Church<br>
>><<a href="mailto:achurch%2Baquaria@achurch.org">achurch+aquaria@achurch.org</a><<a href="mailto:achurch%252Baquaria@achurch.org">achurch%2Baquaria@achurch.org</a>><br>
>>> wrote:<br>
>><br>
>>> Just that it feels really roundabout to me, especially with all the "v."<br>
>>> prefixes added to the variables. As long as we have to set something,<br>
>>> why not just set it once when the thread is created? Then you don't have<br>
>>> to worry about updating it later, plus you can use "global" variables in<br>
>>> the scripts without worrying about forgetting a "v." somewhere.<br>
>>><br>
>>> --Andrew Church<br>
>>> <a href="mailto:achurch@achurch.org">achurch@achurch.org</a><br>
>>> <a href="http://achurch.org/" target="_blank">http://achurch.org/</a><br>
>>><br>
>>> >What's wrong with setting a global variable before each script function is<br>
>>> >called?<br>
>>> ><br>
>>> >On Tue, Jul 6, 2010 at 6:41 PM, Andrew Church<br>
>>> ><<a href="mailto:achurch%2Baquaria@achurch.org">achurch+aquaria@achurch.org</a> <<a href="mailto:achurch%252Baquaria@achurch.org">achurch%2Baquaria@achurch.org</a>><<br>
>>> <a href="mailto:achurch%252Baquaria@achurch.org">achurch%2Baquaria@achurch.org</a> <<a href="mailto:achurch%25252Baquaria@achurch.org">achurch%252Baquaria@achurch.org</a>>><br>
>>> >> wrote:<br>
>>> ><br>
>>> >> Okay, so I've run into a little problem with this. I'm not sure what<br>
>>> >> approach your friend took, but what I've done so far is put a<br>
>>> >> "v = getVars()" at the top of each script, and put "v." in front of all<br>
>>> >> local variables. The problem is that the functions in each script all<br>
>>> >> see only a single version of "v", because the getVars() is only executed<br>
>>> >> once per script instance.<br>
>>> >><br>
>>> >> I guess one way around this would be to add a getVars() call to every<br>
>>> >> function, but that feels a bit fragile to me -- too easy to miss one<br>
>>> >> somewhere, and you can't even trace the problem easily because it'll<br>
>>> >> fall back to the global "v" definition (which you need for initializing<br>
>>> >> stuff at the top of the script).<br>
>>> >><br>
>>> >> What I did for now was to update "v" with the current instance's<br>
>>> variable<br>
>>> >> table right before each call into Lua, but that feels like a hack to me;<br>
>>> >> if we have to mess with the Lua environment from C, we might as well go<br>
>>> >> back to the nested environments I was using before, because at least<br>
>>> with<br>
>>> >> those you don't have to to a lua_setglobal() on every Lua function call.<br>
>>> >><br>
>>> >> I don't know Lua too well, so maybe I'm missing something obvious --<br>
>>> >> any other suggestions?<br>
>>> >><br>
>>> >> --Andrew Church<br>
>>> >> <a href="mailto:achurch@achurch.org">achurch@achurch.org</a><br>
>>> >> <a href="http://achurch.org/" target="_blank">http://achurch.org/</a><br>
</div></div><div><div></div><div class="h5">_______________________________________________<br>
aquaria mailing list<br>
<a href="mailto:aquaria@icculus.org">aquaria@icculus.org</a><br>
<a href="http://icculus.org/mailman/listinfo/aquaria" target="_blank">http://icculus.org/mailman/listinfo/aquaria</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Alec Holowka<br><a href="http://www.infiniteammo.ca">www.infiniteammo.ca</a><br><a href="http://www.bit-blot.com">www.bit-blot.com</a><br>
</div>