News scan on startup vs 'g' in group buff

News scan on startup vs 'g' in group buff

[Harry Putnam]

I probably should know how to find this for myself, but really don't
have a clue.

When gnus starts from scratch, something that scans for 'news' must be
called, I want to know if that call is different than the command 
`gnus-group-get-new-news' that is called with 'g' in group buffer?

Why I ask is that I've had a problem for a good while now where calling
'g' ( `gnus-group-get-new-news' ) times out and unless you have some
kind of timeout setup, its a good minute wait.  Then you aren't sure
if all groups got refreshed or what.

My usual work-around is to use M-g on a topic:
`gnus-topic-get-new-news-this-topic' or even more fine grained by
using 'M-g' on a specific group or a pile of process marked groups.

But a moments thought will tell you that leaves a lot undone that the
'g' command would have taken care of.

One (last ditch) work-around is to restart gnus, which even though it
must call some kind of news scan it does not timeout. 

A poor thing to have to do to get what one can usually do with 'g'.

Since I'm way less skilled than my near multiple decade use of gnus
would indicate and if no one has any advice on how to track down what
is causing the time out, then I thought finding out why a
restart doesn't time out, that is, what is different scanning for news
during start up compared to 'g' then maybe I could just use that bit
for now as a work-around.

Re: News scan on startup vs 'g' in group buff

[Glyn Millington]

Harry Putnam <reader@newsguy.com> writes:

> When gnus starts from scratch, something that scans for 'news' must be
> called, I want to know if that call is different than the command
> gnus-group-get-new-news' that is called with 'g' in group buffer?
>
> Why I ask is that I've had a problem for a good while now where
> calling 'g' ( `gnus-group-get-new-news' ) times out and unless you
> have some kind of timeout setup, its a good minute wait.  Then you
> aren't sure if all groups got refreshed or what.
>
> My usual work-around is to use M-g on a topic:
> gnus-topic-get-new-news-this-topic' or even more fine grained by using
> M-g' on a specific group or a pile of process marked groups.
>
> But a moments thought will tell you that leaves a lot undone that the
> g' command would have taken care of.
>
> One (last ditch) work-around is to restart gnus, which even though it
> must call some kind of news scan it does not timeout.
>
> A poor thing to have to do to get what one can usually do with 'g'.
>
> Since I'm way less skilled than my near multiple decade use of gnus
> would indicate and if no one has any advice on how to track down what
> is causing the time out, then I thought finding out why a restart
> doesn't time out, that is, what is different scanning for news during
> start up compared to 'g' then maybe I could just use that bit for now
> as a work-around.

Is it by any chance gnus-get-unread-articles ? 

On your 'g' problem, a quick look at the docstring for
gnus-group-get-new-news, opens up at least one possibility


,----
| (gnus-group-get-new-news &optional ARG ONE-LEVEL)
| 
| Get newly arrived articles.
| If ARG is a number, it specifies which levels you are interested in
| re-scanning.  If ARG is non-nil and not a number, this will force
| "hard" re-reading of the active files from all servers.
| If ONE-LEVEL is not nil, then re-scan only the specified level,
| otherwise all levels below ARG will be scanned too.
`----


Have you tried passing a numerical argument to 'g' ?   ie 'C-u 2 g', if
your mail groups are at level 2 and 1?

hth

Glyn

Re: News scan on startup vs 'g' in group buff

[Harry Putnam]

Glyn Millington <glyn.millington@gmail.com> writes:

[...]

>> Since I'm way less skilled than my near multiple decade use of gnus
>> would indicate and if no one has any advice on how to track down what
>> is causing the time out, then I thought finding out why a restart
>> doesn't time out, that is, what is different scanning for news during
>> start up compared to 'g' then maybe I could just use that bit for now
>> as a work-around.
>
> Is it by any chance gnus-get-unread-articles ? 

I'm not sure if you're asking me this, or asking for other posters to
answer.. it appears to be the same question I was asking.

What commands or functions scan for news on startup?  Is different
than `g'?

I tried evaluating that function you mentioned but got the same near
infinite stall.  But must have broke out sometime in the next half
hour because after 12 minutes I had to leave the computer... but when
I came back about half hour later it appeared to be out of the stall.

I hope that is not what does it on startup.... because as I've
mentioned, and odd though it seems.  A restart will get all groups
refreshed with no apparent giant pause or stall, whereas
 gnus-get-unread-articles or gnus-group-get-new-news goes into a very
long stall.

