In need of logical help...

[Handarido Optera]

In a notecard reader I want to exclude lines starting with // as well as empty lines (or lines that appear to be empty containing only spaces). Until now this worked for me:

if(llGetSubString(data, 0, 1) != "//" || llStringTrim(data, STRING_TRIM) != "")

In even a most simple stand-alone script now lines starting with // are not excluded, only empty or space filled lines are.

To the contrary, in earlier even very complex scripts lines starting with // are excluded.

In even the same prim this code does exclude // lines in one script, but not in the other.

[Rolig Loon]

Have you tried

if(llGetSubString(data, 0, 1) != "//" && llStringTrim(data, STRING_TRIM) != "")

?

 

[markkemp]

Logically speaking, your variable "data" is not what you think it is.

Make your script output each line into chat. As well as the results of the if statement.

Never test things blindly. Don't be afraid to spam yourself with owner chat channel messages while testing.

[Nova Convair]

I must admit that my title was misleading, it did not refer to the logic of the terms but that there was no logic to discover that exactly the same term causes different results. The point is that the combined terms block lines starting with // in earlier scripts, and let them pass in any new script now. I can tell this after meticulous testing. What works in any case is to split the two arguments into two if statements.

[Estelle Pienaar]

Maybe try to add brackets. I remember that this has once solved a similar problem for me with an OR command:

if((llGetSubString(data, 0, 1) != "//") || (llStringTrim(data, STRING_TRIM) != ""))

[Nova Convair]

---

Handarido Optera wrote:

I must admit that my title was misleading, it did not refer to the logic of the terms but that there was no logic to discover that exactly the same term causes different results. The point is that the combined terms block lines starting with // in earlier scripts, and let them pass in any new script now. I can tell this after meticulous testing. What works in any case is to split the two arguments into two if statements.

---

Nope. Look again.

Is all logic and there is no coincidence. If it doesnt work there is a mistake. If there are complicated terms - how do you know in what order they are calculated? If you don't know that you already made a mistake. (Set brackets)

I never use multiple if's for that kind of stuff. If that makes adifference for you there is a mistake in the expression.

If you dont like this post - stick with if chains if that work. But it's no LSL bug

 

[Estelle Pienaar]

Hi Nova. I am not sure if I fully understand your post. Do you suggest that my proposal of setting additional brackets is a mistake? Or has Handarido put wrong brackets somewhere? Can you show us what the correct line of code would be?

[Rolig Loon]

Placing extra brackets -- parentheses -- never hurts, and it can reduce ambiguity.  If this were my script, I would have placed them as you did, if only to reduce my own chance of getting confused later.

[Madelaine McMasters]

---

Rolig Loon wrote:

Placing extra brackets -- parentheses -- never hurts, and it can reduce ambiguity.  If this were my script, I would have placed them as you did, if only to reduce my own chance of getting confused later.

---

I became paranoid about precedence shortly after leaning to program in C. I moved programs from Dad's PDP-11 to his (my!) Mac, and they stopped working. I don't think the C language had become an ANSI standard yet, so there were some aspects of the language that were "open to interpretation".

Nobody has (yet) complained about all the extra parenthesis and whitespace in my programs, and I think that's because I've left no room for interpretation.

I don't code much these days, you you're all welcome to some parens I'm not using.

(((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((

)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))

Oh, have a few extra braces as well. The compilers seem more consistent about recognizing blocks, but I always seemed to have a problem.

{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{

}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}

And now, because I'm nefarious.

= == = == = == = == = == = == = == = ==

;-)

 

[Qwalyphi Korpov]

I have to agree with everyone except Handario.  Every possible string will either not start with "//" or not be all blank.  Lines of all spaces don't start with "//".  Lines that start with "//" aren't all spaces.  So the condition presented eliminates or includes everyting... not show is whether the if includes or excludes items

 

data == "// something" gives (FALSE OR TRUE) resulting in TRUE

data == "                  "  gives (TRUE  OR FALSE) resulting in TRUE

data == "non blank"   gives (TRUE  OR TRUE)   resulting in TRUE

 

[Madelaine McMasters]

---

Qwalyphi Korpov wrote:

I have to agree with everyone except Handario.  Every possible string will either not start with "//" or not be all blank.  Lines of all spaces don't start with "//".  Lines that start with "//" aren't all spaces.  So the condition presented eliminates or includes everyting... not show is whether the if includes or excludes items

 

data == "// something" gives (FALSE OR TRUE) resulting in TRUE

data == "                  "  gives (TRUE  OR FALSE) resulting in TRUE

data == "non blank"   gives (TRUE  OR TRUE)   resulting in TRUE

 

---

Correct, which is why Rolig's && suggestion fixes the code...

data == "// something" gives (FALSE AND TRUE) resulting in FALSE

data == "                  "  gives (TRUE  AND FALSE) resulting in FALSE

data == "non blank"   gives (TRUE  AND TRUE)   resulting in TRUE

 

[Innula Zenovka]

I would write it slightly differently:

	data = llStringTrim(data,STRING_TRIM);		if (data !="" &&llGetSubString(data,0,1)!="//"){			//process the data		}

 The reason for trimming the data before analysing it is that otherwise you risk circumanstances in which the data begins with a single space (or non-printing character) and then //.     That would cause it to be processed.

Certainly, though, you should be using && as the operator, not ||.   Unless that's a typo, your statement "Until now this worked for me" can't be right, because the || should mean the data is processed no matter what.    

If the data begins //, then llStringTrim(data, STRING_TRIM)  !="" is true,  

If llStringTrim(data, STRING_TRIM does equal "", then llGetSubString(data,0,1) isn't "//".

So both  the negative conditions can never be false  at the same time.   At least one of them is always going to return TRUE.

[Handarido Optera]

Thank you all for the valuable information. You all are dealing with the term itself, suggesting altered variants, different approaches, and logical backgrounds of your suggestions. Thank you very much. But I am sorry to maintain that all are missing the point: The SAME code works in the SAME prim in ONE script AS INTENDED, in the OTHER script NOT AS INTENDED. Or in short, the SAME code (yes I did copy and paste, it IS the same code) has DIFFERENT results. In one case blocking BOTH "//" and " ", in the other ONLY " ". SAME code. My point was not about the logic of the term, it was about the logic that the same term resulted, so to speak, in YES in one script, in NO in the other. So I finally figured the problem was somewhere else in the code.

I think I got it now, it is about naming variables. One tends to name variables easy and descriptive. So for instance, "name" for a name. All works fine for weeks with the growing script until one day you get problems. You test and test and read and blog and go forums a.s.o. a.s.o. The code looks clean and perfect as given in the working examples, whereas your hair is a mess from raising. A search for each variable names in the whole script reveals finally the matter: One of the variable names you picked is used as a parameter name in a function you recently added. 

You may say, what a noob, this is self-evident. But especially as a noob, you might run (as I did) into this problem of name clashes when sticking to the tutorials, wiki explanations, given examples. Even unintentionally, despite carefully naming your variables differently. To give an example, look at these events according to the wiki:

listen(integer channel, string name, key id, string message )

link_message(integer sender_num, integer num, string str, key id )

Works all fine until one day you add a condition if(id == ...) The script gets confused and that results in that the script does not execute code properly. Once confused, it refuses even to execute a condition where the code is perfectly fine and has nothing to do with the clashing variable name. That makes bug detection and testing an infinite journey because the bug is not there where the code does not work. So for instance, I write now always

link_message(integer sender_num, integer num, string l_message, key message_id )