I'm afraid I haven't gotten to deep into the persistence yet. Can you clarify what you mean by type?
Ideally you wouldn't persist OOLua type's as such. (at least as I understand them) You would just persist the objects. To load the persisted data you would re-register the OOLua types, rebuild the C++ objects (using a different persistence/serialization mechanism) and rebuild OOLua's index of Lua object to C++ object. The final step would be to rebuild the Lua state. At that point execution would continue as if nothing happened. Unfortunately the ideal scenario doesn't seem all that doable.
I don't understand the internals of OOLua and/or Eris enough to tweak them to my needs at this time. Hopefully in the future when I have a little more time I'll be able to experiment with that. Currently I'm going to implement a simple type system over OOLua and use OOLua to export C functions. The simple type system will allow me to pass string based ids between Lua and C++. The simple type system will provide some degree of type safety and then I can use Eris to persist the Lua objects easily enough.
You mentioned you experienced the kernel panic because Eris attempted to persist the metatable as well right? This seems to be expected behavior: "Note that the table's or userdata's metatable will also be persisted, if present." [1]
[1] https://github.com/fnuecke/eris#special-persistence-----Original Message----- From: Liam Devine
Sent: Monday, October 28, 2013 4:09 PM To: oolua@xxxxxxxxxxxxx Subject: [oolua] Re: Saving OOLua State On 28/10/13 11:11, Liam Devine wrote:
On 28/10/13 05:44, apscience wrote:Hello again, As part of the project I’m working on I want to be able to stop, save the program state, and then load it at another time. Saving the program state includes the Lua state. However with OOLua I’m a little stumped on how to do this. Saving the C++ objects themselves is easy enough. I can save the Lua state using eris [1]... My other thought would be to onlyshare a string id of objects with lua and then export c++ functions with OOLua as static functions which take the string id and then look up the correct c++ object. However that sounds like I’m remaking a lot of OOLua’s functionality there (like inheritance/type safety/etc.) Any thoughts would be appreciated. Thank you again for the help you’ve already provided. [1] https://github.com/fnuecke/erisSound interesting, I would be pleased if you kept me informed of your progress on this matter. > However I’m not sure how I’d re-link the lua objects to the > C++ objects after loading the state OOLua keeps a table of the mappings between class pointers and Lua userdata pointers that is stored in the registry which maybe of interest. See [1], although it is possible for there to be multiple entries in this table that point to the same userdata, this is due to offsets off pointers in class hierarchy. [1] https://bitbucket.org/liamdevine/oolua/src/c9c4510f48ed5c2de4c64c79c0cedae8c5440442/include/proxy_storage.h?at=OOLua-2
How far have you got with trying to persist OOLua types?
I added a tag OOLUA::Persist Tag and when registering the type in the
lua_State, looked for it and set a metatable field mt['__persist']=true.
It seems the Eris code does not persists it as it documents; instead it
also wanted to persist the metatable[1] at which point it finds light C
Functions and causes a Lua API Panic.
I looked at the test diretory but it was a litle thin to say the least.
So I wonder if this is a bug in the code or documenation, but without
some sort of test coverage I do not want to edit the library.
Not really sure how feasible it would be to persist OOLua types, what
happens for Abstract types? or when types have more derived types that
the code base knows nothing about?
[1]
static void
p_literaluserdata(Info *info) { /* ...
udata */
const size_t size = lua_rawlen(info->L, -1);
const void *value = lua_touserdata(info->L, -1);
WRITE_VALUE(size, size_t);
WRITE_RAW(value, size);
p_metatable(info);/*huh?*/
/* ... udata */
}
--
Liam
