Lua 5.0 and 5.1 together

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Lua 5.0 and 5.1 together

Diego Nehab-3
Hi,

I was wondering if we have a robust solution for having two version of
Lua installed at the same time. Surely, we can have different
directories for all the extension libraries, and different names for the
interpreters. But right now there is a colision in the name of the
environment variables LUA_PATH and LUA_CPATH.

Sure, we can fix Compat-5.1 to use LUA_PATH50 and LUA_CPATH50, or
something similar. But when Lua 5.2 is released, it would be nice if a
standard was in place. During transitions and especially for developers
of libraries, it would be great to have both versions working at the
same time.

Regards,
Diego.
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.0 and 5.1 together

D Burgess-4
> I was wondering if we have a robust solution for having two version of

I thought we had it.
The default LUA_PATH and :LUA_CPATH have 5.1 in the path name
for *nix, Windows uses the module directory. It seems to work
ok for me.

DB
On 4/4/06, Diego Nehab <[hidden email]> wrote:

> Hi,
>
> I was wondering if we have a robust solution for having two version of
> Lua installed at the same time. Surely, we can have different
> directories for all the extension libraries, and different names for the
> interpreters. But right now there is a colision in the name of the
> environment variables LUA_PATH and LUA_CPATH.
>
> Sure, we can fix Compat-5.1 to use LUA_PATH50 and LUA_CPATH50, or
> something similar. But when Lua 5.2 is released, it would be nice if a
> standard was in place. During transitions and especially for developers
> of libraries, it would be great to have both versions working at the
> same time.
>
> Regards,
> Diego.
>
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.0 and 5.1 together

John Belmonte
In reply to this post by Diego Nehab-3
Diego Nehab wrote:

> Hi,
>
> I was wondering if we have a robust solution for having two version of
> Lua installed at the same time. Surely, we can have different
> directories for all the extension libraries, and different names for the
> interpreters. But right now there is a colision in the name of the
> environment variables LUA_PATH and LUA_CPATH.
>
> Sure, we can fix Compat-5.1 to use LUA_PATH50 and LUA_CPATH50, or
> something similar. But when Lua 5.2 is released, it would be nice if a
> standard was in place. During transitions and especially for developers
> of libraries, it would be great to have both versions working at the
> same time.

Hi Diego,

I already tried suggesting this
(http://lua-users.org/lists/lua-l/2006-02/msg00461.html).

We can get by without the Lua authors making a standard, just as we do
regarding versioned names of the lua and luac executables.  Really only
the people doing packaging need to agree.

--John
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.0 and 5.1 together

Diego Nehab-3
Hi,

> I already tried suggesting this
> (http://lua-users.org/lists/lua-l/2006-02/msg00461.html).
>
> We can get by without the Lua authors making a standard, just as we do
> regarding versioned names of the lua and luac executables.  Really only
> the people doing packaging need to agree.

Cool. I totally agree with your suggestion. I guess back then I was in
Brazil and too busy with the beach. :)

As for not needing the support of the authors, this would force us to
patch the lua.c and/or loadlib.c. Since the 5.1.1 has not yet been
released...

So, what is it going to be, people?

Regards,
Diego.
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.0 and 5.1 together

Diego Nehab-3
In reply to this post by D Burgess-4
Hi,

> I thought we had it.
> The default LUA_PATH and :LUA_CPATH have 5.1 in the path name
> for *nix, Windows uses the module directory. It seems to work
> ok for me.

I mean the name of the environment variables, not their contents. :)

[]s,
Diego.
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.0 and 5.1 together

D Burgess-4
In reply to this post by John Belmonte
I like this. I missed it too.

DB

John Belmonte  wrote:
> I already tried suggesting this
> (http://lua-users.org/lists/lua-l/2006-02/msg00461.html).
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.0 and 5.1 together

John Belmonte
In reply to this post by Diego Nehab-3
Diego Nehab wrote:
> Cool. I totally agree with your suggestion. I guess back then I was in
> Brazil and too busy with the beach. :)
>
> As for not needing the support of the authors, this would force us to
> patch the lua.c and/or loadlib.c. Since the 5.1.1 has not yet been
> released...
>
> So, what is it going to be, people?

