New agent code

New agent code

[Henrik Enberg]

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?

Re: New agent code

[Henrik Enberg]

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.

Re: New agent code

[Henrik Enberg]

> 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.

Re: New agent code

[Kai Großjohann]

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)

Re: New agent code

[Kevin Greiner]

[-- 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 --]

Re: New agent code

[Kai Großjohann]

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)

Re: New agent code

[Denis Yakovlev]

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.

Re: New agent code

[Kevin Greiner]

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

Re: New agent code

[Denis Yakovlev]

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.

Re: New agent code

[Kai Großjohann]

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)

Re: New agent code

[Kevin Greiner]

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

Re: New agent code

[Denis Yakovlev]

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.

Re: New agent code

[Katsumi Yamaoka]

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>

Re: New agent code

[Kai Großjohann]

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)

Re: New agent code

[David S Goldberg]

[-- 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

Re: New agent code

[Kai Großjohann]

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)

Re: New agent code

[David S Goldberg]

>>>>> 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

Re: New agent code

[Kai Großjohann]

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)

Re: New agent code

[David S Goldberg]

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

Re: New agent code

[Kai Großjohann]

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)

Re: New agent code

[Henrik Enberg]

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?

Re: New agent code

[Kai Großjohann]

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)