Zugg Software :: View topic - [2.11] Parsing error with #THREAD {name} {commands}

SubAdmin Joined: 18 Nov 2001 Posts: 5187

The parser does not report an error with this instead the commands portion of the command is sent to the mud.

#THREAD abc {#WAITSIGNAL def}
Works. This results in a thread with a name of 'abc' and commands of '#WAITSIGNAL def'

#THREAD {abc} {#WAITSIGNAL def}
Fails. This results in '#WAITSIGNAL def' being sent to the mud.

SubAdmin Joined: 18 Nov 2001 Posts: 5187

Further item on this, threads again not being reused. The debugger log with all message on doesn't even show the creation of the thread. One is created each time though.

Posted: Wed Nov 14, 2007 12:05 am

The #THREAD command currently doesn't call the debugger log routine, so I'll fix this.

And yes, the syntax error is normal. It like using a trigger ID. The name of the thread needs to be either in " quotes, or by itself, otherwise the parser thinks that you are omitting the name and just giving the thread commands. This is because the name is an optional argument.

SubAdmin Joined: 18 Nov 2001 Posts: 5187

That doesn't quite make sense. The parser DOES NOT report an error. The portion that is the commands parameter is treated as commands in both cases.

I guess I am just a little confused because the reference flyout shows the parameter type for the optional name parameter to be the same as 300 other expanded string types. All 300 others recognize {} as a valid parameter delimeter. What you are saying is that #THREAD is treating {abc} as "" which does not make sense.

Posted: Wed Nov 14, 2007 11:43 pm

Yes, it was still a parser problem even though it wasn't raising an error.

Note that this bug *is* different than the #WAITSIGNAL {abc} bug report.

The issue with #THREAD is that the threadname is an *optional* string argument, and it is followed by a "Command" argument. When the parser tries to determine if {abc} is the optional threadname, or the command argument, it was simply looking for the {. This is also done for an optional string followed by a Pattern (to handle optional trigger ID strings).

Since it saw the { around abc, it treated that as a command. I'm not sure why it didn't report an error that there was extra text on the line after that.

In any case, I have fixed this in v2.12 so that it checks for more than just a {. Now it actually checks for various script command characters, such as #, @, %, ;, =, etc. If it doesn't see these characters, then it treats the argument as the optional string.

I only changed this in the case of a "Command" argument following the string. I didn't change it for trigger patterns, because trigger patterns are often just plain text strings. So with the optional trigger ID values, you still cannot put {} around them. But for other commands like #THREAD, it should work better now. Unfortunately, it's just a compatibility issue left over from zMUD before {} were used as general string delimiters in CMUD.

SubAdmin Joined: 18 Nov 2001 Posts: 5187

Now it makes sense. It just makes me wonder how creative I am going to be able to get with thread names. I was considering doing things like #THREAD {%concat("Stupidity",%char)} {commands} the goal of which was to create portions of the script in each session window with a name that is unique to that window. This way I wouldn't have to consider whether session A turned off a class that session B was using.

I am still debating the whole efficacy of using threads in such a fashion though.

Posted: Thu Nov 15, 2007 1:57 am

Hmm, that's true. I can see wanting to create unique names on the fly. I'll give this more thought. Maybe I could allow the % and @ characters, but still not the # ; = characters that are used in commands. Or, maybe I can just make the thread name a required argument instead of being optional.

Wizard Joined: 22 Mar 2007 Posts: 2320

Don't forget the $ character. You should be able to use a local variable to hold the thread name.