Zugg Software :: View topic - Functionality question

Posted: Sun Apr 01, 2007 8:06 am

Tried version 1.26 as my first version since about 1.13, impressive changes! Very few bug messages now. Converted my system across with no compatibiltiy errors, and most things work as intended. However, got a little question on functionality that I have lost and would like to know how to do now.

#fo @design{
clothingLine %i
;couple of other functions
#echo {@commLine}
}

The idea is to collate a large set of information from various variables regarding items of sewable clothing in the mud.

Simplified to show a point. I'm in the middle of a forall loop, and I'm running the clothingLine alias. This saves a value to the commLine variable, which I then want to echo along with other things (as I say, it's simplified).

This doesn't work correctly. My assumption is that it is not finished with the clothingLine alias before it continues, echoing the output before it is ready.

What I need is a command of sorts that says "execute this now, and don't proceed until it is done".

What I previously used in zMud was the <> operator for immediate expansion.

The expansion was very rarely what I used it for, and yes, removing the <> in 95% of cases mean my zMud scripts still work in CMud. However, the ability they exhibitied of "execute this now, and don't proceed until it is done" was my main use for it. I could have my understanding all wrong here, but this is how it seems to me to be. Thoughts?

On another note, are we going to have an actual sql-queryable database in the future? The zMud db before seemed okay, but I found it very clunky to use (can't quite remember why though, it's been a long time since I used it).

Posted: Sun Apr 01, 2007 11:09 am

CMUD doesn't continue with the script until the alias is finished. Similarly, it'll only execute one trigger at a time and won't process anything else until the trigger is done. Lack of <> isn't the problem here - it's probably some other syntax error in your clothingLine alias.

And yes, we are going to have SQL databases in the future.

Posted: Sun Apr 01, 2007 2:58 pm

clothingLine worked correctly in zMud and works in CMud if I run it seperately.

Here is a sample test:

clothingLine 1234;#echo {@commLine}

Changed to use a static number instead of %i, it works. An alias that does that test works. Inside as #FORALL loop, it works.

However, when using %i instead of the static number, it does not. This is the case in zMud and CMud. In zMud the addition of <> around the call to clothingLine corrected the problem. What is the potential problem with %i, or is it perhaps somewhere else?

Posted: Sun Apr 01, 2007 3:46 pm

Well, I used this test script:

#alias test {#say %-1}
#forall cars|bikes|trains|planes {test %i}

and it worked fine. The only thing that's changed about %i is what's done with it when it's sent to the clothingLine alias. The entire contents of %i (even if it's multiple words) will only be interpreted as one parameter of the alias. That's why I suggest that it's a problem with that alias.

Posted: Sun Apr 01, 2007 4:29 pm

Tracking through the problem in an attempt to explain better, it seems that my original example is not full enough to describe what is happening.

Adding a load of debug information to my scripts, this is how I understand the error to be at the moment.

Alias: aForall
#fo @varForall {
aLoop %i
}

Alias: aLoop
#loop 1,3 {
#echo {"%1 test:" %1}
#echo {"%i test:" %i}
}

Variable: aForall
271|2620

In this situation, running aForall gives the following output.

%1 test: 271
%i test: 271
%1 test: 271
%i test: 271
%1 test: 271
%i test: 271
%1 test: 2620
%i test: 2620
%1 test: 2620
%i test: 2620
%1 test: 2620
%i test: 2620

and running aLoop (with 777 as the only parameter) gives...

%1 test: 777
%i test: 1
%1 test: 777
%i test: 2
%1 test: 777
%i test: 3

The latter is more like what it should be doing. In my clothingLine I was running a similar loop to aLoop, but was saving something involving clothingLine's %i to a variable. Ah, how useful debug information can be :)

From what I can see, in nested loops the second %i in aLoop seems to not be referring to aLoop's loop at all, but still contains the information from aForall's %i. You're quite correct that it's a problem involving that alias, but not in a fashion that I had thought!

In finding this, I remembered the removal of the %%i syntax from zMud, since I'd read the changelog. I'd never used it before, but it seems like it would have been necessary in this situation. Reading through it's fix, local variables, I am not sure how they could be used to fix this problem. Is there in fact a problem with nested loops instead?

Posted: Sun Apr 01, 2007 6:20 pm

Now that's a much more useful example. I think this is indeed a bug with the way nested loops are handled. If you were running a normal loop like this:

#forall %1 {#loop 1,3 {#say %i}}

then %i will still contain the value from the iteration of #forall. To correctly produce the iteration number from the #loop, you need to use %j instead of %i. Changing the %i in aLoop to %j will fix this script. But it shouldn't have to, because then the alias can't be used on its own.

Posted: Mon Apr 02, 2007 10:58 am

Hmm... technically at all points my clothingLine (the equivalent of aLoop) is being called it is in another loop. %j fixes this problem in all instances. It was coded initially to be standalone however, so whilst this is indeed a welcome temporary fix, it doesn't fix the root problem. (However, I don't really call this function myself personally, so can probably forget about it.)

Should I repost this bug in the forums as a new topic for Zugg to catch, or is there another bug submission method these days? Appreciate the help too Fang, thanks.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

This particular problem should go into the Cmud Beta forum as a bug. There are three methods to report bugs these days but two of them rely on emails. I have noticed that if for whatever reason I report a bug ONLY via the cmud interface it is FAR more likely to be overlooked until later. YES, I include screen shots AND explanations of the crash what i was doing etc.

So, If I have a crash bug I use the crash report THEN I try to reproduce the problem and post the steps on the boards. Once other people have agreed that yes it is a bug and it can be reproduced it also makes things easier for Zugg to fix them.

The third method of reporting bugs being simply emailing Zugg. And I would say that just given the way email work. Spam and the like not to mention the lack of either direct info from the crash dump/screen shot/others reproducing the problem. It falls very short.

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

I've asked for this behavior to be changed such that %i, %j, etc are treated as local variables. I was told, however, that my scripts would need to be re-written to accommodate loops in nested aliases, hopefully only as a temporary workaround. My workaround was basically to pass the entire list to the alias(es) and let them loop on things, but that's not possible in every situation.

Posted: Mon Apr 02, 2007 4:49 pm

Posted: Mon Apr 02, 2007 4:53 pm

Thanks for the confirmation there Zugg, and thanks also to Arminas and Larkin for their additions. Shall be watching forthcoming versions with keen interest!