1.Could you explain why are these libraries included in all the
xapian-letor headers?
#include<xapian/intrusive_ptr.h>
#include<xapian/types.h>
#include<xapian/visibility.h>
Or just provide me with the documentation of these header. I looked into
these header files but couldn't anything substantial.
2.
Here<https://github.com/rishabhmehrotra/xapian/blob/master/xapian-letor/include/xapian/letor.h#L41>is
the class Letor::Internal intentionally named same as this
Internal<https://github.com/xapian/xapian/blob/99eed23ae87bb96f5f9ee7e14a62e9f4af04af0c/xapian-core/include/xapian/intrusive_ptr.h#L44>namespace
or is it just a coincidence?
3. If I am not wrong we want to dissolve letor_internal to create SVMRanker.
So accordingly letor,h will also change. Right?
Thanks
-Mayank
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xapian.org/pipermail/xapian-devel/attachments/20140310/89ac3f89/attachment-0002.html>
> 1.Could you explain why are these libraries included in all the > xapian-letor headers? > #include<xapian/intrusive_ptr.h> > #include<xapian/types.h> > #include<xapian/visibility.h> > > Or just provide me with the documentation of these header. I looked into > these header files but couldn't anything substantial. >This header connect the xapian-letor to the xapian-core. But Olly will be able to throw more light on intrusive_ptr.h as he migrated the letor code from xapian-core/letor to what is not as xapian-letor/> 2. Here<https://github.com/rishabhmehrotra/xapian/blob/master/xapian-letor/include/xapian/letor.h#L41>is the class Letor::Internal intentionally named same as this > Internal<https://github.com/xapian/xapian/blob/99eed23ae87bb96f5f9ee7e14a62e9f4af04af0c/xapian-core/include/xapian/intrusive_ptr.h#L44>namespace or is it just a coincidence? >The xapain-letor is built on top of xapain-core and follows the same naming conventions as for the xapian-core.> > 3. If I am not wrong we want to dissolve letor_internal to create > SVMRanker. > So accordingly letor,h will also change. Right? >No, the letor.h and letor_internal.h are properly refactored format just basically for svmranker you need to refactor letor_internal_refactored.cc code. The main aim of letor_internal.cc for ranking is to create the ranker and operate trough it rather than defining letor_score() like functions. Cheers, Parth.> > Thanks > > -Mayank > > > > _______________________________________________ > Xapian-devel mailing list > Xapian-devel at lists.xapian.org > http://lists.xapian.org/mailman/listinfo/xapian-devel > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xapian.org/pipermail/xapian-devel/attachments/20140311/d07a83aa/attachment-0002.html>
On Tue, Mar 11, 2014 at 11:39:39AM +0100, Parth Gupta wrote:> > 1.Could you explain why are these libraries included in all the > > xapian-letor headers? > > #include<xapian/intrusive_ptr.h> > > #include<xapian/types.h> > > #include<xapian/visibility.h> > > > > Or just provide me with the documentation of these header. I looked into > > these header files but couldn't anything substantial. > > This header connect the xapian-letor to the xapian-core. But Olly will be > able to throw more light on intrusive_ptr.h as he migrated the letor code > from xapian-core/letor to what is not as xapian-letor/We use the PIMPL idiom for many of the Xapian API classes (though not all - e.g. MSetIterator isn't, as it's just a thin wrapper around an MSet object and an index; and classes which need to be user-subclassable don't use it, as it doesn't really work for those). There's a reasonably good explanation of this technique on wikipedia: http://en.wikipedia.org/wiki/Opaque_pointer#C.2B.2B Our implementation of it uses a referenced counted pointer to the implementation, and intrusive_ptr<> is the implementation of that reference counted pointer. It's actually a lightly patched version of Boost's intrusive_ptr<> implementation. We used to have our own implementation (RefCntPtr<> in base.h, which predates Boost having this, but it seemed more sensible to use a version which somebody else maintains for us. It's not ideal having a patched version, but the current situation is certainly no worse than with base.h. As for the other two headers: * xapian/types.h has the typedefs for various Xapian types (e.g. Xapian::termcount, Xapian::docid). Letor should use these rather than standard C types like int, long, unsigned, unsigned long, etc, to ease extending Xapian to handle more the 4 billion documents or terms. I think currently this isn't done in some places in Letor - those should all be fixed. * xapian/visibility.h supports symbol visibility annotations for compilers and platforms which support it (which is at least all ELF platforms with GCC 4.x). The key thing to know is that this speeds up loading the library, but http://gcc.gnu.org/wiki/Visibility covers the details of how this works. Cheers, Olly