Pluto Library

lua-users home

Pluto is a heavy duty persistence library for Lua.

(For an improved version of the library see: TamedPluto, for a rewrite/port for Lua 5.2 see: [Eris])

Web site: . (Older versions are at a different location [1].)

Description: Pluto is a library which allows users to write arbitrarily large portions of the "Lua universe" into a flat file, and later read them back into the same or a different Lua universe. Object references are appropriately handled, such that the file contains everything needed to recreate the objects in question.

Pluto has the following major features:

For more information, please see the README file.

Dependencies: Pluto 2.0 requires Lua 5.1. Pluto 1.2 requires Lua 5.0.x, where x is 2 or later. If you have Lua 5.0 or Lua 5.0.1, you will need to apply the pc patch listed on the official Lua bugs page or you will receive assertions in luaV_execute when an unpersisted thread returns from a function. Users who experience difficulties are strongly advised to define lua_assert in llimits.h to something useful when compiling in debug mode, to catch assertions by Pluto and Lua.

Contact: Please send questions, comments, bug reports, feature requests, death threats, and chocolate chip cookie recipes to

Author: BenSunshineHill

User Comments

What is the behavior of Pluto regarding lexical closures?

In short, correct.

Are the lexically scoped variables persisted, and do the relationships between the variables and functions persist also?


For example, multiple functions may access the same lexically scoped variable. If they are persisted, and restored, do they still work together, on the same variable?

Hell yes they do.

If so, how? Is the debug interface used?

It treats them properly now. The change was a relatively simple one.

Oh, and Pluto doesn't use the debug interface at all (except insofar as it goes out of its way to keep the debug interface happy). Instead, it directly manipulates the internals. The nice thing about using Pluto for this is that I've already done it so you don't have to. ;)

How about userdata and lightuserdata?

These can be persisted literally, or you can provide persist/unpersist functions to handle cases where i.e. userdata references c-ptrs or must be prepared otherwise.

RecentChanges · preferences
edit · history
Last edited September 23, 2013 3:37 am GMT (diff)