> On your 'g' problem, a quick look at the docstring for
> gnus-group-get-new-news, opens up at least one possibility
>
> ,----
> | (gnus-group-get-new-news &optional ARG ONE-LEVEL)
> | 
> | Get newly arrived articles.
> | If ARG is a number, it specifies which levels you are interested in
> | re-scanning.  If ARG is non-nil and not a number, this will force
> | "hard" re-reading of the active files from all servers.
> | If ONE-LEVEL is not nil, then re-scan only the specified level,
> | otherwise all levels below ARG will be scanned too.
> `----
>
>
> Have you tried passing a numerical argument to 'g' ?   ie 'C-u 2 g', if
> your mail groups are at level 2 and 1?

No, I haven't keep different levels for yrs, and it would take some
serious rearranging to try that.

-------        ---------       ---=---       ---------      -------- 

Now let me ask this a little differently.  

How might I study what happens on startup, as opposed to what happens
when pressing `g' in group mode.

Isn't there some mode where I watch the action somehow, and see what
gets called or where gnus is spending so much time?

Re: News scan on startup vs 'g' in group buff

[Glyn Millington]

Harry Putnam <reader@newsguy.com> writes:

> Glyn Millington <glyn.millington@gmail.com> writes:
>
> [...]
>
>>> Since I'm way less skilled than my near multiple decade use of gnus
>>> would indicate and if no one has any advice on how to track down
>>> what is causing the time out, then I thought finding out why a
>>> restart doesn't time out, that is, what is different scanning for
>>> news during start up compared to 'g' then maybe I could just use
>>> that bit for now as a work-around.
>> Is it by any chance gnus-get-unread-articles ?
>
> I'm not sure if you're asking me this, or asking for other posters to
> answer.. it appears to be the same question I was asking.
>
> What commands or functions scan for news on startup?  Is different
> than `g'?

I was suggesting you explore that function and see where it leads.

> I tried evaluating that function you mentioned but got the same near
> infinite stall.  But must have broke out sometime in the next half
> hour because after 12 minutes I had to leave the computer... but when
> I came back about half hour later it appeared to be out of the stall.

Ok, so that was a dead end!




>> On your 'g' problem, a quick look at the docstring for
>> gnus-group-get-new-news, opens up at least one possibility
>> ,----
>> | (gnus-group-get-new-news &optional ARG ONE-LEVEL)
>> | 
>> | Get newly arrived articles.  If ARG is a number, it specifies
>> | which levels you are interested in re-scanning.  If ARG is non-nil
>> | and not a number, this will force "hard" re-reading of the active
>> | files from all servers.  If ONE-LEVEL is not nil, then re-scan
>> | only the specified level, otherwise all levels below ARG will be
>> | scanned too.
>> `----
>>
>> Have you tried passing a numerical argument to 'g' ?  ie 'C-u 2 g',
>> if your mail groups are at level 2 and 1?
>
> No, I haven't keep different levels for yrs, and it would take some
> serious rearranging to try that.

The idea was to avoid a "hard" read of the active file, to see if that
makes a difference. The right number will catch all your mail groups.
If your mail groups are all level 4 or below then just do 'C-u 4 g'. If
it seizes up again then no joy and you have lost a few more minutes, if
not then the active file reading was the problem.

atb

Glyn

Re: News scan on startup vs 'g' in group buff

[Harry Putnam]

Glyn Millington <glyn.millington@gmail.com> writes:

>>> Have you tried passing a numerical argument to 'g' ?  ie 'C-u 2 g',
>>> if your mail groups are at level 2 and 1?
>>
>> No, I haven't keep different levels for yrs, and it would take some
>> serious rearranging to try that.
>
> The idea was to avoid a "hard" read of the active file, to see if that
> makes a difference. The right number will catch all your mail groups.
> If your mail groups are all level 4 or below then just do 'C-u 4 g'. If
> it seizes up again then no joy and you have lost a few more minutes, if
> not then the active file reading was the problem.

Is there no way to just watch the process and see what the heck gnus
is doing?  Where all the time is being spent?

All my groups are level 3, except nndrafts and its companion whos name
I forgot for the moment. Which are level 2.

I have dozens of nnml and nntp groups all level 3.

But, all may be fixed.  I just went thru a process of shedding 2
foreign servers.  An old defunct server for opera's newsgroups.  And a
server (apn forte-inc) that just ran out yesterday.

Even after deleting all the groups under both servers, I could not
kill them in server buffer.  Finally resorted to editing .newsrc.eld
by removing all references to either of those two servers.

After restart, I tried the 'g' in group buffer, and it worked just
fine.  It may have been a fluke and may be too soon to crow about it
but I think that cleanup has somehow fixed the problem.

I don't believe it could be the apn server since that just lapsed
today.  But possibly getting rid of the old opera server may have done
it. 

However, I'd still like to know how to watch the startup process (or
any other) and be able to see what calls are made etc.

