|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Sat Aug 12, 2006 10:20 pm
CMUD 1.04 Development Blog |
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. |
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
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. |
|
|
|
edb6377 Magician
Joined: 29 Nov 2005 Posts: 482
|
Posted: Sun Aug 13, 2006 12:49 am |
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. |
|
_________________ Confucious say "Bugs in Programs need Hammer" |
|
|
|
Tech GURU
Joined: 18 Oct 2000 Posts: 2733 Location: Atlanta, USA
|
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 |
|
_________________ Asati di tempari! |
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
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 :)
|
|
|
|
Kjata GURU
Joined: 10 Oct 2000 Posts: 4379 Location: USA
|
Posted: Sun Aug 13, 2006 2:31 pm |
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.
|
|
_________________ Kjata |
|
|
|
Rainchild Wizard
Joined: 10 Oct 2000 Posts: 1551 Location: Australia
|
Posted: Sun Aug 13, 2006 10:36 pm |
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 :) |
|
|
|
Vijilante SubAdmin
Joined: 18 Nov 2001 Posts: 5182
|
Posted: Mon Aug 14, 2006 10:29 am |
Hrm, upstate. Guess that means I should sponsor a pint since that is around my little corner of the world.
|
|
_________________ The only good questions are the ones we have never answered before.
Search the Forums |
|
|
|
Chiara Site Admin
Joined: 29 Sep 2000 Posts: 389 Location: USA
|
Posted: Mon Aug 14, 2006 12:38 pm |
Actually Vijilante, check your email. You should have one from Zugg about that whole pint thing.
|
|
|
|
Guinn Wizard
Joined: 03 Mar 2001 Posts: 1127 Location: London
|
Posted: Mon Aug 14, 2006 12:58 pm |
Two breaks in a year, including a proper holiday. Now drinking and socialising too. What is the world coming to...
|
|
_________________ CMUD Pro, Windows Vista x64
Core2 Q6600, 4GB RAM, GeForce 8800GT
Because you need it for text... ;) |
|
|
|
Seb Wizard
Joined: 14 Aug 2004 Posts: 1269
|
Posted: Mon Aug 14, 2006 6:46 pm |
Zugg wrote: |
Based upon recommendations I bought Corsair memory with a nice aluminum heatsink attached to each stick.
...
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. |
I bought some Corsair Value Select RAM for my Laptop and had memory issues - it showed up though intermittedly on the RAM tester available from Microsoft (their crash diagnosis thing gave me a link to it). I was trying to save some money with the Value Select line, even though Corsair recommends their System Select line for laptops. Corsair have a lifetime guarantee, so I thought it would be worth trying. It wasn't worth the hassle, but I did send it back and got a refund. I since bought their recommended System Select module and it works fine even with the existing Hyundai DIMM that came with my laptop.
So my conclusions:
1. Don't bother with cheap RAM, especially on important machines.
2. Test your RAM thoroughly (several hours) if you suspect a problem with it, e.g. if you get random crashes or blue screens, or just if are a little paranoid after installing new RAM.
3. Unmatched RAM may be fine, but it depends on your system and the RAM.
Zugg, it may be worth doing some RAM tests on your suspect RAM. You've also got Memtest86+ at www.memtest.org, which is based on Memtest86. If you find anything, you have evidence of a fault and it might make getting a refund a lot easier.
Glad you've got your development machine working well though. |
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
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:
Code: |
#MODULE A
#CLASS SubfolderA
#MODULE B
#CLASS SubfolderB
#VAR test 1 // creates @test within //B/SubfolderB
#MODULE A // switches back to module A
#VAR test 1 //creates @test within //A/SubfolderA |
Notice that when #MODULE was used to switch back to module A, it remembered that the current class for module A was SubfolderA.
This uncovered several bugs in how the default class and module were being set incorrectly for various things. Buttons were getting created in the wrong windows, and when clicked, they were executing in the wrong module. All of that is fixed now, and I've got a good multi-window test package that I can use to debug further problems with this kind of multi-window setup.
So, lots of good progress today. Not exactly what I expected to work on, but it was all good stuff being fixed. |
|
|
|
edb6377 Magician
Joined: 29 Nov 2005 Posts: 482
|
Posted: Tue Aug 15, 2006 3:17 am |
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. |
|
_________________ Confucious say "Bugs in Programs need Hammer" |
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
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:
Code: |
HostTable.Append
HostTable.FieldbyName['host'].Value := sHost;
HostTable.FieldbyName['port'].Value := iPort;
HostTable.Post;
CharsTable.FieldbyName['hostid'].Value := HostTable.FieldbyName['id'].Value; |
I have done this kind of stuff all the time and never had trouble with it (in zApp, and in much of the new database code within CMUD itself). However, suddenly today this didn't work. The "hostid" field was always getting set to zero!
It took over an hour to realize that HostTable and CharsTable were both TzTable objects instead of TzQuery objects. When I changed them to TzQuery objects (with SQL statements like "select * from hosts") then it started working!
So, TzTable objects are *bad*. And I don't use them anymore. But this old zMUD code converted from ADO that I had ported into CMUD for the session selection window still was using them.
Anyway, it's working now. The next step is to add the interface to the Settings Editor for the Window Object that allows you to change the network connection for the window. Then I need to test it all a bit more and fix the problems with %char, and make sure it is connecting the the correct host/port for each window.
After I have finished with this session stuff, then I'll only have about a day of misc high-priority fixes from the list over in the beta forum. So, a release on Friday is still looking pretty good at this point.
Oh yeah, while I was messing around with the session selection window I added some code from zApp that I developed for loading images. So the images you can load for your session icons now support PNG files. And I'm using PNG images for some of the default session images. They look a lot nicer and handle different background colors much nicer (they support alpha blending). I'll have to notify the MUDs that have paid icons in CMUD and see if they want to send higher quality PNG images for the future.
Over time I'll be putting a lot more PNG support into CMUD. Again, I did most of the work with zApp for this. Eventually all of the button and toolbar images will use PNG files. Right now the only other place in CMUD that is already using PNG images is in the new Preferences screen. The icons for the tabs on the left side of the Preferences are all PNG images, which is why they look nicer on different theme backgrounds than the other toolbars. A pretty minor thing, but it helps CMUD look it's best. Back when I worked on zMUD 7.x I bought a bunch of icons from www.glyfx.com and they have added PNG versions of all their icons over the past couple of years. So the only real work is making PNG versions of some of my CMUD-specific icons, like trigger, alias, etc. That's something I'll be doing in my "spare time" (yeah right) between now and the public release later this fall. |
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
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. |
|
|
|
shalimar GURU
Joined: 04 Aug 2002 Posts: 4689 Location: Pensacola, FL, USA
|
Posted: Fri Aug 18, 2006 1:22 am |
Tomorrow? That soon? Really?
::cheers and does a happy dance::
I can hardly wait. |
|
_________________ Discord: Shalimarwildcat |
|
|
|
Juran Newbie
Joined: 11 Aug 2006 Posts: 7
|
Posted: Fri Aug 18, 2006 7:23 pm |
I've been really happy to see the steady progress; if you keep coding it, I'll keep test it.
|
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
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! |
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
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. |
|
|
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|