Help with error

Posted by Bast on Fri 02 Jan 2009 04:57 PM — 6 posts, 23,176 views.

Bast Fri 02 Jan 2009 04:57 PM #0

I am trying to use the class implementation from:

http://class.luaforge.net/

It works fine in the lua 5.1.3 interpreter on my linux box. But when I create a simple plugin to use the class, I get this error in Mush:


Run-time error
Plugin: Test_Plugin (called from world: Aardwolf)
Immediate execution
C:\Program Files\MUSHclient\lua\class.lua:136: bad argument #1 to 'unpack' (table expected, got nil)
stack traceback:
        [C]: in function 'unpack'
        C:\Program Files\MUSHclient\lua\class.lua:136: in function <C:\Program Files\MUSHclient\lua\class.lua:134>
        C:\Program Files\MUSHclient\lua\class.lua:370: in main chunk
        [C]: in function 'require'
        [string "Plugin"]:1: in main chunk

I don't know enough about lua to figure it out. I could use some help.

Thanks,
Eric

Here is the plugin


<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE muclient>
<muclient>
<plugin
   name="Test_Plugin"
   author="Bast"
   id="76c897dda20af89787c6b438"
   language="Lua"
   purpose="Test class stuff"
   date_written="2008-12-24"
   requires="4.37"
   version="1.0"
   save_state="n"
   >
</plugin>

<script>
<![CDATA[
require 'class'

class "Window"

function Window:initialize(targs)
  --[[
    init the class, named arguments only
      the named arguments are 
      name, title, text, font, background_colour
      title_colour, hyperlink_colour, windowpos,
      title_width, title_colour, title_text_colour,
      text_colour, ishidden
  --]]
  self.name = targs.name or "Default"
end

print("making window")
questwin = Window{name="Quest"}
]]>
</script>

</muclient>

Nick Gammon Australia Forum Administrator Fri 02 Jan 2009 07:26 PM #1

It fails if you even only have


require "class"

The offending line is here:


local a, b = unpack(arg)

When run as we are trying to, arg will be nil. It appears that this particular line is trying to unpack the command-line arguments, of which there are none, as we are not using the command line.

I don't know what it is trying to do. According to the web page you linked:

Quote:

It is written in pure Lua and is fully compatible with Lua 5.0 .

The current state of library is "beta".

Its release date is May 20, 2007, which is almost 2 years ago.

Rather than trying to work out what this rather fancy library does, or doesn't do, I suggest you look at the treatment of classes in the Programming in Lua book here:

http://www.lua.org/pil/16.1.html

It seems strange to me to release a library, intended to be used inside scripts, that relies upon command-line arguments without any hints or comments about how to run it inside a larger script.

Bast Fri 02 Jan 2009 08:33 PM #2

Thanks for the quick answer Nick. It doesn't error out when I use it in a standalone lua script or the lua interpreter on my linux box. It only does that when using it in mushclient. Is there some special initialization that mushclient does? I will try looking into it.

I would use the class thing from the PIL book, but I firmly believe in not reinventing the wheel. Plus, the class.luaforge.com implementation has baseclasses and subclasses and makes it easy to do.

Thanks for the help,
Eric

Nick Gammon Australia Forum Administrator Fri 02 Jan 2009 11:17 PM #3

OK, I have sort-of got to the bottom of it.

As their web page says, the module is compatible with Lua 5.0 (not Lua 5.1).

See this page for the differences between 5.0 and 5.1:

http://www.gammon.com.au/forum/?id=7322

One of the differences is the new way of handling varargs, that is, arguments to a function in the form (...).

The old method used: unpack (arg) to break up the ... argument into a table. Now Lua lets you assign ... to a table.

As mentioned in my thread above, you can simulate the old behaviour like this:


local arg = {...}; arg.n = select ("#", ...)  --> emulate old behaviour

I got the class to mainly work (96%) by laboriously going through and finding each function that used the ... form, and adding that line very near the start of it.

Now why does it work for you under Linux? Well the standard Lua distribution has this in it:


*
@@ LUA_COMPAT_VARARG controls compatibility with old vararg feature.
** CHANGE it to undefined as soon as your programs use only '...' to
** access vararg parameters (instead of the old 'arg' table).
*/
#define LUA_COMPAT_VARARG

In other words, they have built in backwards compatibility for the old vararg system. However I disabled that as documented here:

http://www.gammon.com.au/forum/bbshowpost.php?id=7795

The advice from the Lua developers (above) is to "CHANGE it to undefined ..." which is exactly what I did, to encourage the use of the newer vararg system, rather than the old one.

So really, you are using a module that is designed for Lua 5.0, and is using a deprecated feature, namely the old vararg system.

You may get satisfactory results if you add the line above to wherever you can, but I can't guarantee it. The fact that they have not updated the module for Lua 5.1 tends to suggest it isn't supported, and thus may have other subtle bugs.

Nick Gammon Australia Forum Administrator Fri 02 Jan 2009 11:19 PM #4

A possible workaround would be to download the Lua 5.1 DLL from the LuaBinaries web site, and use that to replace the one used by MUSHclient. I presume that would allow the varargs to work, but can't guarantee it.

Bast Sat 03 Jan 2009 01:19 AM #5

Thank you very much for the help Nick. I will test the class with the ... changes.

Eric