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
Urit
Novice


Joined: 23 Jun 2005
Posts: 32

PostPosted: Sat Oct 20, 2007 5:10 pm   

[2.07] Local variable appending not working correctly
 
I found a fun little bug in local variables.

Any alias which assigns to another variable in this manner has the problem.

To replicate, make an alias with a named parameter. For example:
Code:
#alias bar($foo,$faa) {#variable test$foo 1;#variable test$faa "sixteen"}


Run it with the command:
Code:
bar bippy boo


You will get 2 variables created. In my install, they are: @test4096 and @test4097. This issue occurs with both a previous-version (2.05) package and a fresh install of CMUD with no packages.

If you use a longer name for the local variable, the number will be longer. If you use #variable %concat("test",$foo) 1 it works perfectly.
Reply with quote
Tech
GURU


Joined: 18 Oct 2000
Posts: 2733
Location: Atlanta, USA

PostPosted: Sat Oct 20, 2007 5:49 pm   
 
Confirmed. It seems to be something to do with the implicit concatenation. This is in my mind a "grey area" bug. It doesn't work like one might expect. But Zugg has often warned of the odd results of implicit concatenation.
_________________
Asati di tempari!
Reply with quote
Urit
Novice


Joined: 23 Jun 2005
Posts: 32

PostPosted: Sat Oct 20, 2007 5:54 pm   
 
Well, I can see it just NOT WORKING and trying to make a variable called "test$foo", but appending some weird number is OBVIOUSLY not a feature. Razz
Reply with quote
Taz
GURU


Joined: 28 Sep 2000
Posts: 1395
Location: United Kingdom

PostPosted: Sat Oct 20, 2007 8:24 pm   
 
I agree with Tech and I don't think Zugg will disagree either, you have to use the concat.
_________________
Taz :)
Reply with quote
Urit
Novice


Joined: 23 Jun 2005
Posts: 32

PostPosted: Sat Oct 20, 2007 8:55 pm   
 
If I need to use %concat, then please explain why #variable test@{variable} works fine, but #variable test${localvar} doesn't. I'm just trying to nail down if it's a bug that I get random numbers, a bug that it does even try to concat, or what.
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: Sat Oct 20, 2007 9:05 pm   
 
I believe the number is because local variables are indexed using a number. Normal variables aren't, that's why it works. If CMUD were going to be very strict, it wouldn't work, but it does.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
Urit
Novice


Joined: 23 Jun 2005
Posts: 32

PostPosted: Sat Oct 20, 2007 9:38 pm   
 
Fair enough - now, is there a workaround? I use this functionality quite a bit, so I'm wondering if there's any shortcut (for example, "string" . $var . "string") other than %concat("string",$var,"string").
Reply with quote
Arde
Enchanter


Joined: 09 Sep 2007
Posts: 605

PostPosted: Sat Oct 20, 2007 9:45 pm   
 
I think Fang is right. The numbers is not random, they go in a sequence, because your local vars was created one after another.

P.S. Hmm, I can't get command history in untitled session by pressing the UP key, only through history drop-down list. Is it a feature?
_________________
My personal bug|wish list:
-Wrong Priority when copy-paste setting
-1 prompt trigger for Mapper, Session and General Options, not 3 different!
-#SECTION can terminate threads
-Buttons can't start threads
Reply with quote
Urit
Novice


Joined: 23 Jun 2005
Posts: 32

PostPosted: Sat Oct 20, 2007 10:00 pm   
 
Interesting other development: it works with other implicit concatenation.

For example:

Code:
<alias name="addAff" id="81">
  <value>#ADDITEM affs $aff
#IF (!%null($procShort)) {#IF (@attackType != 0) {#variable need$procShort 1} {#execute proc$procShort}}</value>
  <arglist>$aff,$procShort</arglist>
</alias>


If attackType is 0, it does work and does execute a command correctly.
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: Sat Oct 20, 2007 10:36 pm   
 
