Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Due to spam on this forum, all posts now need moderator approval.
Entire forum
➜ MUSHclient
➜ General
➜ Changing Font causes Crash
Changing Font causes Crash
|
It is now over 60 days since the last post. This thread is closed.
Refresh page
Posted by
| KL
(5 posts) Bio
|
Date
| Mon 15 Mar 2004 07:10 AM (UTC) |
Message
| I can't find this posted elsewhere, so I'm gonna toss it out.
I'm running 3.42, and I attempted to change my font size to less than the client would allow (specifically Lucida Console, where the lowest size was 8pt). I entered 6 for font size, clicked ok, and poof.
KL | Top |
|
Posted by
| Nick Gammon
Australia (23,133 posts) Bio
Forum Administrator |
Date
| Reply #1 on Mon 15 Mar 2004 07:41 AM (UTC) |
Message
| Hmm - can't reproduce that. The "choose font" dialog box is a Windows one, and the sizes there are really the suggested ones for the font, but changing to Lucida Console 6 pt for me does not cause a crash. I can even use 2 pt font - kind of hard to read, but no crash.
Can you try it with the latest version at present - 3.45? |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| KL
(5 posts) Bio
|
Date
| Reply #2 on Mon 15 Mar 2004 08:01 AM (UTC) |
Message
| Actually no, I haven't been able to reproduce it. A longtime poster here suggested it may be a result of my buffer being full (it's set at 15000 lines). *shrug* Odd! :)
(btw, sorry for posting to the wrong forum)
KL | Top |
|
Posted by
| Shadowfyr
USA (1,790 posts) Bio
|
Date
| Reply #3 on Mon 15 Mar 2004 09:02 PM (UTC) |
Message
| I noticed this myself at one point. It only happened when there was significant amounts of text in the back buffer. Since I haven't changed my font in some time, I forgot all about it. | Top |
|
Posted by
| Dave
Australia (93 posts) Bio
|
Date
| Reply #4 on Tue 16 Mar 2004 04:33 AM (UTC) |
Message
| I reproduced it just then. My scrollback buffer was 50,000 lines and I had 29,500 lines of output. I changed the scrollback buffer to 30,000 lines, spammed myself a bit, then changed my font to Lucida Console 6 pt. Clicked OK on the Font Dialog, OK on the settings dialog, then pressed enter. Crash.
However, I changed my scrollback limit to 500 lines, and did the same, with no crash. So maybe it's just some upper limit, and not related to the lines reaching the scrollback limit. I'd say it IS reproducible, but I'm not willing to spam myself 30,000 lines to be 100% sure. :P | Top |
|
Posted by
| Nick Gammon
Australia (23,133 posts) Bio
Forum Administrator |
Date
| Reply #5 on Wed 17 Mar 2004 02:27 AM (UTC) |
Message
| OK, thanks you two. Thanks to Dave's detailed instructions I reproduced it. Basically it miscomputed the line number for the bottom of the screen, based on the scroll bar location, and the font size, as something much larger than was actually in the scrollback buffer, and then crashed trying to find it.
I have put in a couple of boundary checks to stop this happening again. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Ashlan
Australia (8 posts) Bio
|
Date
| Reply #6 on Thu 18 Mar 2004 12:19 AM (UTC) |
Message
| Heyhey, so this fix will be in 3.46? I have had this problem consistently, and never thought to mention it. Usually changing from say courier 8p > lucida 8p, but i'm sure the fonts involved are inconsequential. With a reasonably big output buffer - 10,000+ lines... without doubt, I can wave goodbye to MC.
On that note, a little msn/adobe whatever style <A more recent version of this product has been detected, click to upgrade> pre-check & pop-up on registered versions of the client. Maybe i'm doing the wrong thing, but when nick releases a new version, i go and download the whole client again, and it installs over the top of the old one... is it a mammoth piece of work to have the upgrades simply install the changes in the background?
Cheers. |
@AshNathens | Top |
|
Posted by
| Shadowfyr
USA (1,790 posts) Bio
|
Date
| Reply #7 on Thu 18 Mar 2004 01:12 AM (UTC) |
Message
| Yes it would be. Why? Because mushclient is a 'single' application with the only DLL it uses that I am aware of being the spell checker. I am not even sure that is a DLL, since I haven't looked.
Even ones that use different DLLs to impliment features, cannot simply install and continue running, they have to shutdown. There are two reasons for this.
1) Not all dlls may be loaded in memory at once and the 'new' ones when loaded may not be compatible with the 'old' version. In fact there is 100% certainty they won't be, since they are statistically linked. In other words, the old program will expect Output.dll to have the Note command at the 2350th byte into the file, but the new one compiled with it at say the 2356th byte. Oops. The moment the program loaded the dll and attempted to execute the call *CRASH*.
2. The currently loaded version won't be able to use all the features of the new version until loaded, even if you assume that the first problem is somehow solved. Some dumb user could leave the program running 24-7 and wonder why it doesn't suddenly provide the new features.
About the only things that do keep running are virus scanners. They manage it because they just reload the database, but when ever one needs to install an updated engine, then it also requires a restart (or even a reboot).
*Huge* systems like Windows itself get by with this because most of the time the stuff you are patching is 1-2 dlls that are not even loaded. Major changes to IE and other "integrated" things always require a system reboot of some sort, other things get patched and then run without any problem, since the programs just load the new ActiveX component. This is also however one reason Windows is so much slower than other OS, since ActiveX takes extra time to load, send and recieve data. This is due to the fact that it is dynamically linked, making it easy to drop a new version into place without recompiling everything on the machine, but every request has to go through the OS. Statistically linked dlls are loaded and called directly.
So, 1) mushclient would run like zMud if it got chopped up into easilly updated bits and 2) it is way too small for this to be a major benefit for updating. More likely if such an option was added, it would follow the same sort of thing as GetRight or other small programs, that tell you on the first screen of the installer, "Make sure all copies of MUSHclient are closed before starting the install." It won't happen in the background.
----
Now ironically with plugins... A person could make a plugin that used and FTP client to check for a more recent version and automatically download the new copy and install itself. This would require that all 'current' data in the plugin be stored in a state file before the reload. It also means that you need an FTP client or small application that can check on the file version periodically, without hanging the client. You can code FTP into the client in scripts using Windows ComCtl, but that lags the script during the 2-3 seconds it takes to send a request, have the server respond and data to transfer. Just loading the HTML from a web page to check the status off the mud I play on at a voting site caused 2-3 seconds of lag each time.
So, auto-update Mushclient in the background - NO
Auto-update a plugin - YES (in theory) | Top |
|
Posted by
| David Haley
USA (3,881 posts) Bio
|
Date
| Reply #8 on Thu 18 Mar 2004 01:18 AM (UTC) |
Message
| You don't necessarily have to patch "real-time". A small updater executable could be responsible for shutting down the main version, downloading, overwriting, and then restarting the main executable. That's how a lot of other programs take care of their patching, when they don't do "real-time" patching - which is certainly not an easy task. |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | Top |
|
Posted by
| Ashlan
Australia (8 posts) Bio
|
Date
| Reply #9 on Thu 18 Mar 2004 01:55 AM (UTC) |
Message
| Hee, i see. It's no big issue that programs close down to update - the bigger issue is it's a small energy saver that when you open a program it checks for updates, runs a script, closes itself, updates and re-opens. Or what ever. Saves you checking the download MC page for currently available version. Ash |
@AshNathens | Top |
|
Posted by
| Shadowfyr
USA (1,790 posts) Bio
|
Date
| Reply #10 on Thu 18 Mar 2004 02:21 AM (UTC) |
Message
| Well.. In some programs this is not a big issue. For Mushclient.. Having it auto-close and restart means saving the buffer, the connection, the .... you name it. This isn't really viable. You couldn't for instance save temporary variables used in the script that is currently running, unless you know some way to save the entire state of the script engine. Most engine probably don't even have such a capability. I doubt all of them do, even if some have it. Program that do this get by with it by having 'everything' that they do be savable and reloadable, which is impossible in Mushclient, so there can be no "I am shutting down for a second to update that client. Click OK or Cancel." type thing. More than a few people, even knowing it is a bad idea if they are online, are going to mistakenly hit OK. Some muds also don't allow link-dead, so if the client did this a few too many times, the admin of the mud are bound to get a bit unhappy.
However, the *#1* reason this is a bad idea is that 'we' end up being Nick's beta testers. Any new change gets tested by us and one recent one went so wrong that I had to fix 20-30 trigger that got messed up do to a bug in the 'new' version. I don't like the idea from MS to *fix* my OS, why would I like the idea of unintentional bugs mangling something through an auto-update of MUSHclient? | Top |
|
Posted by
| David Haley
USA (3,881 posts) Bio
|
Date
| Reply #11 on Thu 18 Mar 2004 04:42 AM (UTC) |
Message
| Shadowfyr, if it's just a startup-check, then there is no issue of saving buffers because you won't even have connected yet. If this check is performed before the client even connects a world, then the problem is solved. And if it annoys you that much, I'm sure it could just be turned off.
Your worry about those crashes would rest upon the assumption that Nick would actually do something like that. Knowing Nick, I'm pretty darn sure that he would keep the same excellent quality of code and not release buggy software... everything would be thoroughly tested just like it is now. The big difference is that he could make smaller changes and distribute them more often, as well as it's just that much more convenient for the user.
Besides, again if you don't like it, you could just turn off the auto-update feature. It wouldn't do it without asking you, anyways, I'm sure. |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | Top |
|
Posted by
| Nick Gammon
Australia (23,133 posts) Bio
Forum Administrator |
Date
| Reply #12 on Thu 18 Mar 2004 04:49 AM (UTC) |
Message
| I suggest if you want to know when new updates are ready, subscribe to the section of this forum where they are announced.
That is more efficient, rather than every user (all 10,000 of them? - hard to say because I don't know about unregistered copies) polling some site every day, the people who want to know are emailed when a new version is actually released. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
30,201 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
top