default lists for utils.multilistbox don't work properly

Posted by Fiendish on Thu 21 Jul 2011 10:48 PM — 22 posts, 81,692 views.

USA Global Moderator #0
If I do

utils.multilistbox ("", "", {a="a", b="b", c="c", d="d", e="e", f="f", g="g", h="h", i="i", j="j", k="k", l="l", m="m", n="n"}, {a=true, b=true, c=true, d=true, i=true, m=true, n=true})

then e, f, g, and h are not active (good), but j, k, and l are active even though I don't want them to be (bad).
Australia Forum Administrator #1
Seems OK to me under Windows XP:

Australia Forum Administrator #2
Also under Wine on the Mac:

USA Global Moderator #3
Well, damn. I get this:
http://i.imgur.com/ifgIw.png

I'll try rooting around WINE for possible other issues :\
Amended on Fri 22 Jul 2011 01:59 AM by Fiendish
USA Global Moderator #4
Well it looks like there's something in one of the luajit updates that causes this (I bisected to http://repo.or.cz/w/luajit-2.0.git/commit/420124372b7643410a1cdd6f80b9cc8aa6ec1302), but it only breaks in Linux/WINE and not in Windows 7 for me. I'm going to write an email to Mike Pall about this. Nick, am I correct in thinking that the only relevant MUSHclient code here should be the creation of m_iDefaults in

static int multilistbox (lua_State *L)  {...}

in scripting/lua_utils.cpp?

I wish I had a way to build mushclient here so that I could properly track this down. :\
Amended on Mon 25 Jul 2011 07:22 PM by Fiendish
Australia Forum Administrator #5
Yes that looks like the relevant code. Glancing over it again I can't see anything obviously wrong with it.
USA Global Moderator #6
Yeah, me neither. Is it possible to make me a custom build that spits out the size/contents of msg.m_iDefaults after it's populated in that function?
Australia Forum Administrator #7
Yeah OK, I emailed it to you. I got the number 7 from your test data, which is what I expect.
Australia Forum Administrator #8
Looks like I can't email you files. I uploaded it and emailed you the link. I changed it to actually display the contents.

In case I want to do it again the source is:


  for (set<int>::const_iterator iter = msg.m_iDefaults.begin ();
       iter != msg.m_iDefaults.end ();
       iter++)
         {
          CKeyValuePair kv = msg.m_data [*iter];
          AfxMessageBox ((LPCTSTR) CFormat ("item %i of msg.m_iDefaults (key %s, value %s) exists", 
                         *iter, kv.sKey_.c_str (), kv.sValue_.c_str ()));
         }

USA Global Moderator #9
Thanks, I got the email.
Findings,

items that exist with regular lua:
0 (a), 1 (c), 2 (b), 4 (d), 7 (i), 11 (m), 13 (n)

items that exist with luajit b8:
0 (i), 2 (n), 3 (m), 4 (c), 6 (b), 10 (d), 12 (a)

So they're all there, just in different order and different locations, which I guess matters somehow, because this does work for me:

Quote:

utils.multilistbox ("", "", {[1]="a", [2]="b", [3]="c", [4]="d", [5]="e", [6]="f", [7]="g", [8]="h", [9]="i", [10]="j", [11]="k", [12]="l", [13]="m", [14]="n"}, {[1]=true, [2]=true, [3]=true, [4]=true, [9]=true, [13]=true, [14]=true})


and produces
0,1,2,3,8,12,13 (a,b,c,d,i,m,n)
Amended on Tue 26 Jul 2011 03:07 AM by Fiendish
Australia Forum Administrator #10
This would be confirmed by running this test:


for k, v in pairs {a="a", b="b", c="c", d="d", e="e", 
                   f="f", g="g", h="h", i="i", j="j", 
                   k="k", l="l", m="m", n="n"} do
  print (k, v)
end -- for


On normal Lua I get:


a a
c c
b b
e e
d d
g g
f f
i i
h h
k k
j j
m m
l l
n n


Using the "Aardwolf Lua" I get:


i i
f f
n n
m m
c c
g g
b b
l l
j j
k k
d d
h h
a a
e e


