Re: [Rd] AddComment (gram.y)
On 19/04/2008 1:09 AM, Peter Danenberg wrote: > AddComment in gram.y would have been an extremely useful feature, but > it's been #if-0'd out; is it unimplemented? It was removed in 2001. > > It should have attached a comment attribute to any SEXP associated > with a comment. > The source references achieve something similar. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] package building problem under Windows Vista
Dear list members, I've encountered the following problem trying to build a package under Windows Vista (SP1). The problem occurs with both R 2.6.2 and R 2.7.0 RC (from which this output was produced). The package builds just fine on my XP (SP2) machine. Please see some further comments below. -- snip - Microsoft Windows [Version 6.0.6001] Copyright (c) 2006 Microsoft Corporation. All rights reserved. d:\R-packages>R CMD build tradeCosts * checking for file 'tradeCosts/DESCRIPTION' ... OK * preparing 'tradeCosts': * checking DESCRIPTION meta-information ... OK * installing the package to re-build vignettes installing R.css in C:/Users/JOHNFO~1/AppData/Local/Temp/Rinst602447586 -- Making package tradeCosts adding build stamp to DESCRIPTION installing NAMESPACE file and metadata Error in file(file, "r") : unable to open connection Calls: -> parseNamespaceFile -> parse -> file In addition: Warning message: In file(file, "r") : cannot open file 'C:/Users/JOHNFO~1/AppData/Local/Temp/Rinst602447586/tradeCos ts/NAMESPACE', reason 'Permission denied' Execution halted make[2]: *** [nmspace] Error 1 make[1]: *** [all] Error 2 make: *** [pkg-tradeCosts] Error 2 *** Installation of tradeCosts failed *** Removing 'C:/Users/JOHNFO~1/AppData/Local/Temp/Rinst602447586/tradeCosts' * creating vignettes ... OK * removing junk files * checking for LF line-endings in source and make files * checking for empty or unneeded directories * building 'tradeCosts_0.3-0.tar.gz' d:\R-packages> -- snip - I believe that the error is related to the vignette in the package, since I can build packages without a vignette. Clearly there is a file-permission problem but: (1) I'm using an account with administrator privileges; (2) R is installed into c:\R (and the problem persists even when I install R into d:\R); (3) the problem persists when I run the command window and R itself as administrator, and when I turn off account controls; (4) the problems persists when I reset the environment variables temp and tmp to d:\temp and set the permissions to d:\temp so that all groups and users have full control over that directory. I'm tempted to dump Vista but I've been trying to persist with it since most people (e.g., my students) buying new Windows machines will be getting it. Although I've read section 2.24 of the R for Windows FAQ, it's quite possible that I've missed something of relevance there. Any help would be appreciated. Thanks in advance, John John Fox, Professor Department of Sociology McMaster University Hamilton, Ontario, Canada L8S 4M4 905-525-9140x23604 http://socserv.mcmaster.ca/jfox __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package building problem under Windows Vista
John, The environment variables are case-sensitive (not temp and tmp), and TMPDIR is the one used by 'R CMD build'. I think you need to set TMPDIR to somewhere known to have full control. Why that is not true of C:/Users/JOHNFO~1/AppData/Local/Temp is unclear to me, but I don't think anything you said you did would have tried a different location. Brian On Sat, 19 Apr 2008, John Fox wrote: > Dear list members, > > I've encountered the following problem trying to build a package under > Windows Vista (SP1). The problem occurs with both R 2.6.2 and R 2.7.0 RC > (from which this output was produced). The package builds just fine on my XP > (SP2) machine. Please see some further comments below. > > -- snip - > > Microsoft Windows [Version 6.0.6001] > Copyright (c) 2006 Microsoft Corporation. All rights reserved. > > d:\R-packages>R CMD build tradeCosts > * checking for file 'tradeCosts/DESCRIPTION' ... OK > * preparing 'tradeCosts': > * checking DESCRIPTION meta-information ... OK > * installing the package to re-build vignettes > installing R.css in C:/Users/JOHNFO~1/AppData/Local/Temp/Rinst602447586 > > > -- Making package tradeCosts > adding build stamp to DESCRIPTION > installing NAMESPACE file and metadata > Error in file(file, "r") : unable to open connection > Calls: -> parseNamespaceFile -> parse -> file > In addition: Warning message: > In file(file, "r") : > cannot open file > 'C:/Users/JOHNFO~1/AppData/Local/Temp/Rinst602447586/tradeCos > ts/NAMESPACE', reason 'Permission denied' > Execution halted > make[2]: *** [nmspace] Error 1 > make[1]: *** [all] Error 2 > make: *** [pkg-tradeCosts] Error 2 > *** Installation of tradeCosts failed *** > > Removing 'C:/Users/JOHNFO~1/AppData/Local/Temp/Rinst602447586/tradeCosts' > * creating vignettes ... OK > * removing junk files > * checking for LF line-endings in source and make files > * checking for empty or unneeded directories > * building 'tradeCosts_0.3-0.tar.gz' > > > d:\R-packages> > > -- snip - > > I believe that the error is related to the vignette in the package, since I > can build packages without a vignette. Clearly there is a file-permission > problem but: (1) I'm using an account with administrator privileges; (2) R > is installed into c:\R (and the problem persists even when I install R into > d:\R); (3) the problem persists when I run the command window and R itself > as administrator, and when I turn off account controls; (4) the problems > persists when I reset the environment variables temp and tmp to d:\temp and > set the permissions to d:\temp so that all groups and users have full > control over that directory. > > I'm tempted to dump Vista but I've been trying to persist with it since most > people (e.g., my students) buying new Windows machines will be getting it. > Although I've read section 2.24 of the R for Windows FAQ, it's quite > possible that I've missed something of relevance there. > > Any help would be appreciated. > > Thanks in advance, > John > > > John Fox, Professor > Department of Sociology > McMaster University > Hamilton, Ontario, Canada L8S 4M4 > 905-525-9140x23604 > http://socserv.mcmaster.ca/jfox > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package building problem under Windows Vista
Note that CRAN is also having a problem with the package so its not just you: http://cran.r-project.org/bin/windows/contrib/2.7/check/tm-check.log I also have a problem with the vignettes (note there are two) but as with you this works: Rcmd build --no-vignettes tradeCosts I don't have any special environment variables set for temporary directories and I use C:\Program Files\R\... for R. I use Rcmd.bat and sweave.bat from batchfiles found at: http://batchfiles.googlecode.com which finds R in the registry so no paths need be set. I am on Vista but you seem to have SP1 which I don't have yet. I can build other packages so there is probably something that needs fixing in their vignettes. On Sat, Apr 19, 2008 at 7:52 AM, John Fox <[EMAIL PROTECTED]> wrote: > Dear list members, > > I've encountered the following problem trying to build a package under > Windows Vista (SP1). The problem occurs with both R 2.6.2 and R 2.7.0 RC > (from which this output was produced). The package builds just fine on my XP > (SP2) machine. Please see some further comments below. > > -- snip - > > Microsoft Windows [Version 6.0.6001] > Copyright (c) 2006 Microsoft Corporation. All rights reserved. > > d:\R-packages>R CMD build tradeCosts > * checking for file 'tradeCosts/DESCRIPTION' ... OK > * preparing 'tradeCosts': > * checking DESCRIPTION meta-information ... OK > * installing the package to re-build vignettes > installing R.css in C:/Users/JOHNFO~1/AppData/Local/Temp/Rinst602447586 > > > -- Making package tradeCosts > adding build stamp to DESCRIPTION > installing NAMESPACE file and metadata > Error in file(file, "r") : unable to open connection > Calls: -> parseNamespaceFile -> parse -> file > In addition: Warning message: > In file(file, "r") : > cannot open file > 'C:/Users/JOHNFO~1/AppData/Local/Temp/Rinst602447586/tradeCos > ts/NAMESPACE', reason 'Permission denied' > Execution halted > make[2]: *** [nmspace] Error 1 > make[1]: *** [all] Error 2 > make: *** [pkg-tradeCosts] Error 2 > *** Installation of tradeCosts failed *** > > Removing 'C:/Users/JOHNFO~1/AppData/Local/Temp/Rinst602447586/tradeCosts' > * creating vignettes ... OK > * removing junk files > * checking for LF line-endings in source and make files > * checking for empty or unneeded directories > * building 'tradeCosts_0.3-0.tar.gz' > > > d:\R-packages> > > -- snip - > > I believe that the error is related to the vignette in the package, since I > can build packages without a vignette. Clearly there is a file-permission > problem but: (1) I'm using an account with administrator privileges; (2) R > is installed into c:\R (and the problem persists even when I install R into > d:\R); (3) the problem persists when I run the command window and R itself > as administrator, and when I turn off account controls; (4) the problems > persists when I reset the environment variables temp and tmp to d:\temp and > set the permissions to d:\temp so that all groups and users have full > control over that directory. > > I'm tempted to dump Vista but I've been trying to persist with it since most > people (e.g., my students) buying new Windows machines will be getting it. > Although I've read section 2.24 of the R for Windows FAQ, it's quite > possible that I've missed something of relevance there. > > Any help would be appreciated. > > Thanks in advance, > John > > > John Fox, Professor > Department of Sociology > McMaster University > Hamilton, Ontario, Canada L8S 4M4 > 905-525-9140x23604 > http://socserv.mcmaster.ca/jfox > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package building problem under Windows Vista
Dear Brian, Actually, though it's irrelevant, I did set the environment variables TEMP and TMP (and of course forgot that R uses TMPDIR instead). Unfortunately, setting TMPDIR to d:\temp doesn't solve the problem: snip - Microsoft Windows [Version 6.0.6001] Copyright (c) 2006 Microsoft Corporation. All rights reserved. d:\R-packages>set TMPDIR TMPDIR=d:\temp d:\R-packages>R CMD build tradeCosts * checking for file 'tradeCosts/DESCRIPTION' ... OK * preparing 'tradeCosts': * checking DESCRIPTION meta-information ... OK * installing the package to re-build vignettes installing R.css in d:/temp/Rinst542048336 -- Making package tradeCosts adding build stamp to DESCRIPTION installing NAMESPACE file and metadata Error in file(file, "r") : unable to open connection Calls: -> parseNamespaceFile -> parse -> file In addition: Warning message: In file(file, "r") : cannot open file 'd:/temp/Rinst542048336/tradeCosts/NAMESPACE', reason 'Permis sion denied' Execution halted make[2]: *** [nmspace] Error 1 make[1]: *** [all] Error 2 make: *** [pkg-tradeCosts] Error 2 *** Installation of tradeCosts failed *** Removing 'd:/temp/Rinst542048336/tradeCosts' * creating vignettes ... OK * removing junk files * checking for LF line-endings in source and make files * checking for empty or unneeded directories * building 'tradeCosts_0.3-0.tar.gz' d:\R-packages> snip - Thank you for the suggestion, John > -Original Message- > From: Prof Brian Ripley [mailto:[EMAIL PROTECTED] > Sent: April-19-08 8:53 AM > To: John Fox > Cc: 'R-devel' > Subject: Re: [Rd] package building problem under Windows Vista > > John, > > The environment variables are case-sensitive (not temp and tmp), and > TMPDIR is the one used by 'R CMD build'. I think you need to set TMPDIR > to > somewhere known to have full control. Why that is not true of > C:/Users/JOHNFO~1/AppData/Local/Temp is unclear to me, but I don't > think > anything you said you did would have tried a different location. > > Brian > > On Sat, 19 Apr 2008, John Fox wrote: > > > Dear list members, > > > > I've encountered the following problem trying to build a package > under > > Windows Vista (SP1). The problem occurs with both R 2.6.2 and R 2.7.0 > RC > > (from which this output was produced). The package builds just fine > on my XP > > (SP2) machine. Please see some further comments below. > > > > -- snip - > > > > Microsoft Windows [Version 6.0.6001] > > Copyright (c) 2006 Microsoft Corporation. All rights reserved. > > > > d:\R-packages>R CMD build tradeCosts > > * checking for file 'tradeCosts/DESCRIPTION' ... OK > > * preparing 'tradeCosts': > > * checking DESCRIPTION meta-information ... OK > > * installing the package to re-build vignettes > > installing R.css in > C:/Users/JOHNFO~1/AppData/Local/Temp/Rinst602447586 > > > > > > -- Making package tradeCosts > > adding build stamp to DESCRIPTION > > installing NAMESPACE file and metadata > > Error in file(file, "r") : unable to open connection > > Calls: -> parseNamespaceFile -> parse -> file > > In addition: Warning message: > > In file(file, "r") : > > cannot open file > > 'C:/Users/JOHNFO~1/AppData/Local/Temp/Rinst602447586/tradeCos > > ts/NAMESPACE', reason 'Permission denied' > > Execution halted > > make[2]: *** [nmspace] Error 1 > > make[1]: *** [all] Error 2 > > make: *** [pkg-tradeCosts] Error 2 > > *** Installation of tradeCosts failed *** > > > > Removing > 'C:/Users/JOHNFO~1/AppData/Local/Temp/Rinst602447586/tradeCosts' > > * creating vignettes ... OK > > * removing junk files > > * checking for LF line-endings in source and make files > > * checking for empty or unneeded directories > > * building 'tradeCosts_0.3-0.tar.gz' > > > > > > d:\R-packages> > > > > -- snip - > > > > I believe that the error is related to the vignette in the package, > since I > > can build packages without a vignette. Clearly there is a file- > permission > > problem but: (1) I'm using an account with administrator privileges; > (2) R > > is installed into c:\R (and the problem persists even when I install > R into > > d:\R); (3) the problem persists when I run the command window and R > itself > > as administrator, and when I turn off account controls; (4) the > problems > > persists when I reset the environment variables temp and tmp to > d:\temp and > > set the permissions to d:\temp so that all groups and users have full > > control over that directory. > > > > I'm tempted to dump Vista but I've been trying to persist with it > since most > > people (e.g., my students) buying new Windows machines will be > getting it. > > Although I've read section 2.24 of the R for Windows FAQ, it's quite > > possible that I've missed something of relevance there. > > > > Any help would be appreciated. > > > > Thanks in advance, > > John > > > > > > John Fox,
[Rd] Progress window on updating
I am updating some packages using the packages menu and noticed that the progress window says 100% in the title done all the time. It works, its just that the progress percentage is wrong. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Pb with package::foo(x) <- value
On Sat, 19 Apr 2008, Prof Brian Ripley wrote: > On Fri, 18 Apr 2008, Herve Pages wrote: > >> Hi, >> >> The parser doesn't seem to like this: >> >> somePackage::foo(x) <- value >> somePackage:::foo(x) <- value >> >> where foo() is a replacement function or method defined in package >> somePackage. > > But the error message you show is not from the parser, and > >> parse(text="somePackage:::foo(x) <- value") > expression(somePackage:::foo(x) <- value) > attr(,"srcfile") > > > does work. The error you show arises is in the evaluator. > > That's because that is not legal code. :: and ::: are operators, not part > of the language per se (although I have proposed changing that). The > message comes at a check for a name, and base::length is not a name. It would be nice to be able to handle this some way. Kurt and I have discussed this off and on, but not come up with a good approach. In principle incorporating :: and ::: into the language more directly might be a good idea but I'm not sure how many things this would break. Pragmatically it may be more feasible to modify the complex assignment code to deal with a call of the form ::(somePackage,foo)(x) <- y which is essentially what somePackage:::foo(x) <- value is parsed into. Even there I am a bit nervous at adding to an already fairly hairy piece of code. There are some potential subtleties though: In the evaluation of somePackage:::foo(bar(x)) <- value one deeds to call both somePackage:::foo and somePackage:::foo<-. Just because foo is defined in package X does not necessarily mean foo<- is also deined in package X. Not a very likely scenario, but the sort of thing one needs to think through (and there may be a few others I haven't thought of). I would advise against ever calling an assignment function directly unless you really know what you are doing. The complex assingment process does some initial setup, including checking for the need to duplicate the object to be modified and duplicating if needed. That gets lost with a direct call. Many internal assignment functions also make the duplication check but there are a few that don't (in a most cases that is probably an oversight but I believe it is deliberate in a few). Best, luke > > It often helps to look error messages up in the sources. > > >> For example: >> >> > x <- integer(4) >> > base::length(x) <- 7 >> Error in base::length(x) <- 7 : invalid function in complex assignment >> >> I've tried to put some back quotes on the left side of the assignment in >> different ways but was not successful. So finally I had to use the >> non-replacement form: >> >> > x <- base::`length<-`(x, 7) >> > x >> [1] 0 0 0 0 NA NA NA >> >> Is there a way to avoid this? >> >> Thanks! >> H. >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > -- Luke Tierney Chair, Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: [EMAIL PROTECTED] Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package building problem under Windows Vista
Dear Gabor, > -Original Message- > From: Gabor Grothendieck [mailto:[EMAIL PROTECTED] > Sent: April-19-08 9:10 AM > To: John Fox > Cc: R-devel > Subject: Re: [Rd] package building problem under Windows Vista > > Note that CRAN is also having a problem with the package > so its not just you: > > http://cran.r-project.org/bin/windows/contrib/2.7/check/tm-check.log I'm afraid that I don't see a problem in that check log -- just a string of OKs -- though there is a warning in the log at http://cran.r-project.org/bin/windows/contrib/2.7/check/tradeCosts-check.log . Recall, however, that the package builds (and checks) just fine for me under XP SP2, and that the package fails to build under R 2.6.2 on Vista, for which there is no warning in the package check. When you try to build the tradeCosts package *with* the vignettes, do you get the same file-permission error that I do? Have you been able to build other packages with both vignettes and namespaces successfully? Thanks for the suggestions. John > > I also have a problem with the vignettes (note > there are two) but as with you this works: > > Rcmd build --no-vignettes tradeCosts > > I don't have any special environment variables set for temporary > directories and I use C:\Program Files\R\... > for R. I use Rcmd.bat and sweave.bat from batchfiles found at: > http://batchfiles.googlecode.com > which finds R in the registry so no paths need be set. > I am on Vista but you seem to have SP1 which I don't > have yet. > > I can build other packages so there > is probably something that needs fixing in their vignettes. > > On Sat, Apr 19, 2008 at 7:52 AM, John Fox <[EMAIL PROTECTED]> wrote: > > Dear list members, > > > > I've encountered the following problem trying to build a package > under > > Windows Vista (SP1). The problem occurs with both R 2.6.2 and R 2.7.0 > RC > > (from which this output was produced). The package builds just fine > on my XP > > (SP2) machine. Please see some further comments below. > > > > -- snip - > > > > Microsoft Windows [Version 6.0.6001] > > Copyright (c) 2006 Microsoft Corporation. All rights reserved. > > > > d:\R-packages>R CMD build tradeCosts > > * checking for file 'tradeCosts/DESCRIPTION' ... OK > > * preparing 'tradeCosts': > > * checking DESCRIPTION meta-information ... OK > > * installing the package to re-build vignettes > > installing R.css in > C:/Users/JOHNFO~1/AppData/Local/Temp/Rinst602447586 > > > > > > -- Making package tradeCosts > > adding build stamp to DESCRIPTION > > installing NAMESPACE file and metadata > > Error in file(file, "r") : unable to open connection > > Calls: -> parseNamespaceFile -> parse -> file > > In addition: Warning message: > > In file(file, "r") : > > cannot open file > > 'C:/Users/JOHNFO~1/AppData/Local/Temp/Rinst602447586/tradeCos > > ts/NAMESPACE', reason 'Permission denied' > > Execution halted > > make[2]: *** [nmspace] Error 1 > > make[1]: *** [all] Error 2 > > make: *** [pkg-tradeCosts] Error 2 > > *** Installation of tradeCosts failed *** > > > > Removing > 'C:/Users/JOHNFO~1/AppData/Local/Temp/Rinst602447586/tradeCosts' > > * creating vignettes ... OK > > * removing junk files > > * checking for LF line-endings in source and make files > > * checking for empty or unneeded directories > > * building 'tradeCosts_0.3-0.tar.gz' > > > > > > d:\R-packages> > > > > -- snip - > > > > I believe that the error is related to the vignette in the package, > since I > > can build packages without a vignette. Clearly there is a file- > permission > > problem but: (1) I'm using an account with administrator privileges; > (2) R > > is installed into c:\R (and the problem persists even when I install > R into > > d:\R); (3) the problem persists when I run the command window and R > itself > > as administrator, and when I turn off account controls; (4) the > problems > > persists when I reset the environment variables temp and tmp to > d:\temp and > > set the permissions to d:\temp so that all groups and users have full > > control over that directory. > > > > I'm tempted to dump Vista but I've been trying to persist with it > since most > > people (e.g., my students) buying new Windows machines will be > getting it. > > Although I've read section 2.24 of the R for Windows FAQ, it's quite > > possible that I've missed something of relevance there. > > > > Any help would be appreciated. > > > > Thanks in advance, > > John > > > > > > John Fox, Professor > > Department of Sociology > > McMaster University > > Hamilton, Ontario, Canada L8S 4M4 > > 905-525-9140x23604 > > http://socserv.mcmaster.ca/jfox > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Progress window on updating
Sorry, forgot this: > R.version.string # Vista [1] "R version 2.7.0 alpha (2008-04-03 r45066)" On Sat, Apr 19, 2008 at 9:46 AM, Gabor Grothendieck <[EMAIL PROTECTED]> wrote: > I am updating some packages using the packages menu > and noticed that the progress window says 100% in the > title done all the time. It works, its just that the progress > percentage is wrong. > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Progress window on updating
As the posting guide asked you to do before posting, you need to update to a current snapshot. There was a build for a few hours did that on the second and subsequent downloads only, and yours is two weeks' old. On Sat, 19 Apr 2008, Gabor Grothendieck wrote: > Sorry, forgot this: > >> R.version.string # Vista > [1] "R version 2.7.0 alpha (2008-04-03 r45066)" > > > On Sat, Apr 19, 2008 at 9:46 AM, Gabor Grothendieck > <[EMAIL PROTECTED]> wrote: >> I am updating some packages using the packages menu >> and noticed that the progress window says 100% in the >> title done all the time. It works, its just that the progress >> percentage is wrong. >> > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] nondigits in R_FILEVERSION mess up Windows build
On Fri, 18 Apr 2008, Bill Dunlap wrote: > I tried for the first time to build R from source on Windows, where I > got the source code via svn. Per the Installation and Administration > manual, I altered src\gnuwin32\MkRules so it had the the locally > correct paths to HTML Help Workshop and Inno Setup 5. I also set > USE_SVNVERSION=yes, as suggested in MkRules itself. Then, while in > the directory src/gnuwin32 I ran 'make all recommended' and got an > error from windres very early in the build: > ... > Line 9 of src\gnuwin32\front-ends\rcico.rc is > FILEVERSION R_FILEVERSION > The problem was that my change to MkRules caused 'svnversion' to put an > 'M' (modified) on the end of the svn version it reports. This svn > version number is used in the R_FILEVERSION macro, which is used in in > the *.rc files. The resource file compiler, windres, appears to choke on > non-digits in R_FILEVERSION. (A comment in tools\GETVERSION indicates > it might choke on leading 0's as well.) > > After the following change, to remove the trailing M or S from the > svn version number, the build worked. In R itself, the svn version > contains the trailing 'M' to show it came from modified source. > In the long run it might be nice to alter MkRules so it can read > a LocalMkRules file which is not under svn control, so trivial path > changes in MkRules don't make it look like the build is from modified > source code. I don't think the M-less svn version in R_FILEVERSION > will cause any confusion. I ran into another problem with the trailing 'M' from svnversion when doing 'make rinstaller' in R_HOME/src/gnuwin32: E:\R\R-svn\r-devel\src\gnuwin32\installer>type R-2.8.0dev.log Inno Setup 5 Command-Line Compiler ... Compiler engine version: Inno Setup 5.2.3 (ISPP 5.2.3.0) ... [ISPP] Preprocessing. ... [ISPP] Preprocessed. Parsing [Setup] section, line 10 ... Parsing [Setup] section, line 20 Error on line 12 in e:\R\R-svn\r-devel\src\gnuwin32\installer\R.iss: Value of [Setup] section directive "VersionInfoVersion" is invalid. Compile aborted. The offending line 12 in R.iss is 12 VersionInfoVersion=2.8.0.45381M and it is put there by src/gnuwin32/installer/JRins.pl. The following patch removes possible the trailing M or S from the svn version number when making the Windows installer. With that change 'make installer' completes without error and I can run the installer (and uninstaller) successfully with a locally modified svn tree. It is nice to be able have the svn version available in R and the 'M' (modified) tag is useful information. It would be more useful if we also stored the output of 'svn diff' in the binary distribution, so we could tell exactly what was done. Index: JRins.pl === --- JRins.pl(revision 45381) +++ JRins.pl(working copy) @@ -44,6 +44,7 @@ $SVN = ; close ver; $SVN =~s/Revision: //; +$SVN =~s/[MS]* *$//; $RVER0 .= "." . $SVN; open insfile, "> R.iss" || die "Cannot open R.iss\n"; __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] swig 1.3.35 & R - is the R wrapper still maintained and of interest?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Michael and Soeren ~ I've waited to see if there would be posts from others, but am a little surprised to see only your two. It would seem people aren't using SWIG for R and I wonder why this community hasn't used or wanted such tools? Do we not have a need for them, or are we not aware of them, ...? or ~ So what to do? Firstly, I don't get that crash on load on my Linux box. So we would have to investigate further, but at least it does work somewhere. And such extreme failures are actually less worrying than the potential lack of functionality in the bindings. ~ Soeren has already been in touch with me and indeed the code in the SWIG distribution comes origially from the RSWIG source on the omegahat repository. Unfortunately, the person who took that code and put into the SWIG distribution did by himself and didn't seem to want to work together to improve it add get it beyond the experimental state it was in. Futher, he apparently listed me as the contributor, but haven't communicated at all with the SWIG developers and so I do not have access to the SWIG repository and cannot change the code. So we have a little bit of a problem that might have been better dealt with if code had continued to be developed outside of SWIG by the R community. ~ If there is nobody interested in using SWIG in R, then there is little point in fixing it. I have been working on an alternative way to generate bindings using output from GCC (gcc & g++) and exploring how the bindings should work generally. Most of the ideas I think would be able to go back into SWIG and that _might_ be an easier tool for people to use who don't want more control over the code generation or to do analysis on the code itself. But if nobody other than the two of us is interested in using a general interface code generation mechanism, then perhaps we shouldn't waste too much time on such general resources. However, I think it is of value and I think we can fix up the SWIG module with a little collaboration. ~ D. Michael Lawrence wrote: | I am not sure what is included with swig, but have you seen this? | | http://www.omegahat.org/RSWIG/ | | I'm not sure if it's actively maintained, but at the very least it might | help in your efforts at getting an R swig driver working. | | Michael | | On Fri, Apr 18, 2008 at 3:49 AM, Soeren Sonnenburg <[EMAIL PROTECTED]> wrote: | |> Dear all, |> |> I was trying to use the R swig wrapper with R 2.7 and shogun |> ( http://www.shogun-toolbox.org ) but it fails completely, as in doesn't |> even compile and even after patching then though compiling - crashes... |> |> So I asked on swig-users/swig-devel CC'ing the potential R maintainer |> but I never received a reply. I now wonder if anyone here could help or |> would be willing to maintain R+swig. |> |> The compile fix for R 2.7 is here |> |> http://article.gmane.org/gmane.comp.programming.swig/12697 |> |> and the crash I am now that it compiles see is |> |> #0 0xb804e201 in _dl_debug_state () from /lib/ld-linux.so.2 |> #1 0xb8051608 in dl_open_worker () from /lib/ld-linux.so.2 |> #2 0xb804d5d6 in _dl_catch_error () from /lib/ld-linux.so.2 |> #3 0xb8050f5e in _dl_open () from /lib/ld-linux.so.2 |> #4 0xb74c3c19 in dlopen_doit () from /lib/i686/cmov/libdl.so.2 |> #5 0xb804d5d6 in _dl_catch_error () from /lib/ld-linux.so.2 |> #6 0xb74c42bc in _dlerror_run () from /lib/i686/cmov/libdl.so.2 |> #7 0xb74c3b51 in dlopen@@GLIBC_2.1 () from /lib/i686/cmov/libdl.so.2 |> #8 0xb7efd036 in loadLibrary (path=0xbfa5650c |> "/home/sonne/Documents/work/fml/repositories/shogun/trunk/src/features/Features.so", |> asLocal=1, now=1, search=0x9a81f20 "") at dynload.c:92 |> #9 0xb7d6efb3 in AddDLL (path=0xbfa5650c |> "/home/sonne/Documents/work/fml/repositories/shogun/trunk/src/features/Features.so", |> asLocal=1, now=1, DLLsearchpath=0x9a81f20 "") at Rdynload.c:543 |> #10 0xb7d6f657 in do_dynload (call=0x9e23998, op=0x9a91e44, |> args=0xa60d5e0, env=0xa60d650) at Rdynload.c:904 |> #11 0xb7e43dba in do_internal (call=0x9e239d0, op=0x9a8798c, |> args=0xa60d5e0, env=0xa60d650) at names.c:1129 |> #12 0xb7e0df21 in Rf_eval (e=0x9e239d0, rho=0xa60d650) at eval.c:463 |> #13 0xb7e11a3c in Rf_applyClosure (call=0xa60d74c, op=0x9e23a94, |> arglist=0xa60d6dc, rho=0x9a9a720, suppliedenv=0x9a9a73c) at eval.c:669 |> #14 0xb7e0de19 in Rf_eval (e=0xa60d74c, rho=0x9a9a720) at eval.c:507 |> #15 0xb7e31a00 in Rf_ReplIteration (rho=0x9a9a720, savestack=0, |> browselevel=0, state=0xbfa589a8) at main.c:257 |> #16 0xb7e31ddc in run_Rmainloop () at main.c:306 |> #17 0xb7e31e1c in Rf_mainloop () at main.c:974 |> #18 0x08048776 in main (ac=1, av=0xb805b668) at Rmain.c:35 |> #19 0xb7be8450 in __libc_start_main () from /lib/i686/cmov/libc.so.6 |> #20 0x08048691 in _start () |> |> To reproduce |> |> wget http://nn7.de/debugging/shogun-0.6.1+svn2882.tar.bz2 |> tar xjf shogun-0.6.1+svn2882.tar.bz2 |> cd shogun-0.6.1+svn2882/src |> ./co
Re: [Rd] swig 1.3.35 & R - is the R wrapper still maintained and of interest?
Hi. I also have looked for a SWIG-R module in the recent past. However, since my use case was small enough, and given the experimental state in which I found the current R module implementation, I gave up, and coded the bindings manually. By the way, a tool like SWIG is extremely useful, as tnx to it one should be able maintain R bindings to whatever C libraries with very little mainteinance and documentation costs. And this in turn would open a lot of existing C code to useRs. Unfortunatly It's too late for it, but seems like a GSoC idea on this topic would have been quite interesting... Bests, Antonio. 2008/4/19, Duncan Temple Lang <[EMAIL PROTECTED]>: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > Hi Michael and Soeren > > ~ I've waited to see if there would be posts from others, but am > a little surprised to see only your two. It would seem people aren't > using SWIG for R and I wonder why this community hasn't used or wanted > such tools? Do we not have a need for them, or are we not aware of them, > ...? > or > > ~ So what to do? Firstly, I don't get that crash on load on my Linux > box. So we would have to investigate further, but at least it does work > somewhere. And such extreme failures are actually less worrying than the > potential lack of functionality in the bindings. > > ~ Soeren has already been in touch with me and indeed the > code in the SWIG distribution comes origially from the RSWIG source on the > omegahat repository. Unfortunately, the person who took that code > and put into the SWIG distribution did by himself and didn't seem > to want to work together to improve it add get it beyond the experimental > state > it was in. Futher, he apparently listed me as the contributor, > but haven't communicated at all with the SWIG developers and so I do not have > access to the SWIG repository and cannot change the code. > So we have a little bit of a problem that might have been better dealt with > if > code had continued to be developed outside of SWIG by the R community. > > > ~ If there is nobody interested in using SWIG in R, then there is little > point > in fixing it. I have been working on an alternative way to generate > bindings using > output from GCC (gcc & g++) and exploring how the bindings should work > generally. Most of the ideas I think would be able to go back into SWIG > and that _might_ be an easier tool for people to use who don't want more > control > over the code generation or to do analysis on the code itself. > But if nobody other than the two of us is interested in using a general > interface code > generation mechanism, then perhaps we shouldn't waste too much time on such > general resources. However, I think it is of value and I think > we can fix up the SWIG module with a little collaboration. > > ~ D. > > > Michael Lawrence wrote: > | I am not sure what is included with swig, but have you seen this? > | > | http://www.omegahat.org/RSWIG/ > | > | I'm not sure if it's actively maintained, but at the very least it might > | help in your efforts at getting an R swig driver working. > | > | Michael > | > | On Fri, Apr 18, 2008 at 3:49 AM, Soeren Sonnenburg <[EMAIL PROTECTED]> > wrote: > | > |> Dear all, > |> > |> I was trying to use the R swig wrapper with R 2.7 and shogun > |> ( http://www.shogun-toolbox.org ) but it fails completely, as in doesn't > |> even compile and even after patching then though compiling - crashes... > |> > |> So I asked on swig-users/swig-devel CC'ing the potential R maintainer > |> but I never received a reply. I now wonder if anyone here could help or > |> would be willing to maintain R+swig. > |> > |> The compile fix for R 2.7 is here > |> > |> http://article.gmane.org/gmane.comp.programming.swig/12697 > |> > |> and the crash I am now that it compiles see is > |> > |> #0 0xb804e201 in _dl_debug_state () from /lib/ld-linux.so.2 > |> #1 0xb8051608 in dl_open_worker () from /lib/ld-linux.so.2 > |> #2 0xb804d5d6 in _dl_catch_error () from /lib/ld-linux.so.2 > |> #3 0xb8050f5e in _dl_open () from /lib/ld-linux.so.2 > |> #4 0xb74c3c19 in dlopen_doit () from /lib/i686/cmov/libdl.so.2 > |> #5 0xb804d5d6 in _dl_catch_error () from /lib/ld-linux.so.2 > |> #6 0xb74c42bc in _dlerror_run () from /lib/i686/cmov/libdl.so.2 > |> #7 0xb74c3b51 in dlopen@@GLIBC_2.1 () from /lib/i686/cmov/libdl.so.2 > |> #8 0xb7efd036 in loadLibrary (path=0xbfa5650c > |> > "/home/sonne/Documents/work/fml/repositories/shogun/trunk/src/features/Features.so", > |> asLocal=1, now=1, search=0x9a81f20 "") at dynload.c:92 > |> #9 0xb7d6efb3 in AddDLL (path=0xbfa5650c > |> > "/home/sonne/Documents/work/fml/repositories/shogun/trunk/src/features/Features.so", > |> asLocal=1, now=1, DLLsearchpath=0x9a81f20 "") at Rdynload.c:543 > |> #10 0xb7d6f657 in do_dynload (call=0x9e23998, op=0x9a91e44, > |> args=0xa60d5e0, env=0xa60d650) at Rdynload.c:904 > |> #11 0xb7
[Rd] Fortran underscore problem persists on Linux x86/64 (PR#11206)
Full_Name: Thomas Petzoldt
Version: R 2.8.0 devel, svn version 45389
OS: Linux x86/64 Ubuntu 7.1
Submission from: (NULL) (217.235.62.12)
In contrast to all other tested operating systems a call of Fortran functions on
Linux x86/64 requires an appended underscore.
The problem occured with package deSolve
(http://r-forge.r-project.org/projects/desolve/)
See also:
http://tolstoy.newcastle.edu.au/R/e4/devel/08/04/1224.html
Relevant code snippets
In R:
> getNativeSymbolInfo("iniaqua", PACKAGE = "deSolve")$address
Error in FUN("iniaqua"[[1L]], ...) :
no such symbol iniaqua in package deSolve
> getNativeSymbolInfo("iniaqua_", PACKAGE = "deSolve")$address
attr(,"class")
[1] "NativeSymbol"
In Aquaphy.f:
subroutine iniaqua(odeparms)
external odeparms
double precision pars(19)
common /myparms/pars
call odeparms(19, pars)
return
end
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] AddComment (gram.y)
> The source references achieve something similar. Thanks, Duncan; it seems like SkipComment cannibalizes comments before they get to srcref, though. I had to go back as far as 1999, actually, to find a version of gram.y that implemented AddComment; would anyone object to bringing it back? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] naive question regarding running parallel C code from R
Dirk Eddelbuettel <[EMAIL PROTECTED]> writes: > > As I recall, you use Debian so do > >$ sudo apt-get install r-cran-snow r-cran-rmpi > > to get R support working out-of-the box. Then study the examples for Snow on > Luke's website. [ I also have some slides on my website from presentations I > gave a few years ago. ] > > That allows you to _easily_ do the so-called embarassingly parallel: same > problem, different parameters. Or, you could also loop over CYCLES across > the cluster. Start with something simple to study it and then go from there. > > Hope this helps, Dirk > Very much! Thanks Dirk and Simon - I've got snow and rmpi installed and I'll start from there. Cheers, Tyler -- There is something fascinating about science. One gets such wholesale returns of conjecture out of such a trifling investment of fact. --Mark Twain __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] swig 1.3.35 & R - is the R wrapper still maintained and of interest?
On Sun, 2008-04-20 at 05:44 +1200, Duncan Temple Lang wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > Hi Michael and Soeren > > ~ I've waited to see if there would be posts from others, but am > a little surprised to see only your two. It would seem people aren't > using SWIG for R and I wonder why this community hasn't used or wanted > such tools? Do we not have a need for them, or are we not aware of them, ...? > or Just to do some advertising on this. Using swig you basically automagically get your C function directly available in R. And using typemaps you get things like compute_foo(double* vec, int len); immediately wrapped to R and you may call it via compute_foo(c(1.1, 2.2, 3.3)) same for matrices, returning things and for object oriented stuff even slots!! For the shogun project this means: I for free can support an R, octave and python port only by writing the typemaps once for each language! And hey I've written these typemaps already so you could immediately use this without messing with the R C interface at all. So this is of incredible help and I really think that this should be worked on further. > ~ So what to do? Firstly, I don't get that crash on load on my Linux > box. So we would have to investigate further, but at least it does work > somewhere. And such extreme failures are actually less worrying than the > potential lack of functionality in the bindings. Was this with R 2.7 and pasting things? Because it strangely doesn't crash when I do R < script.R > ~ Soeren has already been in touch with me and indeed the > code in the SWIG distribution comes origially from the RSWIG source on the > omegahat repository. Unfortunately, the person who took that code > and put into the SWIG distribution did by himself and didn't seem > to want to work together to improve it add get it beyond the experimental > state > it was in. Futher, he apparently listed me as the contributor, > but haven't communicated at all with the SWIG developers and so I do not have > access to the SWIG repository and cannot change the code. > So we have a little bit of a problem that might have been better dealt with if > code had continued to be developed outside of SWIG by the R community. Well I guess this could easily be changed if you post on the swig-devel mailinglist with some short explanation. Also swig's svn-trunk is publicly available and as no one seems to maintain the R port your patches will stay current :) Anyway now that this port is in swig, I suggest to maintain it there - things can only improve... > ~ If there is nobody interested in using SWIG in R, then there is little point > in fixing it. I have been working on an alternative way to generate bindings > using Well I would be and I have everything inside of shogun ready (all typemaps, build system etc). > output from GCC (gcc & g++) and exploring how the bindings should work > generally. Most of the ideas I think would be able to go back into SWIG > and that _might_ be an easier tool for people to use who don't want more > control > over the code generation or to do analysis on the code itself. > But if nobody other than the two of us is interested in using a general > interface code > generation mechanism, then perhaps we shouldn't waste too much time on such > general resources. However, I think it is of value and I think > we can fix up the SWIG module with a little collaboration. I would very much hope that we can fix up SWIG & R, with the compile fix for R2.7 to begin with. I would not want to invest time in another solution than swig, simply because swig is very widespread and well maintained for at least python & octave. However while I can contribute isolated test cases with as much debugging information as needed I am unable to do the fixes to the swig-R core. I will certainly ASAP try out patches and I could write some examples... Soeren > ~ D. > > > Michael Lawrence wrote: > | I am not sure what is included with swig, but have you seen this? > | > | http://www.omegahat.org/RSWIG/ > | > | I'm not sure if it's actively maintained, but at the very least it might > | help in your efforts at getting an R swig driver working. > | > | Michael > | > | On Fri, Apr 18, 2008 at 3:49 AM, Soeren Sonnenburg <[EMAIL PROTECTED]> > wrote: > | > |> Dear all, > |> > |> I was trying to use the R swig wrapper with R 2.7 and shogun > |> ( http://www.shogun-toolbox.org ) but it fails completely, as in doesn't > |> even compile and even after patching then though compiling - crashes... > |> > |> So I asked on swig-users/swig-devel CC'ing the potential R maintainer > |> but I never received a reply. I now wonder if anyone here could help or > |> would be willing to maintain R+swig. > |> > |> The compile fix for R 2.7 is here > |> > |> http://article.gmane.org/gmane.comp.programming.swig/12697 > |> > |> and the crash I am now that it compiles see is > |> > |> #0 0xb804e201 in _dl_debug_state () from /lib/ld-
Re: [Rd] swig 1.3.35 & R - is the R wrapper still maintained and of interest?
Duncan, On 20 April 2008 at 05:44, Duncan Temple Lang wrote: | ~ I've waited to see if there would be posts from others, but am | a little surprised to see only your two. It would seem people aren't | using SWIG for R and I wonder why this community hasn't used or wanted AFAICT it is a classic chicken and egg problem. "Something" exists, but is not exactly mature, been used mostly just for a very large and rapidly changing codebase (ie Quantlib, which should stabilise after the 1.0 release 'real soon now') with moderate success and hence doesn't get off the ground for more. | such tools? Do we not have a need for them, or are we not aware of them, ...? | or My conjecture is that it would take off rather forcefully if only there were one or two use cases for moderately-sized well-known libraries, providing both use cases and usage templates. | ~ So what to do? Firstly, I don't get that crash on load on my Linux | box. So we would have to investigate further, but at least it does work | somewhere. And such extreme failures are actually less worrying than the | potential lack of functionality in the bindings. | | ~ Soeren has already been in touch with me and indeed the | code in the SWIG distribution comes origially from the RSWIG source on the | omegahat repository. Unfortunately, the person who took that code | and put into the SWIG distribution did by himself and didn't seem | to want to work together to improve it add get it beyond the experimental state | it was in. Futher, he apparently listed me as the contributor, | but haven't communicated at all with the SWIG developers and so I do not have I think that is not true. Joe Wang had me CCed on a few email he had with the Swig maintainers. He either has or had write access to the Swig repo, and that seems to make sense as he was, afaik, the only one showing up there. Or did you ever offer your code for inclusion there? But all that is spilled milk now. Soeren has an _actual_ issue _right now_ so what can we do to get a proven tool (ie Swig) working and integrated with R for him to get his work done and R and Shogun integrated ? | access to the SWIG repository and cannot change the code. | So we have a little bit of a problem that might have been better dealt with if | code had continued to be developed outside of SWIG by the R community. | | ~ If there is nobody interested in using SWIG in R, then there is little point | in fixing it. I have been working on an alternative way to generate bindings using | output from GCC (gcc & g++) and exploring how the bindings should work Sure, that is very well for you as a research project, but Swig is there, is rather mature, understood and widel y used -- just not as much with R as it could be. IMHO we'd better off focussing on getting Swig working. | generally. Most of the ideas I think would be able to go back into SWIG | and that _might_ be an easier tool for people to use who don't want more control | over the code generation or to do analysis on the code itself. | But if nobody other than the two of us is interested in using a general interface code | generation mechanism, then perhaps we shouldn't waste too much time on such | general resources. However, I think it is of value and I think | we can fix up the SWIG module with a little collaboration. There is definitely interest. Eg from the Quantlib angle, a few people expressed interest a few months ago to revive the R/Quantlib integration via Swig but nothing much has come of it yet. We're all too busy it seems. Dirk | ~ D. | | | Michael Lawrence wrote: | | I am not sure what is included with swig, but have you seen this? | | | | http://www.omegahat.org/RSWIG/ | | | | I'm not sure if it's actively maintained, but at the very least it might | | help in your efforts at getting an R swig driver working. | | | | Michael | | | | On Fri, Apr 18, 2008 at 3:49 AM, Soeren Sonnenburg <[EMAIL PROTECTED]> wrote: | | | |> Dear all, | |> | |> I was trying to use the R swig wrapper with R 2.7 and shogun | |> ( http://www.shogun-toolbox.org ) but it fails completely, as in doesn't | |> even compile and even after patching then though compiling - crashes... | |> | |> So I asked on swig-users/swig-devel CC'ing the potential R maintainer | |> but I never received a reply. I now wonder if anyone here could help or | |> would be willing to maintain R+swig. | |> | |> The compile fix for R 2.7 is here | |> | |> http://article.gmane.org/gmane.comp.programming.swig/12697 | |> | |> and the crash I am now that it compiles see is | |> | |> #0 0xb804e201 in _dl_debug_state () from /lib/ld-linux.so.2 | |> #1 0xb8051608 in dl_open_worker () from /lib/ld-linux.so.2 | |> #2 0xb804d5d6 in _dl_catch_error () from /lib/ld-linux.so.2 | |> #3 0xb8050f5e in _dl_open () from /lib/ld-linux.so.2 | |> #4 0xb74c3c19 in dlopen_doit () from /lib/i686/cmov/libdl.so.2 | |> #5 0xb804d5d6 in _dl_catch_error () from /lib/ld-linux.so.2 | |> #6 0xb74c42bc in
Re: [Rd] AddComment (gram.y)
Peter Danenberg wrote: >> The source references achieve something similar. >> > > Thanks, Duncan; it seems like SkipComment cannibalizes comments before > they get to srcref, though. > > I had to go back as far as 1999, actually, to find a version of gram.y > that implemented AddComment; would anyone object to bringing it back? > Yes, I would. Use the source refs. They aren't "cannibalized", they are still there, where the source ref says they are. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] AddComment (gram.y)
> "DM" == Duncan Murdoch <[EMAIL PROTECTED]>
> on Sat, 19 Apr 2008 16:46:32 -0400 writes:
DM> Peter Danenberg wrote:
>>> The source references achieve something similar.
>>>
> Thanks, Duncan; it seems like SkipComment cannibalizes
>> comments before they get to srcref, though.
>>
>> I had to go back as far as 1999, actually, to find a
>> version of gram.y that implemented AddComment; would
>> anyone object to bringing it back?
>>
DM> Yes, I would.
and so would probably almost everyone in R-core.
We *did* think already back in the last millennium...
and removed them for a good reason
{IIRC, because there were always cases where they were attached
to the wrong expression, and we were more or less convinced,
there was no to do it "right" in all cases}.
Martin Maechler
DM> Use the source refs. They aren't
DM> "cannibalized", they are still there, where the source
DM> ref says they are.
DM> Duncan Murdoch
DM> __
DM> R-devel@r-project.org mailing list
DM> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] 2.7.0 RC (2008-04-19 r45391) package.skeleton LazyLoad incorrect
package.skeleton inserts a lowercase second l in LazyLoad, so that the package is not, in fact, lazy loaded. Martin -- Martin Morgan Computational Biology / Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: Arnold Building M2 B169 Phone: (206) 667-2793 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] swig 1.3.35 & R - is the R wrapper still maintained and of interest?
On Sat, Apr 19, 2008 at 1:41 PM, Dirk Eddelbuettel <[EMAIL PROTECTED]> wrote: > > Duncan, > > On 20 April 2008 at 05:44, Duncan Temple Lang wrote: > | ~ I've waited to see if there would be posts from others, but am > | a little surprised to see only your two. It would seem people aren't > | using SWIG for R and I wonder why this community hasn't used or wanted > > AFAICT it is a classic chicken and egg problem. > > "Something" exists, but is not exactly mature, been used mostly just for a > very large and rapidly changing codebase (ie Quantlib, which should > stabilise > after the 1.0 release 'real soon now') with moderate success and hence > doesn't get off the ground for more. > > | such tools? Do we not have a need for them, or are we not aware of > them, ...? > | or > > My conjecture is that it would take off rather forcefully if only there > were > one or two use cases for moderately-sized well-known libraries, providing > both use cases and usage templates. > This may be somewhat off-topic but: My personal interests have led me away from SWIG-generated bindings, because SWIG does not incorporate the OOP semantics of GObject-based libraries. A large number of C libraries (at least for GUIs and visualization) are implemented around GObject these days, so it's an unfortunate limitation. The GObject introspection project ( http://live.gnome.org/GObjectIntrospection) is really starting to come together. Their IDL, while GObject-focused, will be able to express interfaces to non-GObject-based libraries as well, so it's somewhat of a superset of SWIG. The IDL is XML-based and can be autogenerated from C source using a real C parser (gcc-based). They also finally caught on to my suggestion of embedding memory management, parameter directions, etc in in-line comments (via gtk-doc), which should go a long way towards stream-lining things, even in non-GObject libraries that use gtk-doc like Cairo. The VAPI format from the Vala project (http://live.gnome.org/Vala) is easily hand-edited in C#-ish syntax and will be convertible to the IDL. There are a large number of languages that have some sort of binding to GObject-based libraries (http://www.gtk.org/language-bindings.html), including R of course, and I expect many of them will converge on using the GObject introspection stuff as their input. Anyway, I am not debating the general utility of a SWIG-R connection; just explaining things from my perspective. Michael > | ~ So what to do? Firstly, I don't get that crash on load on my Linux > | box. So we would have to investigate further, but at least it does work > | somewhere. And such extreme failures are actually less worrying than > the > | potential lack of functionality in the bindings. > | > | ~ Soeren has already been in touch with me and indeed the > | code in the SWIG distribution comes origially from the RSWIG source on > the > | omegahat repository. Unfortunately, the person who took that code > | and put into the SWIG distribution did by himself and didn't seem > | to want to work together to improve it add get it beyond the > experimental state > | it was in. Futher, he apparently listed me as the contributor, > | but haven't communicated at all with the SWIG developers and so I do not > have > > I think that is not true. Joe Wang had me CCed on a few email he had with > the > Swig maintainers. He either has or had write access to the Swig repo, and > that seems to make sense as he was, afaik, the only one showing up there. > Or > did you ever offer your code for inclusion there? > > But all that is spilled milk now. Soeren has an _actual_ issue _right > now_ > so what can we do to get a proven tool (ie Swig) working and integrated > with > R for him to get his work done and R and Shogun integrated ? > > | access to the SWIG repository and cannot change the code. > | So we have a little bit of a problem that might have been better dealt > with if > | code had continued to be developed outside of SWIG by the R community. > | > | ~ If there is nobody interested in using SWIG in R, then there is little > point > | in fixing it. I have been working on an alternative way to generate > bindings using > | output from GCC (gcc & g++) and exploring how the bindings should work > > Sure, that is very well for you as a research project, but Swig is there, > is > rather mature, understood and widel y used -- just not as much with R as > it > could be. IMHO we'd better off focussing on getting Swig working. > > | generally. Most of the ideas I think would be able to go back into SWIG > | and that _might_ be an easier tool for people to use who don't want more > control > | over the code generation or to do analysis on the code itself. > | But if nobody other than the two of us is interested in using a general > interface code > | generation mechanism, then perhaps we shouldn't waste too much time on > such > | general resources. However, I think it is of value and I think > | we can fix up
Re: [Rd] 2.7.0 RC (2008-04-19 r45391) package.skeleton LazyLoad incorrect
Martin Morgan wrote: > package.skeleton inserts a lowercase second l in LazyLoad, so that the > package is not, in fact, lazy loaded. > > Martin > Fix committed. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
