R2winBUGS & WinBUGS gui

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

R2winBUGS & WinBUGS gui

cooch17
I am trying to figure out if it is possible to run winBUGS from within
R, using R2winBUGS, without having winBUGS spawn any windows (basically
- 'true' batch - no GUI actions at all). The reason being I have a
machine which I (and several others) ssh/telnet into, and would like to
run winBUGS without having to mount a virtual desktop of any kind.

I've looked through the r2winBUGS docs, and there doesn't seem to be any
command(s) which I can invoke to simply use the winBUGS 'engine', and
not the winBUGS windows.

Yes, I know I could look at classic BUGS, or openBUGS, but neither work
particularly well for my purposes (since the code I'm using makes use of
a numb4er of winBUGS 'extensions' which aren't supported in other
flavours of BUGS).

Is this possible in any fashion?

Thanks in advance...

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: R2winBUGS & WinBUGS gui

Uwe Ligges


Evan Cooch wrote:

> I am trying to figure out if it is possible to run winBUGS from within
> R, using R2winBUGS, without having winBUGS spawn any windows (basically
> - 'true' batch - no GUI actions at all). The reason being I have a
> machine which I (and several others) ssh/telnet into, and would like to
> run winBUGS without having to mount a virtual desktop of any kind.
>
> I've looked through the r2winBUGS docs, and there doesn't seem to be any
> command(s) which I can invoke to simply use the winBUGS 'engine', and
> not the winBUGS windows.
>
> Yes, I know I could look at classic BUGS, or openBUGS, but neither work
> particularly well for my purposes (since the code I'm using makes use of
> a numb4er of winBUGS 'extensions' which aren't supported in other
> flavours of BUGS).
>
> Is this possible in any fashion?

No. The idea is to use BRugs, i.e. OpenBUGS in such cases. If OpenBUGS
lacks some features, you are certainly welcome to implement them and
send patches to Andrew Thomas.

Best,
Uwe Ligges


> Thanks in advance...
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: R2winBUGS & WinBUGS gui

cooch17

>
> No. The idea is to use BRugs, i.e. OpenBUGS in such cases. If OpenBUGS
> lacks some features, you are certainly welcome to implement them and
> send patches to Andrew Thomas.
>
>

Thanks very much. I thought as much, but given that I have had a 0%
success rate in getting OpenBUGS to run on any GNU/Linux platform, I was
resigning myself into using winBUGS under wine. I have recently
installed a different distro on one of my machines - perhaps time to try
openBUGS again.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: R2winBUGS & WinBUGS gui

cooch17
In reply to this post by Uwe Ligges

>
> No. The idea is to use BRugs, i.e. OpenBUGS in such cases. If OpenBUGS
> lacks some features, you are certainly welcome to implement them and
> send patches to Andrew Thomas.
>

Just finished trying the install of openBUGS under linux yet again. Same
problems (more or less), which I'll list here for the benefit (possibly)
of others who might go this route.

1. connect to

http://www.mathstat.helsinki.fi/openbugs/

Download latest zip of openBUGS

2. unzip it (preserving directory structure) onto Linux machine (in this
case, running Fedora Core 8 latest flavours of everything, including R).

3. look at the 'docs' for installing under linux. I say 'docs'
advisedly, since there really isn't much to read - here it is in its
entirety.

OpenBUGS for both Windows and Linux can be downloaded as a .zip file
from here <http://www.mathstat.helsinki.fi/openbugs/OpenBUGS.zip>. The
source code comes with the installation: check the readme notes to see
how to compile the code. you will need to install Black Box
<http://www.oberon.ch/blackbox.html> as well.


      Old Installation Instructions for LinBUGS (which may or may not
      still work):

   1. Un-zip the .zip file into the folder of your choice.
   2. Change the permissions for the LINBUGS and CBugs files (e.g. with
      chmod 755 LinBUGS CBugs)
   3. Change the temp directory in LINBUGS to the current directory (at
      the moment it is "/home/ant/temp"). Use the full path name (can
      anyone suggest a less ugly way of doing this? We don't want to put
      the temp directory in OpenBUGS/).
   4. Start LinBUGS with the command LINBUGS.


