[Pan-users] Re: Re: Score limit

[Duncan]

Ronny Hippler posted <address@hidden>, excerpted below, 
on Tue, 14 Dec 2004 10:20:38 -0500:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Tue, 14 Dec 2004 02:30:55 -0700, Duncan wrote:
> 
>>> %BOS
>>> [^alt\.binaries\.emulators\.mame$]
>>>     score: =1001
>>>     subject: 720b\.zip
>>>     score: =1002
>>>     subject: alphaho\.zip
>>>     score: =1003
>>>     subject: arknoidu\.zip
> 
>>group entry section.  (One can always add the the same group entry more
>>than once, and that's what I've done.)
> 
> Yea but when you have a list of 500+ it is easier to just do it that
> way. I am not creating them with in mame.
> 
>>the impression that the rules and score order didn't matter within the
>>group entry, and that it would assign the same score to all matches within
>>the group entry.
> 
> Nope works just fine, first one gets score of 1001 the next 1002 etc.
> makes grouping the same file easier as I just sort on the score. 
> - --

Hmmm... if you used a proper sig line delimiter
(CRLF-dash-dash-space-CRLF, thus dash-dash-space alone on a line), it'd
make things a bit easier for auto-sig-snipping when quoting.  Of course,
it's up to you, but that's one reason there "is" such a thing as a
"proper" sig delimiter, to make automatic management thereof a bit easier.
(PAN of course both creates such proper delimiters, and automatically
trims based on them.  IIRC from last time I read the GNKSA guidelines,
that's one of the things it checks, tho I'm not sure whether as a
SHOULD or MUST.  Of course, this is a mailing list, but mail sig
delimiters should be the same as news sig delimiters.)

Anyway... thanks for the tip!  I hadn't thought about using scoring in
that way, and likely won't much as sorting on other things (subject)
/usually/ works, particularly if those in the newsgroup have agreed on a
general subject format, as many have, such that unsortables (such as size)
come AFTER desired sortables (such as attached filename) in a subject
line.  Where sorting by subject doesn't work, sorting by date usually
does, once most of the ones that /can/ be sorted by subject have been
dealt with, hopefully leaving only the troublesome ones to sort by date,
with few interminglings.  However, this sort of tip could be very useful
in a few otherwise very troublesome cases.

Again, since I'd be using the technique for only the troublesome cases,
I'd probably be able to create the scores individually, and then remove
them once I was done.

Which of course brings up the question...  If you are already handling
this in an automated way outside of PAN, which seems to be the case, why
not break the handling into a group of X files at a time.  It'd seem to me
that if you run into the problem at 300-ish lines, you could handle
probably 100 files at a time (a filter and a score line for each, plus a
generous allowance for "trim", you could actually probably do closer to
120-135-ish files at a time), which is a pretty big chunk, IMO. If you can
automate the rest of the process as you apparently have, I'd not consider
breaking the job into 100 file chunks much of a challenge at all.

Of course, yes, that's working around the problem rather than directly
fixing it, but your use of scoring seems a bit novel to me, and I'd guess
PAN simply wasn't designed with it in mind, so you are likely lucky it
works as good as it does.

So.. maybe try that, and take a look at the PAN code and possibly submit a
patch that does away with the limit, as well, assuming you have the
necessary coding skills (I don't).  After all, allowing the end user to
work with the code and submit patches when they find a problem, instead of
having to work around it as one would with closed source, is one of the
benefits of open source.  =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin