First, I need to apologize for the poor quality of v1.13. Now I know why some people seem to be so angry.
Yesterday I fixed a bunch of problems, including the new bug where pressing Enter on a blank line wasn't sending anything to the MUD. That was a side effect of the new OnInput processing occuring on every line sent to the MUD. OnInput normally won't send blank text to the MUD. For example, using the new #NOINPUT command clears the buffer of text being sent to the MUD, so nothing is sent.
So I had to make an exception when using the command line, or when specifically trying to send blank text to the MUD (like #SEND "")
What I also discovered was that *.MUD settings files were not getting loaded/converted at all. I don't know when this broke, but it *used* to work fine. Part of the problem was that the Default Settings (default.pkg) somehow got a "System" class added to them. This was deleted a couple of versions ago, so I'm not sure how it got back in there. Since each *.MUD file also contains their own System class, it was getting confused and placing your imported settings into the default package.
To make matters worse, the changes to the Settings Editor caused it to not create a new tab for the imported settings. So even though the settings were in memory, they didn't show up in the settings editor.
Yeah, it was a complete mess.
Today I added the Compatibility Report to the loading of *.MUD files from the session screen. When opening a session using a *.MUD file, it will convert it to a PKG file and then ask if you want to view the compatibility report. I also uncovered some problems with the compatibility report that I'm fixing.
I also started looking into the multiplaying issues. This gets really complicated. I know a lot of people are upset about how this worked right now, but I assure you that it is NOT WORKING the way I want it. The whole point is to make this EASIER than zMUD and not harder. So I'm well aware of the current problems.
But what gets complicated is that there is only a single screen layout. So when you open two session icons, and CMUD autosaves the layout, which session should get the new layout?
The answer turns out to be "neither". If you want to save a new session icon that automatically loads both sessions, then you need to select the File/Save Session As to save the double-window layout to a new session icon. Currently v1.13 saves the screen layout to the last session that was open, which can really mess it up. But in 1.14 the AutoSave Layout option gets turned off when you load a second session.
I'm also changing how packages are handled when loading multiple sessions. I'm going to try and figure out how to support loading multiple copies of the *same* session. In v1.13 it won't load multiple packages with the same name. So when you load 2 copies of your session, there is only a single copy of the package in memory, so you still only have a single window on the screen, which isn't really what you want.
Anyway, I'll be spending more time this week trying to get all of this multisession stuff working better, and to make it work better with converting your existing *.MUD files.
Today I also got side tracked on a bad parser issue. This was posted over in the Beta Forum, but it was a problem with #REGEX not recognizing the ID value before the pattern. I thought this was a trivial one, and when I looked at the code and compared #REGEX with #TRIGGER, it looked like it *should* work.
Turns out there was a huge bug in the parser when counting parameters to commands in some cases. Especially when there was an odd number of parameters.
This is partly a result of how Yacc works (the parser generator that CMUD uses to build the parser). I've mentioned this in a blog entry before, but Yacc always looks ahead one state. And in the CMUD parser, some states are psuedo-states that just execute some code. So there were cases where Yacc would look ahead, causing some code to get executed, but then Yacc could back up again if the correct token wasn't found.
In this particular case, the code being executed was doing a Push of the current stackframe. So Yacc would look ahead, causing a Push, and then back up and never do the Pop. So the stack could get screwed up.
This isn't the same stack as the runtime stack, but it *is* used to keep track of things like the number of arguments given to a command. Imagine the example:
Code:
#ALIAS test {#IF (true) {#SHOW 1 2 3}} "class"
The parser first starts parsing the #alias command. While parsing #alias, it runs into #if. It needs to push the stack, parse the #IF, then pop the stack to return to the #alias arguments. While parsing #IF it encounters #SHOW and has to do this again. This stack allows it to determine that the #SHOW command has 3 arguments, the #IF command has 2, and the #ALIAS command has 3.
If this stack gets messed up by Yacc's lookahead, then the parser can get the wrong number of arguments. In the case of #REGEX, when you did:
Code:
#REGEX "id" {pattern} {commands}
in v.1.3, if you looked at the compiled code, you would see a (2) after the call to #REGEX indicating that only 2 arguments were getting passed to it. It should have been (3).
Fixing this was pretty complicated. I had to make some pretty major changes to the parser to make sure that the Yacc lookahead couldn't execute any kind of code that was undoable like the Push without a Pop.
It took several hours for me to get the parser working again. And while my test scripts all seem to work, it's very possible that I've added some new bugs to the parser.
So, when 1.14 is released, I'll need all of you guys who are good at uncovering wierd parser errors (Rorso, Tech, edb, etc) to pound on the new version and see what new stuff is broken.
I really hate doing this kind of stuff to the parser. It's all very flimsy and there are so many side effects in the parser. These particular changes *did* make part of the parser simpler and easier to follow, so that's probably a good thing. But there are still many obscure syntaxes that my test scripts don't test.
Anyway, this will be a long week. My bug list is growing faster that I can deal with it right now. But except for implementing Events in the next week or two, all I am going to do between now and the public release is fix bugs. I know that the help files are also important, but at this point, given how buggy CMUD is, I think I need to focus on bug fixes and not get distracted by other stuff.
Joined: 18 Oct 2000 Posts: 2733 Location: Atlanta, USA
Posted: Thu Nov 09, 2006 2:30 am
Zugg, sounds like you've had a really rough week. But it's kinda to be expected. Remember 13 is an unlucky number. I have a gut feeling that 1.14 will be alot better (and rest assured we'll all bang against it.)
I'm looking forward to more discussion on how Event's will work I have to go search to see if there are any that I've forgotten.
You'll get the bugs knocked out soon enough. As an aside, I was hoping we could get an update on Chiara's CMUD experience and introduction to mudding.
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
Posted: Fri Nov 10, 2006 2:40 am
Another long day again today. This is really becoming a big struggle. I'm really not happy with all of the bugs I'm still dealing with (and I'm sure you're not happy about it either).
Today I found yet another problem that was being caused by the background database update thread. Have I mentioned recently how much I *hate* threads? This one was really obscure. But I found a case that was reproduceable. What I was doing was importing a *.MUD file provided by a user. It would import just fine. It had a main window, and 2 child chat windows. Upon exiting and reloading, the main window was no longer displayed. When I checked the settings editor, I found that the main window was now marked as a Module instead of a Window.
So I go back and add some breakpoints to the code and try it again. This time it works just fine. I take out the breakpoints and the problem happens again. Setting debugger breakpoints is NOT supposed to do this!!! Of course, setting breakpoints changes the speed of the program. And this was enough to cause the problem not to occur. So I added some code to try and trap where the Module/Window option was being reset. I had a heck of a time doing this without altering the speed and making the problem go away.
I *finally* got a setup working where I could capture some debug information and still get the problem to occur. Each setting in CMUD has an Options field, which is a bunch of boolean flag values. Each setting type has different flags. In this case, the Module/Window flag is bit number 9. Bit number 9 is also used by Triggers to indicate an alarm. Somehow, setting the alarm option bit for a trigger was instead setting the Module/Window option for the main window!
This is bad. This was happening in my low-level SetFieldValue routine. This routine takes a record number, a field number, and a value. It was being called with the record number of the trigger, but somehow changing record zero instead (which is the record of the main window).
Turns out that I was not Locking and Unlocking the database within this routine. So if the background database update thread was running at exactly the right (or wrong) moment, then in the middle of the SetFieldValue routine the database buffers could get changed, causing data corruption.
That was 5 hours right there. But this was a nasty bug that could have been causing all sorts of really wierd problems. I was just lucky to run across a case I could reproduce most of the time.
The next bug to fix was the one reported in the forums about settings getting deleted when you clicked on various things in the tree view. First I thought I had already solved this on Tuesday. And it's certainly possible that I did something that helped. I could not get it to fail just simply clicking on items in the tree. However, one time I accidentally double-clicked, which toggles the enabled flag for the setting. Then all hell broke loose and settings started getting renamed and deleted just like in the post.
This took about an hour to track down. Basically, my double-click event routine was calling my ToggleEnabled routine, which toggles the bit in the database record indicating if the setting is enabled or not. But I learned that the DevExpress tree view is doing some annoying stuff with Windows messages. Instead of doing some stuff right away, they post some messages to the Windows event queue. So when my double-click event is called, the Treeview isn't actually updated yet with the correct focused record. So it would change the database record of the wrong setting and then change the database record out from under the treeview. So when the treeview messages got processed from the queue after this, the tree wasn't in the same state as before, and that caused all sorts of data corruption.
So I had to create my own event message so that the double-click event routine would just post my ToggleEnabled message to the Windows queue, which would then execute after all of the other queued messages finished.
The good news was that, as announced in the forum, I also found the bug causing the preferences to not save. This is the issue with fonts and colors getting reset that has been reported for many versions now. I was very happy to finally fix that one.
Anyway, that was today's mess. You'd think that by now I'd have bugs like the database update thread issue fixed. These are not the kind of huge bugs that I should be dealing with at this late phase in the beta. I'm really starting to worry about the public release. Because of vacation issues at Christmas and some financial issues, the public release deadline is really pretty solid. I have a couple of days of flexibility, but that's about it. My preference has always been to just release something when it's ready. But I don't have that luxury this time around. So all of these bugs are really stressing me out.
Oh well, just taking it one-day-at-a-time right now. Getting all stressed about it certainly isn't going to help anyone.
Well, on the one hand you are seeing huge bugs that you didn't expect. On the other hand you are fixing these bugs and as a whole cMud is much stabler already than it was a few versions back. You could get to the point, and may already be there, where fixing one bug has a domino effect and fixes a lot of the bugs you did know about.
I'm starting to venture out of the strictly safe zones in the muds I play with cmud. I just wouldn't do that a few versions back.
Yes I know it isn't safe to do that. I also am not picking any fights while stepping out of hiding.
_________________ Arminas, The Invisible horseman
Windows 7 Pro 32 bit
AMD 64 X2 2.51 Dual Core, 2 GB of Ram
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
Posted: Sat Nov 11, 2006 4:31 am
I'm going to take my two-day weekend on Saturday and Sunday this week just like a normal person
So I went ahead and released v1.14 tonight. It has all of the major bug fixes that I've been talking about in this blog, plus a few I didn't talk about yet. There are still lots of bugs to be fixed, so don't get too upset if your favorite bug isn't fixed yet. But this made a pretty good dent in the really major problems I think.
As mentioned in the version history, I think I figured out how to allow you to open multiple copies of the same session. So give the multisession stuff another try and see if it works better now. It should dock the sessions a bit better, and it will turn off the auto-save for the layout so that your single-character layouts don't get overwritten with the multi-session stuff. You should still be able to use the Save Session As to create a new session with the full layout saved.
I tested a lot more *.MUD files this time around and played with the compatibility report a bit more and fixed several problems with that. So hopefully this version will work a lot better importing your zMUD files. In fact, I'd probably recommend re-importing your *.MUD files since the previous versions has the database corruption possibilities that I mentioned earlier in this blog.
I hope it's finally saving all preferences and session options properly now. That was a major focus of my bug fixing today.
I also took some time to add the Auto Append option for aliases so that they append unused arguments like they did in zMUD. The default is normally off, but this option is automatically enabled for each alias that is imported from a *.MUD file.
Anyway, I feel a bit better today about this release. I certainly think it's a big improvement over 1.13, so at least that's positive progress. But I think I'm going to log off now and try to relax a bit tonight. Even though I'm not doing any programming tomorrow, I'll still log into the forums and see how the 1.14 release is going.
I'm really starting to worry about the public release. Because of vacation issues at Christmas and some financial issues, the public release deadline is really pretty solid. I have a couple of days of flexibility, but that's about it. My preference has always been to just release something when it's ready. But I don't have that luxury this time around. So all of these bugs are really stressing me out.
Oh well, just taking it one-day-at-a-time right now. Getting all stressed about it certainly isn't going to help anyone.
I just had an idea that may be something to consider if you find yourself needing to compromise between (a) financial issues, and (b) releasing something when it's ready. The idea is to release a "Release Candidate" (or "Gamma"). This wouldn't come with the same beta warnings (although probably a little disclaimer when you installed), but would give you some defence against claims of buggy software. Since the 30 day trial will have run out of for a lot of people, I expect a lot of people will still buy at this point.
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
Posted: Sat Nov 11, 2006 5:49 pm
The main driving factor is when the existing zMUD discounts end. I've said that they end when the public version is released, and I need this to happen before the Christmas break.
I thought you said they were only valid during the beta period... but I suppose you've probably said both at various times, which makes it difficult to slot in a further release stage. Anyway, just an idea.
You cannot post new entries in this Blog You cannot reply to entries in this Blog You cannot edit your posts in this Blog You cannot delete your posts in this Blog
I have a gut feeling that 1.14 will be alot better (and rest assured we'll all bang against it.)
