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

[Maksim Struchalin]

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

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

_____________________________________________________



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?


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

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