Re: 5.1 package proposal and Kepler libs

Hi Adrian,
very nice summary!
I basically agree with what you write,
Here's my 2c :
> The "compat-5.1.lua" script must be loaded before all other 
> scripts/modules, so the appropiate module() and require() functions
> are defined by it. I propose to load it from "luacheia.lua" (our 
> bootscript). A good place to load it is at the end, so we don't break
>  things from our bootscript.

Okay

> As "compat-5.1.lua" can use LUA_PATH to find scripts and LUA_CPATH
> for binary modules, we must add the LuaCheia paths to that variables.
> I think the best approach is from "luacheia_wrapper.c": if the
> variables exist, LuaCheia's paths are appended to them; otherwise the
> variables are created before spawning the Lua interpreter.

Okay

> Finally, the C functions defined in "compat-5.1.c" should be in the 
> "liblualib.{a,so}" shared libraries, so it's available to C modules 
> using the new API. I though two possible solutions:

I'd vote for version A:

> A.)  Link "compat-5.1.o" into "lauxlib.{so,a}", and merge the
> function definition from "compat-5.1.h" into "lauxlib.h". This
> approach modifies Lua sources, but migration to 5.1 will be easier,
> as things will be in the right place without touching anything.

This seems to be the 'easiest' approach.
Are we sure that in 'official' Lua 5.1 things will be there also? Is 
that 'fixed'?

> Regarding module adaptation to the new module system, if we don't zap
>  the "cheia.load", "cheia.loadlib" and "cheia.gluaload" functions we
> can still load our modules without modifying them. New modules or
> adapted ones can be loaded with the new "require()" implementation
> shipped into "compat-5.1.lua". When loading a module that uses the
> new module system via the "cheia.load" function we can print some
> kind of "deprecation warning" to stderr. Somewhat in the future we'll
> have to bury "cheia.load" and friends deep in the earth as a phantom
> of the past xDDDD

I do not have a big problem with dumping cheia.load and friends now or 
later... The evolution of LuaCheia has seen more than one move like this ;)
I would suggest leaving them as you say for now and slowly migrating 
existing modules...
The only modules I imagine that could be a 'problem' are gluahost based 
ones... or any module using a non-standard loading mechanism for that 
matter...

Okay, that's just my 2 cents.

Do I understand this right: we can expand LuaCheia in a way that we can 
used 'both worlds' side by side? That would be my favorite.

Thanks very much Adrian,
-Martin


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/