Zugg Software :: View topic

Posted: Tue Oct 17, 2006 12:33 am

I was supposed to work more on help files today, but I got distracted again by some bugs. I wanted to figure out why the new multiline syntax had screwed up so much stuff.

I finally found the problems with it. What the parser was doing was trapping the \n newline (LF) and checking to see if there was indentation after it. If there was enough indentation after it, then it was converting this from a NEWLINE token to a normal WHITESPACE token for the yacc parser.

When using nested commands, the current indentation value needs to be saved, and then restored after the command is finished. However, Yacc is always looking ahead by one token. So, when it was working on a syntax line like this:

ComLine :== COM_ID {PushCom;} Arguments {PopCom;} NEWLINE

then when the lexical analyzer (lex part) was checking the newline to see if it should return NEWLINE or WHITESPACE, the PopCom hadn't actually been executed yet. The PushCom and PopCom deal with pushing and popping the current state to a stack. Each state has it's own current indentation value.

So it was comparing the indentation with the inner command instead of with the outer command.

Sounds a bit complicated, and the above code is only pseudo code...the real code is more complicated than this. But that's the basic idea.

Anyway, I was able to fix this by checking the stack within the lex routines, and also fixed some problems were the current indent value was getting changed when it shouldn't. And now I've tested more examples of different multiline syntax and they all seem to work properly.

Sorry I messed this up so bad in 1.10. It really screwed up a lot of previously-valid scripts, which makes 1.10 a bit hard to test. Look for 1.11 later this week.

I also found one of the performance problems causing the settings editor and fly-out settings to take soooo long when you had a large amount of scripts. The DevExpress code for the TreeView component was updating itself all the time. By disabling the datasets used in these windows until the windows were open, the treeview was having to load all of the records and then sort them within the tree.

This is fine...the tree view needs to grab the data at some point. And grabbing the data to display isn't normally this slow. The problem was that in the process of displaying the settings window, the tree view was trying to update itself multiple times whenever something changed. It was actually reloading the data about 10 times more than it needed to.

I places some DataController.BeginUpdate and DataController.EndUpdate statements around some code to tell the tree not to update all the time, and that seems to have solved this particular performance issue.

Unfortunately, I just noticed that it's not updating the ID Name to match the Name field in some cases. The ID Name is the shorter name that can be indexed that is shown in the tree view. The Name field can be much longer (like for trigger patterns). If the Name and IDName fields match, then CMUD tries to keep them in synch. But this seems to be broken now, and I'm not sure if it's because of one of my performance tweaks, or if there is another problem.

Yet more stuff that needs fixing.

Tonight I'm going to work on some of the help file topics, and get some new screenshots for CMUD.

Posted: Tue Oct 17, 2006 2:47 am

Sounds like it was a trying day Zugg... but we all appreciate the efforts. Thanks for all the hard work.

Posted: Sat Oct 21, 2006 2:38 am

I got v1.11 out today (Friday). I spent the past few days improving the help files. I still have a lot of work to do, but it's getting better. I worked through most of the Getting Started section and put together a few screenshots.

Today I worked on more bug fixes. Based upon some posts in the beta forum I found another annoying parser bug and fixed it. Then I spent most of the day dealing with issues in the Package Editor where package tabs were not working correctly and the drag/drop had gotten broken at some point. Also dealt with the issue of the ID and Name fields not keeping synchronized when they should and overwriting each other when they shouldn't. That turned out to be an obscure side effect of some optimizations I had done. That database Tree View control from DevExpress is really finicky and has some wierd side effects sometimes.

Hopefully I've fixed more problems then I've caused.

I still want to announce CMUD to all zMUD users on Halloween, so next week I need to implement the Event stuff that replaces the old "atconnect" aliases, and also continue to work more on the help files. If you think there are any other huge issues that need fixing before the announcement, let me know.

Apprentice Joined: 12 Jun 2006 Posts: 106

Manual triggers! Ok, so the vast majority of people don't use them, but still ;)