[GenABEL-dev] ISNAN problem in filevector found by Jenkins

Tue Nov 19 15:17:11 CET 2013

Hi Lennart,

I see you are improving your Russian :-).

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). 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.

best,
Maksim

On 19/11/2013 16:10, L.C. Karssen wrote:
> Hi ??????,
>
> (trying a Russian keyboard layout, no idea if this works...).
>
> On 19-11-13 09:44, Maksim Struchalin wrote:
>> 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.
> 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.
>
>> 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.
> 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).
>
>
>> 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.
> I think this is what should be done with the DAlib directory (another
> symlinked dir).
>
>>   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.
>>
>> _____________________________________________________
>>
> 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.
>
>>
>> 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?
> Yes, as far as I understand, they mean linking to a library during
> installation/compilation.
>
>
> Best,
>
> Lennart.
>>
>> best,
>> Maksim
>>
>>
>>
>> On 19/11/2013 15:14, L.C. Karssen wrote:
>>> 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:
>>> http://cran.r-project.org/web/packages/XML/index.html and the Rcurl
>>> package depends on libcurl:
>>> http://cran.r-project.org/web/packages/RCurl/index.html
>>>
>>> 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:
>>>> Hi Lennart,
>>>>
>>>> How the users under win will install such a library?
>>>>
>>>> best,
>>>> Maksim
>>>>
>>>> On 19/11/2013 14:46, L.C. Karssen wrote:
>>>>> 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
>>>>> genabel-devel at lists.r-forge.r-project.org
>>>>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/genabel-devel
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>> _______________________________________________
>> 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
>>
>
>
> _______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/genabel-devel/attachments/20131119/79119437/attachment.html>