Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not

[Kevin Greiner <kgreiner@xpediantsolutions.com>]

Marcus Frings <iam-est-hora-surgere@despammed.com> writes:

> * Mark Plaksin <happy@mcplaksin.org> wrote:
>
>>>> Please verify that this buffer contains, at least, one occurrance of
>>>> "DISCREPENCY LOCATED".  If it does, please send the contents of this
>>>> buffer to me.
>
>> I didn't get any occurrences :(  In case it's useful, the (160k) output
>> is here: http://mcplaksin.org/happy/kjg.txt
>
> Well, I had some of these. Don't know what this means. :-)

To answer your question, it means that the old, and new, algorithms
disagreed as to the type (primary, secondary, foreign) of the group's
server.  This supports your position that the new algorithm changed
the behavior of gnus.

So the question is, did the new algorithm introduce a new bug or fix
an old bug (one that you were incidentally depending on)?

Here's the debug for one of the groups (I changed the IP # just to
confuse any casual readers).

Beginning Test on Group nnimap+192.168.0.1:INBOX.Mark
method = nnimap:192.168.0.1

cmethod = (nnimap:192.168.0.1 nnimap 192.168.0.1 
  (nnimap-address 192.168.0.1)
  (nnimap-authinfo-file ~/.authinfo)
  (nnimap-stream ssl)
  (nnimap-list-pattern INBOX.*))

method = (nnimap 192.168.0.1 
  (nnimap-address 192.168.0.1)
  (nnimap-authinfo-file ~/.authinfo)
  (nnimap-stream ssl)
  (nnimap-list-pattern INBOX.*))
method[(nnimap 192.168.0.1 
          (nnimap-address 192.168.0.1)
          (nnimap-authinfo-file ~/.authinfo)
          (nnimap-stream ssl)
          (nnimap-list-pattern INBOX.*))]
 entry in type-cache = 
  ((nnimap 192.168.0.1 
      (nnimap-address 192.168.0.1)
      (nnimap-authinfo-file ~/.authinfo)
      (nnimap-stream ssl)
      (nnimap-list-pattern INBOX.*)) .
 secondary)
method-type = secondary
Need to calc method type is nil
new-results = nil
Beginning old solution
method = nnimap:192.168.0.1
method = (nnimap 192.168.0.1)
not equal = t
not secondary method = t
old-results = t
DISCREPENCY LOCATED: old-results = t new-results = nil

Now, to explain what this means.  By the debug, the value of
old-results was t so this expression evaluates to true.

(and (setq method (gnus-info-method info))
     (not (inline
	    (gnus-server-equal
	     gnus-select-method
	     (setq method (gnus-server-get-method nil method)))))
     (not (gnus-secondary-method-p method)))

The pseudo-code for this expression is

 (AND ... Have a non-nil method (The nil method is equivalent to the primary) ...
      (NOT ... Equal to the primary (gnus-select-method) method ...)
      (NOT ... Any of the known secondary methods ...))

or

The old algorithm concluded that this group was foreign.

Marcus, in your very first message (dated 18 Jan), you listed your
config as:

(setq gnus-secondary-select-methods
      '((nnimap "192.168.0.1"
		(nnimap-address "192.168.0.1")
		(nnimap-authinfo-file "~/.authinfo")
		(nnimap-stream ssl)
		(nnimap-list-pattern "INBOX.*")
		)))

This means that the (nnimap "192.168.0.1" ...) method shown in the
debug is a SECONDARY method.  This clearly shows that the old code was
buggy and that Lars new code fixed the bug.

As for your problem, gnus is certainly following a different branch in
the code.  You could be triggering either a latent bug in that code
or, the more likely, it's something in your configuration.

So let's take the easy path.  Open the gnus-start.el file and search
for ";; These groups are native or secondary.".  Insert this
expression after this line.

(when (equal (gnus-info-group info) "nnimap+192.168.0.1:INBOX.Mark")
  (debug))

Eval the buffer (don't compile it) then fetch the groups.  When the
debugger starts, use the 'c' and 'd' commands to step through the
gnus-get-unread-articles function.  Don't bother going to deep into the
functions it calls.  What you really want to know is which branch of
the cond is executed.

Here's the only issue left concerning Lars' code.  The value of the
variable 'method' is different.  In the old code, the variable
identified which method but none of the method parameters.  In the new
code, method identifies the fully-qualified method.  This should NOT
cause a problem.  However, your stepping though this code may tell a
different story.

Personally, my bet is that gnus is evaluating
(> (gnus-info-level info) level) as true.


Now then Mark, I suspect that you've been reading along so far.  Your
test results indicate that you didn't get any of the "DISCREPENCY
LOCATED" messages. That indicates that your problem is probably due to
'method' having a different value.  Hmmm... Didn't I just say that
that wasn't an issue?  This job just isn't fun anymore.

Gnus should be adding your groups to retrieve-groups. So, add the
debug expression shown above (with a suitable group name) then please
step through the code to see when it branched past the
(push (list method group) retrieve-groups) statement.

Thanks,
Kevin