Zugg Software :: View topic - #delnitem and #additem sometimes loses list-ness

Apprentice Joined: 13 Feb 2004 Posts: 157 Location: USA

My intent: use a set of list variables to each store 20 strings, removing the oldest each time I add a new one, for a "rolling buffer" history of each of several channel-sets. The trouble is, I'll create a variable as a list and then sometimes it forgets that it's a list and turns into a single string. I'm updating it using only this alias (savehistory):

sChanText = %trim( %replace( %stripansi( %-2), "|", ";"))
#if (@sChanText <> "") {
#delnitem %concat( "lChanHist", %1) 1
#additem %concat( "lChanHist", %1) @sChanText
}

I might call it like this:

savehistory Market (Market): Bonzo says, 'Buy my stuff!'

and the string "(Market): Bonzo says, 'Buy my stuff!'" should be put into the end of lChanHistMarket, while the oldest item in said list disappears.

This often works, but if I leave it running for a while, the list might become only a few items long, or more commonly, forget that it's a list entirely, so if I look at it I see only one item like any old string variable. I thought it might be because of characters in the string that confuse #additem, and the %replace() and %stripansi() are (futile) precautions to try to avoid that, but maybe there are other characters to avoid. (I'm also replacing double-quotes (") with single-quotes (') prior to calling the alias.)

Can anyone suggest what could be causing these lists to change length or simply cease to be lists?

MASTER Joined: 28 Nov 2000 Posts: 4817 Location: USA

You won't need %trim. Aliases automatically trim leading/trailing spaces unless you make a special effort to include them.

You won't need %stripansi. Just don't type in any ANSI codes and there won't be any to strip. Since you're probably using a trigger to do this, just don't select the ANSI Trigger or Line Color options and the trigger will take care of stripping ANSI codes. Of course, it would be simpler to put the script in the trigger itself, but I'm sure you have reasons for using an alias instead.

EDIT: When you replace the list-separator |, with the command-separator ;, your variable ceases to be a list.

Characters which are likely to cause problems include all special characters. The comma is especially difficult to handle since it is a delimiter for all functions, which is why I avoid using %concat as much as possible.

#TR {^~(Market~):} {#IF (%numitems( @lChanHistMarket) > 19) {#DELN lChanHistMarket 1};#VAR lChanHistMarket {@lChanHistMarket|%trigger}}

Apprentice Joined: 13 Feb 2004 Posts: 157 Location: USA

As it happens I use | as my command separator too. The semicolon switch doesn't cause me any problems, but it also doesn't seem to solve anything.

So a string list can't hold strings that have any special characters, even commas, safely? Dang, that means the entire approach is flawed. Maybe I'll have to resort to doing my own list parsing on a plain old string instead, using %word().

Posted: Mon Mar 15, 2004 4:12 pm

IMHO there is no need to change the command separator. The list-separator will always be |, it can't be changed unless you use different list handling functions and commands. Almost any character in the ASCII list can be used in your list except the list separator character.

The main problem i see in your script is '%stripansi( %-2)'. If the string passed into %-2 has commas, it multiplies the number of arguments seen by the function. First of all zMUD functions are sensitive to commas, secondly %-2 expansion is always done first (arguments are directly pasted) in the script. When dealing with functions in zMUD, always use double quotes unless you are absolutely sure that commas do not exist in the parameter. It should be %stripansi( "%-2"). If that doesn't work, Open Debug window and Add a Watch on the list variable or expressions while your script is running.

MASTER Joined: 28 Nov 2000 Posts: 4817 Location: USA

It's usually not the stringlist which has problems with special characters, it's the functions.

If you persist in using | as your command-separator, you will be limited to using the list functions and commands to manipulate lists. That will make this sort of script much more difficult, if not impossible.

Apprentice Joined: 13 Feb 2004 Posts: 157 Location: USA

But it's the commas, not the |s, causing the problem. In any case, parsing them myself will work just fine. Given the way values are pasted and not scoped, as long as I can't be sure what text will be in the strings, I think #additem would always be brittle no matter which special characters are being used.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

I had problems with commas in parameters when I was doing triggers to tag room names for the automapper. My solution to the problem was quite simple: put the parameter inside double quotes, making the parameter count as a single string.

%replace("%-2", "|", ";") should work, if %replace(%-2, "|", ";") is giving you problems.

MASTER Joined: 28 Nov 2000 Posts: 4817 Location: USA

Instead of arguing over which special characters cause problems, just try the trigger.

Modified for | as command-separator:
#TR {^~(Market~):} {#IF (%numitems( @lChanHistMarket) > 19) {#DELN lChanHistMarket 1}|#VAR lChanHistMarket {@lChanHistMarket~|%trigger}}