Zugg Software :: View topic - [2.12] New #WAITFOR syntax throws "argument still on stack" Error

Apprentice Joined: 03 Nov 2007 Posts: 132

Type on command line:

#THREAD "TestThread" {#WAITFOR {TestPattern} 500 {#say pattern matched} {#say timedout}}

If you type #say TestPattern immediately after this you get:

ERROR: argument still on stack: #say pattern matched

If you let it timeout you get:

ERROR: argument still on stack: #say timedout

This is the only syntax I could find on how to use the new #WAITFOR based on Zugg's comments in the #SUSPEND not suspending #WAITFOR thread.

Posted: Sat Nov 17, 2007 6:33 pm

I can't get this to fail here. I tried your example above and let it time out and I didn't get any error. I also tried the simpler:

#WAITFOR {TestPattern} 500 {#say pattern matched} {#say timedout}

example and it worked too. So can anyone else confirm this? Maybe you still have the old cmd.db command database from an older version?

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

It seems to be working fine for me too

Apprentice Joined: 03 Nov 2007 Posts: 132

Well I uninstalled everything prior to reinstalling 2.12 but I will try again.

Apprentice Joined: 03 Nov 2007 Posts: 132

Uninstalled again, deleted essentially everything cmud related on computer except my specific package. Installed again, worked fine. One of these days I'll make a bug thread regarding uninstall not working properly.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I haven't quite gotten to installing 2.12 yet. I will see if I can get my installation to replicate the problem. Perhaps I will finally get to make a bug report that doesn't require "1. Launch CMud".

Malach, if you could tell me how you normally do your installation it would be helpful.

Apprentice Joined: 03 Nov 2007 Posts: 132

Normally I run the uninstall.exe in the CMUD folder. Click continue on the million approve windows Vista pops up. Then I have to go actually delete the CMUD folder as the uninstall doesn't do that. I empty my recycle bin then run the install program freshly downloaded.

If I'm trying to be extremely clean I delete everything on my computer cmud related except for my package itself.

Also, Zugg, my earlier cleaning didn't actually fix the problem as next time I got an error I was right back to the new command syntax not being recognized. Where would I find the cmd.db to see if that's the problem?

Posted: Sat Nov 17, 2007 8:45 pm

The cmd.db file should be in the same directory as the CMUD.EXE file.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Ok Malach, when you say "next time I got an error" do you mean the #VAR problem you have been having, any crash, or just any sort of parsing error. Also please check the original #WAITFOR syntax, as well as all the newer commands and functions "#RESULT, #RETURN, #BREAK, #EXIT, %priority". I am just fishing here because I have never had any of the commands become broken like that with CMud.

Another thing to try is make sure it isn't working, close CMud, make sure it is closed by checking in the task manager, then copy the cmd.db, finally try to delete the cmd.db. The reason I suggest trying this is because it might show that something has the db in use and is causing the problem. If we find that to be the case then it is quite a bit easier to work at figuring out what is keeping it in use.

Apprentice Joined: 03 Nov 2007 Posts: 132

Any error that prompts a pop-up window. An error from searching the settings. An access violation. An index out of bounds. Any of those.

None of the commands as implemented by 2.12 work as implemented by 2.12. The original #WAITFOR works fine but not the modified one. #RETURN works but as it did in 2.11. #RESULT is not recognized, #EXIT is not recognized.

Deleting the cmd.db file works normally without it being in use elsewhere. Also, the cmd.db file is showing a date modified of 11/17/2007 12:48 AM so I'm assuming this is the latest one. I'm at a loss.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

So #RETURN is no longer breaking the way it did for you in 2.11, instead it is functioning as it was supposed to 2.11 and not operating the way it should for 2.12. Curiouser and curiouser. Just for giggles run a full file search on your system for "cmd.db".

Apprentice Joined: 03 Nov 2007 Posts: 132

I got 2.11 to work eventually but it involved deleting a lot of registry keys. I just had to do the same after doing an uninstall of this version so we'll see if it fixes it.