But unless there is a big blunder in my code, I don't see how the order of getting the keys matters.
Australia Forum Administrator #11
Let me put it this way ... using the Aardwolf Lua, this screenshot shows that the keys are being fetched in the order you showed, but the listbox looks fine:

USA Global Moderator #12
This problem from the ordering only happens to me under Wine, though. It doesn't seem to happen in Windows. Under Windows I get the same result as you do in that last screenshot. It's very weird to me that a system-dependent problem would manifest in this way, which is why I thought it was a luajit problem, but then the result of the lua segment is the same on both ends. :\
Amended on Tue 26 Jul 2011 06:10 AM by Fiendish
USA Global Moderator #13
Maybe this is actually a Wine bug after all and it only gets tickled because of the order change in luajit? I don't know.
Australia Forum Administrator #14
Fiendish said:

Well it looks like there's something in one of the luajit updates that causes this (I bisected to http://repo.or.cz/w/luajit-2.0.git/commit/420124372b7643410a1cdd6f80b9cc8aa6ec1302), but it only breaks in Linux/WINE and not in Windows 7 for me.


I am at a bit of a loss to explain this. If it failed on all platforms I would say you have a LuaJIT problem. If it always failed on Wine I would say Wine is not handling the multi list box properly. But your combination puzzles me.

Certainly I can believe that the hashing algorithm that hashes table entries might work differently under the JIT version than the normal version, but we have seen that the table sequence doesn't seem to directly affect the problem.
Australia Forum Administrator #15
Let me briefly explain what the code is trying to do. The list box has the "sorted" attribute checked, so when you add (say) y, then x, it sorts it into x and then y order. So it gets the "new position" from the listbox insertion, and uses *that* and not the original position for modifying things like the selected flag. It also stores the original position (under the "extra data" field) so that it can relate back the original position, when chosen, and not the position it eventually ends up in the list.

And all this works, or seems to, because list boxes work regardless of the order that you add things into them, as the screen shot shows.

But maybe under Wine, the number returned is prior to sorting, or something, which defeats the effort I have put in to resolve this issue.

USA Global Moderator #16
Maybe presort the items? :\
At least it seems I can effectively work around this by using numeric indexes, since those are always sorted correctly directly out of Lua.
Amended on Tue 26 Jul 2011 07:07 AM by Fiendish
Australia Forum Administrator #17
I shouldn't have to pre-sort things to work around what is increasingly looking like a problem in Wine. It looks like LuaJIT is triggering the problem by the way it is hashing things, but really the core problem is that the listbox is not functioning as documented, as evidenced by its correct behaviour under Windows.
Australia Forum Administrator #18
Fiendish said:

Thanks, I got the email.


Not my original one I presume?


This Message was undeliverable due to the following reason:

Your message is larger than the destination computer is willing to
accept, so it was returned.  The error message below indicates the
size of your message and the maximum size allowed by the receiving
E-mail system.  You may be able to split your message into several
smaller pieces and have them delivered separately.

Your message was rejected by gmail-smtp-in.l.google.com for the following reason:

    5.7.0 Our system detected an illegal attachment on your message. Please
    5.7.0 visit http://mail.google.com/support/bin/answer.py?answer=6590 to
    5.7.0 review our attachment guidelines. m2si18421449pbj.63

The following recipients did not receive this message:

...


So my attachment was illegal, eh?


Illegal

contrary to or forbidden by law, esp. criminal law: illegal drugs.


What law did it break?
Amended on Tue 26 Jul 2011 10:34 AM by Nick Gammon
USA #19
Nick Gammon said:
What law did it break?

"This program has performed an illegal operation and will be shut down."
USA Global Moderator #20
"You are in violation of the law!"
"You're in violation of your face!"

It seems gmail is very aggressive about blocking zipped executables.
Amended on Tue 26 Jul 2011 02:36 PM by Fiendish
Australia Forum Administrator #21
Twisol said:

Nick Gammon said:
What law did it break?

"This program has performed an illegal operation and will be shut down."


That reminds me of the people who call up call centers and complain that their computer told them they are doing something illegal.