Re: [Pan-users] Fetching new article headers in subscribed groups ever X minutes?

[christian]

On Sun, 24 Feb 2013 03:24:46 +0000, Duncan wrote:

> Christian posted on Sat, 23 Feb 2013 17:21:55 +0000 as excerpted:
> 
>> Hi,
>> 
>> I am new to Pan. I'm running Pan 0.139. I have tried to figure out how
>> to have Pan check for and fetch new article headers every 30 minutes,
>> but I can't figure out how. In other news readers I've used it's been
>> pretty obvious how to set this, but in Pan it's either hidden or I am
>> missing something obvious. Please let me know how I can set it so that
>> Pan fetches new articles by time interval, in my case 30 minutes.
> 
> This is interesting/distressing...
> 
> For some time, pan has (well, had, see below...) the feature of being
> able to download headers from the specified groups when given the
> appropriate command line interface (CLI) option, and as with any self-
> respecting Unix-based program, one was expected to simply setup a
> cronjob from there, if scheduled activity was desired.  The CLI option
> was (based on the sources, which I just looked at) supposed to work like
> this:
> 
> pan headers:group.name1,another.group.name2,third.group.name3[,...]
> 
> ... with the group names separated by commas if there was more than one.
> There was (and remains) the --no-gui option, as well, to do it without
> popping up the GUI.
> 
> Unfortunately, somewhere along the line that feature apparently
> bitrotted and no longer works (just tested, I get a segfault), at least
> not with the 0.140-live-git-version I'm running, and based on your post,
> I'd assume not with 0.139 as well.  I don't remember anyone ever
> bringing up the problem here (tho it might have been bugged, I didn't
> check) and I hadn't done binaries at all for years until literally the
> last week or two, and didn't actually use that CLI feature (like most I
> guess I do mostly GUI) back when I did binaries, so I have absolutely NO
> idea when the feature bitrotted, but I do remember people using either
> that same feature or a very similar CLI-based-header-fetch feature many
> years ago, so I'm sure it must have worked back then.
> 
> But one of the coders (I'd guess either Heinrich or KHaley, depending on
> when the problem was caught) apparently became aware of the problem, and
> the --help output for the headers: option (and a couple others) is now
> commented out, with the comment "Doesn't work yet."
> 
> I'm almost positive the feature worked back half a decade ago or so when
> Charles was still actively developing pan, so that "yet" in the comment,
> instead of "currently broken" or similar, hints to me that the comment
> was added sometime post-Charles-era, and that whoever added it wasn't
> aware that it had worked in the past (assuming it did, but as I said,
> I'm almost positive it did...).
> 
> Which is all rather distressing to me, not only because of the broken
> header-fetch functionality itself, but because of its impact on the
> recently added "actions" feature, as well.  One of the big issues with
> pan, at least since the C++ rewrite, has been that it had a way to fetch
> headers (aka overviews) from the command-line, and thus could be setup
> in a cronjob or whatever for scheduled automatic header-fetches, but
> that it had no way of auto-fetching bodies (actual posts) as well.  The
> "actions"
> feature (see the actions tab of pan prefs) FINALLY allowed score-based-
> auto-actions, including auto-cache and auto-save, and I thought with the
> appropriate actions and/or score settings and an appropriate cronjob,
> pan could FINALLY download both headers and bodies entirely unattended.
> 
> Unfortunately, if the CLI-based header-downloading feature is broken, so
> is the new actions feature, or at least a good part of the benefit it
> was supposed to bring! And here I was thinking that since I was back
> into binaries now, I might actually try out the feature!  =:^(
> 
> 
> Hopefully Heinrich will jump in here with some comments about what might
> have gone wrong in the code and how easy it might be to fix, especially
> since it's likely him that commented the corresponding --help output (if
> I knew git a bit better I could use git blame to trace down exactly when
> that was commented, and maybe look further back to see when it broke,
> tho it might have been before pan switched to git from SVN, in which
> case it might be a dead-end search...), and it'll likely be him
> committing the fix.  But if it was trivial to fix, I'm sure it'd have
> been fixed instead of the associated --help output commented, so I'd
> guess it's at least a bit beyond "trivial". =:^(  OTOH, since the
> comment /does/ say "yet", it's likely that whoever commented that output
> never new it worked in the first place, so didn't know it was simply
> broken and thought it had never been implemented at all, so it's quite
> likely the overestimated the complexity of actually getting it working
> (again).
> 
> 
> This was my Friday so I do have the next couple days off, but I really
> do need to do some house cleaning and other chores...  If I have time,
> however, or decide to be lazy and play on the computer rather than doing
> the cleaning I really SHOULD be doing, since I do build pan from git
> here and thus do have pan's git history back to when it was transferred
> from SVN, anyway, I might look into it further.  If I'm lucky, I'll find
> the commit that broke it as well as the commit that added the comment,
> which should definitely help in fixing the problem, and if I'm REALLY
> lucky, it'll be obvious what went wrong in that commit, even to this
> non-coder, and if I'm REALLY lucky, I'll even be able to come up with a
> fix.
> 
> We'll see...  But I REALLY do need to spend at least one day cleaning
> and doing laundry, etc, so who knows if I'll get to it at all, let alone
> get lucky enough to find the problem and have it be something simple
> enough I can actually fix. =:^(
> 
> Of course, should anyone with the skills have the time to look into it
> first and post a patch that I can simply apply and test... =:^)
> 
> 
> Meanwhile... alternative that should be a functional workaround...
> 
> Consider installing and running a local news server such as leafnode,
> running on the localhost loopback interface (127.0.0.1 in IPv4, someday
> I need to jump in and learn IPv6...).  You can setup the server to do
> the scheduled pulls, then set pan up to connect to the local server over
> the localhost loopback.

Thank you for your detailed response and workaround. As a Pan newbie 
(I've done Usenet since 95) I find it odd that there's no built in 
functionality for timed fetching of new headers. So odd in fact I wonder 
if there's a reason for it?

Now on to installing a news server! :)

-- 
//christian