* September Gnus 0.40 is released @ 1996-02-21 2:26 Lars Magne Ingebrigtsen 1996-02-21 3:20 ` Steven L Baur 1996-02-21 4:14 ` d. hall 0 siblings, 2 replies; 28+ messages in thread From: Lars Magne Ingebrigtsen @ 1996-02-21 2:26 UTC (permalink / raw) Bug fixes. Get it from <URL:http://www.ifi.uio.no/~larsi/sgnus.tar.gz> or "ftp.ifi.uio.no:/pub/emacs/gnus/". ChangeLog since last release: Wed Feb 21 00:21:56 1996 Lars Magne Ingebrigtsen <larsi@ifi.uio.no> * gnus.el (gnus-summary-refer-parent-article): Also check the NOV references. * gnus-salt.el (gnus-possibly-generate-tree): Don't generate trees for pseudo-articles. * nnvirtual.el (nnvirtual-retrieve-headers): Make sure the group exists. * gnus.el (gnus-summary-read-group): Search all frames when recentering the group buffer. (gnus-summary-hide-thread): Didn't hide dummy threads. * gnus.el (gnus-summary-prepare-threads): Dummy roots would swallow the following article. * gnus-msg.el (gnus-new-empty-mail): New function. (gnus-summary-resend-bounced-mail): Use it. * gnus-picon.el (gnus-picons-display-x-face): Make sure buffer exists. Tue Feb 20 04:45:34 1996 Lars Ingebrigtsen <lars@eyesore.no> * gnus.el (gnus-group-set-current-level): Error if not a group on the current line. (gnus-summary-next-page): Don't go to the next article when 'never and at the end of the group. (gnus-group-make-group): Make sure the server is opened. (gnus-read-descriptions-file): Make sure the method is a method and not a server. * gnus-msg.el (gnus-copy-article-buffer): Ditto. (gnus-forward-insert-buffer): Ditto. * gnus-cite.el (gnus-cite-parse): Use `gnus-set-text-properties'. * nnheader.el (nnheader-temp-write): Would bug out on nil files. -- (domestic pets only, the antidote for overdose, milk.) larsi@ifi.uio.no * Lars Ingebrigtsen ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: September Gnus 0.40 is released 1996-02-21 2:26 September Gnus 0.40 is released Lars Magne Ingebrigtsen @ 1996-02-21 3:20 ` Steven L Baur 1996-02-21 11:06 ` Per Abrahamsen 1996-02-21 4:14 ` d. hall 1 sibling, 1 reply; 28+ messages in thread From: Steven L Baur @ 1996-02-21 3:20 UTC (permalink / raw) nnbabyl.el still has an unprotected call to set-text-properties. -- steve@miranova.com baur Unsolicited commercial e-mail will be proofread for $250/hour. Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone except you in November. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: September Gnus 0.40 is released 1996-02-21 3:20 ` Steven L Baur @ 1996-02-21 11:06 ` Per Abrahamsen 1996-02-21 19:00 ` Steven L Baur 0 siblings, 1 reply; 28+ messages in thread From: Per Abrahamsen @ 1996-02-21 11:06 UTC (permalink / raw) This emacs is reserved for Gnus: PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 6037 abraham 23 0 14M 13M sleep 15:42 0.13% 0.13% emacs This emacs is for development (cc-mode, gud, ediff, vc, and compile): PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 975 abraham 33 0 11M 8032K sleep 30:36 0.00% 0.00% emacs Just for comparison: PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 22473 abraham 34 0 12M 5372K sleep 8:55 0.00% 0.00% netscape The Emacs is an 19.31 pretest. The Netscape is 1.1N. Acceptable? I guess that depends on how much memory you have. My boss thinks that giving developers enough memory helps productivity, so as long as nobody tells him that it just makes us write bloated software, I don't have a problem. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: September Gnus 0.40 is released 1996-02-21 11:06 ` Per Abrahamsen @ 1996-02-21 19:00 ` Steven L Baur 1996-02-21 21:50 ` Andy Eskilsson 1996-02-22 1:12 ` Lars Magne Ingebrigtsen 0 siblings, 2 replies; 28+ messages in thread From: Steven L Baur @ 1996-02-21 19:00 UTC (permalink / raw) >>>>> "Per" == Per Abrahamsen <abraham@dina.kvl.dk> writes: Per> PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND Per> This emacs is reserved for Gnus: Per> 6037 abraham 23 0 14M 13M sleep 15:42 0.13% 0.13% emacs Per> 22473 abraham 34 0 12M 5372K sleep 8:55 0.00% 0.00% netscape ... Per> Acceptable? I guess that depends on how much memory you have. Per> My boss thinks that giving developers enough memory helps Per> productivity, so as long as nobody tells him that it just makes us Per> write bloated software, I don't have a problem. As does my boss. I'm also inclined to agree with you that memory usage with GNU Emacs is within acceptable limits. A comparison with Netscape is fair, although a better metric would be against 2.0 instead of 1.1N. Whatever the difference, there is no comparison with respect to functionality, Gnus + X?Emacs wins no contest. 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? -- steve@miranova.com baur Unsolicited commercial e-mail will be proofread for $250/hour. Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone except you in November. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: September Gnus 0.40 is released 1996-02-21 19:00 ` Steven L Baur @ 1996-02-21 21:50 ` Andy Eskilsson 1996-02-22 1:12 ` Lars Magne Ingebrigtsen 1 sibling, 0 replies; 28+ messages in thread From: Andy Eskilsson @ 1996-02-21 21:50 UTC (permalink / raw) Cc: ding / Steven L Baur <steve@miranova.com> wrote: | | 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? This shouldn't stop us(ehm the Gnus developers) from keeping eyes open for memory leaks, memory hogging stuff that really ain't worth it? I don't know much about the memoryhandling in emacs/gnus, but I think you are talking about two different memory-hogs here: 1. Memory leaks (I think it is possible!), features that take a large hunk of memory, that they(the user/feature) might not need. 2. Feature 'leaks', simply more features, more memory. I think this thread started with the first point, and Steven is talking about the second? /andy (on his 386sx16 with 1 meg ram.. ehh, hoold it..) -- Don't walk in front of me, I might be unable to follow you. Don't walk after me, I might be unable to lead you. Just walk by my side and be my friend. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: September Gnus 0.40 is released 1996-02-21 19:00 ` Steven L Baur 1996-02-21 21:50 ` Andy Eskilsson @ 1996-02-22 1:12 ` Lars Magne Ingebrigtsen 1996-02-22 8:22 ` d. hall 1 sibling, 1 reply; 28+ messages in thread From: Lars Magne Ingebrigtsen @ 1996-02-22 1:12 UTC (permalink / raw) 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? No -- especially since this is being typed on a Linux bux with 6 megs of ram. :-) (It's where I do 90% of my work.) I find that when just running Gnus and reading small groups, it usually doesn't grow beyond 4 megs, which leaves room for gnus.el and gnus.texi and stuff without trashing. Entering a group with 2000 articles is totally out of the question, though. -- "Yes. The journey through the human heart would have to wait until some other time." ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: September Gnus 0.40 is released 1996-02-22 1:12 ` Lars Magne Ingebrigtsen @ 1996-02-22 8:22 ` d. hall 1996-02-22 18:03 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 28+ messages in thread From: d. hall @ 1996-02-22 8:22 UTC (permalink / raw) Cc: ding [-- 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: September Gnus 0.40 is released 1996-02-22 8:22 ` d. hall @ 1996-02-22 18:03 ` Lars Magne Ingebrigtsen 1996-02-22 20:49 ` Steven L Baur 0 siblings, 1 reply; 28+ messages in thread From: Lars Magne Ingebrigtsen @ 1996-02-22 18:03 UTC (permalink / raw) dhall@illusion.apk.net (d. hall) writes: > 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. Reading the nov file doesn't make Emacs increase in size much. Generating the summary buffer does. Gnus creates all kinds of odd thread trees (3 cons cels per article), a `gnus-newsgroup-data' list (5 cons cells per article), and all those text properties that make the summary buffer look all pretty an nice (I have no idea how many cons cells). If you enter a group with 10000 unread articles, all those small cons cells do add up. > I'm don't use nnmh, and yet this needs to be loaded with nndraft, > which I like... which presents problems. nndraft is a wrapper around nnmh, so you need both loaded. -- "Yes. The journey through the human heart would have to wait until some other time." ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: September Gnus 0.40 is released 1996-02-22 18:03 ` Lars Magne Ingebrigtsen @ 1996-02-22 20:49 ` Steven L Baur 0 siblings, 0 replies; 28+ messages in thread From: Steven L Baur @ 1996-02-22 20:49 UTC (permalink / raw) (Two articles I posted Wed 21-Feb, (about 21 hours ago) were damaged by an experimental recompiled XEmacs, this article should be O.K.) >>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes: Lars> Reading the nov file doesn't make Emacs increase in size much. Lars> Generating the summary buffer does. Gnus creates all kinds of odd Lars> thread trees (3 cons cels per article), a `gnus-newsgroup-data' list Lars> (5 cons cells per article), and all those text properties that make Lars> the summary buffer look all pretty an nice (I have no idea how many Lars> cons cells). Let's see. Add to that the text properties of fancy citation highlighted text, *Group* buffer color schemes ... There must be some room for reusing extents intelligently on XEmacs though. Once the code starts to settle down, this sounds like a worthwhile project. Regards, -- steve@miranova.com baur Unsolicited commercial e-mail will be proofread for $250/hour. Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone except you in November. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: September Gnus 0.40 is released 1996-02-21 2:26 September Gnus 0.40 is released Lars Magne Ingebrigtsen 1996-02-21 3:20 ` Steven L Baur @ 1996-02-21 4:14 ` d. hall 1996-02-21 6:55 ` Gnus Memory usage Steven L Baur 1 sibling, 1 reply; 28+ messages in thread From: d. hall @ 1996-02-21 4:14 UTC (permalink / raw) Cc: ding -----BEGIN PGP SIGNED MESSAGE----- One strange note, I'd like to bring up since all this NNFOLDER talk has been occuring. I ran list-buffers at one time and found all my nnfolder files open in their own buffers. I did a C-h v on nnfolder-always-close, which was t. Right now my emacs is bloated to the point where at times when running Gnus it'll eat up 8 megs of my 16 meg linux. I'd really rather not have to swap all my processes to read news, any suggestions on reducing this? d. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBMSqcJ4X26urqpgG1AQF8DgQAlTViR6+Hwqhkg0rJaGrBa5+hSk+TnBO2 6rcVWTenhcGEqWbR4U5Z2YZBc3RC1hzNLm15JJopEAV/bhi7PntxhuP97meJ0j38 dP+9FYUi/pQHXklQIVlypQCHUCcw81H1RKy4GV2aGaA8QQIl8cA6SqILAyP3tluy Z9JFar18FXo= =BZ7E -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 28+ messages in thread
* Gnus Memory usage 1996-02-21 4:14 ` d. hall @ 1996-02-21 6:55 ` Steven L Baur 1996-02-21 16:38 ` Wes Hardaker 1996-02-21 17:59 ` Gnus Memory usage Mark Borges 0 siblings, 2 replies; 28+ messages in thread From: Steven L Baur @ 1996-02-21 6:55 UTC (permalink / raw) >>>>> "d" == d hall <dhall@illusion.apk.net> writes: d> One strange note, I'd like to bring up since all this NNFOLDER talk has d> been occuring. I ran list-buffers at one time and found all my nnfolder d> files open in their own buffers. I did a C-h v on nnfolder-always-close, d> which was t. Right now my emacs is bloated to the point where at times d> when running Gnus it'll eat up 8 megs of my 16 meg linux. I'd really d> rather not have to swap all my processes to read news, any suggestions on d> reducing this? I'd love to have a Gnus stay down at only 8 MB, but let me quantify my numbers. This is from a Linux 1.2.13, ELF system, output slightly reformatted to align the columns. And yes, I have enabled the allocator that can return memory to the system. ps -ux output: USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND steve 2148 2.8 18.3 4899 5724 ? S 11:39 18:21 /usr/local/bin/xemacs steve 7329 29.6 39.8 9327 12408 ? S 19:30 53:39 /usr/local/bin/xemacs ps -mx output: PID TTY MAJFLT MINFLT TRS DRS SIZE SWAP RSS SHRD LIB DT COMMAND 2148 ? 1994 3431 1976 3968 6660 716 5944 1928 0 986 /usr/local 7329 ? 779 287486 1872 11208 13860 780 13080 2068 0 2753 /usr/local PID 2148 is an XEmacs I've been editing in all afternoon. PID 7329 has been running Gnus. I consider this memory usage unacceptable. The burning question is what does everyone consider acceptable and normal Gnus+X?Emacs memory usage? -- steve@miranova.com baur Unsolicited commercial e-mail will be proofread for $250/hour. Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone except you in November. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Gnus Memory usage 1996-02-21 6:55 ` Gnus Memory usage Steven L Baur @ 1996-02-21 16:38 ` Wes Hardaker 1996-02-22 1:12 ` Lars Magne Ingebrigtsen 1996-02-21 17:59 ` Gnus Memory usage Mark Borges 1 sibling, 1 reply; 28+ messages in thread From: Wes Hardaker @ 1996-02-21 16:38 UTC (permalink / raw) Cc: ding >>>>> "Steven" == Steven L Baur <steve@miranova.com> writes: Steven> This is from a Linux 1.2.13, ELF system, output slightly Steven> reformatted to align the columns. And yes, I have enabled Steven> the allocator that can return memory to the system. You know, I brought up this subject a while back (1 month?) and never got many responses saying 'yeah me too'. Its actually worse than you think. (FYI, I'm running 19.13 with re-alloc as well). Even if you quit gnus, you don't regain the memory, which is what I really don't understand. Wes ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Gnus Memory usage 1996-02-21 16:38 ` Wes Hardaker @ 1996-02-22 1:12 ` Lars Magne Ingebrigtsen 1996-02-22 23:19 ` Wes Hardaker 0 siblings, 1 reply; 28+ messages in thread From: Lars Magne Ingebrigtsen @ 1996-02-22 1:12 UTC (permalink / raw) hardaker@ece.ucdavis.edu (Wes Hardaker) writes: > You know, I brought up this subject a while back (1 month?) and never > got many responses saying 'yeah me too'. Its actually worse than you > think. (FYI, I'm running 19.13 with re-alloc as well). Even if you > quit gnus, you don't regain the memory, which is what I really don't > understand. I thought (X)Emacs could only return memory that was allocated for buffers? That no cons cells (and stuff) were ever returned to the system? Has that changed? -- "Yes. The journey through the human heart would have to wait until some other time." ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Gnus Memory usage 1996-02-22 1:12 ` Lars Magne Ingebrigtsen @ 1996-02-22 23:19 ` Wes Hardaker 1996-02-22 23:50 ` Lars Magne Ingebrigtsen 1996-02-23 1:39 ` Steven L Baur 0 siblings, 2 replies; 28+ messages in thread From: Wes Hardaker @ 1996-02-22 23:19 UTC (permalink / raw) Cc: ding >>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes: Lars> I thought (X)Emacs could only return memory that was Lars> allocated for buffers? That no cons cells (and stuff) were Lars> ever returned to the system? Has that changed? You must think that I know something when I start typing out important sounding sentences. "HA" I say! Anyway, I'm not sure honestly. I would hope it would do as much as possible, but I really don't know. All I know is that when I was doing experiments a while back (sgnus .2? or .1? something I would think) and I started sgnus, I'd get a massive memory increase. Then I would quit sgnus and restart it again. I would get yet another memory increase. This was sort of annoying, since you get XEmacs to grow to a fairly large size simply by reading news say 3 or 4 times during the day. These were fairly consecutive bursts; I should try this again and do things in between the sgnus runs to see if anything gets cleaned up. Maybe tommorrow (ha). Lars> -- "Yes. The journey through the human heart would have to Lars> wait until some other time." Whats that from anyway? Sounds like it should be a great MST3K show though. Wes ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Gnus Memory usage 1996-02-22 23:19 ` Wes Hardaker @ 1996-02-22 23:50 ` Lars Magne Ingebrigtsen 1996-02-23 17:19 ` Wes Hardaker 1996-02-23 1:39 ` Steven L Baur 1 sibling, 1 reply; 28+ messages in thread From: Lars Magne Ingebrigtsen @ 1996-02-22 23:50 UTC (permalink / raw) hardaker@ece.ucdavis.edu (Wes Hardaker) writes: > All I know is that when I was doing experiments a while back (sgnus > .2? or .1? something I would think) and I started sgnus, I'd get a > massive memory increase. Then I would quit sgnus and restart it > again. I would get yet another memory increase. That's definitely not good. I'm running XEmacs at the moment, and it is 13Mb big. (But I did enter a virtual group with 4000 articles a few minutes ago.) > Lars> -- "Yes. The journey through the human heart would have to > Lars> wait until some other time." > > Whats that from anyway? Sounds like it should be a great MST3K show > though. It's from a short story by Janet Frame. She's visiting some natural history museum which has an exhibition on the human heart. She stands around listening to a guide explain something else to a bunch of school children for too long, and she has to rush to catch a train, so she doesn't have time to do the human heart exhibition. Aren't you glad you asked? :-) -- (domestic pets only, the antidote for overdose, milk.) larsi@ifi.uio.no * Lars Ingebrigtsen ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Gnus Memory usage 1996-02-22 23:50 ` Lars Magne Ingebrigtsen @ 1996-02-23 17:19 ` Wes Hardaker 1996-02-24 7:44 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 28+ messages in thread From: Wes Hardaker @ 1996-02-23 17:19 UTC (permalink / raw) Cc: ding >>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes: Lars> It's from a short story by Janet Frame. She's visiting some Lars> natural history museum which has an exhibition on the human Lars> heart. She stands around listening to a guide explain Lars> something else to a bunch of school children for too long, Lars> and she has to rush to catch a train, so she doesn't have Lars> time to do the human heart exhibition. Lars> Aren't you glad you asked? :-) Yep! Thanks. It still sounds like it would make a great MST3K episode. Wes ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Gnus Memory usage 1996-02-23 17:19 ` Wes Hardaker @ 1996-02-24 7:44 ` Lars Magne Ingebrigtsen 1996-02-24 9:26 ` d. hall 1996-02-26 18:12 ` Wes Hardaker 0 siblings, 2 replies; 28+ messages in thread From: Lars Magne Ingebrigtsen @ 1996-02-24 7:44 UTC (permalink / raw) hardaker@ece.ucdavis.edu (Wes Hardaker) writes: > It still sounds like it would make a great MST3K episode. What's MST3K? Uhm. Moon Seven Times... No, that's M7x. MMMSTK. I give up. -- "Yes. The journey through the human heart would have to wait until some other time." ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Gnus Memory usage 1996-02-24 7:44 ` Lars Magne Ingebrigtsen @ 1996-02-24 9:26 ` d. hall 1996-02-26 18:01 ` Stephen Peters 1996-02-26 18:12 ` Wes Hardaker 1 sibling, 1 reply; 28+ messages in thread From: d. hall @ 1996-02-24 9:26 UTC (permalink / raw) Cc: ding -----BEGIN PGP SIGNED MESSAGE----- // thus on 24 Feb 1996 08:44:07 +0100, Lars virtually scripted... hardaker@ece.ucdavis.edu (Wes Hardaker) writes: >> It still sounds like it would make a great MST3K episode. Lars> What's MST3K? Lars> Uhm. Moon Seven Times... No, that's M7x. MMMSTK. I give up. Mystery Science-Fiction Theatre 3000 It's a show that is/was(?) shown on Comedy Central a cable channel here in the U.S. It's one of those cult-following show, normally stereo-typed to the "electronically inclined folk". Not quite up there with Star Trek: *, and I never really got into it. d. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBMS7Z3YX26urqpgG1AQGEoAP+NKu3eqxDhDqSUiYGI3FdxCxBVzUgzKTR Q7I0BhRE6m+kAYIa5I/bhhbRnU3L2XsHso1jngCDe5iXQGCp+kZaGWGtAHbUXOAn Pa/qx4aGDzsB7eTTVre2QHd/JdJVK7HUBwx/1ZoLwRKIdVhQt8gw86Jwz6CeEa6Q eebJjMeXFBM= =mM1e -----END PGP SIGNATURE----- -- ``I don't know what's scarier. Losing nuclear weapons... or it happens so often there's actually a term for it.'' ~ from broken arrow ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Gnus Memory usage 1996-02-24 9:26 ` d. hall @ 1996-02-26 18:01 ` Stephen Peters 0 siblings, 0 replies; 28+ messages in thread From: Stephen Peters @ 1996-02-26 18:01 UTC (permalink / raw) Cc: ding dhall@illusion.apk.net (d. hall) writes: Lars> What's MST3K? >Mystery Science-Fiction Theatre 3000 Mystery Science Theatre 3000, but close enough :-) >It's a show that is/was(?) shown on Comedy Central a cable channel here in >the U.S. It's one of those cult-following show, normally stereo-typed to >the "electronically inclined folk". Not quite up there with Star Trek: *, >and I never really got into it. OK, we're way off-topic here, but I'll just put my two cents in with a little more information. It is still being shown, although it may be leaving the airwaves soon. A big-screen version should be hitting US theatres in April, I believe. The basic idea is that they take a movie -- and I mean a really bad movie, ideally with horrendous special effects and dialogue that makes you wince, and they then make a running wisecracking commentary on the film for its entire length. I wouldn't say that it's stereotyped to "electronically inclined" people -- the jokes are fairly reference-heavy, so I would say it probably appeals more to people with a broad knowledge of pop culture and a fairly sarcastic sense of humor. It is, however, definitely a cult show. We'll see if it can translate at all well to the movie theatre in April, I guess... -- Stephen L. Peters speters%samsun@us.oracle.com For PGP key, use keyservers or send email with subject: SEND PGP KEY PGP fingerprint: BFA4 D0CF 8925 08AE 0CA5 CCDD 343D 6AC6 Oracle won't speak for me, so I won't speak for them. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Gnus Memory usage 1996-02-24 7:44 ` Lars Magne Ingebrigtsen 1996-02-24 9:26 ` d. hall @ 1996-02-26 18:12 ` Wes Hardaker 1 sibling, 0 replies; 28+ messages in thread From: Wes Hardaker @ 1996-02-26 18:12 UTC (permalink / raw) Cc: ding >>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes: Lars> What's MST3K? As people have already said, it stands for "Mystery Science Theater 3000". Its a show made in the U.S. and played on "Comedy Central", which is a Television-cable channel produced by "HBO". Anyway, the show is about this guy that two scientists shot into space. They make him watch really really really really (x inf) bad Science Fiction Movies and study his reactions. Ok... Thats the story behind it. The show is really about watching this guy and 2 of his robot-friends heckle these bad movies. You watch the movie with them and you see their silhouettes on the bottom of the screen (which is a silhouette of the front row of seats in a movie theater). They make wise cracks about these movies, which can on occasion be really funny. On other occasions, I've fallen asleep. The movies they are watch are truly bad. Impressively bad. If they can find enough witty comments to make, they are worth watching though. Most people do seem to be either an avid fan or can't stand it. I'm one of the exceptions that fall in the middle. Wes ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Gnus Memory usage 1996-02-22 23:19 ` Wes Hardaker 1996-02-22 23:50 ` Lars Magne Ingebrigtsen @ 1996-02-23 1:39 ` Steven L Baur 1996-02-23 17:24 ` Wes Hardaker 1996-02-23 21:57 ` Mark Denovich 1 sibling, 2 replies; 28+ messages in thread From: Steven L Baur @ 1996-02-23 1:39 UTC (permalink / raw) >>>>> "Wes" == Wes Hardaker <hardaker@ece.ucdavis.edu> writes: Wes> All I know is that when I was doing experiments a while back (sgnus Wes> .2? or .1? something I would think) and I started sgnus, I'd get a Wes> massive memory increase. Then I would quit sgnus and restart it Wes> again. I would get yet another memory increase. This was sort of Wes> annoying, since you get XEmacs to grow to a fairly large size simply Wes> by reading news say 3 or 4 times during the day. These were fairly Wes> consecutive bursts; I should try this again and do things in between Wes> the sgnus runs to see if anything gets cleaned up. Maybe tommorrow (ha). Why kill and restart Gnus several times in the same XEmacs session? The amount of time lost waiting for garbage collection as the size increases easily surpasses the amount of time it takes to restart the program from scratch. It doesn't appear to hurt anything (if you have the memory available) to just leave Gnus always running. Disconnection is automatic, and reconnection is painless. -- steve@miranova.com baur Unsolicited commercial e-mail will be proofread for $250/hour. Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone except you in November. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Gnus Memory usage 1996-02-23 1:39 ` Steven L Baur @ 1996-02-23 17:24 ` Wes Hardaker 1996-02-23 21:57 ` Mark Denovich 1 sibling, 0 replies; 28+ messages in thread From: Wes Hardaker @ 1996-02-23 17:24 UTC (permalink / raw) Cc: ding >>>>> "Steven" == Steven L Baur <steve@miranova.com> writes: Steven> Why kill and restart Gnus several times in the same XEmacs Steven> session? The amount of time lost waiting for garbage Steven> collection as the size increases easily surpasses the Steven> amount of time it takes to restart the program from Steven> scratch. It doesn't appear to hurt anything (if you have Steven> the memory available) to just leave Gnus always running. Steven> Disconnection is automatic, and reconnection is painless. Well, this is what I've started doing more lately. Originally, I just did it automatically thinking I wouldn't be reading news later. It was then that I noticed things got even worse during the second read. At the time, I didn't read any mail inside gnus, so it was unusual to read news twice in one day. Again, I haven't checked this out in a while so it may not happen anymore. However, if it does shrink XEmacs to quit gnus, that alone might be enough of a reason (though I think we've proven it doesn't shrink by much). When I'm actually trying to get some work done, my HP 715/80 with 96 megs of memory swaps constantly while running Mentor (a bloated EE CAD program). I often quit XEmacs all together before starting Mentor. blah blah blah Wes ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Gnus Memory usage 1996-02-23 1:39 ` Steven L Baur 1996-02-23 17:24 ` Wes Hardaker @ 1996-02-23 21:57 ` Mark Denovich 1996-02-24 7:44 ` Lars Magne Ingebrigtsen 1 sibling, 1 reply; 28+ messages in thread From: Mark Denovich @ 1996-02-23 21:57 UTC (permalink / raw) > > Why kill and restart Gnus several times in the same XEmacs session? > The amount of time lost waiting for garbage collection as the size > increases easily surpasses the amount of time it takes to restart the > program from scratch. It doesn't appear to hurt anything (if you have > the memory available) to just leave Gnus always running. > Disconnection is automatic, and reconnection is painless. Not so. I am forced to use Dynamic-IP PPP. Thus my IP address is never the same after disconnect. Sgnus and just about every other app handle this very poorly, the exception being Netscape. The solution is to kill gnus after the link goes down. Starting it back up when the net is back up. I hope that it doesn't keep growing every time I start-stop it, since do this at least 10 times a day. I mentioned this to Lars sometime ago but don't know if he's doing anything about it. --Mark ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Gnus Memory usage 1996-02-23 21:57 ` Mark Denovich @ 1996-02-24 7:44 ` Lars Magne Ingebrigtsen 1996-02-24 22:08 ` dynamic ip (Re: Gnus Memory usage) Felix Lee 0 siblings, 1 reply; 28+ messages in thread From: Lars Magne Ingebrigtsen @ 1996-02-24 7:44 UTC (permalink / raw) Mark Denovich <madst38@pitt.edu> writes: > Not so. I am forced to use Dynamic-IP PPP. Thus my IP address is > never the same after disconnect. Sgnus and just about every other app > handle this very poorly, the exception being Netscape. > > The solution is to kill gnus after the link goes down. Starting it > back up when the net is back up. I hope that it doesn't keep growing > every time I start-stop it, since do this at least 10 times a day. > > I mentioned this to Lars sometime ago but don't know if he's doing > anything about it. I don't know exactly what I should do about it. Gnus should definitely figure out that something odd is going on when it sends out commands and doesn't get any data back. Perhaps the commands should have a timeout thingie (which would not be enabled by default), and if a command times out, Gnus should just hang up and reconnect. Would that do the trick? -- "Yes. The journey through the human heart would have to wait until some other time." ^ permalink raw reply [flat|nested] 28+ messages in thread
* dynamic ip (Re: Gnus Memory usage) 1996-02-24 7:44 ` Lars Magne Ingebrigtsen @ 1996-02-24 22:08 ` Felix Lee 1996-02-24 22:33 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 28+ messages in thread From: Felix Lee @ 1996-02-24 22:08 UTC (permalink / raw) > Mark Denovich <madst38@pitt.edu> writes: > > Not so. I am forced to use Dynamic-IP PPP. Thus my IP address is > > never the same after disconnect. Sgnus and just about every other app > > handle this very poorly, the exception being Netscape. the main reason netscape handles it is because http needs a new connection for every data transfer. netscape news handles dynamic ip about as well as gnus does (automatic reconnect only on connection shutdown). Lars: > I don't know exactly what I should do about it. Gnus should > definitely figure out that something odd is going on when it sends out > commands and doesn't get any data back. Perhaps the commands should > have a timeout thingie (which would not be enabled by default), and > if a command times out, Gnus should just hang up and reconnect. this would be okay, but to be reliable the timeout would have to be on the order of several minutes (since getting a response to a POST command can take minutes). what I'd like instead is an easy way of doing a manual reconnect, since I know when I need to. -- ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: dynamic ip (Re: Gnus Memory usage) 1996-02-24 22:08 ` dynamic ip (Re: Gnus Memory usage) Felix Lee @ 1996-02-24 22:33 ` Lars Magne Ingebrigtsen 1996-02-25 0:35 ` Felix Lee 0 siblings, 1 reply; 28+ messages in thread From: Lars Magne Ingebrigtsen @ 1996-02-24 22:33 UTC (permalink / raw) Felix Lee <flee@teleport.com> writes: > what I'd like instead is an easy way of doing a manual reconnect, > since I know when I need to. `^' in the group buffer will put you in the server buffer. `C' on a server will close it and `O' will open it. (There probably should be a function to close/reopen all servers. That's on the Red Gnus todo list.) -- (domestic pets only, the antidote for overdose, milk.) larsi@ifi.uio.no * Lars Ingebrigtsen ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: dynamic ip (Re: Gnus Memory usage) 1996-02-24 22:33 ` Lars Magne Ingebrigtsen @ 1996-02-25 0:35 ` Felix Lee 0 siblings, 0 replies; 28+ messages in thread From: Felix Lee @ 1996-02-25 0:35 UTC (permalink / raw) Lars: > `^' in the group buffer will put you in the server buffer. `C' on a > server will close it and `O' will open it. (There probably should be > a function to close/reopen all servers. That's on the Red Gnus todo > list.) hmm, ok. though most of the time my connection hangs up while I'm in middle of a batch command (like "Xu"), so that's a little inconvenient. restarting by hand means I have to restart the whole transfer. alternate approach: start up a keepalive process (such as "ping") to check if the host is still reachable. -- ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Gnus Memory usage 1996-02-21 6:55 ` Gnus Memory usage Steven L Baur 1996-02-21 16:38 ` Wes Hardaker @ 1996-02-21 17:59 ` Mark Borges 1 sibling, 0 replies; 28+ messages in thread From: Mark Borges @ 1996-02-21 17:59 UTC (permalink / raw) Cc: ding >> On 20 Feb 1996 22:55:11 -0800, >> Steven L Baur(sb) wrote: sb> I'd love to have a Gnus stay down at only 8 MB, but let me quantify my sb> numbers. Me too. sb> The burning question is what does everyone consider acceptable and sb> normal Gnus+X?Emacs memory usage? This is on a $uname -a SunOS suomi 5.3 Generic_101318-70 sun4m sparc with numbers reported by top(1). ------------------------------------------------------------------------------ typical xemacs (both sgnus, VM running): PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 25325 mdb -14 0 14M 12M sleep 4:38 1.43% 13.69% xemacs-19.14-b ------------------------------------------------------------------------------ barebones(*) xemacs (xemacs -nw -q) PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 15894 mdb 34 0 7004K 4848K stop 0:01 0.00% 0.00% xemacs-19.14-b (*) You could build a smaller xemacs now by excluding toolbar etc. support at compile-time, I think. ------------------------------------------------------------------------------ minimal xemacs (xemacs -q): PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 15597 mdb 34 0 7232K 5700K sleep 0:03 2.24% 1.75% xemacs-19.14-b ------------------------------------------------------------------------------ minimal xemacs + my .emacs (efs,dmacro,fill-adapt,jka-compr,etc. required): PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 15597 mdb 34 0 8436K 7032K sleep 0:12 11.18% 0.00% xemacs-19.14-b ------------------------------------------------------------------------------ minimal xemacs + my .emacs + sgnus: PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 15597 mdb 34 0 11M 9352K sleep 0:37 3.30% 2.52% xemacs-19.14-b ------------------------------------------------------------------------------ immediately after quitting sgnus: PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 15597 mdb 34 0 10M 9076K sleep 0:38 2.36% 0.00% xemacs-19.14-b ------------------------------------------------------------------------------ However, if I kill off all the buffers and let xemacs run overnight, when I return I the morning I find the RES size has shrunk to something a bit less than 5Mb. -mb- ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~1996-02-26 18:12 UTC | newest] Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1996-02-21 2:26 September Gnus 0.40 is released Lars Magne Ingebrigtsen 1996-02-21 3:20 ` Steven L Baur 1996-02-21 11:06 ` Per Abrahamsen 1996-02-21 19:00 ` Steven L Baur 1996-02-21 21:50 ` Andy Eskilsson 1996-02-22 1:12 ` Lars Magne Ingebrigtsen 1996-02-22 8:22 ` d. hall 1996-02-22 18:03 ` Lars Magne Ingebrigtsen 1996-02-22 20:49 ` Steven L Baur 1996-02-21 4:14 ` d. hall 1996-02-21 6:55 ` Gnus Memory usage Steven L Baur 1996-02-21 16:38 ` Wes Hardaker 1996-02-22 1:12 ` Lars Magne Ingebrigtsen 1996-02-22 23:19 ` Wes Hardaker 1996-02-22 23:50 ` Lars Magne Ingebrigtsen 1996-02-23 17:19 ` Wes Hardaker 1996-02-24 7:44 ` Lars Magne Ingebrigtsen 1996-02-24 9:26 ` d. hall 1996-02-26 18:01 ` Stephen Peters 1996-02-26 18:12 ` Wes Hardaker 1996-02-23 1:39 ` Steven L Baur 1996-02-23 17:24 ` Wes Hardaker 1996-02-23 21:57 ` Mark Denovich 1996-02-24 7:44 ` Lars Magne Ingebrigtsen 1996-02-24 22:08 ` dynamic ip (Re: Gnus Memory usage) Felix Lee 1996-02-24 22:33 ` Lars Magne Ingebrigtsen 1996-02-25 0:35 ` Felix Lee 1996-02-21 17:59 ` Gnus Memory usage Mark Borges
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).