It's presumably because the #var command can also be used to edit the value of a local variable, which is why the name of the local variable in the name parameter of the #var command is expanded into its reference number. #exec only ever expands variables to their values, so it's not ambiguous.

A slightly shorter way, if you really want one, would be to use ("something" + $var).
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
shalimar
GURU


Joined: 04 Aug 2002
Posts: 4662
Location: Pensacola, FL, USA

PostPosted: Sun Oct 21, 2007 7:21 am   
 
I found a quick way for it to fail:

Code:
#TRIGGER {You (*) the%s(*) (%x)'s (*) with your (*).$} {
$t1=%1
$t2=%2
$t3=%3
$t4=%4
$t5=%5
#LOOP 5 {#ECHO $t%i}
}

#SAY {You pierce the clever Uthragoth barbarian's head with your long sword.}

and it will return with:

ERROR: Alarm Trigger You (*) the%s(*) (%x)'s (*) with your (*).$ fired but did not compile


i have tried every combination of %concat( "$t", %i), %expand, %eval i can think of
_________________
Discord: Shalimarwildcat
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1269

PostPosted: Sun Oct 21, 2007 3:13 pm   
 
And does the trigger indeed not compile?
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: Sun Oct 21, 2007 6:15 pm   
 
That example doesn't, because $t is an invalid local variable, but other examples that perhaps should work don't.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: Sun Oct 21, 2007 6:22 pm   
 
I haven't checked it but this should work correctly. If it does not then perhaps Zugg can suggest something that will, or a parser change is needed.
#LOOP 5 {#ECHO ${t%i}}
_________________
The only good questions are the ones we have never answered before.
Search the Forums
Reply with quote
shalimar
GURU


Joined: 04 Aug 2002
Posts: 4662
Location: Pensacola, FL, USA

PostPosted: Mon Oct 22, 2007 8:02 pm   
 
Nope that variant doesn't work either.

Error compiling script:
invalid local variable: t%i
_________________
Discord: Shalimarwildcat
Reply with quote
Zugg
MASTER


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

PostPosted: Mon Oct 22, 2007 8:08 pm   
 
Sorry, this is just a bug. Local variables were changed to return a numeric reference so that commands like #ADDITEM could work with this. But this has had a nasty side effect of always returning a numeric value instead of the local variable contents in all sorts of other scripts. So yes, local variables are a bit broken right now.

In the case of the command:

#LOOP 5 {#ECHO ${t%1}}

you *cannot* perform any indirect local variable lookups. I think you *might* be able to use the %param function to look up named arguments, but I don't think it will work with local variables. Local variables are stored on the runtime stack and are not available to any of the "implicit concat" kinds of parsing syntax. Anything that requires *runtime* parsing vs *compiled* parsing will not work with local variables (because they are only available at compile time).

So, there is no way to product a local variable reference that is evaluated delayed at runtime. Local variables can only be direct references, which is why they are so fast.
Reply with quote
shalimar
GURU


Joined: 04 Aug 2002
Posts: 4662
Location: Pensacola, FL, USA

PostPosted: Mon Oct 22, 2007 8:21 pm   
 
Shouldnt an explicit concat work though? cause %concat( "$t", %i) doesnt work either.
_________________
Discord: Shalimarwildcat
Reply with quote
Zugg
MASTER


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

PostPosted: Mon Oct 22, 2007 8:25 pm   
 
No. Because %concat("$t",%i) is creating the name of the local variable at *runtime*, and local variable names are only available at *compile* time. The compiler converts all local variable references into indexed locations on the runtime stack. At runtime these local variable names no longer exist.

When you use a local variable like $t1 in your script, look at the compiled code tab in the settings editor. You'll see that this was compiled as "Localvar 1" or something like that. In other words, the name "t1" is gone and is replaced by just a number. So at runtime, there aren't any names left so when trying to create a name at runtime like with %concat, there is no way to convert this into a numeric index anymore. Again, that's why local variables are fast...because they are converted to numeric indexes at compile time and not at runtime.
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