Zugg Software :: View topic - [3.20]BUG: Local variables produce different results than global variables

Posted: Sat Jun 19, 2010 2:24 pm

Not sure what's going on with this one, but I found this out because one of my scripts was returning incorrect output. The script itself is quite simple:

Newbie Joined: 01 Apr 2010 Posts: 7

Looks like local variables, or possibly function parameters, or both, have changed dramatically, and not for the better. Many of my scripts have broken, after upgrading to 3.20 from 3.17, and it looks like the common thread between them has been that the broken scripts use local variables and/or call functions with named parameters.

I have a number of test jigs that I run after upgrading to a new beta version, and those test jigs won't even call any of their tests correctly any more. 3.20 is the first version to cause the test jigs to break. These jigs rely pretty heavily on passing values around, so getting them fixed will give me a pretty solid idea of what's going on.

I'll certainly be trying Charneus' %eval stuff above, but if it turns out that all parameters have become strings, that's a pretty big step backwards. In my case, I'll have to overall a large number of scripts, just to introduce variable type conversion code, and I'd consider that a pretty tough payment for anyone upgrading.

I'll provide more detail when I have it, but I wanted to make note that Charneus isn't the only one with issues with local variables.

Tyebald

Posted: Mon Jun 21, 2010 4:41 pm

Please add some additional examples to this thread of some simple scripts that are not working. In Charneus's script, if I replace the call to %regex with some direct variable assignments, then it all works. So I need to pin down if this is a more general problem or just a problem with %regex. Since %regex assigns values to it's variable arguments, it works differently than a lot of other functions.

Posted: Tue Jun 22, 2010 8:04 pm

The issue that I discovered here is that when %match assigned the results to the local variables, the local variables were being treated as Literal String values rather than AutoType values. So in the first line, it was assigning the string "1" to $GQLow and "4" to $GQHigh. And when testing GQHigh:

%eval($GQHigh>11)

it was essentially doing a STRING comparison:

%eval("4">"11")

which was returning true.

I found where I had removed the auto-type of local variables. It had been done to prevent conversion of string tables into string values. But I moved this to the routine used by some functions (like %match) to assign a string/autotype value to a local variable and that should fix it.

So it's possible this might effect other areas where values are assigned to local variables and the AutoType wasn't working and it treated the local variable as a strict string value.

Posted: Tue Jun 22, 2010 9:26 pm

Yeah, I'd been trying to figure out a test I could run to find additional examples, but never could come up with anything. I figured it was something to do with typing the variable, at any rate.

Is this going to be fixed in the future, then?

Charneus

Posted: Tue Jun 22, 2010 9:34 pm

Should be fixed for the next version for Friday.

Apprentice Joined: 23 Jun 2004 Posts: 105 Location: Poland

By the way Zugg, is it better to use the dedicated type of variable rather than Autotype? Is it faster?
I noticed that, after some cMud update, when at the start variable has a type Autotype, after using for eg. #ADDKEY, the type changes to Database Record and after using #ADDITEM - it's changes to the String List, of course this is ok, but is it faster/better to take care by myself to use the dedicated variable type rather then Autotype?

Posted: Tue Jun 22, 2010 10:08 pm

No, there really isn't any performance hit. You should stick with Autotype. In fact, changing the variable type manually yourself might end up being slower because you could accidentally cause an internal table to be converted to or from a string value.

You are correct that using a list command like #ADDITEM will convert the variable to StringList and using a db command like #ADDKEY will convert the variable to Record. This is actually showing that CMUD is creating the internal table, which is what you want. So it's better to let CMUD take care of this since it knows exactly when to perform the conversion for best performance.

For lists and db records, you should really avoid ever messing with the %vartype. Really the only reason to ever use %vartype yourself is when you have a number stored in a variable and you want to be sure it's treated as a literal string value and not a number.

Doing a direct variable assignment, like:
var = "123"
vs
var = 123
already handles this correctly. But imagine that you have some complicated function that returns a value and you want to ensure that any numeric value gets treated as a string and not a number, then you might use %vartype to force the Literal String type.

If the concept of AutoType ever gets in the way and you find yourself needing to use %vartype, then that usually indicates a bug in CMUD or that you are doing something wrong in your script.