Re: News scan on startup vs 'g' in group buff

[Glyn Millington]

Harry Putnam <reader@newsguy.com> writes:

> Glyn Millington <glyn.millington@gmail.com> writes:
>
>>>> Have you tried passing a numerical argument to 'g' ?  ie 'C-u 2
>>>> g', if your mail groups are at level 2 and 1?
>>> No, I haven't keep different levels for yrs, and it would take some
>>> serious rearranging to try that.
>> The idea was to avoid a "hard" read of the active file, to see if
>> that makes a difference. The right number will catch all your mail
>> groups.  If your mail groups are all level 4 or below then just do
>> C-u 4 g'. If it seizes up again then no joy and you have lost a few
>> more minutes, if not then the active file reading was the problem.
>
> Is there no way to just watch the process and see what the heck gnus
> is doing?  Where all the time is being spent?

That is what I don't know. It is entirely possible that I know less than
you in these matters!  

What I still don't know is whether you tried what I suggested - a
numerical argument to 'g' :-)  My suspicion was that Gnus was stuck on an
active-file, and that would have helped confirm it (or not). The fact that
removing defunct servers has loosened things up also tends that way.

> However, I'd still like to know how to watch the startup process (or
> any other) and be able to see what calls are made etc.

Well, if Those Who Know don't reply,  I guess the answer is to be found
somewhere here:


http://www.gnu.org/software/emacs/manual/html_node/elisp/Debugger.html#Debugger

I'll play with that later, but I hope your problem is solved now. 

atb


Glyn

Re: News scan on startup vs 'g' in group buff

[Harry Putnam]

Glyn Millington <glyn.millington@gmail.com> writes:

> What I still don't know is whether you tried what I suggested - a
> numerical argument to 'g' :-)  My suspicion was that Gnus was stuck on an
> active-file, and that would have helped confirm it (or not). The fact that
> removing defunct servers has loosened things up also tends that way.

Sorry, but the way you explained it before it sounded like it depended
on having groups at more than one level.  I guess you are saying I
could have just done C-u N g regardless of my setup eh?

But now with the problem seemingly cleared up, or at least enough to
make the `g' command usable I'm reluctant to try to much
experimenting. 

But just off the top of my head, if the problem was what you
suspected, something you called `a hard read of active file', wouldn't
that mean that in server buffer, forcing a read of active file would
hit the same giant pause.... but it never did.

Now, since 'g' seems to be working as expected, using C-u N 'g'
wouldn't really tell us much would it?

Trying it anyway, I discovered that called this way `C-u 3 g', I get
the big stall... I only let it run for 2 minutes... but it should
never take that long.

Then after C-g to stop the stall I pressed just 'g' with no numeric
argument and it completed in short order.

>> However, I'd still like to know how to watch the startup process (or
>> any other) and be able to see what calls are made etc.
>
> Well, if Those Who Know don't reply,  I guess the answer is to be found
> somewhere here:

>
> http://www.gnu.org/software/emacs/manual/html_node/elisp/Debugger.html#Debugger

Yeah, probably but reading the sections `Explicit Debug' and `Using
Debugger'

The first seems to rely on my knowing where to insert `(debug)' in
source code, which, of course, I do not, and the second never discuses
how to start the debugger... just assumes you have it running.

There is a third and even more likely heading: `Invoking the debugger'
which oddly doesn't actually tell you how to invoke it by hand.  Maybe
it cannot just be started when desired like the perl debugger where
you just run a script with `perl -d'.

Further, the menus on emacs itself only have options to enter the
debugger on error or on quit.  Never just `enter debugger now'

I had visions of some command or evaluation before starting gnus that
would just show what it was doing in another buffer.... but apparently
there is no such possibility.

I have produced backtraces with this code in .gnus:

 (defadvice gnus-group-get-new-news (around gnus-timeout activate)
   "Timeout for Gnus."
   (with-timeout
       (40 (message "Gnus timed out.") (debug))
     ad-do-it))

With various amounts of seconds... above it is 40.

But the backtrace does not show hardly any info, just:

,----
|   Debugger entered: nil
|      gnus-group-get-new-news(nil)
|      call-interactively(gnus-group-get-new-news nil nil)
`----
Not exactly a fount of usable info.

Re: News scan on startup vs 'g' in group buff

[Dan Christensen]

My guess is that gnus isn't doing anything different at startup than
when you press g, but that the difference is the state gnus is in.
At startup, all servers are closed, but when you press g, some are
already open but the connection might be semi-dead.  

So, if you find you are still having trouble, you could try going
into the server buffer and closing all servers before hitting g.
If that helps, then you could see which server(s) you need to
close to eliminate the problem.

Dan