Zugg Software :: View topic

Posted: Thu Nov 03, 2005 4:17 pm

Yet another zMUDXP help topic...

What I need from people this time is a list of existing problems with the zMUD syntax checker. The new MUD client is going to be using a variation of the syntax checker parser and while many problems with the syntax checker have been fixed over the years, I know that it still has trouble sometimes.

In the existing zMUD, a script can fail the syntax checker, but still execute properly. These are the scripts that I need to see posted so that I can fix the syntax checker. In the new MUD client, there will only be a single (improved) parser, so if something doesn't pass the syntax check, it won't execute.

The advantage of improving this parser is that it allows for things that were never possible in zMUD. Things like compiled scripts for incredible speed are the most obvious benefits.

I know that zMUD has supported some sloppy script syntax over the years. I want to maintain as much compatibility as possible between zMUDXP and existing zMUD scripts, but I really want to dump the old kludgy parser in favor of the yacc-generated parser used by the syntax checker.

So, please post your thoughts on this, along with any sample code that fails the current syntax checker which you believe is valid. Thanks for your help and support!

Posted: Thu Nov 03, 2005 5:24 pm

One thing that irks me to no end, is if I'm editing a multiline script, and start typing a new command, but pause before it's complete, it goes haywire with pretty print turned on. I usually have to switch to 'Text' finish typing then switch back.

Posted: Thu Nov 03, 2005 6:21 pm

You won't have to worry about that kind of stuff. The editor part of the syntax checker is being completely replaced. And the syntax checking will work a bit differently. And the "pretty printing" is basically being eliminated (or at least completely overhauled). In the new editor, it leaves your script the way you write it, and just does the syntax highlighting stuff.

But the main point of this thread is to identify any problems with the syntax checker itself, since errors in scripts will prevent them from working in the new client.

GURU Joined: 28 Sep 2000 Posts: 434 Location: USA

Sorry for the slightly off topic reply, but...

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

Yeah, I must say I was going to ask the same as Carabas, but resisted :)

I don't have any scripts that don't prettyprint, I think that I may have had some errors in the development process, but just changed my approach to writing the script so that it did prettyprint.

Apprentice Joined: 14 Sep 2005 Posts: 121

I've got something related to the syntax checker/editor, but not exactly a bug, I just thought about it, and everything is blue and black, black and blue. It's kinda fustrating to look through when you're trying to find a specific function, or command, or variable when it's all friggin blue. I suggest allowing for setting your own color code so that you can have functions one color, commands another, and variables yet another. and maybe even color stuff inside of quotation marks. Then it could become a true syntax editor Razz

. Oh yeah, and as I'd stated previously, the bug about everything inside of a substitute being all black and not even coloring the blue.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I sent you over my scripts per a request from another thread. Some of them actually do things that just put the pretty printer into epilespsy. You just have to to look for where I have '#EXEC {%concat' to get an idea what the problems are.

First off the top of my head, is that the syntax checker reports "Identifier expected" for #ADDITEM, #VARIABLE and some others at the opening brace for the first parameter. As I see it that brace should not be a problem. The second part, of the same parameter, is that the contents are a run time pointer.

While I am all for having compiled code; I do not think you can completely eliminate the current parser. Part of the power of zScript is its ability to rapidly handle indirect references. I may not be able to think my way through 7 levels of indirection; but zScript will, and I can actually script all 7 of those levels with the current script structure. I may have to take some extra effort to make the syntax pass the checker, but I don't want to lose the ability to handle such indirection.

zScript has always maintained an extremely high level of flexibility. I am willing to give up some of that, on the front end, so long as it is still available through secondary means. The loss of the runtime parser will mean the loss of indirection. Before you make that move take a step back and look at how many pointers there are in the zMud source compared to how many solid variables. I am sure you will see the value in being able to handle runtime pointers.

GURU Joined: 10 Oct 2000 Posts: 873 Location: USA

Posted: Fri Nov 04, 2005 1:17 pm

The one that ends up irking me the most is the syntax editor complains if you use < in a condition. For example:

#IF {5 <= 3} {true} {false}

Oddly enough > works fine and doesn't cause a problem. I guess it thinks < is trying to expand a variable and not a condition.

GURU Joined: 10 Oct 2000 Posts: 873 Location: USA

Apprentice Joined: 29 Jul 2002 Posts: 105

#alias cfort {:@cleric:#%1 c fort}
it never liked using # then a parameter :P always gives me a bug, even though it worked perfectly fine. I've tried tests/etc with is number and such it always just spazes out on me.

Posted: Fri Nov 04, 2005 4:21 pm

Compiling won't eliminate indirection. What it's doing is compiling to an intermediate code, and then still interpreting the intermediate code. So it's a combination compiler/interpreter, with the advantages of both.

Oh, and OmegaDeus, you can already change all of the syntax coloring. Go into your preferences and look for the Syntax section. You can change all of that black and blue to anything you want!

Adept Joined: 04 Feb 2005 Posts: 246

Here's one:

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

I use the <> expansion syntax a lot in my scripts, and the syntax checker almost always reports it as an error, though it executes properly. When I include spaces somewhere in the expression between the <>, it reports the error. Without spaces, no error.

Posted: Sat Nov 05, 2005 3:09 pm

Larkin, can you provide some specific examples? The <> syntax is pretty old and it's mostly not needed anymore, so I need to see if you are doing something where the <> are still really needed.

Apprentice Joined: 14 Sep 2005 Posts: 121

Novice Joined: 06 Oct 2005 Posts: 31

Sometimes I use the command #T+ with no arguments to turn off triggers (the same way clicking the gun at the bottom right would). The syntax error says this is wrong, so maybe it's just sloppy scripting, but I guess it can be quite useful.

Wizard Joined: 15 Jan 2002 Posts: 1644 Location: USA

@Saplingg, #IGNORE will Toggle trigger parsing on and off

@Zugg, The only syntax error I can recall in my scripts is in the class script view when using #MENU with a caption that starts with #

#CLASS TestMenu
#MENU {#FIND} {#FIND}
#CLASS 0

You will notice the error if you look at the class script for the TestMenu Class

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

I guess, classes should really be:

#CLASS TestMenu {
#MENU {#FIND} {#FIND}
}