* New agent code @ 2002-11-25 2:13 Henrik Enberg 2002-11-25 2:42 ` Henrik Enberg ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Henrik Enberg @ 2002-11-25 2:13 UTC (permalink / raw) The new agent code seems to be utterly hosed. It downloads all articles on the server every time I do `J s', it expires every article ever fetched except the very last when I do M-x gnus-agent-expire, and when I try to enter an agentized group I get an error "can't select group $FOO" where $FOO is the contents of the .overview for that group. This is with a started from scratch setup, so there's no old stuff lying about. Where do I go from here? ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: New agent code 2002-11-25 2:13 New agent code Henrik Enberg @ 2002-11-25 2:42 ` Henrik Enberg 2002-11-25 3:12 ` Henrik Enberg 2002-11-25 3:54 ` Katsumi Yamaoka 2002-11-25 7:30 ` Kai Großjohann 2 siblings, 1 reply; 22+ messages in thread From: Henrik Enberg @ 2002-11-25 2:42 UTC (permalink / raw) I wrote: > The new agent code seems to be utterly hosed. It downloads all articles > on the server every time I do `J s', it expires every article ever > fetched except the very last when I do M-x gnus-agent-expire, and when I > try to enter an agentized group I get an error "can't select group $FOO" > where $FOO is the contents of the .overview for that group. I have now gotten things to work slightly better. By going back to Gnus 5.9, subscribing there and updating to Oort it mostly works. The only breakage I currently see is that it still expires all but the last article when doing gnus-agent-expire. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: New agent code 2002-11-25 2:42 ` Henrik Enberg @ 2002-11-25 3:12 ` Henrik Enberg 2002-11-25 7:31 ` Kai Großjohann 0 siblings, 1 reply; 22+ messages in thread From: Henrik Enberg @ 2002-11-25 3:12 UTC (permalink / raw) > I wrote: > The only breakage I currently see is that it still expires all but > the last article when doing gnus-agent-expire. I spoke too soon. It doesn't actually expire the articles, it just removes them from the .overview. This isn't intended behavior, is it? Anyway, I can get them back with gnus-agent-regenerate which is a wonderful thing to have working. Also, the agent seems to be a lot snappier now. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: New agent code 2002-11-25 3:12 ` Henrik Enberg @ 2002-11-25 7:31 ` Kai Großjohann 2002-11-26 3:17 ` Kevin Greiner 0 siblings, 1 reply; 22+ messages in thread From: Kai Großjohann @ 2002-11-25 7:31 UTC (permalink / raw) Henrik Enberg <henrik@enberg.org> writes: >> I wrote: >> The only breakage I currently see is that it still expires all but >> the last article when doing gnus-agent-expire. > > I spoke too soon. It doesn't actually expire the articles, it just > removes them from the .overview. This isn't intended behavior, is > it? No, this is not intended behavior. It should only remove from overview the ones that it actually deletes. I didn't test gnus-agent-expire. Sorry. kai -- ~/.signature is: umop ap!sdn (Frank Nobis) ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: New agent code 2002-11-25 7:31 ` Kai Großjohann @ 2002-11-26 3:17 ` Kevin Greiner 2002-11-26 7:30 ` Kai Großjohann 0 siblings, 1 reply; 22+ messages in thread From: Kevin Greiner @ 2002-11-26 3:17 UTC (permalink / raw) [-- Attachment #1: Type: text/plain, Size: 783 bytes --] Kai Großjohann wrote: >Henrik Enberg <henrik@enberg.org> writes: > > > >>>I wrote: >>>The only breakage I currently see is that it still expires all but >>>the last article when doing gnus-agent-expire. >>> >>> >> I spoke too soon. It doesn't actually expire the articles, it just >> removes them from the .overview. This isn't intended behavior, is >> it? >> >> > >No, this is not intended behavior. It should only remove from >overview the ones that it actually deletes. > >I didn't test gnus-agent-expire. Sorry. > >kai > > First, gnus-agent-expire has been tested. Second, read-unmarked articles are removed from the .overview. You wouldn't happen to have gnus-agent-expire-all set? If so, you'll get the behavior that you are describing. Kevin [-- Attachment #2: Type: text/html, Size: 1355 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: New agent code 2002-11-26 3:17 ` Kevin Greiner @ 2002-11-26 7:30 ` Kai Großjohann 2002-11-27 10:47 ` Denis Yakovlev 0 siblings, 1 reply; 22+ messages in thread From: Kai Großjohann @ 2002-11-26 7:30 UTC (permalink / raw) Kevin Greiner <kgreiner@xpediantsolutions.com> writes: > First, gnus-agent-expire has been tested. Sorry, I didn't mean to imply that you didn't test it. > Second, read-unmarked articles are removed from the .overview. You > wouldn't happen to have gnus-agent-expire-all set? If so, you'll > get the behavior that you are describing. Not that it's relevant, as I never invoked agent expiry, but I do have it set to t. So I think I should change it just in case I happen to invoke agent expiry... kai -- ~/.signature is: umop ap!sdn (Frank Nobis) ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: New agent code 2002-11-26 7:30 ` Kai Großjohann @ 2002-11-27 10:47 ` Denis Yakovlev 2002-11-27 17:52 ` Kevin Greiner 0 siblings, 1 reply; 22+ messages in thread From: Denis Yakovlev @ 2002-11-27 10:47 UTC (permalink / raw) kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes: > Kevin Greiner <kgreiner@xpediantsolutions.com> writes: >> Second, read-unmarked articles are removed from the .overview. You >> wouldn't happen to have gnus-agent-expire-all set? If so, you'll >> get the behavior that you are describing. > > Not that it's relevant, as I never invoked agent expiry, but I do > have it set to t. So I think I should change it just in case I > happen to invoke agent expiry... gnus-agent-expire-all set to nil. gnus-agent-expire removes articles older than gnus-agent-expire-days from disk (as it should), but removes almost all articles from .overview (1--3 articles remain). -- Denis K.Y. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: New agent code 2002-11-27 10:47 ` Denis Yakovlev @ 2002-11-27 17:52 ` Kevin Greiner 2002-11-27 19:46 ` Denis Yakovlev 2002-11-27 21:29 ` Kai Großjohann 0 siblings, 2 replies; 22+ messages in thread From: Kevin Greiner @ 2002-11-27 17:52 UTC (permalink / raw) Denis Yakovlev wrote: >kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes: > > > >>Kevin Greiner <kgreiner@xpediantsolutions.com> writes: >> >> > > > >>>Second, read-unmarked articles are removed from the .overview. You >>>wouldn't happen to have gnus-agent-expire-all set? If so, you'll >>>get the behavior that you are describing. >>> >>> >>Not that it's relevant, as I never invoked agent expiry, but I do >>have it set to t. So I think I should change it just in case I >>happen to invoke agent expiry... >> >> > >gnus-agent-expire-all set to nil. >gnus-agent-expire removes articles older than gnus-agent-expire-days >from disk (as it should), but removes almost all articles from .overview >(1--3 articles remain). > > > The intended behavior is as follows: If an article was fetched into the agent's cache, then the article's header will be removed from the overview at the same time as the article is expired. If an article was never fetched, then the article's header will be removed from the overview if the article is marked as read but not marked as ticked nor dormant. If an article is in the overview, but not in the agentview, remove it from the overview. The first rule is probably obvious. The second rule exists because gnus-agent doesn't currently keep a timestamp on when a header was fetched. As a result, I can't expire just a header using gnus-agent-expire-days. The third rule cleans up an overview that has gotten out-of-sync with its agentview. I haven't seen this behavior in my testing so we're going to have to play 20 questions. 1) Did you call gnus-agent-expire using t as the first argument? The first argument is the list of articles to expire. When set to t, this list is interpreted as ALL articles. If you want to expire only unread articles, set it to nil. 2) Have you tried using gnus-agent-regenerate-group to repair this group's overview and agentview files? If so, did gnus-agent-expire then function as desired? If gnus-agent-expire is now behaving correctly, the problem was mostly likely an out-of-date agentview file. The new agent code requires that the contents of the agentview and overview files be synchronized at all times. This is enforced by the new code but the old version didn't work quite as well. 3) Do you want to see read articles in your summary? If so, can you provide any addition criteria for retaining an article header in the overview? Kevin ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: New agent code 2002-11-27 17:52 ` Kevin Greiner @ 2002-11-27 19:46 ` Denis Yakovlev 2002-11-27 21:29 ` Kai Großjohann 1 sibling, 0 replies; 22+ messages in thread From: Denis Yakovlev @ 2002-11-27 19:46 UTC (permalink / raw) Kevin Greiner <kgreiner@xpediantsolutions.com> writes: [...] > 1) Did you call gnus-agent-expire using t as the first argument? The > first argument is the list of articles to expire. When set to t, this > list is interpreted as ALL articles. If you want to expire only > unread articles, set it to nil. ^^^^^^ --- "if ARTICLES is null, all read and unmarked articles" ? Usually I just M-x gnus-agent-expire. Checked --- the first argument is really nil. > 2) Have you tried using gnus-agent-regenerate-group to repair this > group's overview and agentview files? If so, did gnus-agent-expire > then function as desired? If gnus-agent-expire is now behaving > correctly, the problem was mostly likely an out-of-date agentview > file. The new agent code requires that the contents of the agentview > and overview files be synchronized at all times. This is enforced by > the new code but the old version didn't work quite as well. gnus-agent-regenerate-group works very well. M-x gnus-agent-expire M-x gnus-agent-regenerate And the job is done. But next time I call gnus-agent-expire the probmlem is here again. By the way, I've tryed to remove .agentview. In this case I've got: Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil) <(126736 nil) (cond ((not n) (when o ...)) ((< ... ...) (setcdr n ...))) (let ((n ...) (o ...)) (cond (... ...) (... ...))) (if gnus-agent-consider-all-articles (let* (... ... ...) (while o ...) (setq alist ...)) (let (... ...) (cond ... ...))) (save-current-buffer (set-buffer temp-buffer) (if (file-exists-p file) (let ... ...)) (set-buffer-modified-p nil) (let (...) (while load ... ... ... ...)) (gnus-agent-check-overview-buffer) (while (or downloaded nov-arts) (cond ... ... ...)) (if gnus-agent-consider-all-articles (let* ... ... ...) (let ... ...)) (if (setq regenerated ...) (let ... ...))) (with-current-buffer temp-buffer (if (file-exists-p file) (let ... ...)) (set-buffer-modified-p nil) (let (...) (while load ... ... ... ...)) (gnus-agent-check-overview-buffer) (while (or downloaded nov-arts) (cond ... ... ...)) (if gnus-agent-consider-all-articles (let* ... ... ...) (let ... ...)) (if (setq regenerated ...) (let ... ...))) (unwind-protect (with-current-buffer temp-buffer (if ... ...) (set-buffer-modified-p nil) (let ... ...) (gnus-agent-check-overview-buffer) (while ... ...) (if gnus-agent-consider-all-articles ... ...) (if ... ...)) (and (buffer-name temp-buffer) (kill-buffer temp-buffer))) (let ((temp-buffer ...)) (unwind-protect (with-current-buffer temp-buffer ... ... ... ... ... ... ...) (and ... ...))) (with-temp-buffer (if (file-exists-p file) (let ... ...)) (set-buffer-modified-p nil) (let (...) (while load ... ... ... ...)) (gnus-agent-check-overview-buffer) (while (or downloaded nov-arts) (cond ... ... ...)) (if gnus-agent-consider-all-articles (let* ... ... ...) (let ... ...)) (if (setq regenerated ...) (let ... ...))) (let (default-enable-multibyte-characters) (with-temp-buffer (if ... ...) (set-buffer-modified-p nil) (let ... ...) (gnus-agent-check-overview-buffer) (while ... ...) (if gnus-agent-consider-all-articles ... ...) (if ... ...))) (mm-with-unibyte-buffer (if (file-exists-p file) (let ... ...)) (set-buffer-modified-p nil) (let (...) (while load ... ... ... ...)) (gnus-agent-check-overview-buffer) (while (or downloaded nov-arts) (cond ... ... ...)) (if gnus-agent-consider-all-articles (let* ... ... ...) (let ... ...)) (if (setq regenerated ...) (let ... ...))) (let* ((gnus-command-method ...) (file ...) (dir ...) point (downloaded ...) dl nov-arts alist header regenerated) (mm-with-unibyte-buffer (if ... ...) (set-buffer-modified-p nil) (let ... ...) (gnus-agent-check-overview-buffer) (while ... ...) (if gnus-agent-consider-all-articles ... ...) (if ... ...)) (setq regenerated (or regenerated ... ...)) (setq gnus-agent-article-alist alist) (when regenerated (gnus-agent-save-alist group)) (when (and reread gnus-agent-article-alist) (gnus-make-ascending-articles-unread group ...) (when ... ... ...)) regenerated) gnus-agent-regenerate-group("relcom.games") eval((gnus-agent-regenerate-group "relcom.games")) eval-last-sexp-1(t) eval-last-sexp(t) eval-print-last-sexp() call-interactively(eval-print-last-sexp) > 3) Do you want to see read articles in your summary? If so, can you > provide any addition criteria for retaining an article header in the > overview? Kevin Well, headers for all articles not older than gnus-agent-expire-days must be in .overview. It is a simplest solution, I believe. -- Denis K.Y. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: New agent code 2002-11-27 17:52 ` Kevin Greiner 2002-11-27 19:46 ` Denis Yakovlev @ 2002-11-27 21:29 ` Kai Großjohann 2002-11-28 5:51 ` Kevin Greiner 1 sibling, 1 reply; 22+ messages in thread From: Kai Großjohann @ 2002-11-27 21:29 UTC (permalink / raw) Kevin Greiner <kgreiner@xpediantsolutions.com> writes: > The intended behavior is as follows: > If an article was fetched into the agent's cache, then the article's > header will be removed from the overview at the same time as the > article is expired. > If an article was never fetched, then the article's header will be > removed from the overview if the article is marked as read but not > marked as ticked nor dormant. > If an article is in the overview, but not in the agentview, remove it > from the overview. > > The first rule is probably obvious. The second rule exists because > gnus-agent doesn't currently keep a timestamp on when a header was > fetched. As a result, I can't expire just a header using > gnus-agent-expire-days. The third rule cleans up an overview that has > gotten out-of-sync with its agentview. Does the rest of the expiry code go by the fetched date or by the article date? Normal (mail) expiry also confuses these two times (date header of message; timestamp of nnml file on disk; time when user hits E -- Kai can't cound). So maybe it's not so bad when the agent does the same. But OTOH, if the articles are expired by elapsed time since fetching and the headers are expired by elapsed time since their date, that would be strange. Hm. -- ~/.signature is: umop ap!sdn (Frank Nobis) ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: New agent code 2002-11-27 21:29 ` Kai Großjohann @ 2002-11-28 5:51 ` Kevin Greiner 2002-11-28 18:24 ` Denis Yakovlev 0 siblings, 1 reply; 22+ messages in thread From: Kevin Greiner @ 2002-11-28 5:51 UTC (permalink / raw) Kai Großjohann wrote: >Kevin Greiner <kgreiner@xpediantsolutions.com> writes: > > > >>The intended behavior is as follows: >>If an article was fetched into the agent's cache, then the article's >>header will be removed from the overview at the same time as the >>article is expired. >>If an article was never fetched, then the article's header will be >>removed from the overview if the article is marked as read but not >>marked as ticked nor dormant. >>If an article is in the overview, but not in the agentview, remove it >>from the overview. >> >>The first rule is probably obvious. The second rule exists because >>gnus-agent doesn't currently keep a timestamp on when a header was >>fetched. As a result, I can't expire just a header using >>gnus-agent-expire-days. The third rule cleans up an overview that has >>gotten out-of-sync with its agentview. >> >> > >Does the rest of the expiry code go by the fetched date or by the >article date? > >Normal (mail) expiry also confuses these two times (date header of >message; timestamp of nnml file on disk; time when user hits E -- Kai >can't cound). So maybe it's not so bad when the agent does the >same. > >But OTOH, if the articles are expired by elapsed time since >fetching and the headers are expired by elapsed time since their >date, that would be strange. > >Hm. > > > Actually, there is no elapse time on the headers. If you fetch an article then the article and header are expired after the elapse time since fetching. If you have just the header, it can be expired as soon as it has been read. My thoughts were that you would only expire a group when recovering disk space outweighed the deletion of read headers. Of course, those headers could still be recovered by refetching the headers from the server. I just took a look back at the gnus-agent-expire prior to my changes. The code is rather convoluted. It is quite possible that NOV entries were only expirable if you had first fetched the article. It appears that if you had fetched the article AND the expiration elapse time was reached, the NOV entries would be deleted when any of the following were true. 1) the article ID preceded the current active range 2) gnus-agent-expire-all is set 3) The article is read and not marked as ticked or dormant. I suspect that this behavior is probably close to being acceptable. From what I've seen in the preceding posts, some people are seeing a different behavior. One that is not intended. I'm just going to need more information before I can nail down what is wrong. BTW, I'm going to be offline until the 30th or 31st so please be patient with me. Kevin ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: New agent code 2002-11-28 5:51 ` Kevin Greiner @ 2002-11-28 18:24 ` Denis Yakovlev 0 siblings, 0 replies; 22+ messages in thread From: Denis Yakovlev @ 2002-11-28 18:24 UTC (permalink / raw) Kevin Greiner <kgreiner@xpediantsolutions.com> writes: [...] > I just took a look back at the gnus-agent-expire prior to my changes. > The code is rather convoluted. It is quite possible that NOV entries > were only expirable if you had first fetched the article. It appears > that if you had fetched the article AND the expiration elapse time was > reached, the NOV entries would be deleted when any of the following > were true. > > 1) the article ID preceded the current active range > 2) gnus-agent-expire-all is set > 3) The article is read and not marked as ticked or dormant. > > I suspect that this behavior is probably close to being acceptable. > From what I've seen in the preceding posts, some people are seeing a > different behavior. One that is not intended. I'm just going to need > more information before I can nail down what is wrong. This behavior is not "probably close to being acceptable", it _is_ acceptable, I believe. Expiration (deletion from disk) of articles works as described. Expiration of headers is the problem --- it happens immediately. AND form not working. Maybe I'm an idiot. But in the beginning of this thread was the very same problem. Initially I thought of trivial "me too" posting... > BTW, I'm going to be offline until the 30th or 31st so please be > patient with me. Please be patient with us, with me particularly :) Great work. -- Denis K.Y. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: New agent code 2002-11-25 2:13 New agent code Henrik Enberg 2002-11-25 2:42 ` Henrik Enberg @ 2002-11-25 3:54 ` Katsumi Yamaoka 2002-11-25 7:25 ` Kai Großjohann 2002-11-25 7:30 ` Kai Großjohann 2 siblings, 1 reply; 22+ messages in thread From: Katsumi Yamaoka @ 2002-11-25 3:54 UTC (permalink / raw) Cc: ding Hi, Excuse me for a noise, but please don't forget XEmacs users. >>>>> In <87el9a4cro.fsf@enberg.org> >>>>> Henrik Enberg <henrik@enberg.org> wrote: > The new agent code seems to be utterly hosed... While compiling latest Gnus using XEmacs, the byte-compiler complains as follows: While compiling gnus-agent-check-overview-buffer in file /Work/gnus/lisp/gnus-agent.el: ** reference to free variable deactivate-mark While compiling the end of the data: ** the function number-at-point is not known to be defined. The variable deactivate-mark isn't available in XEmacs. The function number-at-point is provided by fsf-compat/thingatpt.el but is not autoloaded. Is the use of thingatpt.el really necessary? In addition, IMHO, the new gnus-agent.el should be re-indented for the whole contents on the condition that indent-tabs-mode is t, and all trailing whitespaces should be removed. -- Katsumi Yamaoka <yamaoka@jpl.org> ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: New agent code 2002-11-25 3:54 ` Katsumi Yamaoka @ 2002-11-25 7:25 ` Kai Großjohann 2002-11-25 20:11 ` David S Goldberg 0 siblings, 1 reply; 22+ messages in thread From: Kai Großjohann @ 2002-11-25 7:25 UTC (permalink / raw) Katsumi Yamaoka <yamaoka@jpl.org> writes: > While compiling latest Gnus using XEmacs, the byte-compiler > complains as follows: > > While compiling gnus-agent-check-overview-buffer in file /Work/gnus/lisp/gnus-agent.el: > ** reference to free variable deactivate-mark > While compiling the end of the data: > ** the function number-at-point is not known to be defined. It seems all these are in gnus-agent-check-overview-buffer. This function is intended to function as a sanity check until more testing determines that everything works correctly. Under these circumstances, maybe it is okay to require FSF compat code? kai -- ~/.signature is: umop ap!sdn (Frank Nobis) ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: New agent code 2002-11-25 7:25 ` Kai Großjohann @ 2002-11-25 20:11 ` David S Goldberg 2002-11-25 20:32 ` Kai Großjohann 0 siblings, 1 reply; 22+ messages in thread From: David S Goldberg @ 2002-11-25 20:11 UTC (permalink / raw) [-- Attachment #1: Type: text/plain, Size: 1308 bytes --] >>>>> On Mon, 25 Nov 2002 08:25:00 +0100, >>>>> kai.grossjohann@uni-duisburg.de (Kai Großjohann) said: > Katsumi Yamaoka <yamaoka@jpl.org> writes: >> While compiling latest Gnus using XEmacs, the byte-compiler >> complains as follows: >> >> While compiling gnus-agent-check-overview-buffer in file /Work/gnus/lisp/gnus-agent.el: >> ** reference to free variable deactivate-mark >> While compiling the end of the data: >> ** the function number-at-point is not known to be defined. > It seems all these are in gnus-agent-check-overview-buffer. This > function is intended to function as a sanity check until more testing > determines that everything works correctly. > Under these circumstances, maybe it is okay to require FSF compat > code? Well doing that and setting deactivate-mark to nil eliminated the errors associated with undefined variables and functions, it resulted in another problem, the attached backtrace which I got when I tried to enter an nnimap folder with unread messages in it. I was able to enter a folder that did not have any unread messages in it, however. Anyway, for now I am using the previous version of gnus-agent.el so I can function at all. Any advice that will allow me to keep up to date (or an updated gnus-agent.el, of course :-) would be greatly appreciated. [-- Attachment #2: Type: text/plain, Size: 1449 bytes --] nil gnus-agent-check-overview-buffer() gnus-agent-retrieve-headers((11665 11673 11927 12064 12066 12158 12171 12172 12174 12176 12182 12185 12187 12188 12190 12243 12326 12328 12330 12334 12340 12351 12356 12369 12372 12404 12414 12421 12429 12430 12431 12433 12436 12438 12440 12441 12442 12443 12451 12457 12460 12476 12477 12485 12489 12502 12506 12509 12510 12512 12519 ...) "nnimap+linus:INBOX.in-box" some) gnus-retrieve-headers((11665 11673 11927 12064 12066 12158 12171 12172 12174 12176 12182 12185 12187 12188 12190 12243 12326 12328 12330 12334 12340 12351 12356 12369 12372 12404 12414 12421 12429 12430 12431 12433 12436 12438 12440 12441 12442 12443 12451 12457 12460 12476 12477 12485 12489 12502 12506 12509 12510 12512 12519 ...) "nnimap+linus:INBOX.in-box" some) gnus-fetch-headers((11665 11673 11927 12064 12066 12158 12171 12172 12174 12176 12182 12185 12187 12188 12190 12243 12326 12328 12330 12334 12340 12351 12356 12369 12372 12404 12414 12421 12429 12430 12431 12433 12436 12438 12440 12441 12442 12443 12451 12457 12460 12476 12477 12485 12489 12502 12506 12509 12510 12512 12519 ...)) gnus-select-newsgroup("nnimap+linus:INBOX.in-box" nil nil) gnus-summary-read-group-1("nnimap+linus:INBOX.in-box" nil nil nil nil nil) gnus-summary-read-group("nnimap+linus:INBOX.in-box" nil nil nil nil nil nil) gnus-group-read-group(nil nil nil) gnus-topic-read-group(nil) call-interactively(gnus-topic-read-group) [-- Attachment #3: Type: text/plain, Size: 55 bytes --] Thanks, -- Dave Goldberg david.goldberg6@verizon.net ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: New agent code 2002-11-25 20:11 ` David S Goldberg @ 2002-11-25 20:32 ` Kai Großjohann 2002-11-26 14:43 ` David S Goldberg 0 siblings, 1 reply; 22+ messages in thread From: Kai Großjohann @ 2002-11-25 20:32 UTC (permalink / raw) David S Goldberg <david.goldberg6@verizon.net> writes: > Well doing that and setting deactivate-mark to nil eliminated the > errors associated with undefined variables and functions, it resulted > in another problem, the attached backtrace which I got when I tried to > enter an nnimap folder with unread messages in it. I was able to > enter a folder that did not have any unread messages in it, however. Ah, the backtrace appears to come from the checking code. Just hit `c'. Of course, it's not practical to hit `c' very often, but it can help in finding the problem that led to the overview buffer being out of whack. I've now added stuff to the code so that it will tell you which of the two debug statements were called. HTH. kai -- ~/.signature is: umop ap!sdn (Frank Nobis) ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: New agent code 2002-11-25 20:32 ` Kai Großjohann @ 2002-11-26 14:43 ` David S Goldberg 2002-11-26 15:11 ` Kai Großjohann 0 siblings, 1 reply; 22+ messages in thread From: David S Goldberg @ 2002-11-26 14:43 UTC (permalink / raw) >>>>> On Mon, 25 Nov 2002 21:32:54 +0100, >>>>> kai.grossjohann@uni-duisburg.de (Kai Großjohann) said: > David S Goldberg <david.goldberg6@verizon.net> writes: >> Well doing that and setting deactivate-mark to nil eliminated the >> errors associated with undefined variables and functions, it resulted >> in another problem, the attached backtrace which I got when I tried to >> enter an nnimap folder with unread messages in it. I was able to >> enter a folder that did not have any unread messages in it, however. > Ah, the backtrace appears to come from the checking code. Just hit > `c'. Sadly that didn't work. I kept getting the same backtrace for each c I hit. On the plus side, after a cvs update this morning, I no longer have the back trace problem, but my inbox folder is messed up. The group buffer properly shows that there are new messages, but when I enter the buffer, I can't see them unless I explicitly jump to them (good thing I show article numbers in my summary line format). It doesn't happen in several other groups, so I figured something might be wrong with the agent overview file. I tried running gnus-agent-regenerate and got this backtrace: Signaling: (wrong-type-argument number-char-or-marker-p nil) gnus-agent-regenerate-group("nnimap+linus:INBOX.in-box" nil) gnus-agent-regenerate(nil) call-interactively(gnus-agent-regenerate) command-execute(gnus-agent-regenerate t) execute-extended-command(nil) call-interactively(execute-extended-command) Thanks, -- Dave Goldberg david.goldberg6@verizon.net ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: New agent code 2002-11-26 14:43 ` David S Goldberg @ 2002-11-26 15:11 ` Kai Großjohann 2002-12-03 14:18 ` David S Goldberg 0 siblings, 1 reply; 22+ messages in thread From: Kai Großjohann @ 2002-11-26 15:11 UTC (permalink / raw) David S Goldberg <david.goldberg6@verizon.net> writes: >>>>>> On Mon, 25 Nov 2002 21:32:54 +0100, >>>>>> kai.grossjohann@uni-duisburg.de (Kai Großjohann) said: > >> David S Goldberg <david.goldberg6@verizon.net> writes: >>> Well doing that and setting deactivate-mark to nil eliminated the >>> errors associated with undefined variables and functions, it resulted >>> in another problem, the attached backtrace which I got when I tried to >>> enter an nnimap folder with unread messages in it. I was able to >>> enter a folder that did not have any unread messages in it, however. > >> Ah, the backtrace appears to come from the checking code. Just hit >> `c'. > > Sadly that didn't work. I kept getting the same backtrace for each c > I hit. Hm. Lessee now... Ah! There are two backtraces, the "duplicate overview line for 4711" one and the "Overview buffer not sorted" one. Of the former, if you have 10,000 duplicates, you get 10,000 backtraces... Usually, I guess that the whole overview buffer will be duplicated. But the backtrace is a chance to investigate the situation: what have you done just before getting the backtrace? What's the contents of the overview buffer at that time? (You might have to search for a buffer name starting with space.) > On the plus side, after a cvs update this morning, I no longer have > the back trace problem, but my inbox folder is messed up. The group > buffer properly shows that there are new messages, but when I enter > the buffer, I can't see them unless I explicitly jump to them (good > thing I show article numbers in my summary line format). It doesn't > happen in several other groups, so I figured something might be > wrong with the agent overview file. I tried running > gnus-agent-regenerate and got this backtrace: > > Signaling: (wrong-type-argument number-char-or-marker-p nil) > gnus-agent-regenerate-group("nnimap+linus:INBOX.in-box" nil) > gnus-agent-regenerate(nil) > call-interactively(gnus-agent-regenerate) > command-execute(gnus-agent-regenerate t) > execute-extended-command(nil) > call-interactively(execute-extended-command) Could you get a more telling backtrace by loading gnus-agent.el (instead of *.elc)? It seems that some steps are missing in this backtrace. kai -- ~/.signature is: umop ap!sdn (Frank Nobis) ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: New agent code 2002-11-26 15:11 ` Kai Großjohann @ 2002-12-03 14:18 ` David S Goldberg 0 siblings, 0 replies; 22+ messages in thread From: David S Goldberg @ 2002-12-03 14:18 UTC (permalink / raw) With a CVS update as of this morning Tue Dec 3 09:17:20 2002 EST, all my problems with the agent seem to have gone away other than I see some compiler warnings about free variables. Thanks! -- Dave Goldberg david.goldberg6@verizon.net ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: New agent code 2002-11-25 2:13 New agent code Henrik Enberg 2002-11-25 2:42 ` Henrik Enberg 2002-11-25 3:54 ` Katsumi Yamaoka @ 2002-11-25 7:30 ` Kai Großjohann 2002-11-25 16:58 ` Henrik Enberg 2 siblings, 1 reply; 22+ messages in thread From: Kai Großjohann @ 2002-11-25 7:30 UTC (permalink / raw) Henrik Enberg <henrik@enberg.org> writes: > The new agent code seems to be utterly hosed. It downloads all articles > on the server every time I do `J s', Hm. I'm surprised. I don't see this behavior at all. But then, I subscribed to the groups using the old version of gnus-agent. So maybe it is necessary to test this code for people who start using it. kai -- ~/.signature is: umop ap!sdn (Frank Nobis) ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: New agent code 2002-11-25 7:30 ` Kai Großjohann @ 2002-11-25 16:58 ` Henrik Enberg 2002-11-25 20:17 ` Kai Großjohann 0 siblings, 1 reply; 22+ messages in thread From: Henrik Enberg @ 2002-11-25 16:58 UTC (permalink / raw) Cc: ding kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes: > Henrik Enberg <henrik@enberg.org> writes: > >> The new agent code seems to be utterly hosed. It downloads all articles >> on the server every time I do `J s', > > But then, I subscribed to the groups using the old version of > gnus-agent. So maybe it is necessary to test this code for people who > start using it. It is probably a good idea to test this before releasing a sharp version. Then again, I have a sneaking suspicion it just might be my newsserver doing something screwy. I had problems with the last batch agent upgrades too. Anyone else using news.cis.dfn.de? ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: New agent code 2002-11-25 16:58 ` Henrik Enberg @ 2002-11-25 20:17 ` Kai Großjohann 0 siblings, 0 replies; 22+ messages in thread From: Kai Großjohann @ 2002-11-25 20:17 UTC (permalink / raw) Henrik Enberg <henrik@enberg.org> writes: > It is probably a good idea to test this before releasing a sharp > version. Then again, I have a sneaking suspicion it just might be my > newsserver doing something screwy. I had problems with the last > batch agent upgrades too. Hm. How to detect this? Maybe newsserver-screwiness detection should be built in to Gnus. That would be quite useful, I imagine. kai -- ~/.signature is: umop ap!sdn (Frank Nobis) ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2002-12-03 14:18 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-11-25 2:13 New agent code Henrik Enberg 2002-11-25 2:42 ` Henrik Enberg 2002-11-25 3:12 ` Henrik Enberg 2002-11-25 7:31 ` Kai Großjohann 2002-11-26 3:17 ` Kevin Greiner 2002-11-26 7:30 ` Kai Großjohann 2002-11-27 10:47 ` Denis Yakovlev 2002-11-27 17:52 ` Kevin Greiner 2002-11-27 19:46 ` Denis Yakovlev 2002-11-27 21:29 ` Kai Großjohann 2002-11-28 5:51 ` Kevin Greiner 2002-11-28 18:24 ` Denis Yakovlev 2002-11-25 3:54 ` Katsumi Yamaoka 2002-11-25 7:25 ` Kai Großjohann 2002-11-25 20:11 ` David S Goldberg 2002-11-25 20:32 ` Kai Großjohann 2002-11-26 14:43 ` David S Goldberg 2002-11-26 15:11 ` Kai Großjohann 2002-12-03 14:18 ` David S Goldberg 2002-11-25 7:30 ` Kai Großjohann 2002-11-25 16:58 ` Henrik Enberg 2002-11-25 20:17 ` Kai Großjohann
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).