Re: Pluto updated

["Grisha" <grisha@...>]

Hi, Ben

> Glad to hear it. :) What's the project, if you don't mind my asking?
I'm working for the Eagle Dynamics team, we started to use Lua a bit for our
last project Lock On: Modern Air Combat (www.lo-mac.com). Now I'm working on
a new simulation core for future projects. Lua support is included into the
core, so that system designers (people good in aviation but not so good in
programming) can use Lua to describe objects.

> My current thinking on that is to have a separate set of functions to
build the permanents table. You'll be able to hand it top-level namespaces
("coroutine", "string", etc.) and it'll recurse through them and build a
permanents table. It'll also build a "linkage map" which you'll serialize
along with the persisted data. That linkage map, then, can be used to
rebuild the permanents table on the other end by searching through the
global environment for the proper keys. I'll eventually make it so that keys
that are not found invoke a user-defined function, which can in turn load
missing modules and plugins. I'll be working on these functions in the next
couple of days, but I haven't yet done enough conceptual work to figure out
how difficult it'll be. One thing's for sure: Unlike the current pluto
functions, which are designed for the general case, these will be designed
for the (more limited) common case. As such, their use will be completely
optional.

Great, it should work. One last thing though: when you recurse through that
top-level namespaces it's better to use string keys still. This will further
increase stability because small change in some library will not cause that
library to link wrong.

> I'm not sure that that's a problem at this point. If you have a large area
of C data that needs to be serialized, and you want to write your own
serialization function, there's no problem with that: just write it out to a
string or literally serialized userdata and save it in the fixup closure. On
the other end, use the fixup closure to invoke your custom C deserialization
functions. Since an arbitrary amount of data may be written, it's the same
functionality as if the reader/writer were given directly to the custom
serialization/deserialization functions. Does this solution sound adequate?

Not exactly: note the 'nice' word in my statement :). This approach will
work, but will require unnecessary copy of undefined amount of data several
times, which IMHO looks ugly. It would be much more convinient for
programmers to serialize userdata in it's native form, without converting it
into Lua form.

Best Regards,
Grisha

P.S. Just another feature we badly need is a remote debugger. We use LuaPlus
now but it modifies Lua core files and adds lots of features we don't need.
>From reading this list for some time looks like we are not alone with this
problem. If there'd be a small remote debugger doing just that (maybe
through LuaSocket connection?) - that would be great.