Patching Lua to take care of distribution details is not a big deal, we
already do it for other things (e.g. patching luaconf.h to add /usr/...
variants to search paths).  Only one person need do the work and we can
then share the patch.  I'll take a stab at it this weekend.

--John
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.0 and 5.1 together

Andre Carregal
> > Diego Nehab wrote:
> > As for not needing the support of the authors, this would force us to
> > patch the lua.c and/or loadlib.c. Since the 5.1.1 has not yet been released...

> John Belmonte wrote:
> Patching Lua to take care of distribution details is not a big deal, we
> already do it for other things (e.g. patching luaconf.h to add /usr/...
> variants to search paths).  Only one person need do the work and we can
> then share the patch.  I'll take a stab at it this weekend.

While this is true, another option to consider is one similar to Compat-5.1.

Compat has been used both for upward compatibility and for exercising the  new package model during the 5.1 cycle. A similar approach (Compat-5.2? 6.0?) could be used to implement and exercise incoming novelties for the next version of Lua to be used by Lua 5.1 users.

As long as the delta does not imply parsing differences or a unmappable C API, we should be able to offer it through the development of the next version of Lua.

We can tell that the experience of being able to port modules to Lua 5.1 in a series of smaller steps was an interesting one. The delta from Compat R5 to Lua 5.1 is a lot smaller than Lua 5.0 to Lua 5.1 and that may appeal to those who are not sure about the jump.

Andre
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.0 and 5.1 together

