"seen" marks create adjacent lists

"seen" marks create adjacent lists

[Karl Kleinpaste]

I've been experimenting a bit with seeing what happens to .newsrc.eld
regarding certain parameters, so I've been saving and formatting
.newsrc.eld at various points, so as to diff them.

I've noticed that "seen" marks have a pronounced tendency to create
pointlessly adjacent number lists, rather than subsuming new items
into existing lists.  Here's an example:

@@ -1389,9 +1390,10 @@
            (90348 . 90351)))
          (nntp "news"))
         ("nntp+news:comp.protocols.dns.bind" 3
-         ((1 . 106775))
+         ((1 . 106777))
          ((seen
-           (105429 . 106775)))
+           (105429 . 106776)
+           106777))
          (nntp "news"))
         ("nntp+news:comp.protocols.dns.ops" 3
          ((1 . 93004))

Before this particular run of Gnus, I'd seen up through 106775.  When
I ran Gnus, there were 2 articles there, which I read (or at least
used `d' on), and Gnus correctly identifies that I've seen up through
106777 now.

But notice that the "seen" list has gone from a single cons up to
106775, to a cons up to 106776 *plus* a straggler 106777.

What's the point of that?  It seems to me that this should have
resulted in a single cons (105429 . 106777).  And in fact when I
hand-edit .newsrc.eld to reflect this, it works just fine.

In some very busy groups I read, this has induced some really
impressively large "seen" lists, all numerically adjacent.

--karl

Re: "seen" marks create adjacent lists

[Lars Magne Ingebrigtsen]

Karl Kleinpaste <karl@charcoal.com> writes:

> I've noticed that "seen" marks have a pronounced tendency to create
> pointlessly adjacent number lists, rather than subsuming new items
> into existing lists.  Here's an example:

[...]

> -           (105429 . 106775)))
> +           (105429 . 106776)
> +           106777))
>           (nntp "news"))
>          ("nntp+news:comp.protocols.dns.ops" 3
>           ((1 . 93004))
>
> Before this particular run of Gnus, I'd seen up through 106775.  When
> I ran Gnus, there were 2 articles there, which I read (or at least
> used `d' on), and Gnus correctly identifies that I've seen up through
> 106777 now.

This must be a bug in the range handling functions...  Hm...

This is the code that does the updating:

	(when (eq (cdr type) 'seen)
	  (setq list
		(if list
		    (gnus-range-add (gnus-uncompress-sequence list) 
				    gnus-newsgroup-unseen)
		  (gnus-compress-sequence gnus-newsgroup-articles))))

First of all -- we see that the code is wonky.  It uncompresses the
range of seen articles, which will give us a rather huge list of
articles after a while.

However:

(gnus-range-add (gnus-uncompress-sequence '((105429 . 106775)))
                '(106776 106777))
=>
((105429 . 106777))

It does seem to give us the right results.  Can you reproduce this
error?

Removing the uncompress thing gives us the same answer.

(gnus-range-add '((105429 . 106775))
                '(106776 106777))
=>
((105429 . 106777))                

(I've now done this in the source as well.)

> In some very busy groups I read, this has induced some really
> impressively large "seen" lists, all numerically adjacent.

I've looked over my .newsrc.eld file, and I don't see that.  However,
I do see lots of huge seen lists, with an article missing here and
there, and that's probably due to cross-post handling.  And, looking
over the code, I see that I've forgotten to write code to remove seen
ranges outside the range of active articles.  I've now fixed this as
well. 

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: "seen" marks create adjacent lists

[Simon Josefsson]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Karl Kleinpaste <karl@charcoal.com> writes:
>
>> I've noticed that "seen" marks have a pronounced tendency to create
>> pointlessly adjacent number lists, rather than subsuming new items
>> into existing lists.  Here's an example:
>
> [...]
>
>> -           (105429 . 106775)))
>> +           (105429 . 106776)
>> +           106777))
>>           (nntp "news"))
>>          ("nntp+news:comp.protocols.dns.ops" 3
>>           ((1 . 93004))
>>
>> Before this particular run of Gnus, I'd seen up through 106775.  When
>> I ran Gnus, there were 2 articles there, which I read (or at least
>> used `d' on), and Gnus correctly identifies that I've seen up through
>> 106777 now.
>
> This must be a bug in the range handling functions...  Hm...
>
> This is the code that does the updating:
>
> 	(when (eq (cdr type) 'seen)
> 	  (setq list
> 		(if list
> 		    (gnus-range-add (gnus-uncompress-sequence list) 
> 				    gnus-newsgroup-unseen)
> 		  (gnus-compress-sequence gnus-newsgroup-articles))))
>
> First of all -- we see that the code is wonky.  It uncompresses the
> range of seen articles, which will give us a rather huge list of
> articles after a while.
>
> However:
>
> (gnus-range-add (gnus-uncompress-sequence '((105429 . 106775)))
>                 '(106776 106777))
> =>
> ((105429 . 106777))
>
> It does seem to give us the right results.  Can you reproduce this
> error?

FWIW, the code didn't used to look that way.  It used to look like:

		(if list
		    (gnus-add-to-range list gnus-newsgroup-unseen)
		  (gnus-compress-sequence gnus-newsgroup-articles))))

which breaks in this case:

(gnus-add-to-range '(1 2 3 4) '(5 6 7))
=> ((1 . 2) (3 . 4) (5 . 7))

which is what accidently happened, since `push' was used to populate
`gnus-newsgroup-unseen'.  I think I fixed this on 200-12-27.

> Removing the uncompress thing gives us the same answer.
>
> (gnus-range-add '((105429 . 106775))
>                 '(106776 106777))
> =>
> ((105429 . 106777))                
>
> (I've now done this in the source as well.)

People that have been running with the old code might have bad ranges
which the `gnus-uncompress-range' would fix though.  Bud it is
probably better not to cater for that.