bug?

bug?

[Vladimir Volovich]

Hi!

when entering some nntp group, i've got an error:

Debugger entered--Lisp error: (wrong-type-argument listp 24744)
  gnus-adjust-marked-articles(("some.group.name" 3 ((1 . 24843)) ((seen 24602 . 24744))))
  gnus-select-newsgroup("some.group.name" nil nil)
  gnus-summary-read-group-1("some.group.name" nil t nil nil nil)
  gnus-summary-read-group("some.group.name" nil t nil nil nil nil)
  gnus-group-read-group(nil t)
  gnus-group-select-group(nil)
  call-interactively(gnus-group-select-group)

other groups are entered without an error.

some time ago, our news server was reinstalled, and all article
numbering was restarted from scratch. may this be the reason for the
above error? how do i recover from that error? (and why it doesn't
happen for other groups?)

Best,
v.

Re: bug?

[Lars Magne Ingebrigtsen]

Vladimir Volovich <vvv@vsu.ru> writes:

> Debugger entered--Lisp error: (wrong-type-argument listp 24744)
>   gnus-adjust-marked-articles(("some.group.name" 3 ((1 . 24843)) ((seen 24602 . 24744))))

The `seen' list there isn't valid.  It should be
(seen (24602 . 24744)), not (seen 24602 . 24744).

`G E' on the group to edit the list.

But do you know what caused that corruption?  Can you reproduce the
actions that led to this situation?

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

Re: bug?

[Katsumi Yamaoka]

