Re: [Rd] Sligthly OT Re: Makefile for embedding OpenBUGS in R package
Tobias Verbeke wrote: Hi Ben, Tobias Verbeke tobias.verbeke at businessdecision.com writes: The resulting package now allows for using an embedded OpenBUGS on GNU/Linux without relying on WINE. Thanks to all for their helpful comments. woo-hoo! this is great! Any chance that this will propagate to the R2WinBUGS package at some point ... ??? A quick look at R2WinBUGS reveals that this package does not embed the OpenBUGS distribution within the package. This is not needed per se, but will then imply that the user has to compile the C file that accesses the brugs.so shared library (or a variant as the path to the bugs executable is an argument to the bugs function in R2WinBUGS). When I worked on this (for a specific application a client had in mind), I deliberately chose to avoid any administration in addition to ordinary R package installation. The BRugs package, on the contrary, embeds a (previous) version of OpenBUGS and could use what we found out in this thread, but then the interface of BRugs is more designed for interactive use of BUGS which currently still is possible only on Windows. It might be an idea to modify the BRugsFit function (BRugs' meta function) to run a script file in one go when it runs on GNU/Linux. This modification is needed as the current BRugsfit uses the interactive commands modelCheck(), modelCompile() etc. in separate steps. If the maintainer (in cc) would think this is a good idea, the following things should then be assured within the BRugs package in addition of changing BRugsFit function for it to work under Linux: (1) all of the BUGS files (data, model, inits and script files) should have CR LF line endings (2) the script file produced should end on modelQuit() without any additional character (no newline) Alternatively, it could be put into (yet another) R - BUGS package, but this would duplicate a lot of the BRugs code. I'm fine with it, but I'd prefer to have such wrappers in R2WinBUGS (which already includes all those ugly wrappers). BRugs was intended to have a more or less clean interface and I'd like to see a working .so that would be available at some point for running under Linux. So if anybody has the knowledge and tools to help Andrew Thomas, please do. Additions to R2WinBUGS and BRugs are welcome. Please send patches against the sources on sourceforge (http://sourceforge.net/projects/bugs-r), since considerable changes have been made in the current developer version: e.g. integration of OpenBUGS 3.0.1 (thanks to Insightful), ports to S-PLUS (thanks to Insightful). Please make sure any changes will not break behaviour under S-PLUS. Thanks you very much for contributing to BRugs! Best, Uwe Kind regards, Tobias __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sligthly OT Re: Makefile for embedding OpenBUGS in R package
Hin-Tak Leung wrote:
Tobias Verbeke wrote:
snipped
Actually, I think Hin-Tak is right about the absolute path. Even when
the R code will call the executable that resides in that directory, R
will call it from any directory and that (current) directory will be
resolved (at least that is what I observe experimentally).
When such an absolute path is coded in, everything runs fine -- we now
can run a BUGS script from within R under GNU/Linux !
It would however be nice to solve the remaining problem of the
absolute path in the dlopen() call, i.e. being able to fill in
`dynamically' the library path to which the package is actually
installed.
Is there a way to have the library path to which a package is
installed available during package installation and then to do some
text-processing to fill in this path dynamically into the C file i.e.
as argument of dlopen() before compiling it?
snipped
I don't know if there is a neater way of doing this, but one somewhat
clunky way is to process the result of .libPath() , append each of its
elements by package/inst/OpenBUGS/bugs.so and test if the file exists,
(.libPath() should be quite a small character vector so it should be too
slow to test every one), then pass the result as an explicit
argument to the main bugs binary before everything else it takes.
I think there is a more clever way of telling where the current package
is installed/located but it escapes me at the moment. Perhaps the source
code of data() (just typying 'data' without the () at the comment prompt
will display the source), can shed some lights on this, since data()
does something quite similiar.
Thank you, Hin-Tak, for pointing me in the right direction.
Please find below the final C code I use to get OpenBUGS
running.
#include stdlib.h
#include stdio.h
#include dlfcn.h
int main (int argc, char *argv[])
{
void * handle;
void (*cli)(void);
char * error;
char * sopath;
sopath = argv[1]; /* path of brugs.so */
handle = dlopen(sopath, RTLD_LAZY);
if (!handle) {
fprintf (stderr, %s\n, dlerror());
exit(1);
}
* (void **) (cli) = dlsym(handle, CLI);
if ((error = dlerror()) != NULL) {
fprintf (stderr, %s\n, error);
exit(1);
}
(*cli)();
dlclose(handle);
return 0;
}
At the R level, the use of system.file seemed to me to be
the most generally applicable. The relevant lines from the
calling R code are:
## construct system command
exe - if (iswin) bugs.exe else linbugs
sofile - brugs.so
OpenBUGSpath - system.file(OpenBUGS, package = CGHmix)
pathexe - file.path(OpenBUGSpath, exe)
pathso - file.path(OpenBUGSpath, sofile)
cmd - if (iswin){
paste(pathexe, , scriptfile, , resultsfile, sep = )
} else {
paste(pathexe, pathso, , scriptfile, , resultsfile,
sep = )
}
system(cmd)
The resulting package now allows for using an embedded OpenBUGS
on GNU/Linux without relying on WINE. Thanks to all for their helpful
comments.
Kind regards,
Tobias
--
Tobias Verbeke - Consultant
Business Decision Benelux
Rue de la révolution 8
1000 Brussels - BELGIUM
+32 499 36 33 15
[EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sligthly OT Re: Makefile for embedding OpenBUGS in R package
Tobias Verbeke tobias.verbeke at businessdecision.com writes: The resulting package now allows for using an embedded OpenBUGS on GNU/Linux without relying on WINE. Thanks to all for their helpful comments. woo-hoo! this is great! Any chance that this will propagate to the R2WinBUGS package at some point ... ??? Ben Bolker __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sligthly OT Re: Makefile for embedding OpenBUGS in R package
Hi Ben, Tobias Verbeke tobias.verbeke at businessdecision.com writes: The resulting package now allows for using an embedded OpenBUGS on GNU/Linux without relying on WINE. Thanks to all for their helpful comments. woo-hoo! this is great! Any chance that this will propagate to the R2WinBUGS package at some point ... ??? A quick look at R2WinBUGS reveals that this package does not embed the OpenBUGS distribution within the package. This is not needed per se, but will then imply that the user has to compile the C file that accesses the brugs.so shared library (or a variant as the path to the bugs executable is an argument to the bugs function in R2WinBUGS). When I worked on this (for a specific application a client had in mind), I deliberately chose to avoid any administration in addition to ordinary R package installation. The BRugs package, on the contrary, embeds a (previous) version of OpenBUGS and could use what we found out in this thread, but then the interface of BRugs is more designed for interactive use of BUGS which currently still is possible only on Windows. It might be an idea to modify the BRugsFit function (BRugs' meta function) to run a script file in one go when it runs on GNU/Linux. This modification is needed as the current BRugsfit uses the interactive commands modelCheck(), modelCompile() etc. in separate steps. If the maintainer (in cc) would think this is a good idea, the following things should then be assured within the BRugs package in addition of changing BRugsFit function for it to work under Linux: (1) all of the BUGS files (data, model, inits and script files) should have CR LF line endings (2) the script file produced should end on modelQuit() without any additional character (no newline) Alternatively, it could be put into (yet another) R - BUGS package, but this would duplicate a lot of the BRugs code. Kind regards, Tobias -- Tobias Verbeke - Consultant Business Decision Benelux Rue de la révolution 8 1000 Brussels - BELGIUM +32 499 36 33 15 [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sligthly OT Re: Makefile for embedding OpenBUGS in R package
Hin-Tak Leung wrote: Prof Brian Ripley wrote: OpenBUGS is distributed under GPL2, so this seems not to apply. It is distributed as source and as binaries: the difficulty is that it is written in Object Pascal for which a compiler is not readily available. Argh, I just thought of a proper technical reason, and I think I have spotted a possible bug in the original poster's code! Some choose to do dlopen() when the DLL/so is in a non-standard/non-system location, as an alternative to setting LD_LIBRARY_PATH explicitly or other link-loader magics. The line: handle = dlopen(./brugs.so, RTLD_LAZY); Seems to suggest this, However, the problem with this code, is that the current directory (./) may not be where the user thinks it is. I think the user meant to prepend $R_HOME/library/package/inst/ somehow to brugs.so, and dlopen'ing $R_HOME/library/package/inst/brugs.so instead. No, it's fine if the executable is started in the same directory, and that can be assured by the calling R code. Otherwise it will only work if you have the package in the main library of R. Anyway, it is still highly preferable to just load the Bugs lib into R, if we only could compile the stuff... Uwe Hin-Tak snipped __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sligthly OT Re: Makefile for embedding OpenBUGS in R package
Thank you very much for your input. In the meantime I was -- thanks to the pointer to the Rserve Makefile by Professor Ripley -- able to have a Makefile that built the package correctly: SFILE = ../inst/OpenBUGS/linbugs.c XFILE = ../inst/OpenBUGS/linbugs SOFILE = ../src/linbugs.so all: $(XFILE) copyop $(XFILE): $(SFILE) gcc -m32 -o $(XFILE) $(SFILE) -ldl copyop: $(XFILE) # Only *.so get copied. Therefore we need to fake the bin files as .sos to get # copied. Not a nice hack, but it works... (Comment from Rserve) cp $(XFILE) $(SOFILE) clean: rm -f *.so *~ $(XFILE) .PHONY: copyop clean (Note that I changed the naming of the C source and compiled file following a complaint by the package checker that observed that the OpenBUGS distribution has a directory Bugs which on case-insensitive systems could be confused with bugs, the previous name of the executable) Uwe Ligges wrote: Hin-Tak Leung wrote: Prof Brian Ripley wrote: OpenBUGS is distributed under GPL2, so this seems not to apply. It is distributed as source and as binaries: the difficulty is that it is written in Object Pascal for which a compiler is not readily available. Argh, I just thought of a proper technical reason, and I think I have spotted a possible bug in the original poster's code! Some choose to do dlopen() when the DLL/so is in a non-standard/non-system location, as an alternative to setting LD_LIBRARY_PATH explicitly or other link-loader magics. The line: handle = dlopen(./brugs.so, RTLD_LAZY); Seems to suggest this, However, the problem with this code, is that the current directory (./) may not be where the user thinks it is. I think the user meant to prepend $R_HOME/library/package/inst/ somehow to brugs.so, and dlopen'ing $R_HOME/library/package/inst/brugs.so instead. This should be $R_HOME/library/package/OpenBUGS/brugs.so (without the inst level that is taken out when installing the package) No, it's fine if the executable is started in the same directory, and that can be assured by the calling R code. Otherwise it will only work if you have the package in the main library of R. Anyway, it is still highly preferable to just load the Bugs lib into R, if we only could compile the stuff... Actually, I think Hin-Tak is right about the absolute path. Even when the R code will call the executable that resides in that directory, R will call it from any directory and that (current) directory will be resolved (at least that is what I observe experimentally). When such an absolute path is coded in, everything runs fine -- we now can run a BUGS script from within R under GNU/Linux ! It would however be nice to solve the remaining problem of the absolute path in the dlopen() call, i.e. being able to fill in `dynamically' the library path to which the package is actually installed. Is there a way to have the library path to which a package is installed available during package installation and then to do some text-processing to fill in this path dynamically into the C file i.e. as argument of dlopen() before compiling it? Thanks again, Tobias -- Tobias Verbeke - Consultant Business Decision Benelux Rue de la révolution 8 1000 Brussels - BELGIUM +32 499 36 33 15 [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sligthly OT Re: Makefile for embedding OpenBUGS in R package
Tobias Verbeke wrote: snipped Actually, I think Hin-Tak is right about the absolute path. Even when the R code will call the executable that resides in that directory, R will call it from any directory and that (current) directory will be resolved (at least that is what I observe experimentally). When such an absolute path is coded in, everything runs fine -- we now can run a BUGS script from within R under GNU/Linux ! It would however be nice to solve the remaining problem of the absolute path in the dlopen() call, i.e. being able to fill in `dynamically' the library path to which the package is actually installed. Is there a way to have the library path to which a package is installed available during package installation and then to do some text-processing to fill in this path dynamically into the C file i.e. as argument of dlopen() before compiling it? snipped I don't know if there is a neater way of doing this, but one somewhat clunky way is to process the result of .libPath() , append each of its elements by package/inst/OpenBUGS/bugs.so and test if the file exists, (.libPath() should be quite a small character vector so it should be too slow to test every one), then pass the result as an explicit argument to the main bugs binary before everything else it takes. I think there is a more clever way of telling where the current package is installed/located but it escapes me at the moment. Perhaps the source code of data() (just typying 'data' without the () at the comment prompt will display the source), can shed some lights on this, since data() does something quite similiar. Good luck, and it is an interesting discussion so far. Hin-Tak __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sligthly OT Re: Makefile for embedding OpenBUGS in R package
Prof Brian Ripley wrote: OpenBUGS is distributed under GPL2, so this seems not to apply. It is distributed as source and as binaries: the difficulty is that it is written in Object Pascal for which a compiler is not readily available. Argh, I just thought of a proper technical reason, and I think I have spotted a possible bug in the original poster's code! Some choose to do dlopen() when the DLL/so is in a non-standard/non-system location, as an alternative to setting LD_LIBRARY_PATH explicitly or other link-loader magics. The line: handle = dlopen(./brugs.so, RTLD_LAZY); Seems to suggest this, However, the problem with this code, is that the current directory (./) may not be where the user thinks it is. I think the user meant to prepend $R_HOME/library/package/inst/ somehow to brugs.so, and dlopen'ing $R_HOME/library/package/inst/brugs.so instead. Hin-Tak snipped __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sligthly OT Re: Makefile for embedding OpenBUGS in R package
Hi Hin-Tak, On Tue, Aug 07, 2007 at 01:10:36AM +0100, Hin-Tak Leung wrote: GPL-licensed code dlopen()'ing proprietary-licensed binary-only DLL/so is allowed Do you have any evidence? (eg: something written on www.fsf.org?) As far as I know, the normal grounds for allowing GPL code to link with proprietary code is the text However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. Cheers, Andrew __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sligthly OT Re: Makefile for embedding OpenBUGS in R package
Andrew Clausen wrote: Hi Hin-Tak, On Tue, Aug 07, 2007 at 01:10:36AM +0100, Hin-Tak Leung wrote: GPL-licensed code dlopen()'ing proprietary-licensed binary-only DLL/so is allowed Do you have any evidence? (eg: something written on www.fsf.org?) As far as I know, the normal grounds for allowing GPL code to link with proprietary code is the text However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. I don't - but openbugs (if you assume it to be the 'major' component) is certainly not part of the OSes on which the resulting executable runs. Consider a few well-known applications in the x86 linux world for loading binary-only windows DLLs - e.g. ndiswrapper, mplayer. They distribute the different licensed components separately, or ask the users to get it elsewhere. *Re-distribution* (not usage of) of components bundling together having different re-distributing licensing terms is a sticky matter. Hin-Tak P.S. I don't know if the original poster has any intention of distributing his package for others to use; but having parts of his package distributed binary-only and also under a different and more restrictive license term can be sticky. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sligthly OT Re: Makefile for embedding OpenBUGS in R package
OpenBUGS is distributed under GPL2, so this seems not to apply. It is distributed as source and as binaries: the difficulty is that it is written in Object Pascal for which a compiler is not readily available. On Tue, 7 Aug 2007, Hin-Tak Leung wrote: Prof Brian Ripley wrote: On Mon, 6 Aug 2007, Tobias Verbeke wrote: snipped I presume. Actually, these files appear to differ. The file I referred to was the file ./Manuals/CBugs.html contained in the current OpenBUGS release: http://mathstat.helsinki.fi/openbugs/OpenBUGS.zip I am baffled by that C file: why not just link an even simpler stub against brugs.so rather than play around with dlopen? snipped [I am not familiar with openbugs nor its licensing terms, but seeing as it is distributed as part-binary-only...] I agree there is little technical reasons for dlopen() vs a simpler stub, but there is occasionally licensing/legal reasons for doing so - GPL-licensed code dlopen()'ing proprietary-licensed binary-only DLL/so is allowed, but a 'more intimate' linking of GPL-code with more restrictive code is sometimes troublesome in its licensing status. But the C code is also under GPL2: see the comment on the web page I mentioned. Doing what Tobias is proposing (communicating with another program via files) is generally accepted as allowed under different licencing agreements. The whole brugs executable would be under GPL2. (for private/internal use, there is no reason for going the dlopen() routine...) Just an idea... Hin-Tak -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
