From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/56771 Path: main.gmane.org!not-for-mail From: Marcus Frings Newsgroups: gmane.emacs.gnus.general Subject: Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not Date: Sun, 21 Mar 2004 18:44:38 +0100 Organization: Schismatrix Sender: ding-owner@lists.math.uh.edu Message-ID: References: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1B57hp-0001Dy-00 for ; Sun, 21 Mar 2004 19:29:53 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1B57hQ-0002GR-00; Sun, 21 Mar 2004 12:29:28 -0600 Original-Received: from justine.libertine.org ([66.139.78.221] ident=postfix) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1B57hK-0002GM-00 for ding@lists.math.uh.edu; Sun, 21 Mar 2004 12:29:22 -0600 Original-Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by justine.libertine.org (Postfix) with ESMTP id 8F82E3A0039 for ; Sun, 21 Mar 2004 12:29:21 -0600 (CST) Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1B5705-0007EA-00 for ; Sun, 21 Mar 2004 18:44:41 +0100 Original-Received: from pd95f8367.dip.t-dialin.net ([217.95.131.103]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 21 Mar 2004 18:44:41 +0100 Original-Received: from protagonist by pd95f8367.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 21 Mar 2004 18:44:41 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: ding@gnus.org Original-To: ding@gnus.org Original-Lines: 196 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd95f8367.dip.t-dialin.net X-PGP-Key: 0xE10F502E (DH/DSS) X-PGP-Fingerprint: 53FC 5A87 27BE 1D30 FEB4 861A 948F D6A0 E10F 502E Mail-Copies-To: nobody Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAElBMVEUtERpEIB1dPit3NimZ ZTm8WjeCaEzZAAACfUlEQVR42lVUQYLbIAwUpL0jnAeA7L2HlX1PbPyA1ub/X+mIZLNbDg5oGCEN Q4jew6VAP4awiKyJyGcR/JCX4DI5SrJO6+oslMi+ORF2eANkWsN3GkfEgZii1Lpmm8ozFcd8fQCW dZVtm5VzzoKw1usY2fgy1TofrZ1tbzYW1U+rRgzYKoLn+URWlJcdTVKnus4I1P3E9/hc05Rwhher V0YkMsJRImpN9IsoTiiHaTDCfgaXcqAYPMqV+xol01qxP5BfU/DBRVSFgX44THtLFJykEhMql+pl 3HiYKxh3PUregp8snRRxakVN+3m3ibAbwWBRGYeltb/Ted4Ha3ActrtpgIHG2yeCt07VeStMdDma LZteWyt9tqveIoWoixHajHRbZyzHxp4e7gUoZNGhyzhr9pAdR0CkY0K5WkA7D7XWZBp1MZFmaLIZ YDhnu8EPW+lYz/bgxc4uDACU1dooI1Jtt99IhWIT2xXKqJBbUdF2XBDPnA0IIqi4lQU01ctiJwQD WMasTW/DB7IUd7TK7FPs1kMa3Nx0tnJzx7yll8NCzOOxqHd1C6TL/AiwsZgzcwClhDD8IRpUH+Hp R+LkeLDaVYPTQfPLqEDYuVAixNfAfM3vlxCCc+ygxnKUgE091mkMDwxdsKNQTG/f9z1QfW+n3tyv H++K+wf+Pfm1eMUdzh+W3YS9cfzxKk2xiwLA6eS/KWzTwa77UCbv/wfoWmvVAukS1OuVucmEoUuW RwwdeHZBruPOnLeV0N8zd4av9/cZaN07w1y/D+DwtXnowAvBssfhEwAXIwBC65aqiyGTZXy6Fm8K Xgv9ePfVpv0zcMD1vULurf7XpP/Z/ANzQp7ApenyawAAAABJRU5ErkJggg== X-Now-Playing: Anathema - "Pressure" [A Fine Day To Exit] User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) Cancel-Lock: sha1:SCk80Q6OvzP/QGpnVbP3t6WOlDo= Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:56771 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:56771 * Kevin Greiner wrote: > Marcus Frings writes: >> * Mark Plaksin 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 ? 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."