[-- Attachment #1: Type: text/plain, Size: 1364 bytes --]

Hi,

I am using Gnus and T-gnus (based on latest Gnus).

>>>>> In <m3sn9m59oi.fsf@quimbies.gnus.org>
>>>>>	Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:

Lars> Vladimir Volovich <vvv@vsu.ru> writes:

>> Debugger entered--Lisp error: (wrong-type-argument listp 24744)
>>   gnus-adjust-marked-articles(("some.group.name" 3 ((1 . 24843)) ((seen 24602 . 24744))))

Lars> The `seen' list there isn't valid.  It should be
Lars> (seen (24602 . 24744)), not (seen 24602 . 24744).

Lars> `G E' on the group to edit the list.

Lars> But do you know what caused that corruption?  Can you reproduce the
Lars> actions that led to this situation?

I was troubled with the same problem.  I am not sure if a record
like (seen NUM1 . NUM2) was generated by only T-gnus or both
Gnus and T-gnus.  However, the fact is that such records will
not be fixed even if I use the original Gnus to load and save
.newsrc.eld file, and I still could not read newsgroups if there
are such corrupted records.  So, I have tried to fix this as
follows:

2002-01-15  Katsumi Yamaoka  <yamaoka@jpl.org>

	* gnus-sum.el (gnus-adjust-marked-articles): Fix the record for
	`seen' if it looks like (seen NUM1 . NUM2).  It should be
	(seen (NUM1 . NUM2)).

It has been done only in T-gnus.  The attached patch is for
Gnus.  As mentioned above, I am not sure if it is really needed
for Gnus too, sorry.


[-- Attachment #2: gnus-sum.el.diff --]
[-- Type: application/x-patch, Size: 449 bytes --]

Re: bug?

[Lars Magne Ingebrigtsen]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> 	* gnus-sum.el (gnus-adjust-marked-articles): Fix the record for
> 	`seen' if it looks like (seen NUM1 . NUM2).  It should be
> 	(seen (NUM1 . NUM2)).

Thanks for the patch; I've applied it to Oort Gnus v0.05 (i. e., CVS).

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

Re: Bug?

[Torgny Nyblom]

ShengHuo ZHU <zsh@cs.rochester.edu> writes:

> make.bat is written for NTEmacs. I don't know whether it works for
> XEmacs. And, a broken gnus.elc could cause the problem, so you'd
> better remove all .elc files before compiling.

It has worked fine until now. BTW all .elc are removed before
compiling. If this might be a problem how do I get gnus compiled?

>From make.bat:
---->
@echo off
set EMACS=D:\XEmacs-21.1.9\i386-pc-win32\xemacs.exe
set LISPDIR=D:\xemacs-packages\lisp\gnus

cd lisp
%EMACS% -batch -q -no-site-file -l ./dgnushack.el -f dgnushack-compile

del /q %LISPDIR%\OLD\*.*
copy %LISPDIR%\*.* %LISPDIR%\OLD\
del /q %LISPDIR%\*.*
copy *.* %LISPDIR%
del *.elc

cd ..

<----

-- 
Torgny Nyblom | torgny@linux.nu | +46 (0)709 987246

Re: Bug?

[ShengHuo ZHU]

Torgny Nyblom <torgny@nyblom.org> writes:

> Update: When I run make.bat I get this error:
> ---->
> Compiling c:\gnus\lisp\earcon.el...
> While compiling toplevel forms in file c:\gnus\lisp\earcon.el:
>   !! End of stream (("internal input stream"))
> <----
> This error doesn't occur when running make.bat in gnus 5.8.7.
> 
> Might this have something to do with my problem?

make.bat is written for NTEmacs. I don't know whether it works for
XEmacs. And, a broken gnus.elc could cause the problem, so you'd
better remove all .elc files before compiling.

ShengHuo

Re: Bug?

[Torgny Nyblom]

Update: When I run make.bat I get this error:
---->
Compiling c:\gnus\lisp\earcon.el...
While compiling toplevel forms in file c:\gnus\lisp\earcon.el:
  !! End of stream (("internal input stream"))
<----
This error doesn't occur when running make.bat in gnus 5.8.7.

Might this have something to do with my problem?

-- 
Torgny Nyblom | torgny@linux.nu | +46 (0)709 987246

Re: Bug?

[Norbert Koch]

Torgny Nyblom <torgny@nyblom.org> wrote:

Hi!

> Signaling: (end-of-file "internal input stream")
>   load-internal("gnus" nil t nil binary)
>   load("gnus" nil t nil)
>   require(gnus)
>   byte-code("..." [require gnus gnus-cache nnvirtual gnus-sum gnus-score] 2)
>   load-internal("gnus-agent" nil nil nil binary)
>   load("gnus-agent" nil nil nil)
>   command-execute(gnus-unplugged t)
>   execute-extended-command(nil)
>   call-interactively(execute-extended-command)

Erm, this sounds like a missing closing parenthesis. Can you check
the region you've commented?

norbert.

Re: Bug?

[Torgny Nyblom]

ShengHuo ZHU <zsh@cs.rochester.edu> writes:

> Torgny Nyblom <torgny@nyblom.org> writes:
> 
> > Hi,
> > 
> > when I try to start XEmacs with the latest CVS snapshot I get this
> > backtrace (works fine in emacs), but if I change to another version
> > (perhaps 3 weeks old) all is fine. Might this be a bug in gnus or am I
> > doing something wrong?
> > This error comes at startup that is before gnus is loaded. I've managed
> > to narrow it down to when the bbdb is initiated.
> 
> It could be a compiling, installation or BBDB-related problem.
> 
> Could you reconfigure Gnus, compile it and (temporarily) load it
> before BBDB?

Done. The fault happens weather I initiate bbdb or not. I get this if I
comment out my bbdb-init:

Signaling: (end-of-file "internal input stream")
  load-internal("gnus" nil t nil binary)
  load("gnus" nil t nil)
  require(gnus)
  byte-code("..." [require gnus gnus-cache nnvirtual gnus-sum gnus-score] 2)
  load-internal("gnus-agent" nil nil nil binary)
  load("gnus-agent" nil nil nil)
  command-execute(gnus-unplugged t)
  execute-extended-command(nil)
  call-interactively(execute-extended-command)

This time I tryed a new CVS snapshot.

-- 
Torgny Nyblom | torgny@linux.nu | +46 (0)709 987246

Re: Bug?

[ShengHuo ZHU]

Torgny Nyblom <torgny@nyblom.org> writes:

> Hi,
> 
> when I try to start XEmacs with the latest CVS snapshot I get this
> backtrace (works fine in emacs), but if I change to another version
> (perhaps 3 weeks old) all is fine. Might this be a bug in gnus or am I
> doing something wrong?
> This error comes at startup that is before gnus is loaded. I've managed
> to narrow it down to when the bbdb is initiated.

It could be a compiling, installation or BBDB-related problem.

Could you reconfigure Gnus, compile it and (temporarily) load it
before BBDB?

ShengHuo

Bug?

[Torgny Nyblom]

Hi,

when I try to start XEmacs with the latest CVS snapshot I get this
backtrace (works fine in emacs), but if I change to another version
(perhaps 3 weeks old) all is fine. Might this be a bug in gnus or am I
doing something wrong?
This error comes at startup that is before gnus is loaded. I've managed
to narrow it down to when the bbdb is initiated.

----
Signaling: (end-of-file "internal input stream")
  load-internal("gnus" nil t nil binary)
  load("gnus" nil t nil)
  require(gnus)
  byte-code("..." [require bbdb gnus] 2)
  load-internal("bbdb-gnus" nil nil nil binary)
  load("bbdb-gnus" nil nil nil)
  bbdb-insinuate-message()
  bbdb-initialize(gnus message sc w3)
  byte-code("..." [require bbdb bbdb-initialize gnus message sc w3 add-hook gnus-startup-hook bbdb-insinuate-gnus 46 bbdb-default-area-code nil bbdb-north-american-phone-numbers-p ".*torgny.*\\|.*e95tny.*" bbdb-user-mail-names t bbdb-always-add-addresses (lambda nil (setq bbdb/news-auto-create-p ...)) gnus-select-group-hook bbdb/mail-auto-create-p bbdb-use-pop-up 3 bbdb-pop-up-target-lines name bbdb-completion-type never bbdb-new-nets-always-primary bbdb-canonicalize-redundant-nets-p ("net notes") bbdb-elided-display ("net notes") bbdb-pop-up-elided-display auto bbdb-offer-save "BBDB is loaded"] 5)
  load-internal("~/xemacs/bbdb-init" nil nil nil binary)
  load("~/xemacs/bbdb-init")
  byte-compile-if-newer-and-load("~/xemacs/bbdb-init")
  load-internal("d:\\.xemacs-options.el" nil nil t undecided)
  load("d:\\.xemacs-options.el" nil nil t)
  load-file("~/.xemacs-options.el")
  (if (string-match "XEmacs" emacs-version) (load-file "~/.xemacs-options.el") (load-file "~/.emacs-options.el"))
)
  load-internal("~\\.emacs" t t t undecided)
  load("~\\.emacs" t t t)
  load-user-init-file("")
  load-init-file()
  command-line()
  normal-top-level()