I did do a full search for the cmd.db and only the one in the cmud program file folder was coming up.

EDIT: No, this didn't fix it this time.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I think we established that something in your system is caching the older cmd.db. Maybe there is something Zugg can do with how he opens the database to deal with the problem, but I am at a loss to guess what is doing it or where to find it.

I would guess that that same caching is also the cause of the duplicate variables, and likely the reason that the duplicate variable actually cause an error for you.

Maybe someone with the same version of Vista as you can help. Maybe you should in the control panel for something like Data Sources and see if there is any mention there. Beyond that the only thing I can hazard saying might help is a reboot.

Apprentice Joined: 03 Nov 2007 Posts: 132

Reboots don't help.

Apprentice Joined: 03 Nov 2007 Posts: 132

So after an exhaustive search of every nook and cranny of my computer I found a folder called "virtual store" in this folder was a CMUD folder that had a variety of cmud files in it which included a cmd.db file from the 9th. A cmd.db file that was NOT showing up in all my other searches.

So I cleared that out and did some searching on this virtual store. Apparently Vista's security measures know few bounds. Here's a quote:

"For example, if a member of the Users group is logged onto a machine and runs an application that writes a log file back to the Program Files directory, this write will fail. Why? Because the access control list (ACL) on the Program Files directory does not allow standard users to write to that location. When the data redirection file system driver receives the failed return code from this write, it redirects the write to a copy of the file made in the virtual store, a location in the user’s profile."

and

"Another technology designed to flag legacy applications as needing elevation is installer detection. Installer detection tells AIS that an app needs to be elevated based on certain predefined criteria, such as the executable name containing "setup" or the binary resources containing "installer." There is currently no facility within Windows Vista to delegate elevation of an app to certain users or groups."

If you would prefer a program to not do this you can flag it run as administrator all the time and some also suggested as setting it to run as an XP service pack 2 program.

So yeah...

Anyway, my mysterious non-recognizable commands error is gone and I'll see whether or not the duplicate variable issue is solved as well.

Posted: Mon Nov 19, 2007 5:37 pm

Apprentice Joined: 03 Nov 2007 Posts: 132

I have always accepted the default installer options and the program files were in the Program files area and the data files in the my games CMUD directory. The problem arose because uninstalling didn't get rid of the older files in my virtual store area and the program would read from the updated files the first few times it was run but after that go back to the old ones in the virtual store.

Posted: Mon Nov 19, 2007 7:22 pm

That's what I don't understand though. The uninstaller does delete files like the cmd.db file. And I haven't seen this trouble on my copy of Vista, so I'm not sure what is different. And I don't get any CMUD files in my virtual store. Maybe someone else who has some experience with installers and uninstallers on Vista can help more, but at this point I'm not sure what I'd do differently. Or maybe I'll take a look at Nullsoft's forums to see if there are any suggestions there. But the CMUD installer/uninstaller really isn't very complicated at all. I know Vista has some annoying stuff in it, but I'm not sure what is causing this to happen on your system but not mine.

Apprentice Joined: 03 Nov 2007 Posts: 132

I'm not sure. Since I set CMUD to run as administrator nothing has populated in that virtual store but it wasn't running as administrator before, just as a normal program.

Posted: Mon Nov 19, 2007 8:09 pm

You shouldn't mark CMUD as always running as admin unless you absolutely need to. This isn't needed normally on Vista and if CMUD isn't working unless the Run as Admin is enabled, then that's an indication that something else is wrong in the permissions or privs on your Vista system. I've tried CMUD "out of the box" on both Vista Home and Vista Business (don't have Vista Ultimate though) and it works fine running as a normal application.

Since we are still beta testing, I'd prefer that you turned off the "Run as Admin" so that we could determine if there are still problems with Vista that we need to resolve.

Apprentice Joined: 03 Nov 2007 Posts: 132

It works fine out of the box except this updating issue. I can turn it off and then see what happens next time I go to upgrade with the next beta version.