http://bugzilla.spamassassin.org/show_bug.cgi?id=3217





------- Additional Comments From [EMAIL PROTECTED]  2004-03-26 12:28 -------
Subject: Re:  SpamAssassin.pm: "bayes_scanner" may be undefined

On Fri, Mar 26, 2004 at 09:44:45AM -0800, [EMAIL PROTECTED] wrote:
> Thanks.  Do you mean that the calling application should change from:
> 
>    $X = new Mail::SpamAssassin(...)
>    $X->init_learner(...)
>    $X->rebuild_learner_caches(...)
>    $X->finish_learner(...)
> 
> to:
> 
>    $X = new Mail::SpamAssassin(...)
>    $X->init(1)
>    $X->init_learner(...)
>    $X->rebuild_learner_caches(...)
>    $X->finish_learner(...)

Yeah, or you could, technically, do init_learner then init if you're not
going to deal with learn_to_journal.  I think init() then init_learner()
is more accurate.

> But around line 1150 in SpamAssassin.pm is the declaration of
> "init", immediately preceded by a comment that looks significant:
> "non-public methods", which I took to mean that we (the "public"
> caller) should _not_ try this approach.
> 
> I'm quite willing to believe that I've misunderstood something
> somewhere here.  Enlightenment would be welcome!

:)

Well, hrm.  I was going to say that rebuild_learner_caches() is a
non-public function, but the docs don't quite bare me out on that one...
Basically what the docs say is you're expected to do:

init_learner()
learn()
rebuild_learner_caches()
finish_learner()

and learn() does init() (so does check() and a bunch of other "public
API" functions).

So I guess the question is -- should daemons be expecting to be able to
do a force sync/expire without doing a learn/check/etc first?





------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Reply via email to