[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Why this error in table.sort()?
- From: Steve Litt <slitt@...>
- Date: Fri, 4 Feb 2011 02:02:16 -0500
On Friday 04 February 2011 01:00:26 Geoff Leyland wrote:
> On 4/02/2011, at 6:49 PM, Steve Litt wrote:
> > Hi all,
> > For my presentation, I'm using table.sort(mytable, sortfcn), where
> > mytable has only consecutive integer keys starting with 1, and each
> > element consists of a table with named keys (fname, lname, from, to). I
> > want to sort by lname then fname.
> > By mistake I changed the first line of the sort order function's if
> > statement from:
> > if thiss.lname < nextt.lname then return true
> > to
> > if thiss.lname < nextt.fname then return true
> > Notice nextt.fname. That's not my intent, and I understand it should give
> > me wrong results, but why should it be a compile time error? Whereas
> > nextt.lname runs as expected, nextt.fname throws the following error:
> > =================
> > slitt@mydesk:/d/at/htmlslides_data/leap_lua$ ./tableproblem.lua
> > /usr/bin/lua: ./tableproblem.lua:20: attempt to index local 'thiss' (a
> > nil value)
> > stack traceback:
> > ./tableproblem.lua:20: in function <./tableproblem.lua:14>
> > [C]: in function 'sort'
> > ./tableproblem.lua:28: in main chunk
> > [C]: ?
> Don't take my word for it, but I think that if your ordering function is
> wrong (as in, not consistent) then table.sort can end up passing nil as
> one of the arguments to the ordering function. If you break the ordering
> contract, sort doesn't make many promises.
A few diagnostic prints and defaulting thiss and nextt if they were nil
revealed that function byname() was executed several times before thiss became
nil (and later nextt became nil).
I'm thinking maybe the problem was a rock/paper/scissors type of thing:
Rock breaks scissors
Scissors cuts paper
Paper covers rock
In that case it could go on forever rearranging until something went wrong.
I'll have to investigate further, but thanks. Your advice and the advice of
Drake Wilson got me to put diagnostic prints into the sort order function,
which showed instantly that the first several times through it was executing
without errors from Lua (what I called compiler errors in the previous
Recession Relief Package