(the admonition that it may or may not work is not inspiring). Confirmed
at step (2), where you're supposed to change permissions on 2 files
which, in fact, are *not* distributed in the openBUGS.zip file. This
makes it rather tough to install. ;-)


I dug around, and found some folks have hacked together a LINGUS script
- one version I found fairly commonly looks like:

#!/bin/bash

export LD_ASSUME_KERNEL=2.4.1

DIR=$(dirname $0)
cd "$DIR"
if [ \! -e "$DIR/temp" ] ; then
        mkdir "$DIR/temp"
fi

if [ -e bugs.so ] ; then
        ./cbugs "$DIR" "$DIR/temp" "/bugs.so"
else
        ./cbugs "$DIR" "$DIR/temp" "/brugs.so"


Fine, except for line two, which doesn't work with newer distros.

And, apparently (based on a bunch of websites I just looked at), BRugs
doesn't work under Linux, not unless you want to install the Blackbox
compiler (is there one for Linux?), and recompile. Not me (not today,
anyway...).

So, unless I (and a lot of folks who seem to be running into the same
issues), my preliminary conclusion is that neither openBUGS nor BRugs
are ready for prime time on a Linux platform. Which seems a shame, given
how many people using MCMC etc. use Linux as their primary platform.

Guess I'll have another look at JAGS.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: R2winBUGS & WinBUGS gui

Uwe Ligges


Evan Cooch wrote:

>> No. The idea is to use BRugs, i.e. OpenBUGS in such cases. If OpenBUGS
>> lacks some features, you are certainly welcome to implement them and
>> send patches to Andrew Thomas.
>>
>
> Just finished trying the install of openBUGS under linux yet again. Same
> problems (more or less), which I'll list here for the benefit (possibly)
> of others who might go this route.
>
> 1. connect to
>
> http://www.mathstat.helsinki.fi/openbugs/
>
> Download latest zip of openBUGS
>
> 2. unzip it (preserving directory structure) onto Linux machine (in this
> case, running Fedora Core 8 latest flavours of everything, including R).
>
> 3. look at the 'docs' for installing under linux. I say 'docs'
> advisedly, since there really isn't much to read - here it is in its
> entirety.
>
> OpenBUGS for both Windows and Linux can be downloaded as a .zip file
> from here <http://www.mathstat.helsinki.fi/openbugs/OpenBUGS.zip>. The
> source code comes with the installation: check the readme notes to see
> how to compile the code. you will need to install Black Box
> <http://www.oberon.ch/blackbox.html> as well.
>
>
>       Old Installation Instructions for LinBUGS (which may or may not
>       still work):
>
>    1. Un-zip the .zip file into the folder of your choice.
>    2. Change the permissions for the LINBUGS and CBugs files (e.g. with
>       chmod 755 LinBUGS CBugs)
>    3. Change the temp directory in LINBUGS to the current directory (at
>       the moment it is "/home/ant/temp"). Use the full path name (can
>       anyone suggest a less ugly way of doing this? We don't want to put
>       the temp directory in OpenBUGS/).
>    4. Start LinBUGS with the command LINBUGS.
>
>
> (the admonition that it may or may not work is not inspiring). Confirmed
> at step (2), where you're supposed to change permissions on 2 files
> which, in fact, are *not* distributed in the openBUGS.zip file. This
> makes it rather tough to install. ;-)
>
>
> I dug around, and found some folks have hacked together a LINGUS script
> - one version I found fairly commonly looks like:
>
> #!/bin/bash
>
> export LD_ASSUME_KERNEL=2.4.1
>
> DIR=$(dirname $0)
> cd "$DIR"
> if [ \! -e "$DIR/temp" ] ; then
> mkdir "$DIR/temp"
> fi
>
> if [ -e bugs.so ] ; then
> ./cbugs "$DIR" "$DIR/temp" "/bugs.so"
> else
> ./cbugs "$DIR" "$DIR/temp" "/brugs.so"
>
>
> Fine, except for line two, which doesn't work with newer distros.
>
> And, apparently (based on a bunch of websites I just looked at), BRugs
> doesn't work under Linux, not unless you want to install the Blackbox
> compiler (is there one for Linux?), and recompile. Not me (not today,
> anyway...).
>
> So, unless I (and a lot of folks who seem to be running into the same
> issues), my preliminary conclusion is that neither openBUGS nor BRugs

