[GenABEL-dev] moving filevector and iterator to DatABEL

[L.C. Karssen]

Hi Maksim,


On 14-11-13 18:06, Maksim Struchalin wrote:
> Hi All,
> 
> I would like to start discussing a plan of moving filevector and
> iterator libraries in DatABEL.

I'm not sure if I understand you completely, but filevector is also used
by ProbABEL and OmicABEL. DatABEL is built on top of filevector.
So my idea is to make filevector a 'real' library (a .so file), that can
be used by all of these projects. The result will be the same as (what I
think is) your idea: no more symbolic links to the filevector directory
in SVN.
This way, we can just tell the user to install the fv library (like
he/she needs to install e.g. a BLAS library, the GSL or some databse
lib. To make the system administrator's life easier we can package the
fv lib in a .deb and .rpm package, for example.
For ProbABEL we already have this dependency on the Eigen library and a
dependency on the Boost libraries will (likely) be added in the future.

> At the current version of GenABEL, the
> code of iterator and filevector is copied to the body of package and
> compiled separetly from DatABEL (like DataABEL does not exists at all).
> It makes some troubles (e.g. for impute2databel). I think we can
> separate this code from GenABEL and it will be quite easy.

Sounds like a good idea. Proper design.

> 
> I tried to do it, but I got in some problems. As I see, iterator is
> called from three GenABEL functions: impute2databel, qtscore and
> summary.snp.data. Two months ago Lennart changed impute2databel in a way
> that it calls iterator from DatABEL.

I did this because of CRAN errors. IIRC it was some sort of namespace
problem.

> I see that it works more or less
> good now (at least on my computer). But qtscore and summary.snp.data use
> a special version of iterator which is implemented in GenABEL itself
> (called iteratorGA). I compared iterators from DatABEL and GenABEL and
> they are quite different. So, as I see, the main problem of moving
> itarator to DatABEL is in these two function only which should be
> changed in a way that they use iterator implemented in DatABEL.

I haven't looked at the code, but it sounds like a reasonable, good plan.

> 
> Another issue is compatibility of impute2databel. As I understand, the
> current implementation of impute2databel (which call iterator from
> DatABEL) is not compatible with mac/win. 

Are we sure about that? Yurii, can you confirm this? I could check on
Windows.

> Perhaps the problem is in
> absense of R_init_DatABEL.cpp file in DatABEL (manual "Writing R
> Extensions, Registering native routines"). This file conatins some code
> which tells R about the functions in DatABEL (a function iterator in our
> case) which are gonna be used from other pakcages. We only need to
> implement it in DatABEL (I did it and it works for me).

Do you mean it works for you on other platforms than Linux?

> 
> I do not know how these changes might affect other *ABEL packages: I see
> that MixABEL, TestABEL use its own iterators. But, I expect that it does
> not touch them.
> 
> So, I propose:
> 1) Make a test on mac/win and see how R_init_DatABEL.cpp solve the
> compatibility issue.

OK.

> 2) Change qtscore and summary.snp.data in a way that it calls iterator
> which is implemented in DatABEL.

Does anybody know what the differences between the different iterator
implementations are? And/or why these exist?

> 3) Test everything and see that it works.

I agree, always a good plan :-).


> 
> 
> It seems easy to do. The only difficulty which I see is changing qtscore
> and summary.snp.data. For myself, I see a routine work with spending 95%
> time for understanding what is written there. If some of you can consult
> me here, it would accelerate everything (for example: what was the
> reason for creating iteratorGA?)

I'm sorry, as you can see by my comment below, I don't know either.

> 
> What do you think about the plan? Do you see any pitfalls? Would like to
> contribute :-)?

Given my suggestion/plan/wish to have filevector as a proper (not R
related) library, I think it would be good to see how other R packages
handle dependencies on external libraries. And how they interface to
them. This should be OK as I'm sure many packages do. I think it is
enough to add
SystemRequirements: libfilevector
to the DESCRIPTION file.

With respect to GenABEL depending on a shared library provided by
DatABEL I'm a bit worried by the following section in the R extensions
manual:
http://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Linking-to-other-packages:
"It is not in general possible to link a DLL in package packA to a DLL
provided by package packB".
Although section 5.8.1 seems to provide a possibility:
"It is possible to link a shared object in package packA to a library
provided by package packB under limited circumstances on a Unix-alike OS."
A bit of discussion on this can be found on stackoverflow.com:
http://stackoverflow.com/questions/12328156/r-package-that-links-to-external-c-library


> 
> Small remark: The name iterator is already used in stl C++ library
> (compliler told it to me when I was implementing R_init_DatABEL.cpp in
> DatABEL).  So, we need to change it to something like "iteratorDA".

I completely agree. Just 'iterator' is too confusing with the C++ notion
of iterator.


Thanks for digging through all this,

Lennart.

> 
> best,
> Maksim
> 
> _______________________________________________
> genabel-devel mailing list
> genabel-devel at lists.r-forge.r-project.org
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/genabel-devel

-- 
-----------------------------------------------------------------
L.C. Karssen
Utrecht
The Netherlands

lennart at karssen.org
http://blog.karssen.org

Stuur mij aub geen Word of Powerpoint bestanden!
Zie http://www.gnu.org/philosophy/no-word-attachments.nl.html
------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: OpenPGP digital signature
URL: <http://lists.r-forge.r-project.org/pipermail/genabel-devel/attachments/20131115/4d375aeb/attachment.sig>