Re: September Gnus 0.40 is released

[dhall@illusion.apk.net (d. hall)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3644 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----

ð thus on 22 Feb 1996 02:12:47 +0100, Lars virtually scripted...

Steven L Baur <steve@miranova.com> writes:

>> A hard choice has already been made to abandon support for earlier
>> versions of Emacs.  Are we also prepared to abandon lesser endowed
>> systems as well?

Lars> No -- especially since this is being typed on a Linux bux with 6 megs
Lars> of ram.  :-) (It's where I do 90% of my work.)  I find that when just
Lars> running Gnus and reading small groups, it usually doesn't grow beyond
Lars> 4 megs, which leaves room for gnus.el and gnus.texi and stuff without
Lars> trashing.  Entering a group with 2000 articles is totally out of the
Lars> question, though.

Okay call me spoiled (hmm... I might actually spell check this article
since it's a subject near and dear to my heart) in that I think 16 megs
isn't enough.  Just a year and half ago I was tinkering around with a 486
dx2/80 with 4 megs of ram and thinking it was hot s**t (now with 16 megs
I'm beginning to wonder with the current crop and trend with software if
even _that_ is enough to "scratch by").

I've been doing some checking, the main problem seems to be when I try to
access some of the higher volume newsgroups, namely comp.lang.c (with
_heavy_ adaptive scoring).  If I leave off reading that newsgroup for a
couple days I'm sacked with a couple thousand articles that Gnus needs to
parse through, and I'm leery to leave that emacs process running after I
read that newsgroup.  So a possible option includes a "stealthing
procedure" for the newsgroup (which probably pertains to asynch reading of
the overview files).  Basically catching "snippets" of the overview file in
gnus-large-newsgroup sections.  I'd be willing to trade time for memory
usage in matters like this, also it'll break the waiting time into
segments.

Also I've looked into reducing of the overall feature loading in default
Gnus.  I've been doing some extensive feature tree studying in the last few
days to trace where all my memory is going.  The features variable grows
exponentially with each little Gnus feature I like to try out.  Inherently
I'm a minimalist, and like to load just what I need and use.  I'm don't use
nnmh, and yet this needs to be loaded with nndraft, which I like...  which
presents problems.  I do use nnfolder, and would love to have nndraft use
nnfolder instead of nnmh, possible in future releases (Red Gnus)?  I don't
know if nndraft would be considered a back-end in and of itself or a
back-end "wrapper" to another back-end.  The feature tree grows with X
interface, but that is to be expected.  I don't think Gnus can be broken
into any smaller files to reduce feature overhead =).

To give an extent of how bad minimalism can get, I've deleted most of
loaddefs.el and re-did the update after deleting 25% of the lisp directory
(well this and the fact that some idiot put the IDE cable backwards into my
western digital 1.6 gig hard-drive, thereby frying it, and reducing me to
my .5 meg Maxtor hard drive and further leaving me in a crunch for disk
space right now).

d.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBMSwnzYX26urqpgG1AQFjugQAhUaWb5cflx35uTsK+Boi5EEAQrYUjMLM
D3CPby6JydArBAQD4qQ9pMARwyVa+TXJPtYpo8OHmoVjxLMklf/eWzP9xNhbDoy8
nbPKbb1fbtOkwnBJXhhiB22nfMob+jgXX6NwnrktOfhMVdWjNSIAohmO6JcxhFzC
njbdbIC1NHk=
=2z2n
-----END PGP SIGNATURE-----
--
Hi!  Darren's answering machine is broken.  This is his refrigerator.
Please speak very slowly, and I'll stick your message to myself with
one of these magnets.
				~ answering machine message