Zugg Software :: View topic

Posted: Sat Aug 12, 2006 10:20 pm

Creating a Development Blog for the first CMUD beta seemed to help, so I think I'll start a new one for the upcoming 1.04 beta version.

If you have seen the various posts in the CMUD Beta Forum about sessions, packages, modules, windows, etc, then you will already know that this 1.04 version has undergone some pretty serious changes. This went well beyond simple bug fixing. Part of the design needed to be re-thought.

Thanks to the feedback in those forum posts, things are working much better in 1.04 so far. The distinction between a "Module" and a "Window" and how these relate to Packages and Sessions has cleaned up sections of the code that were pretty messy.

I've gotten the basic Module and Window stuff all rewritten and working. I was going to start on the Session stuff today. But in finishing up the Module/Window code, I wanted to add something to the settings editor when you are looking at the properties of a Window to allow you to show/hide the window.

You see, when you click the X button to close a window in CMUD, the visible window object goes away, but the Window object still exists in the Settings. This makes sense when you think about it. Just because you close the Tells window doesn't necessarily mean you want to remove it permenantly from the Package. After all, if you had defined a bunch of triggers and stuff within the window, they would all be gone now.

The proper way to permanently remove a Module or Window from a Package is to go into the Settings editor, select the Window/Module and Delete it there.

This has a nice effect. If you type the #WINDOW Tell command, it creates the Tell Window object. Then if you click the X button, the window goes away, but if you type #WINDOW Tell again, then the window comes back and still has all of the triggers and stuff that it had before.

OK, so anyway, I wanted a way to hide/show the visible window from the settings editor. So you could select the Tell window in the settings editor, and uncheck the "Visible" property and that would be like clicking the X button to close the window. Then checking the "Visible" property would re-create the visible window.

In doing this, I ran across another bug in the Window Docking system. You might recall that based upon my suggestions, the author of the AQDock system added a way to tell a panel to destroy itself when the X button is clicked, rather than just hiding itself. Remember in CMUD 1.03 how clicking the X button didn't really remove the window...it was still available in the Windows menu. In 1.04, clicking the X button really does remove the visible window object.

Also, when you have set the HideAction to be "Destroy", simply setting the dock panel Visible := false property also destroys the panel. But in his code, the author was setting the physical FVisible field value *after* the panel was being destroyed. Setting a field property of an object that has been destroyed is a big no-no. It doesn't cause an immediate error, but it's overwriting memory that is no longer allocated.

Fortunately, the FastMM stuff caught this problem and after some tracing I was able to uncover the bug in the AQDock code and email it to the author. Once again, FastMM saves the day.

So, now I've got the windows all working the way I want them. Clicking the X button removes the visible window, but keeps the Window object in the Settings. I also added just a "Hide" option to the pull-down window in the docked window caption that just temporarily hides the window like it did in 1.03 for people who liked that.

On Monday I'll start making changes to the Session window and the Session toolbar button to reflect the discussion in the "More on Sessions" post over in the beta forum. This will probably take about two days to get working. That should take care of the rest of this multiple window/session stuff.

I'm actually looking forward to this because I wanted a better multi-tab telnet client myself for sysadmin work, and I never liked how zMUD handled this. So I've actually still been using the plain Windows telnet client to connect to the zuggsoft.com server for sysadmin work. I'll be really happy when I get the SSH and SFTP stuff added to CMUD too.

As you might have seen in the "Major things to fix in 1.04" thread, I have already fixed the database variable problems in the settings editor. I did that yesterday. Turned out to be some annoying issues in how the DevExpress Grid component dealt with multi-tab Page Controls where some tabs were hidden. On the Variable setting editor page, there is actually a multi-tab PageControl and the Data Type pulldown box changes these hidden pages. But this was causing some issues with the Grid control used for the String List and Database variable data types.

