List Intersection Functin Blows Up

i dunno why....

but my little list intersection finding code blows up the script error window with all KINDS of interesting gobbledeygook. can anyone help out?


THE CODE

list listIntersect(list l1, list l2)
{

    integer c;
    list test;
    list build;
    

        for(c=0;c<n1;c++)
        {
            test = llList2List(l2, c, c);
            if(llListFindList(l1, test) != -1)
              build += test;
        }
   
    
    return build;
}



default
{

        touch_start(integer total_number)
    {
        list foo = [ 1, 3, 5, 7, 9, 11, 22];
        list bar = [ 1, 2, 3, 22];
        list blah = listIntersect(foo, bar);
        llOwnerSay(llList2CSV(blah));
    }
}

i originally just had llList2List(l2, c, c) in the if. i also tried build = llListInsertList(build, test, 10); which should have worked.
whatever it does, if i put an llownersay at the beginning, it doesnt even get to that before blowing up.

if it matters any, here's what the script error window is trying to tell me.

list intersect [script:New Script]: Script run-time error
list intersect [script:New Script]: System.InvalidProgramException: Invalid IL code in LSL_c57a9a25_9716_de9d_af66_c0f374b24a05:glistIntersect (System.Collections.ArrayList,System.Collections.ArrayList): IL_0025: stloc.1


at LSL_c57a9a25_9716_de9d_af66_c0f374b24a05.edefaulttouch_start (Int32 total_number) [0x00000]
at LSL_c57a9a25_9716_de9d_af66_c0f374b24a05edefaulttouch_startFrame.ResumeVoid () [0x00000]
at LindenLab.SecondLife.UThread.UThread.Run () [0x00000]
at LindenLab.SecondLife.Script.Run (ScriptEvent evt) [0x00000]

It runs fine in LSLEditor. Between that and the mono stack trace, I'd guess it's an LSL bug. Maybe drop the script in a note with the error you're getting and send it to Babbage?


The real code has n1 defined somewhere, yes?

You're missing some code there; "n1" would be undefined.

I believe the script error you're getting is a Mono bug and not related to your code (i.e. just try compiling again, or compile using LSL until you get it working).

This slightly modified script has no run time errors:

list listIntersect(list lv1, list lv2)
{
    integer c;
    list test;
    list build;
    integer n1=llGetListLength(lv2);
    for(c=0;c<n1;c++)
    {
        test = llList2List(lv2, c, c);
        if(llListFindList(lv1, test) != -1)
          build += test;
    }
    return build;
}

default
{
        touch_start(integer total_number)
    {
        list foo = [ 1, 3, 5, 7, 9, 11, 22];
        list bar = [ 1, 2, 3, 22];
        list blah = listIntersect(foo, bar);
        llOwnerSay(llList2CSV(blah));
    }
}

The variable names l1 and l2 are changed, spooky
I too have run time errors with those variable names in the code.
I took the liberty to define the variable n1, but that has nothing to do with the run time error

great, so the issue is namespace collision with internal variables? because the compile is stupid and doesn't sanitize user variable names before compiling? I thought this was already addressed with the event_handler<->user_function naming collisions.

thanks guys!

i thought 'build' was the evil variable name, i didnt think to try changing l1 and l2.

and yeah... there was originally more code. i was comparing the length of l1 and l2 (with n1 and n2), and whichever one was shorter, i used that in the for loop to go through the other list. do you think that optimization is worth the time it takes to calculate those?

for huge lists, potentially yes.
you can easily get which one is larger(a.length -b.length), the question is it worth it size wise to include 2 separate looping structures (or to swap the list positions, which has speed implications)... (arrays would make this simple)

there might be a way to combine the lists and do your checking from one end or another to get around this, but dangerous memory-wise.

or do this...

//-- don't use this see below
list uListElementsInList( list vLstA, listvLstB ){
    string vStrX = llDumpList2String( vLstA, "~@" );
    list vLstC = llParseString2List( vStrX, vLstB + (list)"~@", [] );
    return llParseString2List( vStrX, vLstC + (list)"~@", [] );
}

it's not 100% safe ( elements containing "~@" will break it), ignores nulls in both lists (with a little work that could be avoided I think) , and will retain duplicate elements from A if the value exists in B (but then so does your code).

ETA:
or NOT... I forgot the spacers/separators lists were limited in element count, and oh yeah, it only works for string data types, others are ignored .... well it was an idea...