----

-- 
Torgny Nyblom | torgny@linux.nu | +46 (0)709 987246

bug?

[Vladimir Volovich]

Hi,

something strange happened. i pressed "g" in a group buffer to get new
mail, but Emacs asked "Revisit the file literally?" (what does it mean
and why this happened?). I answered yes. Then the history of my nnmbox
groups was broken. If i try to exit gnus (q), Emacs asks the same
question. I turned on debugging, and when i answered "no" to this
question, an error occurs "File already visited non-literally".
Backtrace follows.

Signaling: (error "File already visited non-literally")
  signal(error ("File already visited non-literally"))
  error("File already visited non-literally")
  find-file-noselect("/home/vvv/mbox" nil raw)
  apply(find-file-noselect ("/home/vvv/mbox" nil raw))
  nnheader-find-file-noselect("/home/vvv/mbox" nil raw)
  nnmbox-read-mbox()
  nnmbox-request-scan(nil "")
  gnus-request-scan(nil (nnmbox ""))
  gnus-read-active-file()
  gnus-group-get-new-news(nil)
* call-interactively(gnus-group-get-new-news)

??? I'm confused... ;-)

	Best regards, -- Vladimir.

Re: Bug?

[Lars Magne Ingebrigtsen]

Sudish Joseph <sudish@mindspring.com> writes:

> If it's possible to yank multiple copies of groups through C-y, C-k
> should be intelligent enough to not kill every copy of the group.  Or,
> if C-y works with topics (and it does, thank god), C-k should as well.

Yes, it's supposed to work.  It doesn't?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: Bug?

[Sudish Joseph]

In article <d9917od96w.fsf@sejong.cs.umn.edu>,
Raja R Harinath <harinath@cs.umn.edu> writes:
> Sudish Joseph <sudish@mindspring.com> writes:
>> A somewhat flawed one.  If you kill one copy of the group the other
>> one disappears.  To delete one, it's necessary to kill both, exit
>> gnus, restart, then subscibe again.  Which means that you lose all
>> ticks, article counts, etc.

> Nothing so drastic is necessary.  Use `gnus-topic-remove-group' (T D).

So we've officially dropped support for C-k/C-y?  This is the method
used for group position manipulation since Gnus 3.x (and probably
earlier).  

If it's possible to yank multiple copies of groups through C-y, C-k
should be intelligent enough to not kill every copy of the group.  Or,
if C-y works with topics (and it does, thank god), C-k should as well.

-Sudish

Re: Bug?

[Raja R Harinath]

Sudish Joseph <sudish@mindspring.com> writes:
> In article <m2vias269g.fsf@proletcult.ifi.uio.no>,
> Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
> > gorkab@sanchez.com (Brian Gorka) writes:
> >> RGnus .70 seems to let you subscribe to the same newsgroup more than
> >> once. 
> >> 
> >> Is this a bug or a 'feature'? 
> > Feature.
> A somewhat flawed one.  If you kill one copy of the group the other
> one disappears.  To delete one, it's necessary to kill both, exit
> gnus, restart, then subscibe again.  Which means that you lose all
> ticks, article counts, etc.

Nothing so drastic is necessary.  Use `gnus-topic-remove-group' (T D).

- Hari

-- 
Raja R Harinath ------------------------------ harinath@cs.umn.edu
"When all else fails, read the instructions."      -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing."   -- Roy L Ash

Re: Bug?

[Sudish Joseph]

In article <m2vias269g.fsf@proletcult.ifi.uio.no>,
Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
> gorkab@sanchez.com (Brian Gorka) writes:
>> RGnus .70 seems to let you subscribe to the same newsgroup more than
>> once. 
>> 
>> Is this a bug or a 'feature'? 

> Feature.

A somewhat flawed one.  If you kill one copy of the group the other
one disappears.  To delete one, it's necessary to kill both, exit
gnus, restart, then subscibe again.  Which means that you lose all
ticks, article counts, etc.

-Sudish

Re: Bug?

[Hrvoje Niksic]

Brian Gorka (gorkab@sanchez.com) wrote:
> Is this a bug or a 'feature'?

It's a feature (no quotes).  So you can have alt.sex.emacs under both
"Sex" and "Emacs" topics.  Whichever you come to first, you'll read
it, and group info will get updated.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Hocemo 101-icu!
--------------------------------+--------------------------------
Oh lord won't you buy me a color TV...

Re: Bug?

[Lars Magne Ingebrigtsen]

gorkab@sanchez.com (Brian Gorka) writes:

> RGnus .70 seems to let you subscribe to the same newsgroup more than
> once.  I was trying to add the PGP newsgroups, and apparently I had
> already added them under security.  Whoops.
> 
> Is this a bug or a 'feature'? 

