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

[Marcus Frings <iam-est-hora-surgere@despammed.com>]

* Kevin Greiner <kgreiner@xpediantsolutions.com> wrote:
> 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.

Ah, okay.

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

I also thought in the first place that there could be a bug in my
configuration since I have a pretty large setup which is divided into
many separate files but now I am sure for 100 % that my configuration is
fine because the bug also shows up if I load my gnus_server.el *only*
(and no other Gnus configuration files!). My gnus_server.el:

,----[ gnus_server.el ]
| (setq gnus-select-method '(nntp "iridium.home.local"))
| 
| (setq gnus-read-active-file 'some)
| 
| (setq gnus-check-new-newsgroups 'ask-server)
| 
| (setq gnus-save-killed-list nil)
| 
| (setq gnus-check-bogus-newsgroups 'ask-server)
| 
| (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.*")
| 		)))
| 
| (add-to-list 'gnus-secondary-select-methods
| 	     '(nntp "gmane" (nntp-address "news.gmane.org")))
| 
| (setq gnus-refer-article-method
|       '(current
| 	(nntp "iridium.home.local")           ; lokaler Newsserver
| 	(nntp "news.t-online.de")             ; news.t-online.de
|         (nnweb "google" (nnweb-type google))  ; groups.google.com
| 	(nntp "news.gmane.org")))             ; news.gmane.org
| 
| (setq gnus-refer-thread-limit t)
`----

In my opinion there's nothing in my setup that could cause the bug.

> 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

One question: Should I have patched an unmodified gnus-start.el or the
one which contains the patch with both of the old and new algorithms
from your last mail? By the way, I patched an original gnus-start.el
from a fresh upstream CVS checkout.

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

Well, I have done what you asked me to do but unfortunately I failed to
find any valuable information. When I hit "c" it just runs through and
the *Backtrace* buffer will be closed immediately within 1 second. Then
I used "d" to go step by step (Argh, I guess I had to hit "d" more than
1000 times :-) but I was unable to recognize something interesting
concerning (> (gnus-info-level info) level) because I really have no
clue about Lisp debugging. 

> 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.
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  :-)

One thing I haven't understood yet:
Why does it fail on Emacs 21.3.1 but works with a (Windows) CVS Emacs
which I downloaded from <http://www.crasseux.com/>?

Regards,
Marcus
-- 
"The father's eyes said `Beautiful! How beautiful you are!'. The boy's eyes
said `How beautiful! She glitters like a star!'. The child's eyes uttered joy
and stilled my heart with sadness for the way we are. And this is why I hate
you and how I understand that no-one ever knows or loves another."