Menu
▾
▴
bugs-r-devel
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(11) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
(7) |
May
(24) |
Jun
(15) |
Jul
(5) |
Aug
(21) |
Sep
(85) |
Oct
(9) |
Nov
|
Dec
|
| 2008 |
Jan
(15) |
Feb
(11) |
Mar
|
Apr
(2) |
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
(29) |
Oct
(47) |
Nov
(1) |
Dec
(1) |
| 2009 |
Jan
(8) |
Feb
(12) |
Mar
(14) |
Apr
(4) |
May
(1) |
Jun
|
Jul
(5) |
Aug
|
Sep
|
Oct
(11) |
Nov
(18) |
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
(1) |
Apr
(3) |
May
(24) |
Jun
|
Jul
(1) |
Aug
(7) |
Sep
(5) |
Oct
(3) |
Nov
(4) |
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
(13) |
Apr
(3) |
May
(2) |
Jun
|
Jul
(1) |
Aug
(24) |
Sep
(3) |
Oct
|
Nov
|
Dec
(29) |
| 2012 |
Jan
(5) |
Feb
(5) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
(9) |
May
(1) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <li...@us...> - 2008-10-11 17:48:14
|
Revision: 90
http://bugs-r.svn.sourceforge.net/bugs-r/?rev=90&view=rev
Author: ligges
Date: 2008-10-11 17:47:53 +0000 (Sat, 11 Oct 2008)
Log Message:
-----------
rewording based on suggestion by Rodney Sparapani
Modified Paths:
--------------
trunk/R2WinBUGS/man/bugs.Rd
Modified: trunk/R2WinBUGS/man/bugs.Rd
===================================================================
--- trunk/R2WinBUGS/man/bugs.Rd 2008-10-10 21:09:44 UTC (rev 89)
+++ trunk/R2WinBUGS/man/bugs.Rd 2008-10-11 17:47:53 UTC (rev 90)
@@ -94,11 +94,13 @@
\pkg{WinBUGS}, defaults to \code{FALSE} on Windows, and \code{TRUE}
otherwise. Not available in S-PLUS.}
\item{WINE}{character, path to \file{wine} binary file, it is
- tried hard to get the information automatically if not given.}
+ tried hard (by a guess and the utilities \code{which} and \code{locate})
+ to get the information automatically if not given.}
\item{newWINE}{Use new versions of Wine that have \file{winepath}
utility}
\item{WINEPATH}{character, path to \file{winepath} binary file, it is
- tried hard to get the information automatically if not given.}
+ tried hard (by a guess and the utilities \code{which} and \code{locate})
+ to get the information automatically if not given.}
\item{bugs.seed}{random seed for \pkg{WinBUGS} (default is no seed)}
\item{summary.only}{If \code{TRUE}, only a parameter summary for very quick analyses is given,
temporary created files are not removed in that case.}
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <gg...@us...> - 2008-10-10 21:09:53
|
Revision: 89
http://bugs-r.svn.sourceforge.net/bugs-r/?rev=89&view=rev
Author: ggorjan
Date: 2008-10-10 21:09:44 +0000 (Fri, 10 Oct 2008)
Log Message:
-----------
ditto
Modified Paths:
--------------
trunk/R2WinBUGS/inst/NEWS
Modified: trunk/R2WinBUGS/inst/NEWS
===================================================================
--- trunk/R2WinBUGS/inst/NEWS 2008-10-10 21:06:41 UTC (rev 88)
+++ trunk/R2WinBUGS/inst/NEWS 2008-10-10 21:09:44 UTC (rev 89)
@@ -2,6 +2,8 @@
=====================
Update 2.1-8?
+- findUnixBinary now fails (with a meaningfull error message) always if the
+ binary file does not exist.
- If working.directory=NULL (the default setting), then a temporary
directory is used as a working directory to prevent overwriting/removing
the existing files.
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <gg...@us...> - 2008-10-10 21:06:46
|
Revision: 88
http://bugs-r.svn.sourceforge.net/bugs-r/?rev=88&view=rev
Author: ggorjan
Date: 2008-10-10 21:06:41 +0000 (Fri, 10 Oct 2008)
Log Message:
-----------
Some more test to make sure we find a binary that exists. This should also solve some dubious warnings on Mac, where which or locate would return "no winepath in ...". Now findUnixBinary will fail with a meaningfull error message.
Modified Paths:
--------------
trunk/R2WinBUGS/R/wineutils.R
Modified: trunk/R2WinBUGS/R/wineutils.R
===================================================================
--- trunk/R2WinBUGS/R/wineutils.R 2008-09-16 09:04:14 UTC (rev 87)
+++ trunk/R2WinBUGS/R/wineutils.R 2008-10-10 21:06:41 UTC (rev 88)
@@ -2,7 +2,7 @@
{
## --- Environmental variable ---
tmp <- Sys.getenv(toupper(x))
- if(nchar(tmp) != 0) return(tmp)
+ if(nchar(tmp) != 0 && file.exists(tmp)) return(tmp)
## else
## --- Standard place ---
@@ -12,13 +12,13 @@
## --- Which ---
tmp <- system(paste("which ", x, sep=""), intern=TRUE)
- if(length(tmp) != 0) return(tmp)
+ if(length(tmp) != 0 && file.exists(tmp)) return(tmp)
## else ..
## --- Locate ---
tmp <- system(paste("locate ", x, " | grep bin/", x, "$", sep=""), intern=TRUE)
tmp <- tmp[length(tmp)] ## keep only last hit
- if(length(tmp) > 0) return(tmp)
+ if(length(tmp) > 0 && file.exists(tmp)) return(tmp)
stop(paste("couldn't find", x, "binary file"))
}
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: Rodney S. <rsp...@mc...> - 2008-10-08 16:39:52
|
Gorjanc Gregor wrote: > >> 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. >> > > Is there any other way to find wine binary on Mac direcly from R? I agree that > is can be cumbersome to set the whole system even on linux, but it seems it > is more complicated on Mac. I think that it would be good if search for wine and > winepath binaries would work without hassle. > > gg > > > No, there isn't. But, I think the bugs documentation is clear now. which needs to be able to find them, or you must provide their paths. So, I symlinked wine/winepath into /usr/local/lib and tested it and it works!!! -- 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:37:52
|
... >> 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... OK > 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. Is there any other way to find wine binary on Mac direcly from R? I agree that is can be cumbersome to set the whole system even on linux, but it seems it is more complicated on Mac. I think that it would be good if search for wine and winepath binaries would work without hassle. gg |
|
From: Rodney S. <rsp...@mc...> - 2008-10-08 16:36:52
|
Gorjanc Gregor wrote: > > 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 > Then I guess it must be due to Wine packaging differences between Linux and Mac. Let's see if the patch fixes it, then we will have proven that it is the problem on Mac (and, apparently, Mac only). -- 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 |
|
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: 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: 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: 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: 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 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: 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 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: 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: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: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: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: 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: 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 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: 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: 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: 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
|
