lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Hi, Virgil

Actually, there's no need for either size information or terminator:
userdata must save exactly same amount of data, as it will load. I
understand that then you can't handle situation when it doesn't from Pluto,
but it's a problem of userdata's programmer. IMHO if you load userdata
wrong - your overall loading procedure will not succeed, so there's no point
in trying to recover and continue loading.

About light userdata: we don't use it not because it lacks size, but because
it lacks metatable. We are quite happy with the way Lua handles userdatas

Best Regards,

----- Original Message ----- 
From: "Virgil Smith" <>
To: "'Lua list'" <>
Sent: Thursday, June 10, 2004 6:57 PM
Subject: RE: Pluto updated

> > Not exactly: note the 'nice' word in my statement :). This approach will
> work, but will require unnecessary copy of undefined amount of data
> times, which IMHO looks ugly. It would be much more convinient for
> programmers to serialize userdata in it's native form, without converting
> into Lua form.
> The problem with this suggestion is that it gets ugly itself with respect
> object length encoding/termination in the resulting stream.  Lots of
> don't know their serialized size until after serialization is complete.
> such object must either accept a copy operation in the process OR requires
> use of a terminator(a.k.a. sentinel) value/sequence, which in turn must be
> guaranteed not to occur in the stream or an escaping mechanism must be
> added. <Actually there is another option, but it violates the stream
> and so does not fit with the reader/writer function abstractualization,
> back up in the "stream" to record the length.>
> It seems inappropriate to me for Pluto to enforce a terminator/escaping
> mechanism.  So it would have to rely on C code associated with the
> to enforce its own mechanism, which requires that the userdata must add
> form of identification into the stream BEFORE it serializes, and then if
> that identification cannot be matched to something in the Lua universe
> during the unpersist operation then the whole remainder of the stream will
> be lost.
> IMHO this complexity is not advisable for heavily reused code.  I think it
> would be better to keep the mainline code as simple and intelligible as
> possible and then let users customize the code to handle specialized
> NOTE: There is 1 additional case to be mentioned (and I think its the case
> that Grisha was discussing).  The naively simple serialization method for
> structures, etc. is to just binary copy them (or parts of them) into the
> stream.  In this case the current lua_pushuserdata interface is
> inefficient because it will require a pointless raw copy operation.  This
> not a fault of Pluto so much as a falt in Lua5 (see the "Lua and C memory
> management" thread).  A "light" userdata is useless as a buffer pointer
> because it does not include size information.  A "full" userdata requires
> side objects to be tied to Lua immediately upon creation, or force a copy
> operation.  What would be handy here is something like a "middleweight"
> userdata that contains a pointer and a size.  A __persist metamethod could
> create these rather than create full userdata and copy the data into it.
> Of course it would be very nice if Lua5.1 "fixed" userdata in this way,
> Pluto would not have to add its own special case "type".  On the other
> usage consistent with a contiguous buffer of the specified length could
> be enforced by Lua, and it would even be advantageous for some GC purposes
> if this was NOT the norm (unless userdata also get a useful per-instance
> data mechanism in which to keep a full list of buffer/length pairs to
> all dynamically allocated members).