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] \dontshow
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) }
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] 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] Issue tracking in packages [was: Re: [R] change in read.spss, package foreign?]
On 9/10/05, Gabor Grothendieck <[EMAIL PROTECTED]> wrote: > 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. > 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). __ 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?]
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. -- 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?]
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. From a repositoriy maintainer's point of view: Yes, if people really want it, then please something in a DESCRIPTION file. Lookup whether a file exists takes a lot of time, in particular if you do not have the source package in an extracted form. Note that CRAN does not have to handle one or two packages, but processes 600 for each repository... Uwe Ligges __ 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] [R] Debugging R/Fortran in Windows
Duncan, >> 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 No, I didn't find a version of valgrind that works on Windows. I used it on Linux. Best wishes, James __ 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?]
> > 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. > In which case a Changlog entry in DESCRIPTION would be a very nice addition, and would have the advantage of not requiring changes to packages. -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?]
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 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. 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 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. -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?]
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?]
> "TL" == Thomas Lumley <[EMAIL PROTECTED]>
> on Sat, 10 Sep 2005 09:32:29 -0700 (PDT) writes:
>> 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.
>>
TL> In which case a Changlog entry in DESCRIPTION would be a
TL> very nice addition, and would have the advantage of not
TL> requiring changes to packages.
yes *and* does allow slightly more flexibility with almost
no cost, as Fritz confirmed.
And, BTW, Gabor, NEWS and ChangeLog are not at all the same
thing and it would be silly to urge users to one of them.
At least 'ChangeLog' is a well defined format for emacs users
that can very quickly be updated semi-automagically
("C-x 4 a" when you're in file foo.R with function myfun(.)
autogenerates a neat entry in a ChangeLog file);
but then really people should be allowed to use other formats
for good reasons.
Martin
__
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
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: > > > 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 it source anywhere other than in the R > subdirectory. Existing packages have their change logs in different places > and different formats. In terms of the source package the source code is in the R subdirectory because its been standardized that way and the R CMD tools support it. It could, in principle be anywhere and brought into the built package at build time had it not been designed that way. The same is true of the change information. The point is that there is really no difference in principle between the two. Furthermore, what existing packages do is not important since its no harder and probably easier to adapt to the standard scheme. Even if that were not the case I don't think that that should drive the design. > 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. Source code is optional too. One can create a package with no R subdirectory. In fact the only thing you cannot leave out and still pass R CMD check is the DESCRIPTION file. There really is no difference between change information and the source. Both could be in the source package or not in the source package and just brought into the built package at build time depending on how the build process is designed. Also in both cases the advantage of having everything in the source package is that the built package can be guaranteed to be built from the source package. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] FreeBSD 7.0-CURRENT and R-2.2.0 alpha
These were found by AC_CHECK_FUNCS (please confirm what configure said) so most likely some macro needs to be set or header included. Could you please find out how configure managed to find cpow etc when they appear not to be in libc/libm? On Sat, 10 Sep 2005, Rainer Hurling wrote: > 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, > R
