Noddy question on accessing sublists.

I know I haven't had enough coffee yet today so there's probably some dumb typo in the following, but please help me out anyway.

Why do I get 2 output instead of 10 in the following test script on rez? My global list of lists is accepted fine on compile, but I seem to be messing something up as it seems to be returning the size of a sublist.

// Sublist access test proggie

list inventoryTypesList =
[
    [INVENTORY_BODYPART,    "BODY"],
    [INVENTORY_CLOTHING,    "CLTH"],
    [INVENTORY_LANDMARK,    "LMRK"],
    [INVENTORY_NOTECARD,    "NOTE"],
    [INVENTORY_OBJECT,      "OBJT"],
    [INVENTORY_SCRIPT,      "SCRT"],
    [INVENTORY_SOUND,       "SOUN"],
    [INVENTORY_TEXTURE,     "TXTU"],
    [INVENTORY_GESTURE,     "GEST"],
    [INVENTORY_ANIMATION,   "ANIM"]
];

default
{
    state_entry()
    {
        llWhisper(0, "There are " + (string)llGetListLength(inventoryTypesList) + " inventory types");
        // Expected output is 10, but I get 2 --- it seems to be returning the size of a sublist
    }
}

Silly rabbit, nesting lists is for real programing languages.

// Sublist access test proggie

list inventoryTypesList =
[
    INVENTORY_BODYPART,    "BODY",
    INVENTORY_CLOTHING,    "CLTH",
    INVENTORY_LANDMARK,    "LMRK",
    INVENTORY_NOTECARD,    "NOTE",
    INVENTORY_OBJECT,      "OBJT",
    INVENTORY_SCRIPT,      "SCRT",
    INVENTORY_SOUND,       "SOUN",
    INVENTORY_TEXTURE,     "TXTU",
    INVENTORY_GESTURE,     "GEST",
    INVENTORY_ANIMATION,   "ANIM"
];

default
{
    state_entry()
    {
        llWhisper(0, "There are " + (string)(llGetListLength(inventoryTypesList)/2) + " inventory types");
        // Expected output is 10, but I get 2 --- it seems to be returning the size of a sublist
    }
}

It compiled it , Strife.

Ie. this is valid LSL. It would have chucked out the nested sublists in the declaration otherwise.

Now you can add lists to lists, which is sorts sub lists, and then "stride" over them, but its still not an array, sigh.

Thanks Kelly.

Yep, if nested lists aren't supported in LSL that's fine, can't support everything. I hope that they will be in LSL one day though.

What wasn't fine was that the compiler didn't reject them if they weren't supported. And even worse of course, that it delivered an incorrect list length at runtime. So yes, if it wasn't me that made a typo, then it's a kosher compiler bug.

I'll report it as you suggested.

OK, bug reported.

But this highlights a problem. I wasn't all that concerned about Don Linden's progress on arrays for LSL because I assumed that lists could carry any valid type, including other lists.

Now that it's clear that this is not so, LSL is almost totally crippled for structured data, requiring us to pack and unpack everything into CSV strings before storing on lists. This is, er, how can I put it politely, suboptimal. (And it's placing unnecessary extra load on LL servers too.)

It's 2004, LL. Data structuring was invented in the 1950's. Please catch up.

If you don't have the resources, send me the compiler and I'll try to fix it, free.

Ooooooh... Open source dev of LSL... :macks self silly:: I know it's a patently bad idea, but it's such a sexy concept...

i've heard rumor that Cory would give the byte code to a deserving programer. I think the best way to show we are deserving is to build an offline syntax checker / compiler. If your willing to work on it Morgaine the dream might come true.

You don't have to pack the data, but you do have to do structures by hand, which is a pain, but not impossible.

Say you wanted a list of the following C-Like structure.

struct foo {
integer m_nInt1;
integer m_nInt2;
string m_szStr;
key m_kKey;
};

You would define some constants

integer INT1_OFF = 0;
integer INT2_OFF = 1;
integer STR_OFF = 2;
integer KEY_OFF = 3;

These are just each member's position in our imaginary struct.
Then you need the total size (well, number of members) of the struct

integer FOO_SIZE = 4;

So, then you build your list:

list lFooList =  [
2, 3, "monkey", "SOME-KEY-BLAH BLAH",
9, 6, "apple", "SOME-OTHER-KEY-HEY-HEY",
...];