I also added support for @var.%1 and @var.$arg syntax into the parser. That part was pretty easy. Working on this new parser/compiler in CMUD is a *lot* easier than working on the old parser in zMUD.

Still hopeful for a release of 1.04 towards the end of next week. Our family visit to New York that was originally scheduled back in February had gotten moved to the end of August, so I only have next week before we leave for that. So I really want to get 1.04 out so people can play with it while I'm gone for a week.

Posted: Sat Aug 12, 2006 10:34 pm

Oh, something else interesting happened earlier this week. I finally got fed up with my computer getting so slow when Delphi started taking up lots of memory. In the middle of a long programming session Delphi can start taking up about 400MB of RAM. It's about 200MB base usage with all of the components that I load with it (along with CodeRush), but after some debug sessions, memory leaks from my own bugs start eating up Delphi's memory. I was having to exit Delphi and restart it to reset that memory. And every time I'd shutdown Delphi I'd get all sorts of crashing errors.

I had 1GB of RAM on the system, and between Delphi and things like Firefox (which also seems to eat up memory as it runs), I think Windows was running out of RAM and starting to swap stuff to disk, causing things to get really slow.

So, I went to NewEgg.com and bought a 2x1GB matched set of RAM. My computer only has 2 memory slots, and I currently had 2x512MB in them. So, in order to max out the memory to 2GB, I had to buy 2 1GB sticks. Based upon recommendations I bought Corsair memory with a nice aluminum heatsink attached to each stick. Sure makes the memory feel a lot less fragile with a strip of aluminum coating it.

Anyway, so I got this memory on Thursday and installed it. And yes, Delphi works a lot better now. It can eat up 400-500MB without running out of RAM and swapping.

But the really interesting part of this story is that suddenly Delphi has stopped crashing when I shut it down. It has gone several days now and I've started and stopped Delphi a lot without *any* crashes. This is incredible! I've never had Delphi work this well before.

Then, I tried taking the old 2x512 memory down to my game system. My gaming system has 3 memory slots and was currently running 2x256,512 for a total of 1GB. I wanted to replace those 2x256 with the 2x512 that I took out of my development machine. Well, that caused the gaming computer to start crashing. Not immediately. Usually only when I opened Firefox and started web surfing. It basically made the system really unreliable. I tried lowering the speed settings for the memory in the BIOS, but that didn't help at all.

My conclusion is that the 2x512 memory that was in my Development system was flaky and giving memory errors. These could have been causing my Delphi crashes, and could also be responsible for those wierd times when a file on my disk would get changed somehow. The 2x512 memory was Kingston ValueRam and I should really know better. It's not worth the potential hassle of buying cheap memory these days. I'm much happier with the Corsair memory, and the price was still pretty good.

So anyway, I'm much happier now that the Development computer is much more stable. The extra amount of RAM and the stability really helps reduce my stress. There was nothing like Delphi screwing up to get me really stressed and upset. So hopefully that won't happen as much now.

Magician Joined: 29 Nov 2005 Posts: 482

I am glad you got the ram problem sorted out. As an oncall technician i run into that problem often. I have found the same thing. The value brands of ram while being cheaper just arent worth it in the long run.

I myself in my development machines have Corsair Ram with Blue Heatsinks on them. My performance is well worth it and i recommend it to all of my customers. The other major problem i run into on other peoples machines is mismatched ram. Some motherboards hate that. They even added a setting into many motherboards now called memory compatibility mode for that situation.

Glad you worked it out and its making your CMUD development life a bit easier.

At least now you wont have to figure out REAL memory problems vs Flaky Memory anymore.

Posted: Sun Aug 13, 2006 1:10 am

Congrats on the RAM issues Zugg. If you feel like having a pint sponsored will you're in NYC give me a shout and let me know.

Tech

Posted: Sun Aug 13, 2006 2:11 am

Hey Tech...we'll actually be in upstate NY (up near Albany). Skipping the big city this time around. But I'll keep you in mind for the future :)

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

