Log in

No account? Create an account
Overloading the Machine -- Day [entries|friends|calendar]

[ website | wjsullivan.net ]
[ userinfo | livejournal userinfo ]
[ calendar | livejournal calendar ]

Google Talk with Bitlbee [26 Aug 2005|04:53pm]

Bitlbee has instructions on their front page for using Bitlbee with Google Talk, but they weren't quite right for me.

Using the im.bitlbee.org public server, the way I added the account for Google Talk to my Bitlbee account was:

  account add jabber me@gmail.com mypassword talk.google.com:ssl


Their instructions talk about using the port number 5222, but that only caused problems for me. The ssl seemed necessary, though.

There's really no reason I need to be part of another IM service, but I just don't like feeling left out.

Also, Google seems to have disabled inter-server communication with other Jabber servers, which strikes me as a pretty lame but understandably corporate thi\ ng to do.

4 comments|post comment

A Planner lesson learned [26 Aug 2005|11:38pm]

I strongly recommend changing the default behavior of planner-tasks-file-behavior if you tend to do anything risky with your Planner pages.

I had a bad experience today with Planner. I don't think it was Planner's fault. I suspect a coding-system problem, since I've been experimenting with different ones lately, and confusing myself, or a problem with upgrading a few of the libraries and trying to reload them in my running session. There was some kind of significant change that I vaguely remember being warned about involving 'emacs-wiki-current-file' or something similar. This was causing errors so I gave up trying to keep the session going and restarted.

Whereupon my current day page, with all my to-do items on it (I use forwarding so that undone tasks are always moved forward) was gone. Yesterday's page, where I hoped things would be, was a binary gargbage mess of garbled characters.

No problem, I thought, I'll just revert the patches to my planner pages. I keep all my planner pages under version control in darcs for just this reason. I try to stay current with Planner development, so I try to be prepared for the side effects of experimentation.

Well, turns out I had done my darcs commands in the wrong order, and did not actually add today's and yesterday's pages to the repository until they were already corrupted. Dumb, I know. Painful too.

And the Emacs-generated backup was also corrupted. Argh. That's two levels of redundancy I managed to bust through. How many do I need?

Anyway, the big lesson I learned out of this is, the default setting of planner-tasks-file-behavior is dangerous for someone like me. I never would have saved the plan pages by myself, when I saw the errors going on. I would have bailed on the emacs session without saving anything and started fresh. But somehow, these pages got saved anyway, because the default behavior is to save and close buffers automatically. If I could track down the process by which this corruption happened, I could help solve it, but I can't.

The best I can do is add (setq planner-tasks-file-behavior nil) to my .emacs. I don't care if I have a lot of open buffers or have to answer Yes to a lot of Save Buffer? questions. Minor inconveniences to go through to protect my stuff. And of course I'll remember to run darcs commands in the right order. The idea of changes I don't directly make being saved behind my back --- and then the buffers closed --- is disconcerting.

The day was not lost though. Because I still had all of the tasks on their respective project pages, I was able to construct a script that scanned for all of the tasks with links to the date pages for yesterday and today, and restore them. So in the end, I don't think I lost anything.

And I had one of those chances you secretly hope for when you're learning to be a better programmer; an actual problem that needs to be solved.

P.S. I'm not knocking Planner at all. Accidents and problems happen while using any program. I'm thankful that Planner (with Emacs) gives me ways to adjust settings that will help prevent them from happening again.

post comment

[ viewing | August 26th, 2005 ]
[ go | previous day|next day ]