Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

Looping through variables.

Chaz Longstaff
Registered User
Join date: 11 Oct 2006
Posts: 685
08-08-2007 18:40
list TermsList = ["apple", "banana", "orange"];
list Variables = [AccessNo, AdminList, AdminMode];

for (i = 0; i <= llGetListLength( Variables); i++) {

[assign i term from TermsList to i variable from Variables]

}

giving a result such that it then knows what AccessNo equals. So that if I go llSay(0, AccessNo), I will get it saying "apple".

I charged into doing this, but then screeched to a halt when mulling over my llList2Whatever functions.

It's probably dead easy but I just got stumped here.

p.s. The lists in question are way longer, which is why I'm bothering at all -- to avoid assigning them line by line.
Osgeld Barmy
Registered User
Join date: 22 Mar 2005
Posts: 3,336
08-08-2007 19:25
use llListFindList it will return the index integer which you can then use to access the same index on the other list
Qie Niangao
Coin-operated
Join date: 24 May 2006
Posts: 7,138
08-08-2007 19:40
It would be a lot easier if it weren't impossible. ;) Well, that is, a list can't contain variables, only values. So the line

list Variables = [AccessNo, AdminList, AdminMode];

would try to evaluate AccessNo, etc., and put the values into a list, rather than storing some kind of handle or pointer to the variables themselves.

But probably what's really desired is still possible. For example, one might use a symbolic constant for the index values of the list, something like:

integer ACCESS_NO = 0;
integer ADMIN_LIST = 1;
integer ADMIN_MODE = 2;

and then retrieve the list elements by index, e.g.:

llOwnerSay(llList2String(termsList, ACCESS_NO));

Or, for other applications, there are association lists, either paired or strided, the latter of which might look like:

list termList = ["AccessNo", "apple", "AdminList", "banana", "adminMode", "orange"];

llOwnerSay(llList2String(termsList, llListFindList(termsList, ["AccessNo"]) + 1));

or something like that. The paired-list a-list approach is what Osgeld suggested (whilst Qie was still a'typin')--but still, the termsList would have to contain strings, not variables.

Perhaps obviously, the a-list approaches use way more memory and are much slower than the symbolic index value scheme, but permit dynamic, runtime definition of the terms.
Chaz Longstaff
Registered User
Join date: 11 Oct 2006
Posts: 685
08-08-2007 20:26
ah kk thanks guys.

I figured I was being really dumb either because it was blindingly obvious how to do it, or blindingly obvious that it couldn't be done. :}

Too bad, as the list is really long, and I probably could have saved a fair old bit of memory. Oh well, other ways to save memory.
Chaz Longstaff
Registered User
Join date: 11 Oct 2006
Posts: 685
08-10-2007 11:07
From: Qie Niangao
It would be a lot easier if it weren't impossible. ;) Well, that is, a list can't contain variables, only values. So the line

list Variables = [AccessNo, AdminList, AdminMode];

would try to evaluate AccessNo, etc., and put the values into a list, rather than storing some kind of handle or pointer to the variables themselves.

But probably what's really desired is still possible. For example, one might use a symbolic constant for the index values of the list, something like:

integer ACCESS_NO = 0;
integer ADMIN_LIST = 1;
integer ADMIN_MODE = 2;

and then retrieve the list elements by index, e.g.:

llOwnerSay(llList2String(termsList, ACCESS_NO));

Or, for other applications, there are association lists, either paired or strided, the latter of which might look like:

list termList = ["AccessNo", "apple", "AdminList", "banana", "adminMode", "orange"];

llOwnerSay(llList2String(termsList, llListFindList(termsList, ["AccessNo"]) + 1));

or something like that. The paired-list a-list approach is what Osgeld suggested (whilst Qie was still a'typin')--but still, the termsList would have to contain strings, not variables.

Perhaps obviously, the a-list approaches use way more memory and are much slower than the symbolic index value scheme, but permit dynamic, runtime definition of the terms.


kk

by "a-list" approach you mean?


integer ACCESS_NO = 0;
integer ADMIN_LIST = 1;
integer ADMIN_MODE = 2;

if so, I wasn't sure I was clear how that would impact compiler memory, given that there are over 40ish terms at present to incorporate when I go to "write that out" on paper (granted, I did something like that already, as I think you've seen over here [url], and I'm itching to get rid of it as it is.)


I liked this idea:

list termList = ["AccessNo", "apple", "AdminList", "banana", "adminMode", "orange"];

but my mind kinda boggled when I tried to flesh it out:

list termList = ["AccessNo", "apple", "pomme", "apfel", melanzana", "AdminList", "banana", "banane, "banane", "banana", adminMode", "orange", "orange", "orange", "arancia",]; (etc for 40ish terms.

I thought it had the potential of becoming unwieldy for a tired pair of human eyes to manage (given that most of this LSL stuff is done in stolen wee hours, grin.)
Learjeff Innis
musician & coder
Join date: 27 Nov 2006
Posts: 817
08-10-2007 14:18
a-list = association list, as he describes above.
Learjeff Innis
musician & coder
Join date: 27 Nov 2006
Posts: 817
08-10-2007 14:29
Another way to have associated lists is to use two lists, one for the names and one for the values:

list Names = ["height", "depth", "width", "weight"];
list Vals = [1.9, 1.0, 1.0, 100.0];

I often use this especially when the set of names comes from a notecard, something like this:

define=height=1.9
define=depth=1.0

When parsing the config card line, I use something like this:

CODE

config_parse(string line) {
list parts = llParseString2List(line, ["="], []);
string cmd = parts[0];
if (cmd == "define") {
string name = parts[1];
float val = (float) parts[2];
Names += [name];
Vals += [val];
}
}


Then, if I put all the names in a menu and the user picks one, I get the value like this:

CODE

integer index = llListFindList(Names, [name]);
if (index != -1) {
float val = llList2Float(Vals, index);
}


HTH :)