<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Lennart,<br>
<br>
<a class="moz-txt-link-freetext" href="https://app.box.com/s/iy41ug5qg4sbylul9oyn">https://app.box.com/s/iy41ug5qg4sbylul9oyn</a><br>
<br>
This is an example demonstrating how a GenABEL function
"impute2databel" calls a function "iteratorDA" from DatABEL. Here,
GenABEL is compiled without flv's and iterator's code (I deleted
it from src).<br>
<br>
Could you run the test?:<br>
0) Dowload the file test_GenABEL_iterator.tar.gz from
<a class="moz-txt-link-freetext" href="https://app.box.com/s/iy41ug5qg4sbylul9oyn">https://app.box.com/s/iy41ug5qg4sbylul9oyn</a><br>
1) decompress test_GenABEL_iterator.tar.gz<br>
2) cd test_GenABEL_iterator<br>
3) R CMD INSTALL DatABEL_0.9-4.tar.gz<br>
4) R CMD INSTALL GenABEL_1.7-7.tar.gz<br>
5) run test.R<br>
<br>
It works on my Ubuntu. If it works on your Ubuntu, win and mac,
then we can delete from GenABEL the simlinks to flv and databel.<br>
<br>
best,<br>
Максим<br>
<br>
<br>
On 22/11/2013 21:34, L.C. Karssen wrote:<br>
</div>
<blockquote cite="mid:528F6B78.20004@karssen.org" type="cite">
<pre wrap="">Hi максим,
On 11/19/2013 03:17 PM, Maksim Struchalin wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Lennart,
I see you are improving your Russian :-).
</pre>
</blockquote>
<pre wrap="">
Getting to know the Russian alphabet is step one :-).
</pre>
<blockquote type="cite">
<pre wrap="">
I understand your arguments. I think we can combine our two approaches.
1) We make a so/dll from filevector and let it use by
ProbABEL/OmicABEL/Another_not_R_softABEL.
2) For GenABEL and other R packages, we make a DatABEL.
The code of filevector is the same both for 1) and 2).
</pre>
</blockquote>
<pre wrap="">
But that doesn't solve the problem of having symlinks to the fvlib
directory in our SVN tree... Which means that any update to filevector
can make the depending package (DatABEL) become uncompilable.
In the mean time I've set the first steps towards 'libfilevector' in
SVN, see commits 1415 and 1416. This works (at least for ProbABEL), but
more polishing is needed.
</pre>
<blockquote type="cite">
<pre wrap="">We only add
preprocessor commands (#ifdef and so on) to surround R specific code
(ISNAN() and std::isnan). In this case, compiler choose itself weather
it buids the lib for R or for OS.
If we will want to use only approach 1) for GenABEL in the future, we
can quickly swith to it later.
</pre>
</blockquote>
<pre wrap="">
True, for now this will work.
Best,
Lennart.
</pre>
<blockquote type="cite">
<pre wrap="">
best,
Maksim
On 19/11/2013 16:10, L.C. Karssen wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi максим,
(trying a Russian keyboard layout, no idea if this works...).
On 19-11-13 09:44, Maksim Struchalin wrote:
</pre>
<blockquote type="cite">
<pre wrap="">It seems that your solution is workable but I see little difference with
what it is now. Now the filevector code is incorporated in each
packages.
</pre>
</blockquote>
<pre wrap="">This is what I would like to change, indeed. Code that is reused by so
many packages should not be copied/symlinked into the code tree of those
packages. By symlinking it as we have now, there is no proper way of
specifying a version number of the filevector code. Which, in turn means
that if something changes in the filevector code all other packages need
to be changed immediately (just like what happened with your latest
change). If the filevector code have been a proper library we could have
simply said that ProbABEL still depends on the old filevector version
and take more time to make sure the two play nice together.
Moreover, with the filevector code in a separate library the whole
isnan() issue would not be a problem. We could simply use std::isnan(),
because CRAN wouldn't need to compile the .so/.dll, so no need of ISNAN().
When code is put in a library the internals don't matter as long as the
interface (function names + arguments) to the outside doesn't change.
</pre>
<blockquote type="cite">
<pre wrap="">You propose to follow the same way but pack filelvector code
in one file (dll or so) and distribute 9 packages form GenABEL with the
same library.
</pre>
</blockquote>
<pre wrap="">Indeed. The problem with incorporating it all in DatABEL is that non-R
packages like ProbABEL and OmicABEL depend on the stuff in the fvlib
directory as well. Filevector is central to (almost) all packages in the
GenABEL suite, which is why I proposed to make a library out of it. And,
as noted above, this way packages can depend on different version of the
library.
We can of course discuss whether we want to distribute this .so/.dll as
a separate (operating system) package or withing the R packages. To me
the first option is the 'correct' one, but I see that this may impose on
the user (except on Windows and maybe MacOS, where the .so/.dll is
included in the R package).
</pre>
<blockquote type="cite">
<pre wrap="">Last time I proposed to move filevector in DatABEL. All other packages
(GenA and so on) will load DatAB in R and use filevector fucntions from
DatA. When DatABEL is loaded through library(DatABEL), the file
DatABEL.so is loaded as well.
</pre>
</blockquote>
<pre wrap="">I think this is what should be done with the DAlib directory (another
symlinked dir).
</pre>
<blockquote type="cite">
<pre wrap=""> Thus, you do not need to ask users to
install additional lib because it is in DatABEL already. I think this is
a workable approach that will allow us to delete the filevector code (or
filevector so/dll) from all the packages.
This is some quote from the R manual how to register functions to make
it available from DatAB to GenAB:
_______________________________________________
5.4 Registering native routines
By ‘native’ routine, we mean an entry point in compiled code.
In calls to |.C|, |.Call|, |.Fortran| and |.External|, R must locate the
specified native routine by looking in the appropriate shared
object/DLL. By default, R uses the operating system-specific dynamic
loader to lookup the symbol in all loaded DLLs and elsewhere.
Alternatively, the author of the DLL can explicitly register routines
with R and use a single, platform-independent mechanism for finding the
routines in the DLL. One can use this registration mechanism to provide
additional information about a routine, including the number and type of
the arguments, and also make it available to R programmers under a
different name. In the future, registration may be used to implement a
form of “secure” or limited native access.
_____________________________________________________
</pre>
</blockquote>
<pre wrap="">Hmm, I will have to think about this. This seems to be about how R finds
out in which DLL a function is found (and maybe where the DLL is found
in the filesystem). I think this is separate from the point below, but
I'm not sure.
</pre>
<blockquote type="cite">
<pre wrap="">
Your argument was from "5.8 Linking to other packages: It is not in
general possible to link a DLL in package *packA* to a DLL provided by
package *packB". *I do not quite understand what they mean under 'link'.
May be the mean link a library during intsalltion?
</pre>
</blockquote>
<pre wrap="">Yes, as far as I understand, they mean linking to a library during
installation/compilation.
Best,
Lennart.
</pre>
<blockquote type="cite">
<pre wrap="">
best,
Maksim
On 19/11/2013 15:14, L.C. Karssen wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Maksim,
Good question... The idea is to generate a .dll file for Windows, but
I'm not sure what would be the best way to distribute that. It would be
interesting to see how other packages do that. For example, the XML
package depends on libxml2:
<a class="moz-txt-link-freetext" href="http://cran.r-project.org/web/packages/XML/index.html">http://cran.r-project.org/web/packages/XML/index.html</a> and the Rcurl
package depends on libcurl:
<a class="moz-txt-link-freetext" href="http://cran.r-project.org/web/packages/RCurl/index.html">http://cran.r-project.org/web/packages/RCurl/index.html</a>
In the XML package .zip file for Windows there is a directory libs/x64
and a directory libs/i386. Both contain XML.dll, so I think that for
Linux you simply specify a dependency on a library, whereas for Windows
the actual .dll is in the package (which is quite logical because
Windows lacks the package repositories that most Linux distros have).
It seems that for MacOS the .tgz file also contains a lib directory with
the .so file.
Best regards,
Lennart.
On 19-11-13 08:56, Maksim Struchalin wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Lennart,
How the users under win will install such a library?
best,
Maksim
On 19/11/2013 14:46, L.C. Karssen wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Dear all,
The Jenkins setup already shows its value: After Maksim changed the call
from std::isnan() to ISNAN() in fvlib's CastUtils.cpp an automatic build
of ProbABEL was triggered and it failed (because ISNAN() is an R function).
I guess this is one more reason to try to convert fvlib into a real
(shared) library.
Does anyone have another workable solution?
Lennart.
_______________________________________________
genabel-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:genabel-devel@lists.r-forge.r-project.org">genabel-devel@lists.r-forge.r-project.org</a>
<a class="moz-txt-link-freetext" href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/genabel-devel">https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/genabel-devel</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
genabel-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:genabel-devel@lists.r-forge.r-project.org">genabel-devel@lists.r-forge.r-project.org</a>
<a class="moz-txt-link-freetext" href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/genabel-devel">https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/genabel-devel</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
genabel-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:genabel-devel@lists.r-forge.r-project.org">genabel-devel@lists.r-forge.r-project.org</a>
<a class="moz-txt-link-freetext" href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/genabel-devel">https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/genabel-devel</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
genabel-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:genabel-devel@lists.r-forge.r-project.org">genabel-devel@lists.r-forge.r-project.org</a>
<a class="moz-txt-link-freetext" href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/genabel-devel">https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/genabel-devel</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
genabel-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:genabel-devel@lists.r-forge.r-project.org">genabel-devel@lists.r-forge.r-project.org</a>
<a class="moz-txt-link-freetext" href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/genabel-devel">https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/genabel-devel</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
genabel-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:genabel-devel@lists.r-forge.r-project.org">genabel-devel@lists.r-forge.r-project.org</a>
<a class="moz-txt-link-freetext" href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/genabel-devel">https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/genabel-devel</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
genabel-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:genabel-devel@lists.r-forge.r-project.org">genabel-devel@lists.r-forge.r-project.org</a>
<a class="moz-txt-link-freetext" href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/genabel-devel">https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/genabel-devel</a></pre>
</blockquote>
<br>
</body>
</html>