Older blog entries for cdfrey (starting at number 20)

dwmw2 mentioned that he can't live without a tree view of mail folders showing which have new messages.

I currently use a combination of procmail, mutt, and my own scripts to sort and read mail. The procmail script sorts the mail into organized mbox files in ~/Mail/. Then I run newmail to get a list of mailboxes with new messages in them. Then I use

mutt -f Mail/mboxfile

to read.

Here's an example of my "newmail" output:

 Total     New  Mbox                                                          
------  ------  ----------------------------------------------                
    55       1  barry
   158      21 *bochs-dev (1)
  2096    1405  boost
   446     444 *bugtraq (3)
    80      78  bugtraq-generic
   402     144  c++
  4072       3  canada-dmca-opponents
  1200     157 *cdfrey (1)
   166     120  debian
   246      67  gentoo-announce
    41      15 *gentoo-desktop (1)
  1848    1022  gentoo-dev
    38       6  gentoo-gwn
    82      28  gentoo-hardened
   355     237 *gentoo-portage-dev (1)
   605      62  gentoo-security
   276     247 *gentoo-server (4)
  1217    1217  git
    11      10  gnupg-announce
    91      90  gnupg-devel
   423     331  gnupg-users
   129      82  kt
  1162       8  kwlug
   364     133  libusb
 10023   10022  linux-kernel
   601     344  linux-thinkpad
   144     144 *mailer-daemon (5)
   551     314  mplayer-users
   411     401  open-graphics
  1404     164  plusplus
   541      35  plusplus-commits
    63      34  risks
   211     189  slashdot
    47       2  spca50x-devs
     8       1  xboard

Yes, I'm a little behind. :-) This shows the total messages in the mbox file, the total unread messages, which mboxes have had new mail since I last checked (*), and how many new messages arrived since I last checked.

It's worked pretty well, not only as a mail system but as a spam whitelist too. I only use the code personally, so the code isn't polished for release. It's a single .cc file that can be compiled standalone, so it shouldn't be too hard to play with if you want.

Update: Found a bug where two uninitialized variables cause a new mail count to be out of whack the first time you run it. Once the mailbox data is cached, behaviour is normal.

Grab the file again if this matters to you.

jvic, Just run another X server.

Barry version 0.0.1 released

If you have a BlackBerry, and wish to retrieve data from it on your Linux system, consider paying a visit to the Barry Project page and giving the latest release whirl.

This is of course a very early alpha release, but so far it has the capability to download calendar items, email messages (dates not supported yet), and address book entries. It attempts to convert the address book entries into LDAP LDIF format, and the email into mbox format.

You can also use the command line tool to capture protocol data during database retrieval, in case you wish to lend a hand in the reverse-engineering process.

The library and tool are written in C++. The ultimate goal of this project is to create a fully functional syncing mechanism on Linux. My goal is to have the API easily available in Python, perhaps via SWIG, so GUI folks can use it to integrate with their application of choice; but I haven't gotten that far. People with C++-to-Python experience are extremely welcome right now, even to just give advice on some of the pitfalls to avoid on the C++ side, so when the Python integration time comes, it will be as painless as possible.

I hope to see you on the mailing list if you are interested in this project.

One of the projects currently on the front burner for me is a library and application set for syncing the USB model of the RIM Blackberry handheld on Linux. Net Direct is the company behind this project, with full plans to open source it when it's ready. I may put it on SourceForge early if there is interest, but there's not a lot of code to hack on yet.

The first major task, of course, is to figure out the binary protocol that these devices use. I know about the documentation for the serial protocol at the Cassis project, but unfortunately, the USB protocol isn't the same.

There are rumours that the USB protocol may have been reverse engineered already, but my Google searches come up empty. If anyone knows of such a document, please email me. It would bring this project to fruition much faster.

While I'm on the topic, let me plug two fine USB tools:

• usbsnoop - a Windows filter with source code that intercepts the USB conversation between application and device.

• libusb - an LGPL cross-platform library that lets you work with the low level USB interface in userspace, without developing a kernel driver first.

To all the folks that replied to my previous diary entry, thanks! I apologise for being so busy I couldn't respond in depth as I wanted to.

Thanks to all the folks that bumped me up to Apprentice, which lets me comment on articles. Much appreciated.

ncm:

Monotone

What made you pick Monotone? I haven't yet made the time to evaluate all the distributed source control systems yet to find which one I like best, so I'm always eager to hear other people's reasons for their choices.

The ever present C++ debate

What worries me about the indulgence of template based generic programming over OO inheritance and virtual functions is that with templates, you are duplicating code for each type you wish to code for. This doesn't happen with OO, albeit with a slight performance hit of virtual functions.

This code duplication caused by templates is fine for code that you'd normally write anyway. For example, for_each instead of for loops, or any similar small piece of code.

But the larger your template functions become, the more each instance costs every time you use it.

Take the mozilla string hierarchy currently in discussion. How would you use templates to provide the same string functionality without the code duplication of templates? Mozilla is plenty big enough as it is.

Creating template versions of the mozilla string class, perhaps parameterized with the various functionality as template arguments, would cause each function that needed a general string argument to be a template as well, to accept whatever the user passed in. Am I missing something obvious here?

I must be, because there are a lot of C++ gurus that keep saying inheritance is bad, but tend not to go into detail. :-)

Thanks for the site renewal, quad!

I finally got around to adding some features to the GNU split command, which I felt were sadly lacking ever since I thought of them. :-)

I often use split to break huge files into multi-CD images, such as for backups or archiving. At the same time, I often find I'm low on disk space, so I would like to process each split file chunk as they appear instead of doing it all at once at the end.

I wrote a patch that adds exec and pause functionality with the following arguments:

  -e, --exec=CMD          run CMD after each output file is closed
  -w, --exec-wait=CMD     run CMD after each output file is closed
                          and wait for the child to exit
  -p, --pause             pause for keypress after each output file is closed

I find these features very useful, so I hope they make it into the official coreutils tarball.

If anyone has any tips on how to handle recovering a tty-based STDIN (see the split source code), please let me know. I'm currently just open()ing the tty on STDOUT, but that is not ideal.

uriel:

I can relate to your complaint. I joined advogato for the same reason, except I wanted to comment on the FreeDCE article from a while back.

I appreciate that advogato is not your average blog site, and because of that, it is remarkably spam-lite. Still, it is frustrating when becoming a full fledged member requires bugging other people to certify you.

I suppose I should get back to hacking now too. :-)

Well, it would appear that I've been interrupted by telemarketer calls one too many times. I've decided to do something about it in my own little way.

I've started my own Telemarketer Boycott List. This is mainly for my own memory enhancement, so I can remember the parasites^H^H^Hcompanies that try to turn me into a customer, and thereby avoid them in any future business dealings.

I'm putting it on the web in the hopes that others can benefit from my list, and perhaps create lists of their own.

I'm under no delusions that this will make a great dent in the telemarketing industry, but it will grant me an amount of personal satisfaction.

Marcus: You lucky dude.