Menu
▾
▴
bugs-r-devel
|
From: Sparapani, R. <rsp...@mc...> - 2008-10-03 14:41:56
|
I just sent out a bug report. Did anyone get it? I hate Outlook!
Ok, here we go again. Thanks for fixing the Solaris bugs, but now
I'm having Mac bugs again. I'm going to a conference next month that
requires laptops loaded with R and WinBUGS. And what would be the
perfect addition: R2WinBUGS of course! However, I'm running rev.
87 and there seem to be a few regressions on Mac.
Bug 1, Priority Secondary:
> if(!exists("baseenv", mode="function")) baseenv <- function() NULL
> options(STERM='iESS', editor='emacsclient')
> options(warn=2)
> library(R2WinBUGS)
Loading required package: coda
Loading required package: lattice
> schools <- read.table ("schools.dat", header=T)
> J <- nrow (schools)
> y <- schools$estimate
> sigma.y <- schools$sd
> data <- list ("J", "y", "sigma.y")
> inits <- function()
+ list (theta=rnorm(J,0,100), mu.theta=rnorm(1,0,100),
+ sigma.theta=runif(1,0,100))
> parameters <- c("theta", "mu.theta", "sigma.theta")
> setwd(".")
> schools.sim <- bugs (data, inits, parameters, "schools.bug", debug=TRUE,
+ n.chains=3, n.iter=1000, working.directory=".")
sh: /Volumes/My: No such file or directory
sh: /Volumes/My: No such file or directory
sh: /Volumes/My: No such file or directory
sh: /Volumes/My: No such file or directory
sh: /Volumes/My: No such file or directory
sh: /Volumes/My: No such file or directory
sh: /Volumes/My: No such file or directory
sh: /Volumes/My: No such file or directory
sh: /Volumes/My: No such file or directory
sh: /Volumes/My: No such file or directory
Error in .fileCopy(file.path(bugs.directory, "System/Rsrc/Registry.odc"), :
no files to copy from
Error in if (!file.exists(dos.location)) stop(paste("WinBUGS executable does not exist in", :
argument is of length zero
Error in .fileCopy(file.path(bugs.directory, "System/Rsrc/Registry_Rsave.odc"), :
no files to copy from
>
> traceback()
2: bugs.run(n.burnin, bugs.directory, WINE = WINE, useWINE = useWINE,
newWINE = newWINE, WINEPATH = WINEPATH)
1: bugs(data, inits, parameters, "schools.bug", debug = TRUE, n.chains = 3,
n.iter = 1000, working.directory = ".")
This seems to be a bug with bad defaults. Since supplying the correct defaults
works.
> schools.sim <- bugs (data, inits, parameters, "schools.bug", debug=TRUE,
+ WINE="/Applications/Darwine/Wine.bundle/Contents/bin/wine",
+ WINEPATH="/Applications/Darwine/Wine.bundle/Contents/bin/winepath",
+ bugs.directory="/Applications/WinBUGS14", program="winbugs",
+ n.chains=3, n.iter=1000, working.directory=".")
Can we fix the defaults again?
Bug 2, Priority Primary:
> .schools.bug <- function () {
+ # data: J, y, sigma.y
+ # param: mu.theta, tau.theta, sigma.theta
+ for (j in 1:J){
+ y[j] ~ dnorm (theta[j], tau.y[j])
+ theta[j] ~ dnorm (mu.theta, tau.theta)
+ tau.y[j] <- pow(sigma.y[j], -2)
+ }
+
+ mu.theta ~ dnorm (0, 1.0E-6)
+ tau.theta <- pow(sigma.theta, -2)
+ sigma.theta ~ dunif (0, 1000)
+ }
>
> schools.sim <- bugs (data, inits, parameters, .schools.bug, debug=TRUE,
+ WINE="/Applications/Darwine/Wine.bundle/Contents/bin/wine",
+ WINEPATH="/Applications/Darwine/Wine.bundle/Contents/bin/winepath",
+ bugs.directory="/Applications/WinBUGS14", program="winbugs",
+ n.chains=3, n.iter=1000, working.directory=".")
display(log)
check(Z:/var/folders/z4/z4O5IqhPED0pjZUVP7s0mE+++TI/-Tmp-//RtmpmMFxxp/model58c57c47.txt)
cannot open Z:/var/folders/z4/z4O5IqhPED0pjZUVP7s0mE+++TI/-Tmp-//RtmpmMFxxp/model58c57c47.txt
As we can see from the log, the model file cannot be opened. This is
because the directory RtmpmMFxxp has the restrictive permissions 700.
This naming convention looks like R created this directory. If so,
then can we have R make the permissions 755? If not, then maybe we
should be using C:\windows\temp since it has the right permissions
to begin with.
Thanks again. I can't wait to sing your praises at the conference.
Is anyone else going to that? It's in Charleston SC and it has to do
with the GeoBUGS extensions to WinBUGS. I hope to see you there.
Rodney
|
|
From: Gorjanc G. <Gre...@bf...> - 2008-10-04 14:47:20
|
Hi Rodney,
> I just sent out a bug report. Did anyone get it? I hate Outlook!
Then stop using it! Read further ...
> Bug 1, Priority Secondary:
>> if(!exists("baseenv", mode="function")) baseenv <- function() NULL
>> options(STERM='iESS', editor='emacsclient')
>> options(warn=2)
>> library(R2WinBUGS)
> Loading required package: coda
> Loading required package: lattice
>> schools <- read.table ("schools.dat", header=T)
>> J <- nrow (schools)
>> y <- schools$estimate
>> sigma.y <- schools$sd
>> data <- list ("J", "y", "sigma.y")
>> inits <- function()
>+ list (theta=rnorm(J,0,100), mu.theta=rnorm(1,0,100),
>+ sigma.theta=runif(1,0,100))
>> parameters <- c("theta", "mu.theta", "sigma.theta")
>> setwd(".")
>> schools.sim <- bugs (data, inits, parameters, "schools.bug", debug=TRUE,
>+ n.chains=3, n.iter=1000, working.directory=".")
>sh: /Volumes/My: No such file or directory
...
> Error in .fileCopy(file.path(bugs.directory, "System/Rsrc/Registry.odc"), :
> no files to copy from
> Error in if (!file.exists(dos.location)) stop(paste("WinBUGS executable does not exist in", :
> argument is of length zero
> Error in .fileCopy(file.path(bugs.directory, "System/Rsrc/Registry_Rsave.odc"), :
> no files to copy from
>
> This seems to be a bug with bad defaults. Since supplying the correct defaults
> works.
Hmm, there is a problem with bugs.directory default. It is not really a problem, since
we do not know what is the default place for Mac applications? The default also does
not work on Linux if WinBUGS is not strictly installed in "c:/Program Files/WinBUGS14/"
part of wine. The help of bugs() says
...
Operation system support:
MS Windows no problem
Linux, Mac OS X and Unix in general possible with Wine emulation via useWINE=TRUE, but only for WinBUGS 1.4.*
If useWINE=TRUE is used, all paths (such as working.directory and model.file, must
be given in native (Unix) style, but working.directory can be given in Windows path style
(e.g. “c:/Program Files/WinBUGS14/”) or native (Unix) style (e.g. “/path/to/wine/folder/dosdevices/c:/Program
Files/WinBUGS14”). This is done to achieve greatest portability with default argument value for
working.directory.
Unless you can provide a reasonable defaul for Mac, we can not help you!
I wonder where "sh: /Volumes/My: No such file or directory" is comming from. It looks like the path has space
in it. Perhaps we could be more informative in such cases so that users would be warned that bugs.directory
needs to be accomodated.
I will look into other bug later.
Btw. Why do you use setwd(".")? It does not make sense, since this is changing the working directory to
the current one.
gg
|
|
From: Gorjanc G. <Gre...@bf...> - 2008-10-06 20:04:11
|
...
>> Unless you can provide a reasonable defaul for Mac, we can not help you!
>
> Umm. According to my notes I did. Or was that just a patch that I
> applied to my local copy that was not incorporated into the mainline.
> Can't find it right now. But, the default for all Mac applications is
> /Applications. That was in the workaround I sent. The reason is that
> that the Mac filesystem has permissions since it is just the Unix filesystem
> with a few bells and whistles. The /Applications directory has the
> permissions necessary to allow any user to install applications system-wide,
> a nice compromise between security and practicality. Other directories are
> secure so they are not an option (and for real Mac applications, they actually
> need to be in /Applications: this is probably more than you need or want to know).
Thank you for this details. /Applications/WinBUGS14 then seems to be a good default
for Mac. Does anyone have any other opinion? Additionally, I wonder how can we
set this default. There is already a bunch of arguments for the bugs() functions. Should
we use
bugs.directory=ifelse(???, "c:/Program Files/WinBUGS14/", "/Applications/WinBUGS14")
or should we change the bugs.directory in the code conditionally on the OS? Uwe?
>> Btw. Why do you use setwd(".")? It does not make sense, since this is changing the working directory to
>> the current one.
> I don't know. I got that from the Solaris example that you guys helped me with.
> I figured you guys know what you are doing. My mistake :o)
Actually, you came up with the example and I (we) did not bother ;) What you need is
basically the same as example in ?bugs:
model.file <- system.file(package="R2WinBUGS", "model", "schools.txt")
# Some example data (see ?schools for details):
data(schools)
schools
J <- nrow(schools)
y <- schools$estimate
sigma.y <- schools$sd
data <- list ("J", "y", "sigma.y")
inits <- function(){
list(theta=rnorm(J, 0, 100), mu.theta=rnorm(1, 0, 100),
sigma.theta=runif(1, 0, 100))
}
parameters <- c("theta", "mu.theta", "sigma.theta")
schools.sim <- bugs(data, inits, parameters, model.file,
n.chains=3, n.iter=5000,
bugs.directory="/Applications/WinBUGS14",
clearWD=TRUE)
Can you please test if this works for you? I would like to know if
wine variables are properly initialized.
gg
|
|
From: Uwe L. <li...@st...> - 2008-10-07 13:28:26
|
Gorjanc Gregor wrote:
> ...
>>> Unless you can provide a reasonable defaul for Mac, we can not help you!
>> Umm. According to my notes I did. Or was that just a patch that I
>> applied to my local copy that was not incorporated into the mainline.
>> Can't find it right now. But, the default for all Mac applications is
>> /Applications. That was in the workaround I sent. The reason is that
>> that the Mac filesystem has permissions since it is just the Unix filesystem
>> with a few bells and whistles. The /Applications directory has the
>> permissions necessary to allow any user to install applications system-wide,
>> a nice compromise between security and practicality. Other directories are
>> secure so they are not an option (and for real Mac applications, they actually
>> need to be in /Applications: this is probably more than you need or want to know).
>
> Thank you for this details. /Applications/WinBUGS14 then seems to be a good default
> for Mac. Does anyone have any other opinion? Additionally, I wonder how can we
> set this default. There is already a bunch of arguments for the bugs() functions. Should
> we use
>
> bugs.directory=ifelse(???, "c:/Program Files/WinBUGS14/", "/Applications/WinBUGS14")
>
> or should we change the bugs.directory in the code conditionally on the OS? Uwe?
If my opinion is of interest: Keep it as is and ask the user to provide
the correct path (as we do already). On a German version of Windows (and
corresponding default installation of WinBUGS), the correct path is
"c:/Programme/WinBUGS14", hence the user has to change it there as well
(we cannot introduce a guess for each possible combination of
platform/OS/language anyway, I fear. We should rather stay with the
default for most *Win*BUGS users: English local of more or less modern
Windows OS.
BTW, sorry for slow and short responses, I am quite busy and overwhelmed
by too many incoming mails (R-2.8.0 is in beta state and package
management for CRAN takes some time for the rest of this week, since we
have some problems left).
Best wishes,
uwe
>>> Btw. Why do you use setwd(".")? It does not make sense, since this is changing the working directory to
>>> the current one.
>
>> I don't know. I got that from the Solaris example that you guys helped me with.
>> I figured you guys know what you are doing. My mistake :o)
>
> Actually, you came up with the example and I (we) did not bother ;) What you need is
> basically the same as example in ?bugs:
>
> model.file <- system.file(package="R2WinBUGS", "model", "schools.txt")
> # Some example data (see ?schools for details):
> data(schools)
> schools
>
> J <- nrow(schools)
> y <- schools$estimate
> sigma.y <- schools$sd
> data <- list ("J", "y", "sigma.y")
> inits <- function(){
> list(theta=rnorm(J, 0, 100), mu.theta=rnorm(1, 0, 100),
> sigma.theta=runif(1, 0, 100))
> }
> parameters <- c("theta", "mu.theta", "sigma.theta")
> schools.sim <- bugs(data, inits, parameters, model.file,
> n.chains=3, n.iter=5000,
> bugs.directory="/Applications/WinBUGS14",
> clearWD=TRUE)
>
> Can you please test if this works for you? I would like to know if
> wine variables are properly initialized.
>
> gg
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Bugs-r-devel mailing list
> Bug...@li...
> https://lists.sourceforge.net/lists/listinfo/bugs-r-devel
|
|
From: Uwe L. <li...@st...> - 2008-10-07 14:34:05
|
Rodney Sparapani wrote: > Gorjanc Gregor wrote: >> Hi! >> >> >>> No, it doesn't. But, this does: >>> >>> schools.sim <- bugs(data, inits, parameters, model.file, >>> n.chains=3, n.iter=5000, >>> bugs.directory="/Applications/WinBUGS14", working.directory=".", >>> WINE="/Applications/Darwine/Wine.bundle/Contents/bin/wine", >>> WINEPATH="/Applications/Darwine/Wine.bundle/Contents/bin/winepath", >>> clearWD=TRUE) >>> >> Then we are not successfull in finding wine binaries in Mac. This is done by R2WinBUGS:::findUnixBinary >> function. It goes like this (returning the result on the first success): >> >> * check if there is x (WINE or WINEPATH) environmental variable >> * check if there is /usr/bin/x >> * try with which x >> * try with locate x >> >> I thought that there is which command in Mac also. Afterall Mac uses unix internally. Can you please check in >> the terminal the result of the following commands: >> >> which wine >> which winepath >> >> locate wine >> locate winepath >> >> Btw. As stated last time, working.directory="." is not really needed unless you do want >> to keep the intermediate files in current working directory. >> >> > Actually, working.directory="." is required, otherwise the example doesn't > work. Hence, the reason that it is there... > > And, which/locate aren't going to work. Those are for the Unix subsystem. > Since Darwine is located in a .bundle, /Applications/Darwine/Wine.bundle, > wine/winepath will not be found. A .bundle is like an .app, but a bit more > general. For example, a .bundle may contain almost anything and it usually > does not contain a Mac app: rather, it is often used to contain > command-line > scripts like wine, man pages, shared libraries, etc. However, I take your > point. It probably makes sense to have links from /usr/local/bin to wine and > winepath. But, the documentation should state that this is necessary. I > don't see that anywhere. Maybe there should be a Mac-specific doc as well > or a wiki or something. Thanks. > The ?bugs help pages tells us: WINE character, path to ‘wine’ binary file, it is tried hard to get the information automatically if not given. WINEPATH character, path to ‘winepath’ binary file, it is tried hard to get the information automatically if not given. We said "tried hard [...] if not given", if this leads to misunderstandings, what wording would you prefer? Uwe Ligges |
|
From: Rodney S. <rsp...@mc...> - 2008-10-07 14:48:20
|
Uwe Ligges wrote: > > > > The ?bugs help pages tells us: > > WINE character, path to ‘wine’ binary file, it is tried hard to get > the information automatically if not given. > > WINEPATH character, path to ‘winepath’ binary file, it is tried > hard to get the information automatically if not given. > > > We said "tried hard [...] if not given", if this leads to > misunderstandings, what wording would you prefer? > > > Uwe Ligges > > > > By "tried hard" I thought you meant that you were using the Mac directory defaults that I sent many months ago; hence the reason for my bug reports. A bit opaque, you might agree :o) How about: WINE character, path to ‘wine’ binary file, which/locate tried if not given Thanks! -- Rodney Sparapani Center for Patient Care & Outcomes Research (PCOR) Sr. Biostatistician http://www.mcw.edu/pcor 4 wheels good, 2 wheels better! Medical College of Wisconsin (MCW) WWLD?: What Would Lombardi Do? Milwaukee, WI, USA |
|
From: Uwe L. <li...@st...> - 2008-10-07 16:48:25
|
Rodney Sparapani wrote: > Uwe Ligges wrote: >> >> >> The ?bugs help pages tells us: >> >> WINE character, path to ‘wine’ binary file, it is tried hard to get >> the information automatically if not given. >> >> WINEPATH character, path to ‘winepath’ binary file, it is tried >> hard to get the information automatically if not given. >> >> >> We said "tried hard [...] if not given", if this leads to >> misunderstandings, what wording would you prefer? >> >> >> Uwe Ligges >> >> >> >> > By "tried hard" I thought you meant that you were using the Mac > directory defaults that I sent many months ago; hence the reason > for my bug reports. A bit opaque, you might agree :o) How about: > > WINE character, path to ‘wine’ binary file, which/locate tried if not > given Thanks, will be incorporated shortly. Uwe > Thanks! > |
|
From: Rodney S. <rsp...@mc...> - 2008-10-06 14:10:32
|
Gorjanc Gregor wrote:
> Hi Rodney,
>
>
>> I just sent out a bug report. Did anyone get it? I hate Outlook!
>>
>
> Then stop using it! Read further ...
>
>
Actually, I don't. But, in order to send the bug report from my Mac,
where I did the testing, I had to...
>> Bug 1, Priority Secondary:
>>
>>> if(!exists("baseenv", mode="function")) baseenv <- function() NULL
>>> options(STERM='iESS', editor='emacsclient')
>>> options(warn=2)
>>> library(R2WinBUGS)
>>>
>> Loading required package: coda
>> Loading required package: lattice
>>
>>> schools <- read.table ("schools.dat", header=T)
>>> J <- nrow (schools)
>>> y <- schools$estimate
>>> sigma.y <- schools$sd
>>> data <- list ("J", "y", "sigma.y")
>>> inits <- function()
>>>
>> + list (theta=rnorm(J,0,100), mu.theta=rnorm(1,0,100),
>> + sigma.theta=runif(1,0,100))
>>
>>> parameters <- c("theta", "mu.theta", "sigma.theta")
>>> setwd(".")
>>> schools.sim <- bugs (data, inits, parameters, "schools.bug", debug=TRUE,
>>>
>> + n.chains=3, n.iter=1000, working.directory=".")
>> sh: /Volumes/My: No such file or directory
>>
> ...
>
>> Error in .fileCopy(file.path(bugs.directory, "System/Rsrc/Registry.odc"), :
>> no files to copy from
>> Error in if (!file.exists(dos.location)) stop(paste("WinBUGS executable does not exist in", :
>> argument is of length zero
>> Error in .fileCopy(file.path(bugs.directory, "System/Rsrc/Registry_Rsave.odc"), :
>> no files to copy from
>>
>> This seems to be a bug with bad defaults. Since supplying the correct defaults
>> works.
>>
>
> Hmm, there is a problem with bugs.directory default. It is not really a problem, since
> we do not know what is the default place for Mac applications? The default also does
> not work on Linux if WinBUGS is not strictly installed in "c:/Program Files/WinBUGS14/"
> part of wine. The help of bugs() says
>
> ...
> Operation system support:
>
> MS Windows no problem
>
> Linux, Mac OS X and Unix in general possible with Wine emulation via useWINE=TRUE, but only for WinBUGS 1.4.*
>
> If useWINE=TRUE is used, all paths (such as working.directory and model.file, must
> be given in native (Unix) style, but working.directory can be given in Windows path style
> (e.g. “c:/Program Files/WinBUGS14/”) or native (Unix) style (e.g. “/path/to/wine/folder/dosdevices/c:/Program
> Files/WinBUGS14”). This is done to achieve greatest portability with default argument value for
> working.directory.
>
> Unless you can provide a reasonable defaul for Mac, we can not help you!
>
>
Umm. According to my notes I did. Or was that just a patch that I
applied to my local copy that was not
incorporated into the mainline. Can't find it right now. But, the
default for all Mac applications is
/Applications. That was in the workaround I sent. The reason is that
that the Mac filesystem has
permissions since it is just the Unix filesystem with a few bells and
whistles. The /Applications
directory has the permissions necessary to allow any user to install
applications system-wide, a nice
compromise between security and practicality. Other directories are
secure so they are not an option
(and for real Mac applications, they actually need to be in
/Applications: this is probably more than
you need or want to know).
> I wonder where "sh: /Volumes/My: No such file or directory" is comming from. It looks like the path has space
> in it. Perhaps we could be more informative in such cases so that users would be warned that bugs.directory
> needs to be accomodated.
>
> I will look into other bug later.
>
> Btw. Why do you use setwd(".")? It does not make sense, since this is changing the working directory to
> the current one.
>
> gg
>
I don't know. I got that from the Solaris example that you guys helped
me with. I figured you guys know
what you are doing. My mistake :o)
--
Rodney Sparapani Center for Patient Care & Outcomes Research (PCOR)
Sr. Biostatistician http://www.mcw.edu/pcor
4 wheels good, 2 wheels better! Medical College of Wisconsin (MCW)
WWLD?: What Would Lombardi Do? Milwaukee, WI, USA
|
|
From: Gorjanc G. <Gre...@bf...> - 2008-10-06 20:09:33
|
Rodney, I have been reading some old e-mails and I now realize there are some subtle details. You say you have WinBUGS installed in /Applications/WinBUGS14. For wine you have showed last time that the path is /Applications/Darwine/Wine.bundle/Contents/bin/wine while we had some discussion in Dec 2006 where use of Crossover has been reported - there WinBUGS was installed in /Applications/CrossOver/WinBUGS14.app Can you enlighten us how does one install an application, especially one for MS Windows, on Mac? I would like to know this at least for WinBUGS and for wine. gg |
|
From: Rodney S. <rsp...@mc...> - 2008-10-06 20:44:51
|
Gorjanc Gregor wrote: > Rodney, > > I have been reading some old e-mails and I now realize there are some subtle > details. You say you have WinBUGS installed in /Applications/WinBUGS14. That's correct. > For wine you have showed last time that the path is > > /Applications/Darwine/Wine.bundle/Contents/bin/wine > > That looks right. I don't have the bug report in front of me, but the path is also in the workaround which should be the same. > while we had some discussion in Dec 2006 where use of Crossover has been > reported - there WinBUGS was installed in > > /Applications/CrossOver/WinBUGS14.app > > Well CrossOver is based on Wine, but apparently they have done something else. WinBUGS14.app is what WinBUGS would look in the file system if it were a Mac application. Since it is not, then I'm assuming this is just a wrapper. With Darwine (Mac Wine), there is no wrapper. Launching winbugs.exe starts Wine and runs winbugs.exe. You can double-click on winbugs.exe or you can run it from the command line: open winbugs.exe > Can you enlighten us how does one install an application, especially one for MS Windows, > on Mac? I would like to know this at least for WinBUGS and for wine. > > gg > It depends. Often the app comes with an installer like Darwine does and installs it in /Applications as /Applications/Darwine.app About equally often, there is just a file like Emacs.app that you download and move to /Applications And, if we are talking about a Mac app, then it has to be in either /Applications or /Developer or it won't work: sort of a safety mechanism. And, those are the only directories that have the right permissions to allow all users on the system to do that. The only stuff that goes into /Developer are the Apple XCode tools. So, /Applications is where everything else goes. For MS Windows apps, it's similar. Many MS Windows apps come with an installer like WinBUGS. So, you run that and install it in Z:\Applications\WinBUGS14 Others, like OpenBUGS, you just unzip into /Applications/OpenBUGS -- Rodney Sparapani Center for Patient Care & Outcomes Research (PCOR) Sr. Biostatistician http://www.mcw.edu/pcor 4 wheels good, 2 wheels better! Medical College of Wisconsin (MCW) WWLD?: What Would Lombardi Do? Milwaukee, WI, USA |
|
From: Sparapani, R. <rsp...@mc...> - 2008-10-06 23:40:05
|
No, it doesn't. But, this does:
schools.sim <- bugs(data, inits, parameters, model.file,
n.chains=3, n.iter=5000,
bugs.directory="/Applications/WinBUGS14", working.directory=".",
WINE="/Applications/Darwine/Wine.bundle/Contents/bin/wine",
WINEPATH="/Applications/Darwine/Wine.bundle/Contents/bin/winepath",
clearWD=TRUE)
-----Original Message-----
From: Gorjanc Gregor [mailto:Gre...@bf...]
Sent: Mon 10/6/2008 3:01 PM
To: Sparapani, Rodney
Cc: bug...@li...
Subject: RE: [Bugs-r-devel] Mac bug regressions
...
>> Unless you can provide a reasonable defaul for Mac, we can not help you!
>
> Umm. According to my notes I did. Or was that just a patch that I
> applied to my local copy that was not incorporated into the mainline.
> Can't find it right now. But, the default for all Mac applications is
> /Applications. That was in the workaround I sent. The reason is that
> that the Mac filesystem has permissions since it is just the Unix filesystem
> with a few bells and whistles. The /Applications directory has the
> permissions necessary to allow any user to install applications system-wide,
> a nice compromise between security and practicality. Other directories are
> secure so they are not an option (and for real Mac applications, they actually
> need to be in /Applications: this is probably more than you need or want to know).
Thank you for this details. /Applications/WinBUGS14 then seems to be a good default
for Mac. Does anyone have any other opinion? Additionally, I wonder how can we
set this default. There is already a bunch of arguments for the bugs() functions. Should
we use
bugs.directory=ifelse(???, "c:/Program Files/WinBUGS14/", "/Applications/WinBUGS14")
or should we change the bugs.directory in the code conditionally on the OS? Uwe?
>> Btw. Why do you use setwd(".")? It does not make sense, since this is changing the working directory to
>> the current one.
> I don't know. I got that from the Solaris example that you guys helped me with.
> I figured you guys know what you are doing. My mistake :o)
Actually, you came up with the example and I (we) did not bother ;) What you need is
basically the same as example in ?bugs:
model.file <- system.file(package="R2WinBUGS", "model", "schools.txt")
# Some example data (see ?schools for details):
data(schools)
schools
J <- nrow(schools)
y <- schools$estimate
sigma.y <- schools$sd
data <- list ("J", "y", "sigma.y")
inits <- function(){
list(theta=rnorm(J, 0, 100), mu.theta=rnorm(1, 0, 100),
sigma.theta=runif(1, 0, 100))
}
parameters <- c("theta", "mu.theta", "sigma.theta")
schools.sim <- bugs(data, inits, parameters, model.file,
n.chains=3, n.iter=5000,
bugs.directory="/Applications/WinBUGS14",
clearWD=TRUE)
Can you please test if this works for you? I would like to know if
wine variables are properly initialized.
gg
|
|
From: Gorjanc G. <Gre...@bf...> - 2008-10-07 09:00:17
|
Hi!
> No, it doesn't. But, this does:
>
> schools.sim <- bugs(data, inits, parameters, model.file,
> n.chains=3, n.iter=5000,
> bugs.directory="/Applications/WinBUGS14", working.directory=".",
> WINE="/Applications/Darwine/Wine.bundle/Contents/bin/wine",
> WINEPATH="/Applications/Darwine/Wine.bundle/Contents/bin/winepath",
> clearWD=TRUE)
Then we are not successfull in finding wine binaries in Mac. This is done by R2WinBUGS:::findUnixBinary
function. It goes like this (returning the result on the first success):
* check if there is x (WINE or WINEPATH) environmental variable
* check if there is /usr/bin/x
* try with which x
* try with locate x
I thought that there is which command in Mac also. Afterall Mac uses unix internally. Can you please check in
the terminal the result of the following commands:
which wine
which winepath
locate wine
locate winepath
Btw. As stated last time, working.directory="." is not really needed unless you do want
to keep the intermediate files in current working directory.
-----Original Message-----
From: Gorjanc Gregor [mailto:Gre...@bf...]
Sent: Mon 10/6/2008 3:01 PM
To: Sparapani, Rodney
Cc: bug...@li...
Subject: RE: [Bugs-r-devel] Mac bug regressions
...
>> Unless you can provide a reasonable defaul for Mac, we can not help you!
>
> Umm. According to my notes I did. Or was that just a patch that I
> applied to my local copy that was not incorporated into the mainline.
> Can't find it right now. But, the default for all Mac applications is
> /Applications. That was in the workaround I sent. The reason is that
> that the Mac filesystem has permissions since it is just the Unix filesystem
> with a few bells and whistles. The /Applications directory has the
> permissions necessary to allow any user to install applications system-wide,
> a nice compromise between security and practicality. Other directories are
> secure so they are not an option (and for real Mac applications, they actually
> need to be in /Applications: this is probably more than you need or want to know).
Thank you for this details. /Applications/WinBUGS14 then seems to be a good default
for Mac. Does anyone have any other opinion? Additionally, I wonder how can we
set this default. There is already a bunch of arguments for the bugs() functions. Should
we use
bugs.directory=ifelse(???, "c:/Program Files/WinBUGS14/", "/Applications/WinBUGS14")
or should we change the bugs.directory in the code conditionally on the OS? Uwe?
>> Btw. Why do you use setwd(".")? It does not make sense, since this is changing the working directory to
>> the current one.
> I don't know. I got that from the Solaris example that you guys helped me with.
> I figured you guys know what you are doing. My mistake :o)
Actually, you came up with the example and I (we) did not bother ;) What you need is
basically the same as example in ?bugs:
model.file <- system.file(package="R2WinBUGS", "model", "schools.txt")
# Some example data (see ?schools for details):
data(schools)
schools
J <- nrow(schools)
y <- schools$estimate
sigma.y <- schools$sd
data <- list ("J", "y", "sigma.y")
inits <- function(){
list(theta=rnorm(J, 0, 100), mu.theta=rnorm(1, 0, 100),
sigma.theta=runif(1, 0, 100))
}
parameters <- c("theta", "mu.theta", "sigma.theta")
schools.sim <- bugs(data, inits, parameters, model.file,
n.chains=3, n.iter=5000,
bugs.directory="/Applications/WinBUGS14",
clearWD=TRUE)
Can you please test if this works for you? I would like to know if
wine variables are properly initialized.
gg
|
|
From: Gorjanc G. <Gre...@bf...> - 2008-10-07 09:45:19
|
Bug 2, Priority Primary: >> schools.sim <- bugs (data, inits, parameters, .schools.bug, debug=TRUE, > + WINE="/Applications/Darwine/Wine.bundle/Contents/bin/wine", > + WINEPATH="/Applications/Darwine/Wine.bundle/Contents/bin/winepath", > + bugs.directory="/Applications/WinBUGS14", program="winbugs", > + n.chains=3, n.iter=1000, working.directory=".") > > display(log) > check(Z:/var/folders/z4/z4O5IqhPED0pjZUVP7s0mE+++TI/-Tmp-//RtmpmMFxxp/model58c57c47.txt) > cannot open Z:/var/folders/z4/z4O5IqhPED0pjZUVP7s0mE+++TI/-Tmp-//RtmpmMFxxp/model58c57c47.txt > > As we can see from the log, the model file cannot be opened. This is > because the directory RtmpmMFxxp has the restrictive permissions 700. > This naming convention looks like R created this directory. If so, > then can we have R make the permissions 755? If not, then maybe we > should be using C:\windows\temp since it has the right permissions > to begin with. Are you sure about this? If you use working.directory="." then model file should be written in current working directory and not in the temporary folder created by R. I looked in ?tempdir() and there is no sign that we could modify permissions. I did not check the permissions on linux, but I find it odd that 700 does not allow WinBUGS to open the file. Afterall, 700 should mean that all permissions are granted to the user (owner) of the file, which is the user who started R and subsequently WinBUGS via wine. gg |
|
From: Uwe L. <li...@st...> - 2008-10-07 13:22:21
|
Gorjanc Gregor wrote: > Bug 2, Priority Primary: > >>> schools.sim <- bugs (data, inits, parameters, .schools.bug, debug=TRUE, >> + WINE="/Applications/Darwine/Wine.bundle/Contents/bin/wine", >> + WINEPATH="/Applications/Darwine/Wine.bundle/Contents/bin/winepath", >> + bugs.directory="/Applications/WinBUGS14", program="winbugs", >> + n.chains=3, n.iter=1000, working.directory=".") >> >> display(log) >> check(Z:/var/folders/z4/z4O5IqhPED0pjZUVP7s0mE+++TI/-Tmp-//RtmpmMFxxp/model58c57c47.txt) >> cannot open Z:/var/folders/z4/z4O5IqhPED0pjZUVP7s0mE+++TI/-Tmp-//RtmpmMFxxp/model58c57c47.txt >> >> As we can see from the log, the model file cannot be opened. This is >> because the directory RtmpmMFxxp has the restrictive permissions 700. >> This naming convention looks like R created this directory. If so, >> then can we have R make the permissions 755? If not, then maybe we >> should be using C:\windows\temp since it has the right permissions >> to begin with. > > Are you sure about this? If you use working.directory="." then model file should be written in > current working directory and not in the temporary folder created by R. > > I looked in ?tempdir() and there is no sign that we could modify permissions. I did not check the > permissions on linux, but I find it odd that 700 does not allow WinBUGS to open the file. Afterall, > 700 should mean that all permissions are granted to the user (owner) of the file, which is the user > who started R and subsequently WinBUGS via wine. Yes, and this is the idea of R's tempdir(): We should not need to bother because the user (!) already generated the temporary directory in which we are writing, hence to user should have write permissions. Uwe > gg > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Bugs-r-devel mailing list > Bug...@li... > https://lists.sourceforge.net/lists/listinfo/bugs-r-devel |
|
From: Rodney S. <rsp...@mc...> - 2008-10-07 14:17:35
|
Gorjanc Gregor wrote: > Bug 2, Priority Primary: > > >>> schools.sim <- bugs (data, inits, parameters, .schools.bug, debug=TRUE, >>> >> + WINE="/Applications/Darwine/Wine.bundle/Contents/bin/wine", >> + WINEPATH="/Applications/Darwine/Wine.bundle/Contents/bin/winepath", >> + bugs.directory="/Applications/WinBUGS14", program="winbugs", >> + n.chains=3, n.iter=1000, working.directory=".") >> >> display(log) >> check(Z:/var/folders/z4/z4O5IqhPED0pjZUVP7s0mE+++TI/-Tmp-//RtmpmMFxxp/model58c57c47.txt) >> cannot open Z:/var/folders/z4/z4O5IqhPED0pjZUVP7s0mE+++TI/-Tmp-//RtmpmMFxxp/model58c57c47.txt >> >> As we can see from the log, the model file cannot be opened. This is >> because the directory RtmpmMFxxp has the restrictive permissions 700. >> This naming convention looks like R created this directory. If so, >> then can we have R make the permissions 755? If not, then maybe we >> should be using C:\windows\temp since it has the right permissions >> to begin with. >> > > Are you sure about this? If you use working.directory="." then model file should be written in > current working directory and not in the temporary folder created by R. > > I looked in ?tempdir() and there is no sign that we could modify permissions. I did not check the > permissions on linux, but I find it odd that 700 does not allow WinBUGS to open the file. Afterall, > 700 should mean that all permissions are granted to the user (owner) of the file, which is the user > who started R and subsequently WinBUGS via wine. > > gg > > I'm sure. Actually, it does not mean that. It means, another process with your user id AND group id can access those files. But, the group id of the Wine processes and children is different. Therefore, it cannot access those files. That's why nobody uses 700 (except for something like ~/.ssh), but 755 and 750 are quite common. So, it's a bug. -- Rodney Sparapani Center for Patient Care & Outcomes Research (PCOR) Sr. Biostatistician http://www.mcw.edu/pcor 4 wheels good, 2 wheels better! Medical College of Wisconsin (MCW) WWLD?: What Would Lombardi Do? Milwaukee, WI, USA |
|
From: Gorjanc G. <Gre...@bf...> - 2008-10-07 20:18:52
|
>Uwe Ligges wrote: >> >> >> Well, I do not want to make the tempdir insecure. It might be used by >> other packages as well and users might expect privacy of their data. >> Consider you have data from patients of a clinical trial. Everybody >> using the same machine could access and read temporary data in that >> case. We should not use dirty tricks. We have problems enough telling >> people that R *is* secure given no contributed packages are installed. >> >> Uwe > No, not everybody. That's why I suggested 750, rather than 755. What if > you changed it to 750, then changed it back to 700 after the model file > is read in, but before the sampling begins? That way, it would only be > available as long as necessary. But, can we actually do this directly from R? gg |
|
From: Uwe L. <li...@st...> - 2008-10-08 16:12:25
|
Gorjanc Gregor wrote: >> Uwe Ligges wrote: >>> >>> Well, I do not want to make the tempdir insecure. It might be used by >>> other packages as well and users might expect privacy of their data. >>> Consider you have data from patients of a clinical trial. Everybody >>> using the same machine could access and read temporary data in that >>> case. We should not use dirty tricks. We have problems enough telling >>> people that R *is* secure given no contributed packages are installed. >>> >>> Uwe >> No, not everybody. That's why I suggested 750, rather than 755. What if >> you changed it to 750, then changed it back to 700 after the model file >> is read in, but before the sampling begins? That way, it would only be >> available as long as necessary. > > But, can we actually do this directly from R? Yes, see ?Sys.chmod I will give it a try, but not today due to lack of time. BTW: Is Dawn / Insightful / Tibco still present on this list??? Best, Uwe > gg > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Bugs-r-devel mailing list > Bug...@li... > https://lists.sourceforge.net/lists/listinfo/bugs-r-devel |
|
From: Uwe L. <li...@st...> - 2008-10-07 14:29:16
|
Rodney Sparapani wrote: > Gorjanc Gregor wrote: >> Bug 2, Priority Primary: >> >> >>>> schools.sim <- bugs (data, inits, parameters, .schools.bug, debug=TRUE, >>>> >>> + WINE="/Applications/Darwine/Wine.bundle/Contents/bin/wine", >>> + WINEPATH="/Applications/Darwine/Wine.bundle/Contents/bin/winepath", >>> + bugs.directory="/Applications/WinBUGS14", program="winbugs", >>> + n.chains=3, n.iter=1000, working.directory=".") >>> >>> display(log) >>> check(Z:/var/folders/z4/z4O5IqhPED0pjZUVP7s0mE+++TI/-Tmp-//RtmpmMFxxp/model58c57c47.txt) >>> cannot open Z:/var/folders/z4/z4O5IqhPED0pjZUVP7s0mE+++TI/-Tmp-//RtmpmMFxxp/model58c57c47.txt >>> >>> As we can see from the log, the model file cannot be opened. This is >>> because the directory RtmpmMFxxp has the restrictive permissions 700. >>> This naming convention looks like R created this directory. If so, >>> then can we have R make the permissions 755? If not, then maybe we >>> should be using C:\windows\temp since it has the right permissions >>> to begin with. >>> >> Are you sure about this? If you use working.directory="." then model file should be written in >> current working directory and not in the temporary folder created by R. >> >> I looked in ?tempdir() and there is no sign that we could modify permissions. I did not check the >> permissions on linux, but I find it odd that 700 does not allow WinBUGS to open the file. Afterall, >> 700 should mean that all permissions are granted to the user (owner) of the file, which is the user >> who started R and subsequently WinBUGS via wine. >> >> gg >> >> > I'm sure. Actually, it does not mean that. It means, another process > with your user id AND group id can access those files. But, the group > id of the Wine processes and children is different. Therefore, it > cannot access those files. That's why nobody uses 700 (except for > something like ~/.ssh), but 755 and 750 are quite common. So, it's > a bug. Bug in wine, as far as I can see, since it does not generate files with your user id even if you have started the process. Best wishes, uwe |
|
From: Rodney S. <rsp...@mc...> - 2008-10-07 14:30:42
|
Uwe Ligges wrote: > > > Bug in wine, as far as I can see, since it does not generate files > with your user id even if you have started the process. > > Best wishes, > uwe > > > Or a feature, I suppose. The problem is that R is anticipating that every other app works the same way with respect to group permissions. As we can see, that is not the case. Therefore, R is overly restrictive. But, this all beside the point. We just need to make R2WinBUGS work. Not get into an argument about "who killed who" shall we? -- Rodney Sparapani Center for Patient Care & Outcomes Research (PCOR) Sr. Biostatistician http://www.mcw.edu/pcor 4 wheels good, 2 wheels better! Medical College of Wisconsin (MCW) WWLD?: What Would Lombardi Do? Milwaukee, WI, USA |
|
From: Uwe L. <li...@st...> - 2008-10-07 14:45:18
|
Rodney Sparapani wrote: > Uwe Ligges wrote: >> >> >> Bug in wine, as far as I can see, since it does not generate files >> with your user id even if you have started the process. >> >> Best wishes, >> uwe >> >> >> > Or a feature, I suppose. The problem is that R is anticipating that > every other app works the same way with respect to group permissions. > As we can see, that is not the case. Therefore, R is overly restrictive. > But, this all beside the point. We just need to make R2WinBUGS work. > Not get into an argument about "who killed who" shall we? Indeed, after all, I start thinking that we need a separate package R2wineWinBUGS package for wine. The code with workarounds that makes special cases for wine becomes bigger than the original package. Anyway, I do not have a nice short term solution, I have to admit: Hard to do sensible things without having temporary directories. So we need to write our own tempdir() function for use under wine now. Uwe > |
|
From: Rodney S. <rsp...@mc...> - 2008-10-07 16:30:33
|
Uwe Ligges wrote: > > Indeed, after all, I start thinking that we need a separate package > R2wineWinBUGS package for wine. The code with workarounds that makes > special cases for wine becomes bigger than the original package. > > Anyway, I do not have a nice short term solution, I have to admit: > Hard to do sensible things without having temporary directories. So we > need to write our own tempdir() function for use under wine now. > > Uwe R2WineBUGS? Well, I don't know if it requires a fork. I thought you were going to say that this was as easy as a system() call to loosen up the permissions. Am I way off base here? I'm not a real strong R user so I could be wrong. But, I guess it's about time that I got my hands dirty. Any suggestions for developers docs welcome? Thanks. -- Rodney Sparapani Center for Patient Care & Outcomes Research (PCOR) Sr. Biostatistician http://www.mcw.edu/pcor 4 wheels good, 2 wheels better! Medical College of Wisconsin (MCW) WWLD?: What Would Lombardi Do? Milwaukee, WI, USA |
|
From: Uwe L. <li...@st...> - 2008-10-07 16:47:28
|
Rodney Sparapani wrote: > Uwe Ligges wrote: >> >> Indeed, after all, I start thinking that we need a separate package >> R2wineWinBUGS package for wine. The code with workarounds that makes >> special cases for wine becomes bigger than the original package. >> >> Anyway, I do not have a nice short term solution, I have to admit: >> Hard to do sensible things without having temporary directories. So we >> need to write our own tempdir() function for use under wine now. >> >> Uwe > R2WineBUGS? Well, I don't know if it requires a fork. I thought you were > going to say that this was as easy as a system() call to loosen up the > permissions. Well, I do not want to make the tempdir insecure. It might be used by other packages as well and users might expect privacy of their data. Consider you have data from patients of a clinical trial. Everybody using the same machine could access and read temporary data in that case. We should not use dirty tricks. We have problems enough telling people that R *is* secure given no contributed packages are installed. Uwe > Am I way off base here? I'm not a real strong R user > so I could be wrong. But, I guess it's about time that I got my hands > dirty. Any suggestions for developers docs welcome? Thanks. > |
|
From: Rodney S. <rsp...@mc...> - 2008-10-07 18:38:58
|
Uwe Ligges wrote: > > > Well, I do not want to make the tempdir insecure. It might be used by > other packages as well and users might expect privacy of their data. > Consider you have data from patients of a clinical trial. Everybody > using the same machine could access and read temporary data in that > case. We should not use dirty tricks. We have problems enough telling > people that R *is* secure given no contributed packages are installed. > > Uwe No, not everybody. That's why I suggested 750, rather than 755. What if you changed it to 750, then changed it back to 700 after the model file is read in, but before the sampling begins? That way, it would only be available as long as necessary. -- Rodney Sparapani Center for Patient Care & Outcomes Research (PCOR) Sr. Biostatistician http://www.mcw.edu/pcor 4 wheels good, 2 wheels better! Medical College of Wisconsin (MCW) WWLD?: What Would Lombardi Do? Milwaukee, WI, USA |
|
From: Rodney S. <rsp...@mc...> - 2008-10-07 14:27:48
|
Gorjanc Gregor wrote: > Hi! > > >> No, it doesn't. But, this does: >> >> schools.sim <- bugs(data, inits, parameters, model.file, >> n.chains=3, n.iter=5000, >> bugs.directory="/Applications/WinBUGS14", working.directory=".", >> WINE="/Applications/Darwine/Wine.bundle/Contents/bin/wine", >> WINEPATH="/Applications/Darwine/Wine.bundle/Contents/bin/winepath", >> clearWD=TRUE) >> > > Then we are not successfull in finding wine binaries in Mac. This is done by R2WinBUGS:::findUnixBinary > function. It goes like this (returning the result on the first success): > > * check if there is x (WINE or WINEPATH) environmental variable > * check if there is /usr/bin/x > * try with which x > * try with locate x > > I thought that there is which command in Mac also. Afterall Mac uses unix internally. Can you please check in > the terminal the result of the following commands: > > which wine > which winepath > > locate wine > locate winepath > > Btw. As stated last time, working.directory="." is not really needed unless you do want > to keep the intermediate files in current working directory. > > Actually, working.directory="." is required, otherwise the example doesn't work. Hence, the reason that it is there... And, which/locate aren't going to work. Those are for the Unix subsystem. Since Darwine is located in a .bundle, /Applications/Darwine/Wine.bundle, wine/winepath will not be found. A .bundle is like an .app, but a bit more general. For example, a .bundle may contain almost anything and it usually does not contain a Mac app: rather, it is often used to contain command-line scripts like wine, man pages, shared libraries, etc. However, I take your point. It probably makes sense to have links from /usr/local/bin to wine and winepath. But, the documentation should state that this is necessary. I don't see that anywhere. Maybe there should be a Mac-specific doc as well or a wiki or something. Thanks. -- Rodney Sparapani Center for Patient Care & Outcomes Research (PCOR) Sr. Biostatistician http://www.mcw.edu/pcor 4 wheels good, 2 wheels better! Medical College of Wisconsin (MCW) WWLD?: What Would Lombardi Do? Milwaukee, WI, USA |
|
From: Gorjanc G. <Gre...@bf...> - 2008-10-08 16:33:50
|
... >>> As we can see from the log, the model file cannot be opened. This is >>> because the directory RtmpmMFxxp has the restrictive permissions 700. >>> This naming convention looks like R created this directory. If so, >>> then can we have R make the permissions 755? If not, then maybe we >>> should be using C:\windows\temp since it has the right permissions >>> to begin with. >>> >> >> Are you sure about this? If you use working.directory="." then model file should be written in >> current working directory and not in the temporary folder created by R. >> >> I looked in ?tempdir() and there is no sign that we could modify permissions. I did not check the >> permissions on linux, but I find it odd that 700 does not allow WinBUGS to open the file. Afterall, >> 700 should mean that all permissions are granted to the user (owner) of the file, which is the user >> who started R and subsequently WinBUGS via wine. > > I'm sure. Actually, it does not mean that. It means, another process > with your user id AND group id can access those files. But, the group > id of the Wine processes and children is different. Therefore, it > cannot access those files. That's why nobody uses 700 (except for > something like ~/.ssh), but 755 and 750 are quite common. So, it's > a bug. Then this seems to be Mac specific, since I tested the new behaviour with tempdir() on linux, before I committed last changes. It worked without permission problems on linux. I checked and yes, tempdir() creates a directory with 700 permissions. gg |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X