Something went wrong with my internet connection yesterday around 6pm Eastern and things have been really slow. I've gotten in touch with RCN about this but in the meantime I apologize if the page takes a while to load... :sigh:

Well, I think something's actually seriously broken... pages like here or MB that used to load in less than a second are taking ~30 seconds. When I ssh into my server, characters get echoed back at about 1 per second. So something is probably going pretty wrong. :sigh:

Hmm, power-cycling the modem did the trick. But now port 80 isn't working, even though port 8088 is. I wonder if the ISP is blocking port 80, since I'm almost positive that I opened it up on the firewall...

Ah, what joy it is to be using a normal ISP again, after being on an open internet backbone for five years.

Certainly sounds like it. Comcast would just tell you it's a problem with the signal, and tell you they'll send you a new one. and end the conversation.

<mutters angrily> = Comcast
Grrr! Worst part is that, for my latest Comcast issues, I've concluded that, despite Comcast's "efforts", my problems currently actually have more to do with spammers than Comcast directly.
I'd actually be very happy with Comcast if they'd block known major spammer IP ranges before they ever get to me so I don't have to add them to my firewall... that and teach their regular customers to run antivirus software once in awhile... </rant>

Conner, it's futile to try and employ spam control measures at that level. You inevitably get someone using the service who complains bitterly no matter what measures you put in place for the good of all and insists that they either be exempted from it entirely ( which opens the system up for attack ) or that you disable it entirely because their email isn't being delivered 10 seconds after it's been sent. Comcast apparently just chose the easy way out and doesn't bother filtering anything.

Well unless I've missed something incredibly obvious, that diff link isn't producing a file I can save and use with a patch command. It's producing a rather lengthy fancy format HTML document that would need to be run through by hand. Something I'd prefer to avoid with a patch of this magnitude.

This isn't meant to be a permanent solution of any sort; it's supposed to be a way to explore the diffs. I don't want to enable tarball generation on the browser because that will consume more resources than I care to use, however, I don't object to uploading a tarball to this site. I've done so and it's awaiting approval.

It might be easier to branch stable, then to put your code on top of it, commit, then merge with the const-fix version. That way bzr will take care of everything for you.

I'll take another look right now but I don't recall seeing any "raw" links. I also don't see how branching one thing, putting "my" code on top of it, merging the const-fix, then recommitting would be at all easy for those of us who know nothing of how bzr works. I'm used to SVN, and even then I deal with it through a Windows interface since engaging it from the command line is a pain in the ass.

And thinking about it, what code is there to merge? 1.9 hasn't been touched in quite some time, mainly because we were waiting on this fix to be ready but also because as I said, nobody *cough*Kayle*cough* has given me anything ready for adding in anyway.

EDIT: Well anyway. Got ahold of the diff finally, ran the patch command. Came away squeaky clean except for a single line in imc.c which apparently was already fixed. The compile stands up against -Wwrite-strings as well. So unless anyone can think of some REALLY good reason why this shouldn't go live as a 1.9 update I'd love to hear it now....