(adding and removing items from the list is left as an exercise for the reader.

Then you would have access functions:

string getFooString(list lFoos, integer nIndex)
{ return llList2String(lFoos, FOO_SIZE * nIndex + STR_OFF); }

this returns the string members of the nIndex'th foo in the list. Similarly:

 integer getFooInt2(list lFoos, integer nIndex)
{ return llList2Int(lFoos, FOO_SIZE * nIndex + INT2_OFF; } 

This is basically exactly what the compiler (in a language that has arrays of structures) does for you.
(note, all this code is off the top of my head and completely untested).

Well, not quite, because anything that uses direct-indexed arrays and/or fixed-offset structures is O(1) whereas linear lists are always O(n), regardless of whether it is we or the compiler that does the job.

Nevertheless, that aside, in principle we can organize our own hierarchical data structuring using striding as you did above, if we don't mind the bad scaling with N and if we don't mind our code growing ever longer blood-dripping fangs as the depth of our hierarchy rises.

The last time I did that kind of messing around though it was with Basic and Fortran, more years ago than I care to remember. Eeeeks, we badly need a few remedial improvements in this area, merely to get us somewhere near the eighties.

If only the LSL compiler were open source, we'd get it modernized in a jiffy. <sigh>

It's a great idea actually. With hundreds of eyeballs looking at it, I very much doubt that bugs and other nasties would survive long. And whoever is in charge of the compiler at LL would just need to oversee, running diffs periodically and talking to the FOSS devs on the mailing list.

Putting code into open development doesn't mean you have to run the open code directly. LL could very easily just take new bits that they like from the new source and merge it into theirs, keeping the two quite separate. I don't think it would be ideal, but if it helps reduce paranoia among those who are used to closed sources then it can be one way forward.

Act II:

If only the bytecode interpreter were open source, we'd get it modernized in a jiffy. <sigh>

One pair of eyeballs working under NDA would be a very suboptimal way of doing that, as it would gain none of the benefits of community development and all of the disadvantages of a lone developer working in the dark without the tools and test environment of the company staff.

Maybe a quick fix to a bug like the one I reported is possible under those conditions, perhaps even something like adding arrays. But for a complete development like an offline syntax checker/compiler, that would be a very bad idea. Make it a FOSS project.

Here, here!!!

Morgaine, have you taken a look at the psuedo-multidimentional array code in the script library?
Here's a link in case you havent:
/15/e9/7796/1.html
It works by serializing a n-dimentional array into a 1-dimentional list mathematically.

Sadly, the forum discussion threads on it were erased, courtesy Daniel Linden , during the First Big Forum Change. In case that implementation doesn't meet your speed needs, Alondria posted (in one of those deleted threads) a alternative that involved two synchronized lists (lists with the same number of elements), one that contained data, and another that contained the data's labels. Ex:
["Data1", "Data2", "Data3", "Data4"]
["[0][0]", "[0][1]", "[1][0]", "[0][1]"]

Atm, Im unable to remember, in detail, the other alternatives that were posted.

Of course, none of these are ideal. Im just suggesting what can be done in the mean time, while we wait for LL to implement the real thing
==Chris

Yes indeed, thanks Chris. Non-ideal solutions can often be very useful. As you say, it's a stop-gap measure.

... how hard could it be to hack gcc (or some other open source compiler) so it's syntax checker would work for lsl?

I strongly suspect that internally, LSL "lists" are arrays of pointers.

As the saying goes, "To get there, I wouldn't start from here."

Hacking gcc is not for the faint of heart. In contrast, writing a syntax checker for LSL from scratch is trivial, since LSL has a trivial syntax. In fact, that's worthy of an SL Event ... see who can yacc out the shortest LSL grammar.

For the benefit of readers who may not be acquainted with writing parsers: decent error handling and tree construction is always a lot more work than just the parser itself, and enforcing semantic-to-syntactic crossover issues like variable and function types will increase the effort required by another order. A plain parser for the grammar alone though, sure, that's doable.

That said, what would an offline syntax checker give us? Typos aside, no real programmer would gain anything, since it's pretty much impossible to code LSL scripts wrongly for syntactic reasons. That's one of its endearing features, the extreme simplicity.

Any real difficulties in scripting that some people do experience are all down to semantics not syntax. There's a good thread on that subject currently active, in case anyone's interested --- this is a link to an item I wrote on environmental semantics in that thread recently, as they create a few hiccups for people sometimes.

Of course, if we were talking about creating a complete offline LSL execution environment, that would be another question entirely, and yes, highly useful. However, it wouldn't be a small undertaking, and the syntax of the scripting language it hosts would be by far the least of our worries. In fact, we could provide several language front ends, LSL for beginners and a number of others for those with greater expectations or higher ambitions.

I'd hesitate to propose it though. It's a lot of work, and what's the goal? A separate metaverse eventually? So, shouldn't existing projects merge first?

Nah. LL has strong techie roots, they wouldn't call arrays "lists" when in computer science the two concepts are so utterly different at their very core. It's only in maths that they're the same thing, in the sense that they both implement the concept of sequence.

Anyway, Don Linden's already said that he's implementing arrays, and he wouldn't be doing that if they were already present and just misnamed.

On top of that, the O(n) behaviour of LSL lists has been reported in many threads I've read, with clear advice not to raise N to anything significant to avoid performance plumetting. I don't have any reason to disbelieve it. Feel free to write a simple test --- O(1) and O(n) are extremely simple to distinguish.