mailbox_reader is a Python module providing two classes: Mailbox, a file-like object that iterates through the contents of a mailbox, and Email, an object which holds the individual emails returned by Mailbox. This module has been written with simplicity in mind, and low memory consumption.
mailbox_date_trimmer is a tool for mailing list archives that corrects messages' date headers if they are incorrect. Incorrect means that a message following another has a time difference bigger than one month, usually when the owner of the message had his clock misconfigured. After fixing the archive, running Hypermail over the mailbox will create correct discussion threads.
Nimrod is a statically typed, imperative programming language that tries to give the programmer ultimate power without compromising on runtime efficiency. This means it focuses on compile-time mechanisms in all their various forms. Beneath a nice infix/indentation based syntax with a powerful (AST based, hygienic) macro system lies a semantic model that supports a soft realtime GC on thread local heaps. Asynchronous message passing is used between threads, so no "stop the world" mechanism is necessary. An unsafe shared memory heap is also provided for the increased efficiency that results from that model.
Re: Lessons in Packaging Linux Applications
> As a side note, one of the main reasons
> my favorite distro (Slackware) is my
> favorite distro is because building
> packages seems so much simpler and
> easier than other distributions I've
> used. I hope that package creation can
> be kept reasonably simple.
> Creating packages should not become some
> arcane art that only a 'priesthood of
> packagers' can accomplish properly. It
> needs to be something anyone can do,
> even if their package is only for their
> own particular system.
Have you seen <a
href="http://checkinstall.izto.org">http://checkinstall.izto.org? I use it to create my own debian
packages: ./configure; make; make install
and you have a .deb package. The nice thing is you
can add dependencies to them, and last time I
upgraded with apt-get upgrade, my custom
made packages were replaced correctly with new
binary versions that were available.
Really fantastic. Do get the development version
for dependencies and other advanced uses which
still have not made it to the stable branch.
Re: Mozilla and Phoenix are not Gecko -- Try Skipstone!
> >HOWEVER, I'm also decoding oggs, running
setiathome, serving web pages, batch
downloading other things, and ripping
Queen's audio cd.
>All stuff that doesn't take that much
Think twice. Setiathome and oggenc are two processes which will suck all the CPU for them, running them alone, each gets 50%. This means that ignoring the other tasks, skipstone could have never had more than 33% of the CPU. Calculating 800Mhz * 0.33 makes my benchmark similar to that of a PIII at 266Mhz. Since you say that about your k6 machine, I'm glad I bought an Intel chip instead of that cheaper and faster AMD one I was offered...
> You think that's fast? You've obviously
never tried Opera.
I have tried it, but as you see I'm not the one moaning about browser benchmarks discouraging the use of other software basing myself only the features list of a superficial review. In fact, I only use graphic browsers at work, and there my machine makes Mozilla as fast as lynx...
There are two suspicious things about your negative comments: first, you use a graphical browser for something you don't really need one, you could use a text one, much faster than anything discussed here. Second, if your bottleneck is documentation rendering, please tell me where do I get your neuronal brain-to-cpu bidirectional bus, I want near-to-nul development time too!