Tomas-14
In reply to this post by John Belmonte
> I already tried suggesting this
> (http://lua-users.org/lists/lua-l/2006-02/msg00461.html).

   LUA_5_1_INIT
   LUA_5_1_PATH
   LUA_5_1_CPATH

  The ability to define these PATHs with a variable part would help:

LUA_PATH="/usr/local/share/lua/$VERSION_NUMBER/?.lua..."

  A tricky init-file could do the job either:

if VERSION_NUMBER == "5.0" and not _COMPAT51 then
  assert(loadfile("/usr/local/share/lua/5.0/compat-5.1.lua"))()
end
package.path = string.gsub (package.path, "5.%d+", VERSION_NUMBER)
...

  On both cases, VERSION_NUMBER could be obtained from _VERSION
variable:

VERSION_NUMBER = string.gsub (_VERSION, "^Lua (%d+%.%d+).*$", "%1")

  I think this approch is better than changing .c files don't you
think?

> We can get by without the Lua authors making a standard, just as we do
> regarding versioned names of the lua and luac executables.  Really only
> the people doing packaging need to agree.
  This (the support (?) for multiple installed versions) is an
old subject usually standed out by them, unfortunately.

  Tomas
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.0 and 5.1 together

Antonio Scuri
At 14:23 4/4/2006, Tomas wrote:

>>I already tried suggesting this
>>(http://lua-users.org/lists/lua-l/2006-02/msg00461.html).
>
>   LUA_5_1_INIT
>   LUA_5_1_PATH
>   LUA_5_1_CPATH
>
>         The ability to define these PATHs with a variable part would help:
>
>LUA_PATH="/usr/local/share/lua/$VERSION_NUMBER/?.lua..."
>
>         I think this approch is better than changing .c files don't you
>think?

   Let's say that you have two Lua versions instaled on the same
system in different folders.

   Both will look for LUA_PATH and LUA_CPATH. Where we are going to
install modules for the two different versions? (assuming the modules
are not compatible of course).

   Since the contants of those enviroment variables can be very long
I think that the "LUA_5_1_PATH" is a simple solution.

   The solution that we were considering for another project is to
dynamically set the environment variables during application
initialization. The application will know which version is running so
just configuring LUA_PATH will be enough. But this may not be a good
solution for everyone.

Best,
scuri

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.0 and 5.1 together

Roberto Ierusalimschy
In reply to this post by Diego Nehab-3
> As for not needing the support of the authors, this would force us to
> patch the lua.c and/or loadlib.c. Since the 5.1.1 has not yet been
> released...

We cannot change the defaults for those names from 5.1 to 5.1.1, but we
can (and will) move its defines to luaconf.h, so there will be no need
to patch .c files.

-- Roberto
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.0 and 5.1 together

Diego Nehab-3
In reply to this post by Tomas-14
Hi,

> A tricky init-file could do the job either:
> [... snip ...]

I agree it would be possible to design an init file that, say,
invoked a version-specific init file. It could look like this:

     local function varname(var, version)
         return "LUA_" .. version .. "_" .. var
     end

     local v = string.gsub(_VERSION, "^Lua (%d+)%.(%d+).*$", "%1_%2")
     local init = os.getenv(varname("INIT", v))
     if init then
         if string.sub(init, 1, 1) == '@' then
             dofile(string.sub(init, 2))
         else
             assert(loadstring(init, "=LUA_INIT"))()
         end
     end

     package.path = os.getenv(varname("PATH", v)) or package.path
     print(package.path)
     package.cpath = os.getenv(varname("CPATH", v)) or package.cpath
     print(package.cpath)

What do you think?

Regards,
Diego.
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.0 and 5.1 together

Diego Nehab-3
Hi,

Oh well.

     package.path = os.getenv(varname("PATH", v)) or package.path
     -print(package.path)
     package.cpath = os.getenv(varname("CPATH", v)) or package.cpath
     -print(package.cpath)

Regards,
Diego.
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.0 and 5.1 together

D Burgess-4
Now that I am awake.  Not sure what ytou are asking.

>      package.path = os.getenv(varname("LUA_PATH", v)) or package.path
>      package.cpath = os.getenv(varname("PATH", v)) or package.path

Makes sense to me.


DB
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.0 and 5.1 together

John Belmonte
In reply to this post by Roberto Ierusalimschy
Roberto wrote:
>>As for not needing the support of the authors, this would force us to
>>patch the lua.c and/or loadlib.c. Since the 5.1.1 has not yet been
>>released...
>
>
> We cannot change the defaults for those names from 5.1 to 5.1.1, but we
> can (and will) move its defines to luaconf.h, so there will be no need
> to patch .c files.

I would like to make both versioned and non-versioned variables
available (with the versioned having precedence), as I explained.  Each
has its uses, and I don't see a point in breaking compatibility for
existing 5.1 users.  The change you describe wouldn't obviate the need
for a patch.

--John
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.0 and 5.1 together

John Belmonte
In reply to this post by John Belmonte
I wrote:

> Diego Nehab wrote:
>
>>Cool. I totally agree with your suggestion. I guess back then I was in
>>Brazil and too busy with the beach. :)
>>
>>As for not needing the support of the authors, this would force us to
>>patch the lua.c and/or loadlib.c. Since the 5.1.1 has not yet been
>>released...
>>
>>So, what is it going to be, people?
>
>
> Patching Lua to take care of distribution details is not a big deal, we
> already do it for other things (e.g. patching luaconf.h to add /usr/...
> variants to search paths).  Only one person need do the work and we can
> then share the patch.  I'll take a stab at it this weekend.
Attached is a backwards-compatible patch to check e.g. LUA_5_1_PATH
before LUA_PATH when looking up Lua environment variables (LUA_PATH,
LUA_CPATH, and LUA_INIT).  If the versioned variable exists then the
non-versioned one is not used at all.

--John

diff -urN lua-5.1.orig/src/loadlib.c lua-5.1/src/loadlib.c
--- lua-5.1.orig/src/loadlib.c 2005-12-29 10:32:11.000000000 -0500
+++ lua-5.1/src/loadlib.c 2006-04-09 16:24:16.000000000 -0400
@@ -586,13 +586,23 @@
 /* }====================================================== */
 
 
+static const char * getlenv(lua_State *L, const char* envname) {
+  /* try version-specific name first (e.g. LUA_5_1_PATH for LUA_PATH) */
+  const char *envname2 = luaL_gsub(L, envname, "LUA", "LUA_5_1");
+  const char *val = getenv(envname2);
+  if (val == NULL)
+    val = getenv(envname);
+  lua_remove(L, -1);
+  return val;
+}
+
 
 /* auxiliary mark (for internal use) */
 #define AUXMARK "\1"
 
 static void setpath (lua_State *L, const char *fieldname, const char *envname,
                                    const char *def) {
-  const char *path = getenv(envname);
+  const char *path = getlenv(L, envname);
   if (path == NULL)  /* no environment variable? */
     lua_pushstring(L, def);  /* use default */
   else {
diff -urN lua-5.1.orig/src/lua.c lua-5.1/src/lua.c
--- lua-5.1.orig/src/lua.c 2005-12-29 11:23:32.000000000 -0500
+++ lua-5.1/src/lua.c 2006-04-09 16:24:22.000000000 -0400
@@ -305,8 +305,19 @@
 }
 
 
+static const char * getlenv(lua_State *L, const char* envname) {
+  /* try version-specific name first (e.g. LUA_5_1_PATH for LUA_PATH) */
+  const char *envname2 = luaL_gsub(L, envname, "LUA", "LUA_5_1");
+  const char *val = getenv(envname2);
+  if (val == NULL)
+    val = getenv(envname);
+  lua_remove(L, -1);
+  return val;
+}
+
+
 static int handle_luainit (lua_State *L) {
-  const char *init = getenv("LUA_INIT");
+  const char *init = getlenv(L, "LUA_INIT");
   if (init == NULL) return 0;  /* status OK */
   else if (init[0] == '@')
     return dofile(L, init+1);
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.0 and 5.1 together

Diego Nehab-3
Hi,

> Attached is a backwards-compatible patch to check e.g. LUA_5_1_PATH
> before LUA_PATH when looking up Lua environment variables (LUA_PATH,
> LUA_CPATH, and LUA_INIT).  If the versioned variable exists then the
> non-versioned one is not used at all.

Any ideas how we get the distributors to use this? Actually, on a
similar note, how do we get them to use the improved readline support
too? Are they reading this message? Hear, hear...

Regards,
Diego.
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.0 and 5.1 together

Roberto Ierusalimschy
In reply to this post by John Belmonte
> I would like to make both versioned and non-versioned variables
> available (with the versioned having precedence), as I explained.  Each
> has its uses, and I don't see a point in breaking compatibility for
> existing 5.1 users.  The change you describe wouldn't obviate the need
> for a patch.

I am afraid I could not find your explanation. Would this "double
checking" be used only for compatibility? Or do you propose them as
a "feature"?

-- Roberto
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.0 and 5.1 together

Diego Nehab-3
Hi,

> I am afraid I could not find your explanation. Would this "double
> checking" be used only for compatibility? Or do you propose them as
> a "feature"?

It is a feature request. The reason is simple. If you have Lua 5.1 and
Lua 5.0 installed on the same system, they will fight for control of
variables LUA_INIT, LUA_PATH, and LUA_CPATH. What John proposed was that
each version of Lua should check first for version specific environment
variables, and only if those are not defined should Lua resort to the
generic variables.  For example, Lua 5.1 would first try LUA_5_1_INIT,
and, if not found, then try LUA_INIT. This is what the patch
accomplishes.

Regards,
Diego.
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.0 and 5.1 together

Shmuel Zeigerman-2
Diego Nehab wrote:

>
> If you have Lua 5.1 and
> Lua 5.0 installed on the same system, they will fight for control of
> variables LUA_INIT, LUA_PATH, and LUA_CPATH. What John proposed was that
> each version of Lua should check first for version specific environment
> variables, and only if those are not defined should Lua resort to the
> generic variables.  For example, Lua 5.1 would first try LUA_5_1_INIT,
> and, if not found, then try LUA_INIT. This is what the patch
> accomplishes.
>

I'm using a "dispatcher" file lua_init.lua which is pointed to by LUA_INIT:
   LUA_INIT=@c:\exe\share\lua\lua_init.lua

-- lua_init.lua
local v = string.sub(_VERSION, 5, 7)
if v == "5.0" then
     dofile("c:/exe/share/lua/5.0/compat-5.1.lua")
else
     dofile("c:/exe/share/lua/5.1/lua_init.lua")
end
-- end of lua_init.lua

The file which is run via dofile can initialize LUA_PATH, LUA_CPATH
or package.path, package.cpath

There is an overhead of running one (small) extra lua file. Other than
that, it seems to not restrict me from using 2 versions of Lua
simultaneously.

Could you please tell me what's wrong with that approach?

--
Shmuel
12