After having several problems with a few RAM chips myself, I never trust them anymore. Any time a weird error or crash pops up in Windows without any obvious explanation, my main suspect is always the RAM. I use Memtest86 whenever I want to blame the RAM for my problems and it has always worked great when trying to find out if a chip is faulty or not.

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

Yeah like Kjata said I www.memtest86.com all my RAM when I'm finding it suspect, although it's not always the memory's fault - sometimes it can be the motherboard.

I've never had issues with Kingston ValueRAM myself - got 5 gigs of it spread over my machines, but Corsair do have some pretty cool RAM chips, especially the ones with the LED readout on the top :)

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Hrm, upstate. Guess that means I should sponsor a pint since that is around my little corner of the world.

Site Admin Joined: 29 Sep 2000 Posts: 389 Location: USA

Actually Vijilante, check your email. You should have one from Zugg about that whole pint thing.

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

Two breaks in a year, including a proper holiday. Now drinking and socialising too. What is the world coming to...

Wizard Joined: 14 Aug 2004 Posts: 1269

Posted: Tue Aug 15, 2006 12:17 am

Seb, thanks for the link! I like the precompiled ISO images that they have. That's been the main hassle preventing me from using Memtest86...I don't have any floppy drive on this computer any more, and so making a "boot disk" is a real pain. I just haven't had any time to figure out what I need to do for that in Windows these days. If I can just burn the ISO image to a disk, that might work better for me.

Development today was a *bunch* of little things it seemed like. I never actually got to the main session stuff. I was still messing with Windows. There were several bugs in creating and destroying windows because of some old kludges that were still left from some of the zMUD code porting.

In zMUD, the visual window is the main object, and the preferences and settings are stored within the window. So in zMUD, when you create a new window, it creates the visual "form" object, loads the *.MUD setting file into the window, then docks the window to it's appropriate starting location.

In CMUD, things are reversed. When CMUD loads a Package file, any Window Object within the package get created. CMUD was using the last Window Object created as the object to assign to the visual "form". However, Packages can now contain multiple windows. So just using the last window object isn't correct. In fact, there is no way to determine what the "main window" is. A Package might have several "main windows", each connected to a different network socket.

So, the proper way to handle this in CMUD is to have the Module/Window Object in the settings manage the visual form. When a Window Object is created, the visual form for it is created. When a Window Object is deleted, the visual form is removed.

This makes a lot of sense conceptually, but it was full of problems. The main problem was that during the initial loading of the *.PKG database, you can't create any visual forms yet. When you create a visual form, it tries to determine if the command line should be shown, if the status bar should be shown, and creates any buttons for the window. But at the database load time, those things might not be loaded into memory yet. I have no control over where the button objects are in the package database relative to the window objects.

So, I had to create a "window queue" and when a window object is created, it gets added to this queue. Then, after the package database has been fully loaded, I call a routine that loops through the window queue and actually creates the visual form objects. Since the database has been fully loaded at this point, it can display buttons and do other stuff for displaying the window.

The other problem came when destroying the window. Again, it was a catch-22 situation. Destroying the visual form object does not remove the Module/Window object. I discussed this before. You don't want to delete a Window/Module from a package just because the form was closed by the user...they must delete the window object from the settings editor to force it to be removed from the package file. All of the visual form objects were being removed from memory by Delphi itself when the application closes. When I added code to the Window/Module object to remove the form when the Window Object was destroyed, then I started getting crashes at program exit from the automatic removal of the Delphi form objects that Delphi still thought existed.

Again, a bunch of messing code that just needed to be cleaned up so that things are created and destroyed in the proper places.

For each Window Object in the setting editor, I also now store the default initial position of the window (in terms of how it is docked). So, even though the end-user can drag windows around and dock them how they want, as a package designer you can determine the initial way in which your windows are docked. This is essentially how to tell CMUD whether a window is a main session window (tab-docked) vs a chat window (docked to the top, for example).

