Re: Speed of #t

[Sean Conner <sean@...>]

It was thus said that the Great Roberto Ierusalimschy once stated:
> > The more I think about the alternatives for #t, the more I like the
> > current choice :-)
> 
> It is more or less like democracy ;)

  And this point in the thread is as good as any for the following odd
behavior I saw with Lua today (prompted by this discussion).  I have the
following bit of code:

local function etcpasswd()
  local USERID = 1
  local PASS   = 2
  local UID    = 3
  local GID    = 4
  local NAME   = 5
  local HOME   = 6
  local SHELL  = 7
  
  local users = {}
  local f     = io.open("/etc/passwd","r")
  
  for line in f:lines() do
    local fields = str.split(line)
    local user   = {}

    user.userid = fields[USERID]
    user.uid    = tonumber(fields[UID])
    user.gid    = tonumber(fields[GID])
    user.name   = fields[NAME]
    user.home   = fields[HOME]
    user.shell  = fields[SHELL]
    
    users[user.userid] = user
    users[user.uid]    = user
  end
  
  f:close()
  return users
end

This returns a table of all the users on my development system (Linux) at
home, keyed with both the userid (a string) and the UID (a number).  The
UIDs range from 0 (for root) to 503 (for a regular user), but not
consecutively (there are only 58 entries in the password file).  But now the
odd part:

> users = etcpasswd()
> print(#users)
100

  How odd.  Looking over my passwd file, I would actually expect #users to
be 14, as UIDs 1 through 14 (actually 0 through 14) are in use; users[15]
should be nil, and yes, it is:

> print(#users[15])
nil

  Okay, how about:

> for i = 1 , #users do
>>print(users[i])
>>end
table: 0x8c0d598
table: 0x8c0b870
table: 0x8c21a90
table: 0x8c0da30
table: 0x8c20900
table: 0x8c0d0c8
table: 0x8c0d158
table: 0x8c21248
table: 0x8c20628
table: 0x8c233f0
table: 0x8c1e0e0
table: 0x8c1e380
table: 0x8c1e698
table: 0x8c203c8
nil
nil
nil
nil
nil
nil
nil
nil
table: 0x8c1d598
table: 0x8c27d60
table: 0x8c27ab8
nil
table: 0x8c29d90
table: 0x8c24568
table: 0x8c1f438
nil
nil
table: 0x8c1f180
table: 0x8c2a020
table: 0x8c242e0
nil
nil
table: 0x8c1f890
table: 0x8c26fe0
table: 0x8c24a80
nil
table: 0x8c29ab8
table: 0x8c27228
table: 0x8c26d90
nil
nil
nil
table: 0x8c25648
table: 0x8c1d2e8
table: 0x8c24d00
nil
table: 0x8c25898
nil
nil
nil
table: 0x8c2a580
nil
nil
nil
nil
nil
nil
nil
nil
nil
nil
table: 0x8c27590
table: 0x8c26ae8
table: 0x8c23d78
table: 0x8c1f600
nil
nil
nil
nil
table: 0x8c24850
table: 0x8c2a808
table: 0x8c28140
table: 0x8c1d060
table: 0x8c2aaf0
nil
nil
table: 0x8c1ebc8
nil
nil
nil
nil
nil
nil
nil
table: 0x8c28788
nil
nil
table: 0x8c24fc8
table: 0x8c28650
nil
table: 0x8c2a2d0
nil
table: 0x8c283a0
table: 0x8c24020
table: 0x8c1ef08
table: 0x8c27810

  Very interesting.  

  Now, for this case, I don't care if #users works or not as that's not a
usecase I wrote the code for (I currently use it to print file ownerships;
why all the other information?  Because I can, that's why) but I still find
this interesting.  For the curious, here are the numeric values, in order
they're inserted:

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 99 81 69 37 68 98 34 28 74 32 29 65534 47
51 77 48 23 67 43 38 42 66 100 25 24 39 49 92 76 97 93 89 41 27 33 95 55 75
78 500 501 502 503 

  -spc (So, how would any #t proposal work in the face of this?)