[Xapian-devel] Branching for 1.1

Richard Boulton richard at lemurconsulting.com
Fri Feb 22 11:57:12 GMT 2008


Olly Betts wrote:
> Will this actually work?  Subclassing our reference counted classes
> doesn't really work in general...

Ah - it works, in that it passes my tests, but I'd better look into 
what's going on here a bit more carefully...

I think it's just about okay though: the subclass is a subclass of the 
interface class, not of the reference counted internals, so the subclass 
just inherits the same reference counted internals as the base class 
(and can choose not to initialise them by using the base class 
constructor, it if wishes).

I'm not sure whether it's safe if the copy constructor or assignment 
operator on the subclass are used, though - I'll double-check that.

> Ideally Xapian::Stem shouldn't be reference counted, but Martin was
> highly resistant to my snowball patch to move towards making the
> stemming algorithm variables stack based rather than persistent in a
> struct between invocations (which would allow Xapian::Stem to just wrap
> an enum).
 >
> IIRC, his main argument seemed to be for compatibility with a
> closed-source snowball compiler he has, so I'm not very sympathetic, but
> forking the language doesn't seem ideal.  It's not ideal that we have a
> forked snowball compiler, but at least those changes can hopefully be
> merged back fairly easily at some point (I don't think any are likely to
> be controversial).

Agreed, on all counts...

> I was hoping longer term to be able to teach the snowball code generator
> to make these changes automatically, but that seems quite tricky.

Ooh, that would be nice.  I agree about it being tricky, though.

>> I _could_ make a branch 
>> for this change, but I'm already maintaining 3 branches (at least some 
>> of which I'm hoping to be able to merge into HEAD before 1.1), and I'd 
>> much prefer to make a branch for 1.0.x and maintain that, rather than 
>> make a branch for further changes towards 1.1 and maintain that.
> 
> I don't see why it needs its own branch - HEAD is essentially already
> the 1.1 branch, so changes suitable for 1.1 can go there.
> 
> Although assuming this works, I do have a slight concern about all those
> new virtual method calls being imposed on every user as
> Xapian::Stem::operator() tends to get used rather a lot.  I think this
> needs profiling so we can assess the gain vs pain.

Yes - I was about to run some profiling on it.  At the least, I'll see 
how the performance of stemtest is affected.

-- 
Richard



More information about the Xapian-devel mailing list