Re: [Rd] Optimization in R
I would like to add a remark and a question. Remark. There is a part of R, which allows the user to select among several methods for the same task and also to add his own C code: random number generation. However, the interface for optimization is more complex. In my opinion, looking for a unified interface for this is desirable, but it is a research problem, not a suggestion for an immediate code modification. Question. Is there a way how to optimize a function written in C using optim? This would be very useful, if the optimization needs a lot of iterations. This may be done by defining an R function, which does nothing more than calling .C with appropriate parameters, but this looses efficiency. A more efficient solution could be adding a specified entry point (or several, if derivatives are also available), similar as in the user defined random number generator. Then, a parameter of optim could control, whether the function to be optimized is fn or the C entry point. Petr Savicky. I don't have an example of that but that does not make it less desirable. If one wants to use method 1, 2 or 3 then one can use optim with a method= but if one wants to use methods 4 or 5 then one must use an entirely different function. Surely it would be better to be consistent from the user's viewpoint and allow all of them to work consistently through the same interface. On 8/4/07, Duncan Murdoch [EMAIL PROTECTED] wrote: On 04/08/2007 2:53 PM, Gabor Grothendieck wrote: The example of generic functions. Show me an example where we have a list of ways to do a calculation passed as an argument (analogous to the method argument of optim), where the user is allowed to add his own function to the list. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Optimization in R
I am sorry for omitting a citation in my previous post. The complete message is as follows (my text unchanged). PS I would like to add a remark and a question. Remark. There is a part of R, which allows the user to select among several methods for the same task and also to add his own C code: random number generation. However, the interface for optimization is more complex. In my opinion, looking for a unified interface for this is desirable, but it is a research problem, not a suggestion for an immediate code modification. Question. Is there a way how to optimize a function written in C using optim? This would be very useful, if the optimization needs a lot of iterations. This may be done by defining an R function, which does nothing more than calling .C with appropriate parameters, but this looses efficiency. A more efficient solution could be adding a specified entry point (or several, if derivatives are also available), similar as in the user defined random number generator. Then, a parameter of optim could control, whether the function to be optimized is fn or the C entry point. Petr Savicky. On Sat, Aug 04, 2007 at 06:56:47PM -0400, Gabor Grothendieck wrote: I don't have an example of that but that does not make it less desirable. If one wants to use method 1, 2 or 3 then one can use optim with a method= but if one wants to use methods 4 or 5 then one must use an entirely different function. Surely it would be better to be consistent from the user's viewpoint and allow all of them to work consistently through the same interface. On 8/4/07, Duncan Murdoch [EMAIL PROTECTED] wrote: On 04/08/2007 2:53 PM, Gabor Grothendieck wrote: The example of generic functions. Show me an example where we have a list of ways to do a calculation passed as an argument (analogous to the method argument of optim), where the user is allowed to add his own function to the list. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Makefile for embedding OpenBUGS in R package
Dear list, I'm trying to embed OpenBUGS in an R package for use of it on 64-bit Linux. In order to get the CLI working one has to compile C code contained in $OpenBUGS/Manuals/CBugs.html (copied to say CBugs.c) using gcc -m32 -o bugs CBugs.c -ldl I put the OpenBUGS distribution in the ./inst subdirectory of the package root. Where should I now put the CBugs.c and how should the Makefile look like in order to be able to call $PKG_ROOT/OpenBUGS/bugs afterwards ? Naively putting the following Makefile in ./src does not work -% bugs: ../inst/OpenBUGS/CBugs.c gcc -m32 -o bugs ../inst/OpenBUGS/CBugs.c -ldl -%--- The objective is to use something along the following execfile - system.file(OpenBUGS, bugs, package = mypkg) system(paste(execfile, somescript.script somefile.out)) This system call to the CLI is currently the only (non-WINE) way of using OpenBUGS on Linux in batch mode. Many thanks in advance, 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] Makefile for embedding OpenBUGS in R package
On Mon, 6 Aug 2007, Tobias Verbeke wrote: Dear list, I'm trying to embed OpenBUGS in an R package for use of it on 64-bit Linux. In order to get the CLI working one has to compile C code contained in $OpenBUGS/Manuals/CBugs.html same as http://mathstat.helsinki.fi/openbugs/data/Docu/CBugs.html I presume. (copied to say CBugs.c) using gcc -m32 -o bugs CBugs.c -ldl I put the OpenBUGS distribution in the ./inst subdirectory of the package root. Where should I now put the CBugs.c and how Why do you want to install CBugs.c? should the Makefile look like in order to be able to call $PKG_ROOT/OpenBUGS/bugs afterwards ? Naively putting the following Makefile in ./src does not work What does 'does not work' mean? It's hard to know whether this is just not doing what you wanted, or something else is wrong. -% bugs: ../inst/OpenBUGS/CBugs.c gcc -m32 -o bugs ../inst/OpenBUGS/CBugs.c -ldl -%--- The objective is to use something along the following execfile - system.file(OpenBUGS, bugs, package = mypkg) system(paste(execfile, somescript.script somefile.out)) This system call to the CLI is currently the only (non-WINE) way of using OpenBUGS on Linux in batch mode. I think you need to make ../inst/OpenBUGS/bugs, not src/bugs. So something like all: ../inst/OpenBUGS/bugs ../inst/OpenBUGS/bugs: ../inst/OpenBUGS/CBugs.c gcc -m32 -o ../inst/OpenBUGS/bugs ../inst/OpenBUGS/CBugs.c -ldl However, -m32 builds a 32-bit executable on 64-bit linux. Is that what you wanted? -- 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
Re: [Rd] Makefile for embedding OpenBUGS in R package
- Oorspronkelijk bericht -
Van: Prof Brian Ripley [mailto:[EMAIL PROTECTED]
Verzonden: maandag, augustus 6, 2007 03:46 PM
Aan: 'Tobias Verbeke'
CC: r-devel@r-project.org
Onderwerp: Re: [Rd] Makefile for embedding OpenBUGS in R package
On Mon, 6 Aug 2007, Tobias Verbeke wrote:
Dear list,
I'm trying to embed OpenBUGS in an R package for use of it
on 64-bit Linux. In order to get the CLI working one has to
compile C code contained in $OpenBUGS/Manuals/CBugs.html
same as
http://mathstat.helsinki.fi/openbugs/data/Docu/CBugs.html
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
(copied to say CBugs.c) using
gcc -m32 -o bugs CBugs.c -ldl
I put the OpenBUGS distribution in the ./inst subdirectory of
the package root. Where should I now put the CBugs.c and how
Why do you want to install CBugs.c?
The CBugs.c file itself is indeed not needed in the built package.
should the Makefile look like in order to be able to call
$PKG_ROOT/OpenBUGS/bugs afterwards ?
Naively putting the following Makefile in ./src does not work
What does 'does not work' mean? It's hard to know whether this is just
not doing what you wanted, or something else is wrong.
Apologies. This is the error message when putting the Makefile
in ./src and launching the package checker:
$ R.250 CMD check CGHmix
DISPLAY=localhost:10.0
* checking for working latex ... OK
* using log directory '/home/tverbek1/pkg/CGHmix.Rcheck'
* using R version 2.5.0 (2007-04-23)
* checking for file 'CGHmix/DESCRIPTION' ... OK
* checking extension type ... Package
* this is package 'CGHmix' version '0.1-2'
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking whether package 'CGHmix' can be installed ... ERROR
Installation failed.
See '/home/tverbek1/pkg/CGHmix.Rcheck/00install.out' for details.
The file 00install.out contains:
* Installing *source* package 'CGHmix' ...
** libs
** arch -
gcc -m32 -o ../inst/OpenBUGS/bugs ../inst/OpenBUGS/CBugs.c -ldl
cp: cannot stat `*.so': No such file or directory
ERROR: compilation failed for package 'CGHmix'
** Removing '/home/tverbek1/pkg/CGHmix.Rcheck/CGHmix'
-%
bugs: ../inst/OpenBUGS/CBugs.c
gcc -m32 -o bugs ../inst/OpenBUGS/CBugs.c -ldl
-%---
The objective is to use something along the following
execfile - system.file(OpenBUGS, bugs, package = mypkg)
system(paste(execfile, somescript.script somefile.out))
This system call to the CLI is currently the only (non-WINE)
way of using OpenBUGS on Linux in batch mode.
I think you need to make ../inst/OpenBUGS/bugs, not src/bugs. So
something like
all: ../inst/OpenBUGS/bugs
../inst/OpenBUGS/bugs: ../inst/OpenBUGS/CBugs.c
gcc -m32 -o ../inst/OpenBUGS/bugs ../inst/OpenBUGS/CBugs.c -ldl
Thank you.
However, -m32 builds a 32-bit executable on 64-bit linux. Is that what you
wanted?
Yes. The shared object (brugs.so) comes with the OpenBUGS distribution
and currently can only be cross-compiled by the main OpenBUGS developer
(Andrew Thomas) who knows all secrets of the Windows only BlackBox
(nomen omen) Component Pascal compiler.
$ file brugs.so
brugs.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped
Many thanks for your ever instructive answer.
Tobias
P.S. Contents of CBugs.c from OpenBUGS distribution (3.0.1)
/* GNU General Public Licence
This small C program loads the brugs.so ELF shared library and calls the CLI
function.
Save it as a .c file and then compile it on Linux using gcc -o bugs CBugs.c
-ldl
*/
#include dlfcn.h
#include stdio.h
#include string.h
int main (int argc, char **argv)
{
void * handle;
void (*cli)(void);
handle = dlopen(./brugs.so, RTLD_LAZY);
if (!handle)
return 1;
* (void **) (cli) = dlsym(handle, CLI);
(*cli)();
dlclose(handle);
return 0;
}
--
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
Re: [Rd] Optimization in R
On Mon, 6 Aug 2007, Petr Savicky wrote: Question. Is there a way how to optimize a function written in C using optim? The algorithms used by optim are all accessible from C. The manual Writing R Extensions has a section on The R API, including the optimization routines. -thomas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Makefile for embedding OpenBUGS in R package
As the BRugs maintainer, as far as I can tell, the most recent OpenBUGS
brugs.so is not compatible with (at least) my system and I do not have
the compilers to try it myself. Hence we still only ship BRugs for
Windows, but if anybody else has ideas how to get the BRugs.so compiled
(or just running without traps, I'd be happy to hear about it.
Uwe Ligges
Tobias Verbeke wrote:
- Oorspronkelijk bericht -
Van: Prof Brian Ripley [mailto:[EMAIL PROTECTED]
Verzonden: maandag, augustus 6, 2007 03:46 PM
Aan: 'Tobias Verbeke'
CC: r-devel@r-project.org
Onderwerp: Re: [Rd] Makefile for embedding OpenBUGS in R package
On Mon, 6 Aug 2007, Tobias Verbeke wrote:
Dear list,
I'm trying to embed OpenBUGS in an R package for use of it
on 64-bit Linux. In order to get the CLI working one has to
compile C code contained in $OpenBUGS/Manuals/CBugs.html
same as
http://mathstat.helsinki.fi/openbugs/data/Docu/CBugs.html
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
(copied to say CBugs.c) using
gcc -m32 -o bugs CBugs.c -ldl
I put the OpenBUGS distribution in the ./inst subdirectory of
the package root. Where should I now put the CBugs.c and how
Why do you want to install CBugs.c?
The CBugs.c file itself is indeed not needed in the built package.
should the Makefile look like in order to be able to call
$PKG_ROOT/OpenBUGS/bugs afterwards ?
Naively putting the following Makefile in ./src does not work
What does 'does not work' mean? It's hard to know whether this is just
not doing what you wanted, or something else is wrong.
Apologies. This is the error message when putting the Makefile
in ./src and launching the package checker:
$ R.250 CMD check CGHmix
DISPLAY=localhost:10.0
* checking for working latex ... OK
* using log directory '/home/tverbek1/pkg/CGHmix.Rcheck'
* using R version 2.5.0 (2007-04-23)
* checking for file 'CGHmix/DESCRIPTION' ... OK
* checking extension type ... Package
* this is package 'CGHmix' version '0.1-2'
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking whether package 'CGHmix' can be installed ... ERROR
Installation failed.
See '/home/tverbek1/pkg/CGHmix.Rcheck/00install.out' for details.
The file 00install.out contains:
* Installing *source* package 'CGHmix' ...
** libs
** arch -
gcc -m32 -o ../inst/OpenBUGS/bugs ../inst/OpenBUGS/CBugs.c -ldl
cp: cannot stat `*.so': No such file or directory
ERROR: compilation failed for package 'CGHmix'
** Removing '/home/tverbek1/pkg/CGHmix.Rcheck/CGHmix'
-%
bugs: ../inst/OpenBUGS/CBugs.c
gcc -m32 -o bugs ../inst/OpenBUGS/CBugs.c -ldl
-%---
The objective is to use something along the following
execfile - system.file(OpenBUGS, bugs, package = mypkg)
system(paste(execfile, somescript.script somefile.out))
This system call to the CLI is currently the only (non-WINE)
way of using OpenBUGS on Linux in batch mode.
I think you need to make ../inst/OpenBUGS/bugs, not src/bugs. So
something like
all: ../inst/OpenBUGS/bugs
../inst/OpenBUGS/bugs: ../inst/OpenBUGS/CBugs.c
gcc -m32 -o ../inst/OpenBUGS/bugs ../inst/OpenBUGS/CBugs.c -ldl
Thank you.
However, -m32 builds a 32-bit executable on 64-bit linux. Is that what you
wanted?
Yes. The shared object (brugs.so) comes with the OpenBUGS distribution
and currently can only be cross-compiled by the main OpenBUGS developer
(Andrew Thomas) who knows all secrets of the Windows only BlackBox
(nomen omen) Component Pascal compiler.
$ file brugs.so
brugs.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV),
stripped
Many thanks for your ever instructive answer.
Tobias
P.S. Contents of CBugs.c from OpenBUGS distribution (3.0.1)
/* GNU General Public Licence
This small C program loads the brugs.so ELF shared library and calls the
CLI function.
Save it as a .c file and then compile it on Linux using gcc -o bugs
CBugs.c -ldl
*/
#include dlfcn.h
#include stdio.h
#include string.h
int main (int argc, char **argv)
{
void * handle;
void (*cli)(void);
handle = dlopen(./brugs.so, RTLD_LAZY);
if (!handle)
return 1;
* (void **) (cli) = dlsym(handle, CLI);
(*cli)();
dlclose(handle);
return 0;
}
--
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
[Rd] fortune() candidate?
R will always be arcane to those who do not make a serious effort to learn it. It is ***not*** meant to be intuitive and easy for casual users to just plunge into. -- Bert Gunter, R-help, 06/08/2007 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Compiling R for the Sony Playstation 3?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Barry Rowlingson Sent: Friday, August 03, 2007 10:56 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Douglas Bates; R-devel List Subject: Re: [Rd] Compiling R for the Sony Playstation 3? [snip] Of course if you are doing this for fun I'd like to see a Nintendo Wii port, just so I can play Super Mario Generalised Linear Modelling by waving the controller around. This would put a whole new perspective on the survival package :-) -- Gregory (Greg) L. Snow Ph.D. Statistical Data Center Intermountain Healthcare [EMAIL PROTECTED] (801) 408-8111 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Optimization in R
Thank you for your response. This is a good idea. Although I use my own packages, some of them using other R API's, I missed the optimization ones. Thanks again. Petr Savicky. On Mon, Aug 06, 2007 at 07:16:11AM -0700, Thomas Lumley wrote: On Mon, 6 Aug 2007, Petr Savicky wrote: Question. Is there a way how to optimize a function written in C using optim? The algorithms used by optim are all accessible from C. The manual Writing R Extensions has a section on The R API, including the optimization routines. -thomas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Makefile for embedding OpenBUGS in R package
Hi Uwe,
As the BRugs maintainer, as far as I can tell, the most recent OpenBUGS
brugs.so is not compatible with (at least) my system and I do not have
the compilers to try it myself. Hence we still only ship BRugs for
Windows, but if anybody else has ideas how to get the BRugs.so compiled
(or just running without traps, I'd be happy to hear about it.
My strategy is to produce the data, model and inits file in
a BRugs manner and then produce a script along the lines of
modelCheck('Ratsmodel.txt')
modelData('Ratsdata.txt')
modelCompile()
modelInits('Ratsinits.txt')
modelUpdate(1000)
statsSet('alpha')
statsSet('beta')
modelUpdate(2000)
samplesStats('*')
modelQuit()
which is fed to bugs (compiled as described below) like
./bugs rats.script rats.out
Afterwards I use some simple R utilities to
clean up rats.out and read it in as
as dataframe for further processing.
There are however two (painfully learned and
undocumented) things to keep in mind when
producing these files:
(1) such a script (as well as all other BUGS files)
should use CR LF line endings
(2) There may be absolutely no character (no newline!)
after the final modelQuit() [otherwise you can end
up (like me) with 47 GB of error messages being joyfully
output to rats.out... which is when I had a phone call
from a local sysasmin]
The only missing piece to embed current OpenBUGS in an
R package for automating analyses on Linux is being able
to compile CBugs.c (see below) when building the R package.
I hope this is useful to someone.
Kind regards,
Tobias
Tobias Verbeke wrote:
- Oorspronkelijk bericht -
Van: Prof Brian Ripley [mailto:[EMAIL PROTECTED]
Verzonden: maandag, augustus 6, 2007 03:46 PM
Aan: 'Tobias Verbeke'
CC: r-devel@r-project.org
Onderwerp: Re: [Rd] Makefile for embedding OpenBUGS in R package
On Mon, 6 Aug 2007, Tobias Verbeke wrote:
Dear list,
I'm trying to embed OpenBUGS in an R package for use of it
on 64-bit Linux. In order to get the CLI working one has to
compile C code contained in $OpenBUGS/Manuals/CBugs.html
same as
http://mathstat.helsinki.fi/openbugs/data/Docu/CBugs.html
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
(copied to say CBugs.c) using
gcc -m32 -o bugs CBugs.c -ldl
I put the OpenBUGS distribution in the ./inst subdirectory of
the package root. Where should I now put the CBugs.c and how
Why do you want to install CBugs.c?
The CBugs.c file itself is indeed not needed in the built package.
should the Makefile look like in order to be able to call
$PKG_ROOT/OpenBUGS/bugs afterwards ?
Naively putting the following Makefile in ./src does not work
What does 'does not work' mean? It's hard to know whether this is
just not doing what you wanted, or something else is wrong.
Apologies. This is the error message when putting the Makefile
in ./src and launching the package checker:
$ R.250 CMD check CGHmix
DISPLAY=localhost:10.0
* checking for working latex ... OK
* using log directory '/home/tverbek1/pkg/CGHmix.Rcheck'
* using R version 2.5.0 (2007-04-23)
* checking for file 'CGHmix/DESCRIPTION' ... OK
* checking extension type ... Package
* this is package 'CGHmix' version '0.1-2'
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking whether package 'CGHmix' can be installed ... ERROR
Installation failed.
See '/home/tverbek1/pkg/CGHmix.Rcheck/00install.out' for details.
The file 00install.out contains:
* Installing *source* package 'CGHmix' ...
** libs
** arch -
gcc -m32 -o ../inst/OpenBUGS/bugs ../inst/OpenBUGS/CBugs.c -ldl
cp: cannot stat `*.so': No such file or directory
ERROR: compilation failed for package 'CGHmix'
** Removing '/home/tverbek1/pkg/CGHmix.Rcheck/CGHmix'
-%
bugs: ../inst/OpenBUGS/CBugs.c
gcc -m32 -o bugs ../inst/OpenBUGS/CBugs.c -ldl
-%---
The objective is to use something along the following
execfile - system.file(OpenBUGS, bugs, package = mypkg)
system(paste(execfile, somescript.script somefile.out))
This system call to the CLI is currently the only (non-WINE)
way of using OpenBUGS on Linux in batch mode.
I think you need to make ../inst/OpenBUGS/bugs, not src/bugs. So
something like
all: ../inst/OpenBUGS/bugs
../inst/OpenBUGS/bugs: ../inst/OpenBUGS/CBugs.c
gcc -m32 -o ../inst/OpenBUGS/bugs ../inst/OpenBUGS/CBugs.c -ldl
Thank you.
However, -m32 builds a 32-bit executable on 64-bit linux. Is that
what you wanted?
Yes. The shared object (brugs.so) comes with the OpenBUGS distribution
and currently can only be cross-compiled by the main OpenBUGS
developer (Andrew Thomas) who knows all secrets of the Windows only
BlackBox (nomen omen) Component Pascal compiler.
$ file brugs.so
brugs.so: ELF 32-bit LSB shared object,
Re: [Rd] Makefile for embedding OpenBUGS in R package
On Mon, 6 Aug 2007, Tobias Verbeke wrote:
- Oorspronkelijk bericht -
Van: Prof Brian Ripley [mailto:[EMAIL PROTECTED]
Verzonden: maandag, augustus 6, 2007 03:46 PM
Aan: 'Tobias Verbeke'
CC: r-devel@r-project.org
Onderwerp: Re: [Rd] Makefile for embedding OpenBUGS in R package
On Mon, 6 Aug 2007, Tobias Verbeke wrote:
Dear list,
I'm trying to embed OpenBUGS in an R package for use of it
on 64-bit Linux. In order to get the CLI working one has to
compile C code contained in $OpenBUGS/Manuals/CBugs.html
same as
http://mathstat.helsinki.fi/openbugs/data/Docu/CBugs.html
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?
(copied to say CBugs.c) using
gcc -m32 -o bugs CBugs.c -ldl
I put the OpenBUGS distribution in the ./inst subdirectory of
the package root. Where should I now put the CBugs.c and how
Why do you want to install CBugs.c?
The CBugs.c file itself is indeed not needed in the built package.
should the Makefile look like in order to be able to call
$PKG_ROOT/OpenBUGS/bugs afterwards ?
Naively putting the following Makefile in ./src does not work
What does 'does not work' mean? It's hard to know whether this is just
not doing what you wanted, or something else is wrong.
Apologies. This is the error message when putting the Makefile
in ./src and launching the package checker:
$ R.250 CMD check CGHmix
DISPLAY=localhost:10.0
* checking for working latex ... OK
* using log directory '/home/tverbek1/pkg/CGHmix.Rcheck'
* using R version 2.5.0 (2007-04-23)
* checking for file 'CGHmix/DESCRIPTION' ... OK
* checking extension type ... Package
* this is package 'CGHmix' version '0.1-2'
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking whether package 'CGHmix' can be installed ... ERROR
Installation failed.
See '/home/tverbek1/pkg/CGHmix.Rcheck/00install.out' for details.
The file 00install.out contains:
* Installing *source* package 'CGHmix' ...
** libs
** arch -
gcc -m32 -o ../inst/OpenBUGS/bugs ../inst/OpenBUGS/CBugs.c -ldl
cp: cannot stat `*.so': No such file or directory
ERROR: compilation failed for package 'CGHmix'
Ah, so you need to circumvent the installation mechanism as you do not
have a DLL in your package. See package Rserve for a workaround.
[rest not needed for the reply.]
** Removing '/home/tverbek1/pkg/CGHmix.Rcheck/CGHmix'
-%
bugs: ../inst/OpenBUGS/CBugs.c
gcc -m32 -o bugs ../inst/OpenBUGS/CBugs.c -ldl
-%---
The objective is to use something along the following
execfile - system.file(OpenBUGS, bugs, package = mypkg)
system(paste(execfile, somescript.script somefile.out))
This system call to the CLI is currently the only (non-WINE)
way of using OpenBUGS on Linux in batch mode.
I think you need to make ../inst/OpenBUGS/bugs, not src/bugs. So
something like
all: ../inst/OpenBUGS/bugs
../inst/OpenBUGS/bugs: ../inst/OpenBUGS/CBugs.c
gcc -m32 -o ../inst/OpenBUGS/bugs ../inst/OpenBUGS/CBugs.c -ldl
Thank you.
However, -m32 builds a 32-bit executable on 64-bit linux. Is that what you
wanted?
Yes. The shared object (brugs.so) comes with the OpenBUGS distribution
and currently can only be cross-compiled by the main OpenBUGS developer
(Andrew Thomas) who knows all secrets of the Windows only BlackBox
(nomen omen) Component Pascal compiler.
$ file brugs.so
brugs.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV),
stripped
Many thanks for your ever instructive answer.
Tobias
P.S. Contents of CBugs.c from OpenBUGS distribution (3.0.1)
/* GNU General Public Licence
This small C program loads the brugs.so ELF shared library and calls the
CLI function.
Save it as a .c file and then compile it on Linux using gcc -o bugs CBugs.c
-ldl
*/
#include dlfcn.h
#include stdio.h
#include string.h
int main (int argc, char **argv)
{
void * handle;
void (*cli)(void);
handle = dlopen(./brugs.so, RTLD_LAZY);
if (!handle)
return 1;
* (void **) (cli) = dlsym(handle, CLI);
(*cli)();
dlclose(handle);
return 0;
}
--
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
[Rd] Inconsistency in current release version
At http://cran.at.r-project.org/ it reads that The latest release (2007-04-24): R-2.5.0.tar.gz (read what's new in the latest version). I'm assuming this should be referencing 2.5.1? --Matt Matt Austin Statistician Amgen, Inc __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Sligthly OT Re: Makefile for embedding OpenBUGS in R package
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. (for private/internal use, there is no reason for going the dlopen() routine...) Just an idea... Hin-Tak __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inconsistency in current release version
On 06/08/2007 5:16 PM, Austin, Matt wrote: At http://cran.at.r-project.org/ it reads that The latest release (2007-04-24): R-2.5.0.tar.gz (read what's new in the latest version). I'm assuming this should be referencing 2.5.1? I don't think you're seeing the latest. I see The latest release (2007-06-28): R-2.5.1.tar.gz ( Duncan Murdoch __ 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] Optimization in R
On 8/4/07, Duncan Murdoch [EMAIL PROTECTED] wrote: On 04/08/2007 2:53 PM, Gabor Grothendieck wrote: The example of generic functions. Show me an example where we have a list of ways to do a calculation passed as an argument (analogous to the method argument of optim), where the user is allowed to add his own function to the list. Bin width selection in hist? Family functions for glm? Those come quickly to my mind, but I'm sure there are others. Hadley __ 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