Feature.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Bug?

[Brian Gorka]

RGnus .70 seems to let you subscribe to the same newsgroup more than
once.  I was trying to add the PGP newsgroups, and apparently I had
already added them under security.  Whoops.

Is this a bug or a 'feature'? 

[ Gnus -- 33121 ]
  [ misc -- 0 ]...
  [ Microsoft Newsgroups -- 16808 ]...
  [ Emacs -- 71 ]...
  [ Emulators -- 952 ]...
  [ Warez -- 8296 ]...
  [ HP 48 -- 32 ]...
  [ Babylon 5 -- 299 ]...
  [ Trek -- 1 ]...
  [ PGP -- 55 ]
        28: alt.security.pgp
         3: comp.security.pgp
         1: comp.security.pgp.announce
        14: comp.security.pgp.discuss
         8: comp.security.pgp.resources
         1: comp.security.pgp.tech
        28: alt.security.pgp
         3: comp.security.pgp
         1: comp.security.pgp.announce
        14: comp.security.pgp.discuss
         8: comp.security.pgp.resources
         1: comp.security.pgp.tech
  [ Security -- 968 ]
        28: alt.security.pgp
         3: comp.security.pgp
         1: comp.security.pgp.announce
        14: comp.security.pgp.discuss
         8: comp.security.pgp.resources
         1: comp.security.pgp.tech
       119: comp.os.ms-windows.nt.admin.security
        20: comp.security
       125: comp.security.firewalls
         3: comp.security.gss-api
       315: comp.security.misc
       331: comp.security.unix
  [ Java -- 4159 ]...
  [ Stuff -- 1535 ]...

Re: bug?

[William M. Perry]

Kai Grossjohann writes:
>>>>>> William M Perry writes:
>
>  Bill>   Yes, but not the one you probably think.  A real URL parser
>  Bill> would parse that as:
>
>  Bill> type: ftp		host: nil
>  Bill> user: nil		port: nil
>  Bill> pass: nil		file: does.this.look.like.an.url
>  Bill> targ: nil		attr: nil
>
>  Bill>   This is from the relative URL parsing RFC - cannot remember
>  Bill> the # off the top of my head.
>
>IIRC, relative URLs may not contain a type.  Therefore, the above URL
>is an absolute URL.  From the same relative URL RFC -- I cannot
>remember the number either.  Am I wrong?

  The relative URL RFC has the rules for determining whether a URL is
relative or not and also for the 'correct' way to split a full URL up so
that you can splice a full URL and a relative URL together.

  ftp:blah.blah _IS_ an absolute URL, but points to the _FILE_ blah.blah on
an undefined server on an undefined port.

-Bill P.

Re: bug?

[Kai Grossjohann]

>>>>> William M Perry writes:

  Bill>   Yes, but not the one you probably think.  A real URL parser
  Bill> would parse that as:

  Bill> type: ftp		host: nil
  Bill> user: nil		port: nil
  Bill> pass: nil		file: does.this.look.like.an.url
  Bill> targ: nil		attr: nil

  Bill>   This is from the relative URL parsing RFC - cannot remember
  Bill> the # off the top of my head.

IIRC, relative URLs may not contain a type.  Therefore, the above URL
is an absolute URL.  From the same relative URL RFC -- I cannot
remember the number either.  Am I wrong?

kai
-- 
Life is hard and then you die.

Re: bug?

[William M. Perry]

lars brinkhoff writes:
>ftp:does.this.look.like.an.url ?

  Yes, but not the one you probably think.  A real URL parser would parse
that as:

type: ftp		host: nil
user: nil		port: nil
pass: nil		file: does.this.look.like.an.url
targ: nil		attr: nil

  This is from the relative URL parsing RFC - cannot remember the # off the
top of my head.

-Bill P.

  

bug?

[lars brinkhoff]

ftp:does.this.look.like.an.url ?