llParseString2List Problems

Am I the only one whom the new changes to llParseString2List ended up breaking a hoard of code? (I end up using it to parse speach and whatnot, so if someone plops an extra space or whatnot, it blows it away).

Can anyone thing of a good reason the changes?

The good reason was that you had to do a lot of work before to pass null entires. Now, theoretically, you don't.

However, after playing with it this is how I have found it is working now:

llParseString2List(message,[":"],["1","2"]);

If message = a:b we expect and get ["a","b"]

If message = a::b we expect and (now) get ["a","","b"]

If message = :b (null, seperator, b) we now get ["","b"]
this seems correct to me, if the seperator is first it must be seperating *something*

If message = a: we have a similar effect of ["a",""] for similar reasons.

Now where I think some extra strangeness is comming in. The second set of tokens (spacers) is treated exactly the same as the first except not discarded.

That means "1:" is two tokens next to each other which means there must be a null between right? So the result is... ["","1","",""]. That is null before a seperator, don't throw away that seperator since its a "spacer", null between the seperators and null after the last seperator.

So yeah, it looks like it got ugly quick. But what is the right behavior? My gut is that spacers should be treated differently than seperators and not parse nulls between them, or at the begining or ends of lists. In this case "1:" would create ["1",""] which seems appropriate to me.

Looks like theres scope for several functions in place of just the one ParseString2List, or a few arguments at the end which take default arguments (First, we have to add default arguments into LSL of course).

Azelda

I discussed some of these problems and an appropriate fix for removing nulls if you do not need them in your code in this thread: /54/15/23307/1.html

i noticed this problem accur on my vendor network system, but it only occur on freshly rezzed vendors, not on the one that are actually working inworld

still seeking a way to fix the bug

Please see the other thread listed above

here is a code patch.

//data is an input list retrieved from a listen or notecard or some such.
list test=[""];
integer findnum;
while(1+(findnum = llListFindList(data, test)))
{
    data = llDeleteSubList(data, findnum, findnum);
}

im not sure how it will solve my problem, but well i still dont understand where is my vendor bugging, i will investigate as soon as im back in SL (when i have a decent isp)

WELCOME TO SECOND LIFE

this change makes me feel somewhat peevish if you couldn't tell

I will roll back the changes to llParseString2List (so that it acts as it did previously). Instead I will add a llParseStringKeepNulls. =)

Sorry about springing that on ya folks, I have a lot of other things I'm working on and just plowed through that one.

Errrr, you know that'll break the scripts I just spent several hours patching?

Perhaps, just leave things be now, but bear in mind the possibility of forking functions in the future?

Azelda

LOL!

The problem with leaving it as it is would be that scripts which are broken and not modifiable by the creator will still be broken. Reverting back to the previous behaviour would fix this... although unfortunately yes you would have to unfix things you have worked on recently.

I will endeavor to put changes (which I hope will be minimal) up for comment before making them live, in the future. That way we can hopefully avoid this situation in the future :/.

I owuld suggest making a new call that fixes the problem and leaving the existing call to work as it was before.

Youve taken the words right out of my mouth Eggy
I've already given up on LL's ability to create even a fake programming language.
==Chris

Well, at least it's only taken having to revert only two back-to-back changes to LSL to get y'all to realize that warning your userbase beforehand is a good idea.

How about, from now on (on TOP of giving us at least a week's notice on LSL changes), when you announce that the servers are going to be going down the next day for a patch that you release the patch notes THEN, so we can tell you what you're screwing up.

> The problem with leaving it as it is would be that scripts which are broken and not modifiable by the creator will still be broken. Reverting back to the previous behaviour would fix this... although unfortunately yes you would have to unfix things you have worked on recently.

Ok, but in systems with products that have been put out for sale in the last few days, the same things applies.

Perhaps you can do the following.

Lets assume that LSL bytecode is a one-to-one mapping from a command to binary, eg llSay is 0x01. Now, we assume that llParseString2List is 0x02:

llSay 0x01 (just for illustration)
llParseString2List 0x02 (assumption for this post).

The modification you did the other day, changed directly the definition of the function 0x02. The compiler takes llParseString2List and compiles it into bytecode 0x02.

So, to fix this without causing impact, you could do the following:

- create a new bytecode 0x03, which represents a new function llParseString2ListIgnoreNulls
- update the compiler to compile llParseString2ListIgnoreNulls into bytecode 0x03
- search and replace the asset server for all scripts compiled before the patch date
- replace bytecode 0x02 with bytecode 0x03 in the old scripts

Azelda

Anyone who made use of the loop I posted to remove nulls will not need to unfix their code (rather than adjusting their parsing code to be specific to list elements). I anticipated this unfix and planned for it. It does mean my scripts will have some meaningless null removal, but they won't break in the future.

Thank you. This is the right thing to do.