About Us
Products
Purchase
Downloads
Support
Forums
Contact Us
Site
 Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD Beta Forum
charneus
Wizard


Joined: 19 Jun 2005
Posts: 1876
Location: California

PostPosted: Sat Jun 19, 2010 2:24 pm   

[3.20]BUG: Local variables produce different results than global variables
 
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:

Code:
#LOCAL GQLow GQHigh
#CALL %regex("1to4","(\d+)to(\d+)",$GQLow,$GQHigh)
#PRINT {Showing local variables:%cr    GQLow: $GQLow%cr    GQHigh: $GQHigh}
#PRINT {Showing if GQLow<11<GQHigh:%cr    GQLow<11: %eval($GQLow<11)%cr    GQHigh>11: %eval($GQHigh>11)}
#CALL %regex("1to4","(\d+)to(\d+)",@GQLow,@GQHigh)
#PRINT {Showing global variables:%cr    GQLow: @GQLow%cr    GQHigh: @GQHigh}
#PRINT {Showing if GQLow<11<GQHigh:%cr    GQLow<11: %eval(@GQLow<11)%cr    GQHigh>11: %eval(@GQHigh>11)}
#PRINT {Showing difference between local and global variables (local-global):%cr    GQLow: %eval($GQLow-@GQLow)%cr    GQHigh: %eval($GQHigh-@GQHigh)}
#PRINT {Confirming local variables are numbers:%cr    GQLow: %isnumber($GQLow)%cr    GQHigh: %isnumber($GQHigh)}
#PRINT {Showing difference between global and local variables (global-local):%cr    GQLow: %eval(@GQLow-$GQLow)%cr    GQHigh: %eval(@GQHigh-$GQHigh)}


produces the following results:

Code:
Showing local variables:
    GQLow: 1
    GQHigh: 4
Showing if GQLow<11<GQHigh:
    GQLow<11: 1
    GQHigh>11: 1
Showing global variables:
    GQLow: 1
    GQHigh: 4
Showing if GQLow<11<GQHigh:
    GQLow<11: 1
    GQHigh>11: 0
Showing difference between local and global variables (local-global):
    GQLow: -1
    GQHigh: -4
Confirming local variables are numbers:
    GQLow: 1
    GQHigh: 1
Showing difference between global and local variables (global-local):
    GQLow: 0
    GQHigh: 0


I think the problem lies in the fact that the local variables are being set to strings instead of whatever the correct vartype is. I went ahead and change the evals to %eval(%int($GQHigh)>11) and it worked as expected.

Charneus
Reply with quote
tyebald
Newbie


Joined: 01 Apr 2010
Posts: 7

PostPosted: Sun Jun 20, 2010 6:13 pm   
 
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
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
charneus
Wizard


Joined: 19 Jun 2005
Posts: 1876
Location: California

PostPosted: 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
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Tue Jun 22, 2010 9:34 pm   
 
Should be fixed for the next version for Friday.
Reply with quote
Yodous
Apprentice


Joined: 23 Jun 2004
Posts: 105
Location: Poland

PostPosted: Tue Jun 22, 2010 9:44 pm   
 
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?


Last edited by Yodous on Wed Jun 23, 2010 3:20 pm; edited 2 times in total
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD Beta Forum All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net