Re: [Rd] [R] Debugging R/Fortran in Windows
Thanks very much to Uwe, Duncan and Seth (who replied off the list). Uwe - That section of the R for Windows FAQ was very useful - thanks! Sorry I posted a question involving C/Fortran to R-Help. Duncan - Thanks for all the useful info. I've bookmarked the pages you sent me. Seth - Thanks for suggesting valgrind. I tried it out, and it correctly told me that memory leakage was not the problem (although I didn't believe it at first). It turned out that the reason my variables were being overwritten was not because of memory leakage, but because of my own stupidity - using the same variable name for a function I was estimating and for my current estimate of that function. Sorry I didn't spend more time checking this myself! Thanks again for your help, James __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] \dontshow
Gabor Grothendieck wrote:
On 9/9/05, Gabor Grothendieck [EMAIL PROTECTED] wrote:
In R 2.2.0 I find that even if I use \dontshow in the examples section
of an .Rd file that the code still shows.
Has anyone else seen this?
Are there any packages that use this facility that I could
try in order to check this?
I am using
R.version.string # XP
R version 2.2.0, 2005-09-03
I realize that this description was not clear enough. It does not
show in the help file but when you run the example it shows
and it was that part I was concerned about. Is that the way its
supposed to work?
Yes:
Examples displayed and executed during checks/example runs:
as is
Examples displayed but NOT executed during checks/example runs:
\dontrun{}
Examples NOT displayed but executed during checks/example runs:
\dontshow{}
Examples NOT displayed and NOT executed during checks/example runs:
simply don't type them anywhere ;-)
Best,
Uwe Ligges
__
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
[Rd] FreeBSD 7.0-CURRENT and R-2.2.0 alpha
The configure script runs fine, but when I compile todays alpha version of R-2.2.0 (R-alpha_2005-09-10_r35546.tar.gz) under FreeBSD 7.0-CURRENT from Sept. 4th I get the following output: [...] gcc -I../../src/extra/zlib -I../../src/extra/bzip2 -I../../src/extra/pcre -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H -D__NO_MATH_INLINES -g -O2 -c version.c -o version.o gcc -I../../src/extra/zlib -I../../src/extra/bzip2 -I../../src/extra/pcre -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H -D__NO_MATH_INLINES -g -O2 -c vfonts.c -o vfonts.o f77 -g -O2 -c xxxpr.f -o xxxpr.o gcc -export-dynamic -L/usr/local/lib -o R.bin Rmain.o CConverters.o CommandLineArgs.o Rdynload.o Renviron.o RNG.o apply.o arithmetic.o apse.o array.o attrib.o base.o bind.o builtin.o character.o coerce.o colors.o complex.o connections.o context.o cov.o cum.o dcf.o datetime.o debug.o deparse.o deriv.o dotcode.o dounzip.o dstruct.o duplicate.o engine.o envir.o errors.o eval.o format.o fourier.o gevents.o gram.o gram-ex.o graphics.o identical.o internet.o iosupport.o lapack.o list.o logic.o main.o mapply.o match.o memory.o model.o names.o objects.o optim.o optimize.o options.o par.o paste.o pcre.o platform.o plot.o plot3d.o plotmath.o print.o printarray.o printvector.o printutils.o qsort.o random.o regex.o registration.o relop.o saveload.o scan.o seq.o serialize.o size.o sort.o source.o split.o sprintf.o startup.o subassign.o subscript.o subset.o summary.o sysutils.o unique.o util.o version.o vfonts.o xxxpr.o ../unix/libunix.a ../appl/libappl.a ../nmath/libnmath.a -lf77blas -latlas -lg2c -lm ../extra/zlib/libz.a ../extra/bzip2/libbz2.a ../extra/pcre/libpcre.a /usr/local/lib/libintl.so -Wl,-rpath -Wl,/usr/local/lib -lreadline -lm -liconv complex.o(.text+0x106): In function `mycpow': /usr/local/R-alpha/src/main/complex.c:170: undefined reference to `cpow' complex.o(.text+0x6f9): In function `do_cmathfuns': /usr/local/R-alpha/src/main/complex.c:323: undefined reference to `carg' complex.o(.text+0xb4b): In function `z_log': /usr/local/R-alpha/src/main/complex.c:423: undefined reference to `clog' complex.o(.text+0xb86): In function `z_logbase': /usr/local/R-alpha/src/main/complex.c:429: undefined reference to `clog' complex.o(.text+0xb98):/usr/local/R-alpha/src/main/complex.c:429: undefined reference to `clog' complex.o(.text+0xbd8): In function `z_exp': /usr/local/R-alpha/src/main/complex.c:434: undefined reference to `cexp' complex.o(.text+0xbf8): In function `z_sqrt': /usr/local/R-alpha/src/main/complex.c:439: undefined reference to `csqrt' complex.o(.text+0xc18): In function `z_cos': /usr/local/R-alpha/src/main/complex.c:486: undefined reference to `ccos' complex.o(.text+0xc38): In function `z_sin': /usr/local/R-alpha/src/main/complex.c:491: undefined reference to `csin' complex.o(.text+0xc5e): In function `z_tan': /usr/local/R-alpha/src/main/complex.c:497: undefined reference to `ctan' complex.o(.text+0xd26): In function `z_atan2': /usr/local/R-alpha/src/main/complex.c:523: undefined reference to `catan' complex.o(.text+0xe18): In function `z_asin': /usr/local/R-alpha/src/main/complex.c:541: undefined reference to `casin' complex.o(.text+0xe38): In function `z_acos': /usr/local/R-alpha/src/main/complex.c:553: undefined reference to `cacos' complex.o(.text+0xe58): In function `z_atan': /usr/local/R-alpha/src/main/complex.c:559: undefined reference to `catan' complex.o(.text+0xe78): In function `z_acosh': /usr/local/R-alpha/src/main/complex.c:564: undefined reference to `cacosh' complex.o(.text+0xe98): In function `z_asinh': /usr/local/R-alpha/src/main/complex.c:569: undefined reference to `casinh' complex.o(.text+0xeb8): In function `z_atanh': /usr/local/R-alpha/src/main/complex.c:574: undefined reference to `catanh' complex.o(.text+0xed8): In function `z_cosh': /usr/local/R-alpha/src/main/complex.c:579: undefined reference to `ccosh' complex.o(.text+0xef8): In function `z_sinh': /usr/local/R-alpha/src/main/complex.c:584: undefined reference to `csinh' complex.o(.text+0xf18): In function `z_tanh': /usr/local/R-alpha/src/main/complex.c:589: undefined reference to `ctanh' *** Error code 1 Stop in /usr/local/R-alpha/src/main. *** Error code 1 Stop in /usr/local/R-alpha/src/main. *** Error code 1 Stop in /usr/local/R-alpha/src. *** Error code 1 Stop in /usr/local/R-alpha. Am I missing something? Thank you, Rainer Hurling __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R.version.string (Re: MikTeX will be assumed in R 2.2.0 in Windows)
Gabor Grothendieck wrote: On 9/9/05, Duncan Murdoch [EMAIL PROTECTED] wrote: I've just committed some changes to allow R to be built and to use MikTeX without needing the Rd.sty files to be installed to localtexmf. Unfortunately, the changes are not compatible with other TeX packages, so if you're not using MikTeX you'll need to edit a couple of the config files (or set an environment variable). I'd appreciate hearing of any problems during the alpha or beta test period. A binary build containing the changes should be on CRAN tomorrow or the next day. Look for revision 35546 or higher. Note that R.version.string in R 2.2.0 2005-09-03 does not give this sort of version information. If we are going to use this style I suggest we modify R.version.string accordingly. You can get the revision number from the startup banner if you download a binary build. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Debugging R/Fortran in Windows
James Wettenhall wrote: Thanks very much to Uwe, Duncan and Seth (who replied off the list). Uwe - That section of the R for Windows FAQ was very useful - thanks! Sorry I posted a question involving C/Fortran to R-Help. Duncan - Thanks for all the useful info. I've bookmarked the pages you sent me. Seth - Thanks for suggesting valgrind. I tried it out, and it correctly told me that memory leakage was not the problem (although I didn't believe it at first). Is there a version of valgrind that works in Windows now, or did you do this test somewhere else? Duncan Murdoch It turned out that the reason my variables were being overwritten was not because of memory leakage, but because of my own stupidity - using the same variable name for a function I was estimating and for my current estimate of that function. Sorry I didn't spend more time checking this myself! Thanks again for your help, James __ 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] Issue tracking in packages [was: Re: [R] change in read.spss, package foreign?]
On Fri, 9 Sep 2005 10:33:03 -0700 (PDT), Thomas Lumley (TL) wrote: On Fri, 9 Sep 2005, Gabor Grothendieck wrote: I personally put NEWS, WISHLIST and THANKS files in the 'inst' directory of all my source packages. This has the effect of copying them to the top level of the built version so that they are accessible from R via: I'm not sure that WISHLIST and THANKS need to be available to people who haven't installed the package. NEWS, on the other hand, really does. One option (if it doesn't turn out to be too much work for the CRAN maintainers) would be to have an optional Changelog field in the DESCRIPTION file giving the relative path to the file. This would mean that maintainers would not all have to switch to the same format. eg for foreign Changelog: ChangeLog and for survey Changelog: inst/NEWS This might be enough to make it easy for CRAN to display these when the maintainer provides them. Standard location or a mechachanism like the one you describe are both similar amount of work (and not much at all), the HTML pages are generated by perl and I have the parsed DESCRIPTION file there, i.e., using a fixed name or the value of the Changelog field is basically the same. .f __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] \dontshow
Gabor Grothendieck writes:
On 9/9/05, Gabor Grothendieck [EMAIL PROTECTED] wrote:
In R 2.2.0 I find that even if I use \dontshow in the examples section
of an .Rd file that the code still shows.
Has anyone else seen this?
Are there any packages that use this facility that I could
try in order to check this?
I am using
R.version.string # XP
R version 2.2.0, 2005-09-03
I realize that this description was not clear enough. It does not
show in the help file but when you run the example it shows
and it was that part I was concerned about. Is that the way its
supposed to work?
According to the docs, yes. R-exts has
For example,
x - runif(10) # Shown and run.
\dontrun{plot(x)}# Only shown.
\dontshow{log(x)}# Only run.
-k
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Issue tracking in packages [was: Re: [R] change in read.spss, package foreign?]
Thomas Lumley writes: On Fri, 9 Sep 2005, Gabor Grothendieck wrote: How about if there were just a standard location and name such as inst/NEWS, inst/WISHLIST, inst/THANKS (which has the advantage that they are automatically made available in the built package under the current way packages are built) The problem is that there *isn't* a standard location. As Robert Gentleman has pointed out, if you only maintain two or three packages it isn't too bad to change them to some new layout, but if you are the bioconductor project it gets painful quite quickly. Also, there are good reasons for having NEWS in the top level directory. Nearly everything that isn't an R package does this, because it's a useful standard. And similar things could be said about Emacs users with ChangeLog files in top-level package directories ... I like the suggestion about using a Changelog (or whatever it would be called) field in the package DESCRIPTION meta-data. If we have that, we could not only use this for repository-side presentation of the package, but also install such info and have a simple show_package_change_log() function ... -k -thomas __ 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] Issue tracking in packages [was: Re: [R] change in read.spss, package foreign?]
On 9/10/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Fri, 9 Sep 2005 10:33:03 -0700 (PDT), Thomas Lumley (TL) wrote: On Fri, 9 Sep 2005, Gabor Grothendieck wrote: I personally put NEWS, WISHLIST and THANKS files in the 'inst' directory of all my source packages. This has the effect of copying them to the top level of the built version so that they are accessible from R via: I'm not sure that WISHLIST and THANKS need to be available to people who haven't installed the package. NEWS, on the other hand, really does. One option (if it doesn't turn out to be too much work for the CRAN maintainers) would be to have an optional Changelog field in the DESCRIPTION file giving the relative path to the file. This would mean that maintainers would not all have to switch to the same format. eg for foreign Changelog: ChangeLog and for survey Changelog: inst/NEWS This might be enough to make it easy for CRAN to display these when the maintainer provides them. Standard location or a mechachanism like the one you describe are both similar amount of work (and not much at all), the HTML pages are generated by perl and I have the parsed DESCRIPTION file there, i.e., using a fixed name or the value of the Changelog field is basically the same. .f Regarding the two possibilities I think there is an advantage in a fixed name in a fixed location since one always knows where to look. The extra level of indirection in the DESCRIPTION file just means that one has to fill out yet another field and the user can't know where to look directly, for sure, but must first look it up in the DESCRIPTION file. I think the DESCRIPTION file idea was motivated by making it easier for existing packages but in fact I think its no harder to rename and move a file, and maybe easier, than to add a line to the DESCRIPTION file. Also I think this should apply not only to NEWS/ChangeLog but also to THANKS and WISHLIST and that would mean 3 more lines in the DESCRIPTION file so it could rapidly get out of hand. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Issue tracking in packages [was: Re: [R] change in read.spss, package foreign?]
On 9/10/05, Kurt Hornik [EMAIL PROTECTED] wrote: Thomas Lumley writes: On Fri, 9 Sep 2005, Gabor Grothendieck wrote: How about if there were just a standard location and name such as inst/NEWS, inst/WISHLIST, inst/THANKS (which has the advantage that they are automatically made available in the built package under the current way packages are built) The problem is that there *isn't* a standard location. As Robert Gentleman has pointed out, if you only maintain two or three packages it isn't too bad to change them to some new layout, but if you are the bioconductor project it gets painful quite quickly. Also, there are good reasons for having NEWS in the top level directory. Nearly everything that isn't an R package does this, because it's a useful standard. And similar things could be said about Emacs users with ChangeLog files in top-level package directories ... I like the suggestion about using a Changelog (or whatever it would be called) field in the package DESCRIPTION meta-data. If we have that, we could not only use this for repository-side presentation of the package, but also install such info and have a simple show_package_change_log() function ... One could have that without this meta data. show_package_change_log could just check if the file is present. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] \dontshow
On 9/10/05, Gabor Grothendieck [EMAIL PROTECTED] wrote:
On 9/10/05, Kurt Hornik [EMAIL PROTECTED] wrote:
Gabor Grothendieck writes:
On 9/9/05, Gabor Grothendieck [EMAIL PROTECTED] wrote:
In R 2.2.0 I find that even if I use \dontshow in the examples section
of an .Rd file that the code still shows.
Has anyone else seen this?
Are there any packages that use this facility that I could
try in order to check this?
I am using
R.version.string # XP
R version 2.2.0, 2005-09-03
I realize that this description was not clear enough. It does not
show in the help file but when you run the example it shows
and it was that part I was concerned about. Is that the way its
supposed to work?
According to the docs, yes. R-exts has
For example,
x - runif(10) # Shown and run.
\dontrun{plot(x)}# Only shown.
\dontshow{log(x)}# Only run.
-k
A bit of background. My package depends on external software that
would not be on CRAN.
In order to pass R CMD check on a system that does not contain the
external software, what I am currently doing is to add an if statement at
the beginning and end of each example section in each help file and in the
demo that checks if the external software is present. This check is done
within a \dontrun{...} in the case of the help files.
The if statement at the top simply checks for the availability of the external
software on the system and if not found then replaces f, the function
which would otherwise access that software, with a dummy function.
The if statement at the bottom removes the dummy function.
For example,
\dontrun{ if (!software.found()) f - function(...) cat(*** software
not present\n) }
...body of example...
\dontrun{ if (!software.found()) rm(f) }
Sorry, those should have been dontshow, not dontrun.
Now this is quite kludgy but I currently know of no better alternative.
The help file looks ok but when you run it it does show the if statements
at the beginning and end which may be a bit disconcerting.
I had previously placed the entire body of the example section or demo
in an if but that had the disadvantage of not interleaving input and output
but rather showing all input and then all output.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R.version.string (Re: MikTeX will be assumed in R 2.2.0 in Windows)
On 9/10/05, Duncan Murdoch [EMAIL PROTECTED] wrote: Gabor Grothendieck wrote: On 9/9/05, Duncan Murdoch [EMAIL PROTECTED] wrote: I've just committed some changes to allow R to be built and to use MikTeX without needing the Rd.sty files to be installed to localtexmf. Unfortunately, the changes are not compatible with other TeX packages, so if you're not using MikTeX you'll need to edit a couple of the config files (or set an environment variable). I'd appreciate hearing of any problems during the alpha or beta test period. A binary build containing the changes should be on CRAN tomorrow or the next day. Look for revision 35546 or higher. Note that R.version.string in R 2.2.0 2005-09-03 does not give this sort of version information. If we are going to use this style I suggest we modify R.version.string accordingly. You can get the revision number from the startup banner if you download a binary build. Duncan Murdoch I normally document what version I am using by displaying R.version.string. If R.version.string is no longer definitive under 2.2.0 then it either needs to be modified so that it is or we need some other way of getting that capability. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R.version.string (Re: MikTeX will be assumed in R 2.2.0 in Windows)
Gabor Grothendieck wrote: On 9/10/05, Duncan Murdoch [EMAIL PROTECTED] wrote: Gabor Grothendieck wrote: On 9/9/05, Duncan Murdoch [EMAIL PROTECTED] wrote: I've just committed some changes to allow R to be built and to use MikTeX without needing the Rd.sty files to be installed to localtexmf. Unfortunately, the changes are not compatible with other TeX packages, so if you're not using MikTeX you'll need to edit a couple of the config files (or set an environment variable). I'd appreciate hearing of any problems during the alpha or beta test period. A binary build containing the changes should be on CRAN tomorrow or the next day. Look for revision 35546 or higher. Note that R.version.string in R 2.2.0 2005-09-03 does not give this sort of version information. If we are going to use this style I suggest we modify R.version.string accordingly. You can get the revision number from the startup banner if you download a binary build. Duncan Murdoch I normally document what version I am using by displaying R.version.string. If R.version.string is no longer definitive ^ It never was for non-released versions checked out from svn (or cvs in the older days) ... Uwe Ligges under 2.2.0 then it either needs to be modified so that it is or we need some other way of getting that capability. __ 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] Issue tracking in packages [was: Re: [R] change in, read.spss, package foreign?]
On 9/10/05, Frank E Harrell Jr [EMAIL PROTECTED] wrote: I would vote for allowing a URL or external file name in in DESCRIPTION, whose contents could be automatically displayed for the user when needed. Our changelogs are automatically generated by CVS and are on the web. Normally I would have expected a NEWS file to contain information similar to the R NEWS file https://svn.r-project.org/R/trunk/NEWS which is a less granular summary of the cvs or svn logs. http://developer.r-project.org/R.svnlog.2005 For those of my packages that use svn I also have a NEWS file. The NEWS and log files are not the same. If the DESCRIPTION file were to pull in log files off the net or otherwise then I think it should be done at build time and incorporated into the distribution. Perhaps we need the capability to reference both the NEWS file and the cvs/svn logs. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Issue tracking in packages
On 10 Sep 2005, [EMAIL PROTECTED] wrote: I like the suggestion about using a Changelog (or whatever it would be called) field in the package DESCRIPTION meta-data. If we have that, we could not only use this for repository-side presentation of the package, but also install such info and have a simple show_package_change_log() function ... For what its worth, I don't like this idea of adding a ChangeLog field to the DESCRIPTION file. Agreeing upon a standard location for NEWS or CHANGES or some such seems a more simple solution. As long as the presence of such a file is *optional*. And if the location really needs to be at the top, then the build tools could grab it from there as they do the DESCRIPTION file. + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Issue tracking in packages [was: Re: [R] change in, read.spss, package foreign?]
On Sat, 10 Sep 2005, Frank E Harrell Jr wrote: I would vote for allowing a URL or external file name in in DESCRIPTION, whose contents could be automatically displayed for the user when needed. Our changelogs are automatically generated by CVS and are on the web. Yes, this would be nice. However, a URL facility is already present (and you already use it, and link changelogs to the URL, as do I). -thomas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Issue tracking in packages
On Sat, 10 Sep 2005, Seth Falcon wrote: For what its worth, I don't like this idea of adding a ChangeLog field to the DESCRIPTION file. Agreeing upon a standard location for NEWS or CHANGES or some such seems a more simple solution. As long as the presence of such a file is *optional*. And if the location really needs to be at the top, then the build tools could grab it from there as they do the DESCRIPTION file. We're certainly agreed on its being optional. -thomas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Issue tracking in packages [was: Re: [R] change in, read.spss, package foreign?]
Gabor Grothendieck wrote: On 9/10/05, Frank E Harrell Jr [EMAIL PROTECTED] wrote: I would vote for allowing a URL or external file name in in DESCRIPTION, whose contents could be automatically displayed for the user when needed. Our changelogs are automatically generated by CVS and are on the web. Normally I would have expected a NEWS file to contain information similar to the R NEWS file https://svn.r-project.org/R/trunk/NEWS which is a less granular summary of the cvs or svn logs. http://developer.r-project.org/R.svnlog.2005 For those of my packages that use svn I also have a NEWS file. The NEWS and log files are not the same. If the DESCRIPTION file were to pull in log files off the net or otherwise then I think it should be done at build time and incorporated into the distribution. I would not vote for pulling files off the net. It is useful to see change log entries dated after when the package was built, so the users can get a sense of the value of updating or can bother the maintainer to create a new version. Frank Perhaps we need the capability to reference both the NEWS file and the cvs/svn logs. -- Frank E Harrell Jr Professor and Chair School of Medicine Department of Biostatistics Vanderbilt University __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Issue tracking in packages [was: Re: [R] change in read.spss, package foreign?]
On 9/10/05, Thomas Lumley [EMAIL PROTECTED] wrote: On Sat, 10 Sep 2005, Gabor Grothendieck wrote: And one more comment. The DESCRIPTION file does not record the location or existence of the various subdirectories such as R, man, exec, etc. If NEWS is to be recorded as a meta data line item in DESCRIPTION then surely all of these should be too so its symmetric and they are all on an equal footing (or else none of them should be, which in fact I think is preferable). I don't see any advantage in symmetry. The locations of these The present discussion is where the change information may be located but that is also true of the source and other information.We could just as easily have a field in the DESCRIPTION that tells the build where to find the R source. Its really the same issue. subdirectories are fixed and I can't see why someone trying to decide whether to install an upgrade needs to know if it has an exec subdirectory before they download the package. That is a different issue which has not been discussed up to now. I agree that that would be desirable. It does seem independent of the other issues discussed. If CRAN processing speed can be enhanced then I see no reason other than work involved to have the build automatically enter a DESCRIPTION field of News: Yes However, to make the user fill out another field and to burden the user with having to look at DESCRIPTION first seems to add complexity without benefit. I can think of one intermediate situation. The source DESCRIPTION has the path to the NEWS which the build grabs and puts it in a standard place in the built package. However, if we allow that for the NEWS then we should allow it for all components rather than an inconsistent approach. I also don't see why THANKS and WISHLIST should need to be visible before you download the package. CRAN does display a URL if one is given, and if Either way would be ok in my opinion. these are important they could be at that URL. The changelog, on the other hand, is one piece of information that is really valuable in deciding whether or not to update a package, so it would be worth having it visible on CRAN. Since other coding standards suggest different things for the name and location of this file, a path in DESCRIPTION seems a minimal change. There is no current standard. This is our chance to make it the same for all packages and therefore easier for all users. In short, how about we have a standard name and location for the NEWS, cvs/svn log, WISHLIST, THANKS in the source package. The build would maintain their locations and, in the case of NEWS and the svn/cvs log enter lines in the DESCRIPTION file such as: NEWS: Yes ChangeLog: Yes for sake of CRAN processing speed (if it turns out that this does make a material difference which it may not). This would seem to satisfy all requirements. Its simple, its easy to move to since one just renames or renames and moves one's files (without the need for modifying the DESCRIPTION file in every package or having yet more fields in the DESCRIPTION file) and its easy for the user since they know where everything is supposed to be located without a complicating level of indirection. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R.version.string (Re: MikTeX will be assumed in R 2.2.0 in Windows)
Gabor Grothendieck wrote: On 9/10/05, Duncan Murdoch [EMAIL PROTECTED] wrote: Gabor Grothendieck wrote: On 9/9/05, Duncan Murdoch [EMAIL PROTECTED] wrote: I've just committed some changes to allow R to be built and to use MikTeX without needing the Rd.sty files to be installed to localtexmf. Unfortunately, the changes are not compatible with other TeX packages, so if you're not using MikTeX you'll need to edit a couple of the config files (or set an environment variable). I'd appreciate hearing of any problems during the alpha or beta test period. A binary build containing the changes should be on CRAN tomorrow or the next day. Look for revision 35546 or higher. Note that R.version.string in R 2.2.0 2005-09-03 does not give this sort of version information. If we are going to use this style I suggest we modify R.version.string accordingly. You can get the revision number from the startup banner if you download a binary build. Duncan Murdoch I normally document what version I am using by displaying R.version.string. If R.version.string is no longer definitive under 2.2.0 then it either needs to be modified so that it is or we need some other way of getting that capability. R.version$svn rev will give you the svn revision in 2.2.0 and up. Normally you won't need this; there is only one release of R per x.y.z version number. You only need to go to svn revision when you are looking at unreleased snapshot builds. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Issue tracking in packages [was: Re: [R] change in read.spss, package foreign?]
On Sat, 10 Sep 2005, Gabor Grothendieck wrote: On 9/10/05, Thomas Lumley [EMAIL PROTECTED] wrote: On Sat, 10 Sep 2005, Gabor Grothendieck wrote: And one more comment. The DESCRIPTION file does not record the location or existence of the various subdirectories such as R, man, exec, etc. If NEWS is to be recorded as a meta data line item in DESCRIPTION then surely all of these should be too so its symmetric and they are all on an equal footing (or else none of them should be, which in fact I think is preferable). I don't see any advantage in symmetry. The locations of these The present discussion is where the change information may be located but that is also true of the source and other information.We could just as easily have a field in the DESCRIPTION that tells the build where to find the R source. Its really the same issue. There are two important differences 1/ No existing package has its source anywhere other than in the R subdirectory. Existing packages have their change logs in different places and different formats. 2/ Having source code where it will not be found must be an error -- making the source code available to R *cannot* be optional. Making a change log available *must* be optional. -thomas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