This also lays the groundwork for having the individual network host,port,user,password fields defined for each window object in the session, which is what I'll be working on tomorrow.

I also added the new #MODULE command today, which, like the #CLASS command, lets you set the current Module. Each Module remembers the "current class" being used. So when you use the #CLASS command, you are changing the current class of the current module. So, you can do stuff like this:

Magician Joined: 29 Nov 2005 Posts: 482

On that memtext86 page zugg about 3/4 of a page down

http://www.memtest86.com/memtest86-3.2.iso.zip

Sounds like you are making good progress towards the packages being better defined. Thats definatly important.

Posted: Wed Aug 16, 2006 2:32 am

Got a good start on the changes for the session icons today. I have added a new database table within the sessions.db file called Hosts. It contains the hostname, port, username, and password fields (and a title for the record). The records in the normal chardb table now have a id pointer into the hosts table, rather than storing this information within the session record itself.

By separating the host information from the session information it should now be possible to assign different network sockets to different windows without requiring a session icon for each connection. The Hosts table will cache all host information used in socket connections.

I have added a menu option to the session list that allows you to clear this cache (it removes any entry that doesn't have a corresponding session entry and is not used by a window within a session).

This has also allowed me to improve the user interface for selecting the host/port/user/etc. There are now dropdown menus on these fields. So, when you create a new session, you can select the hostname from a dropdown list of existing names in the Hosts table. When you select a host, the port field is automatically filled in and has a dropdown list of all port values that have been used on that host.

When editing a session icon, the Title field also has a dropdown list of known session titles, and when you select an existing title, it automatically fills in the host, port, character name, and password fields.

These dropdown lists are editable fields, so you can still enter any value that you want. It also has typeahead completion so as you type the name of a host, it can fill in the rest for you. Pressing Enter or Tab accepts the value and then fills in the port automatically. So, selecting a known socket connection is now really easy. Just a couple of keystrokes.

While I was working on this, I uncovered a really *nasty* database bug. This is a bug that I believe is in zMUD too, but it's probably obscure enough not to effect much.

In Delphi, there is a component called TTable for accessing a table of a database. This is an old concept from before it supported SQL queries. The Zeos Database library that I using has a compatible component called TzTable, along with the normal TzQuery for more general SQL queries.

When zMUD started using an MDAC/ADO database for the character database (the chardb.mdb file), I used a TTable component (since ADO databases just had tables and not general query objects at that time). When this was converted to use the Zeos Database system and SQLITE, I replaced the ADO TTable component with the Zeos TzTable component.

Well, there is apparently a nasty bug in TzTable components. After a new record is added to the database with Append, then saved using Post, the field values of the record just added are not available! In particular, if the primary key field is being auto-incremented, when you try and fetch this value after posting the record, you always get a zero rather than the actual ID value of the added record.

This caused a big problem when I split the chardb database into two tables. It uses code like this:

Posted: Fri Aug 18, 2006 12:11 am

Yesterday was mostly a loss. Something was messing with my allergies, or I was fighting some bug. But I felt awful and didn't get much done. Maybe the extra sugar I had on my birthday lowered my immune system or something.

Today I'm feeling a bit better and got more done. But once again I didn't get to finish the window-specific network connection stuff. Since that's new functionality, I might just end up leaving that out of this particular beta version. When I started doing more testing, I discovered a big area that I had forgotten about. When I made the changes to the settings editor for the Module/Window stuff, I forgot about the fly-out settings editor. The fly-out settings editor and the main settings editor use two different cursor sets and filters of the same physical data. But they are two separate forms in Delphi and there was code that needed to be updated to handle the module/window stuff. In particular, the filter to only show the current module wasn't working, and it wasn't creating settings in the correct module. Finally got all of that fixed.

Then I worked on some of the other critical bugs. I fixed a really wierd bug where using a period somewhere in the middle of your command line would cause all spaces to get stripped on the line. This was an obscure parser bug. While I was working on the parser, I also fixed the parenthesis in paths (like .e(open door)w syntax) and fixed the issue with the %char vs %char() system variable and function.

Or course, along the way I had to break stuff. So it took a while to get everything working again. Some days it seems like I add as many bugs as I fix.

I also fixed the problem with CMUD not creating the initial package file and character subdirectory.

I'll be fixing some other misc bugs tonight. Then tomorrow I'll try to finish up a couple of loose ends and see if I can get something released. I need to keep reminding myself that this is still a Beta version and I can't possibly fix all of the bugs yet. But with all of the window/module/session stuff I have made enough significant changes that I need to get a new version released to see what new problems it has.

Posted: Fri Aug 18, 2006 1:22 am

Tomorrow? That soon? Really?

::cheers and does a happy dance::

I can hardly wait.

Newbie Joined: 11 Aug 2006 Posts: 7

I've been really happy to see the steady progress; if you keep coding it, I'll keep test it. Very Happy

Posted: Sat Aug 19, 2006 4:24 am

Well, there is still plenty of stuff to fuss over in CMUD, but I decided to go ahead with the release so that everyone will have something to play with while we are away visiting our family in NY.

I didn't get the window-specific network connection stuff added. The underlying framework is all set up, but there was at least another day of implementing it and testing it. And it really matters more for the zTelnet client than for CMUD. You can still open multiple session windows as with zMUD, so multiplaying should still work.

Also, because of this, I do not yet auto-save the layout or toolbars with the session. There are still some issues with restoring docking layouts automatically. You can save it manually yourself using the menu option, and you can enter the filename into the Files tab for your session (and check the Use Layout option) and it will try to load the layout when the session loads.

There still seem to be some issues with window-specific settings. I notice that if I save a session with a Tell window, when it is restore the Tell window has a command line and status bar, so those options are not sticking. I testing some other settings, like colors, and they seemed to stick. So there is still some unknown issue with saving preferences with windows.

But with all of that, I still think 1.04 fixes a lot of issues and is pretty useable. I played a MUD for a while yesterday and didn't have any crashes. There are some visual issues with various Mapper dialogs since the mapper doesn't yet use the themed controls, but those are pretty minor. I'm really liking the fact that CMUD now uses the proper Windows font and with ClearType enabled in XP, I think it looks very nice.

I'll be watching the forums on and off tomorrow, but then we leave. I will have Internet access towards the end of next week and will try to check the forums again then. Hope everyone enjoys the new version. It's been a lot of work, but it's getting more fun to work on every day.

Thanks to everyone for your support. If you think CMUD is starting to work well enough, start telling your friends about it. As we get further into the beta testing, we need more and more testers to find the obscure bugs. The more bugs I can fix, the better the public version will be!

When I get back from our trip, I'll be working on the SSH and SFTP stuff next. I'll release the SSH add-on for CMUD, and the first beta of our new Telnet/SSH client. This will share the majority of code with CMUD, and I want to release it early enough to get some good beta testing for it so that I can release the public versions of CMUD and zTelnet simultaneously. The SSH stuff should only take a couple of weeks. After that release, then it's time to put in the scriptable zApp forms!

Still plenty of work to keep me busy!

Posted: Mon Aug 21, 2006 4:21 am

Well, I'm going to close out this blog thread since 1.04 *and* 1.05 were released. These versions didn't go as well as I hoped, but oh well. As I said, I wanted to get it into the hands of testers while I'm gone. It was either a) not release anything and lose a week, or b) release what I had and at least get feedback for a week. I still think (b) was the right choice. Still lots of stuff to fix before this is anywhere near a public release.

My guess is that I'll actually do a 1.06 after I get back, and *before* I add the SSH stuff, just to try and get things working a bit better so people can really start using CMUD.

Anyway, we have to get up at 3am to get to the airport, so I'm going to bed now. Talk to you again in a week.