BRugs is just an interface to OpenBUGS.

> are ready for prime time on a Linux platform. Which seems a shame, given
> how many people using MCMC etc. use Linux as their primary platform.

Yes, sure, and indeed, it is a shame that nobody of those people who
want it to work under Linux is trying to submit patches to make it work.


Uwe Ligges



> Guess I'll have another look at JAGS.
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: R2winBUGS & WinBUGS gui

cooch17

>
> Yes, sure, and indeed, it is a shame that nobody of those people who
> want it to work under Linux is trying to submit patches to make it work.
>
>
>
I agree, but I *think* the primary reason for this is that it requires
installing Blackbox as a PASCAL compiler. For much of the Linux
community, if it doesn't make use of a standard GNU compiler (there *is*
a GNU Pascal compiler, but since I (and most others) don't know PASCAL,
I've never installed it), there will be little interest. Of course, what
seems attractive about JAGS is that it is less dependent on a non-GNU
compiler (although the dependencies to Blackbox may not be large -
relative to GNU Pascal - don't know), and is written in a more familiar
language.

What everyone wants is a tarball with a simple configure, make, make
install sequence, that plays nice with R, under linux, which is the OS
of choice (based on the statistics I have) for folks with high-end
hardware (read - multi-processor 64-bit chips with a 64-bit OS). Of
course, this doesn't happen by itself (your point is well-taken).

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: R2winBUGS & WinBUGS gui

Ben Bolker

Evan Cooch wrote
>
> Yes, sure, and indeed, it is a shame that nobody of those people who
> want it to work under Linux is trying to submit patches to make it work.
>
>
>
I agree, but I *think* the primary reason for this is that it requires
installing Blackbox as a PASCAL compiler. For much of the Linux
community, if it doesn't make use of a standard GNU compiler (there *is*
a GNU Pascal compiler, but since I (and most others) don't know PASCAL,
I've never installed it), there will be little interest. Of course, what
seems attractive about JAGS is that it is less dependent on a non-GNU
compiler (although the dependencies to Blackbox may not be large -
relative to GNU Pascal - don't know), and is written in a more familiar
language.

What everyone wants is a tarball with a simple configure, make, make
install sequence, that plays nice with R, under linux, which is the OS
of choice (based on the statistics I have) for folks with high-end
hardware (read - multi-processor 64-bit chips with a 64-bit OS). Of
course, this doesn't happen by itself (your point is well-taken).
  I'd like to second Evan's point.  I would try to help with OpenBUGS
if I could, but the little bit that I looked at convinced me that it would
mean getting up to speed on a big, complicated black box (so to
speak) -- and it seems that even the experts on OpenBUGS can't
really figure out what's going on.

There are many threads about this ... the thread ending around

https://stat.ethz.ch/pipermail/r-devel/2007-August/046632.html

suggests that Tobias Verbeke did find a way to wrap OpenBUGS on Linux
to run it without Wine (and without a Windows front-end?) -- Uwe indicated
that he would prefer it to go into R2WinBUGS with the other "ugly wrappers" ...
So the three choices for running BUGS analyses more-or-less natively, and/or without
firing up the WinBUGS window, are ...

 1. make Tobias's stuff work with R2WinBUGS or BRugs
 2. switch to JAGS
 3. make OpenBUGS compilation work on Linux

  #1 seems to be the best short-term prospect; #2 might be best in
the long term (a second, and possibly cleaner, implementation of an
engine to interpret BUGS(like) code, that runs cross-platform etc.);
#3 would be best for continuing the effectiveness/spread of the original
BUGS lineage.  (Does OpenBUGS compile on the Mac ... ????)

   I may try to work on these at some point, but probably not in the
next month ...
   
  Ben Bolker