[Rd] Minor typo in optim.Rd (in details section)
Dear R-Core member,
I spotted the following minor typo in:
https://svn.r-project.org/R/trunk/src/library/stats/man/optim.Rd
currently:
==
\details{
[...]Conjugate gradient methods will generally be more fragile that the BFGS
method, [...]
}
Should read:
\details{
[...]Conjugate gradient methods will generally be more fragile than the BFGS
method, [...]
}
Cheers,
Bernhard
Dr. Bernhard Pfaff
Global Structured Products Group
(Europe)
Invesco Asset Management Deutschland GmbH
Bleichstrasse 60-62
D-60313 Frankfurt am Main
Tel: +49(0)69 298 07230
Fax: +49(0)69 298 07178
Email: [EMAIL PROTECTED]
*
Confidentiality Note: The information contained in this mess...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Minor typo in optim.Rd (in details section)
Fixed, thanks.
On Thu, 23 Feb 2006, Pfaff, Bernhard Dr. wrote:
>
> Dear R-Core member,
>
> I spotted the following minor typo in:
> https://svn.r-project.org/R/trunk/src/library/stats/man/optim.Rd
>
>
> currently:
> ==
> \details{
> [...]Conjugate gradient methods will generally be more fragile that the BFGS
> method, [...]
> }
>
>
> Should read:
>
> \details{
> [...]Conjugate gradient methods will generally be more fragile than the BFGS
> method, [...]
> }
>
> Cheers,
> Bernhard
>
> Dr. Bernhard Pfaff
> Global Structured Products Group
> (Europe)
>
> Invesco Asset Management Deutschland GmbH
> Bleichstrasse 60-62
> D-60313 Frankfurt am Main
>
> Tel: +49(0)69 298 07230
> Fax: +49(0)69 298 07178
> Email: [EMAIL PROTECTED]
> *
> Confidentiality Note: The information contained in this mess...{{dropped}}
>
> __
> 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
[Rd] Problem during "make" with the devel version R-2.3.0 under Sun OS
Hello R users and developers, I had a problem when I tried to install the last version of R-devel. I know that this R version is an unstable version and that this problem may be irrelevant. I am maintaining a R package thus I check if this package can be installed with the development version. ( Everinthing is fine with the R-patched) The details are the following: My machine: System: SunOS Release: 5.9 Kernel ID : Generic_117171-07 Machine : sun4u Processor :sparc Platform : SUNW Sun-Fire-880 R version 2.3.0 Under development (unstable) SVN: Revision: 37414 Last Changed Date: 2006-02-22 Resultsaffer configure: R is now configured for sparc-sun-solaris2.9 Source directory: . Installation directory:/usr/local C compiler:gcc -g -O2 -std=gnu99 Fortran 77 compiler: g77 -g -O2 C++ compiler: g++ -g -O2 Fortran 90/95 compiler:f90 Interfaces supported: X11, tcltk External libraries:readline Additional capabilities: PNG, JPEG, iconv, MBCS, NLS Options enabled: R profiling The problem during make: 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 -g -O2 -std=gnu99 -c plot.c -o plot.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 -g -O2 -std=gnu99 -c plot3d.c -o plot3d.o /usr/ccs/bin/as: "/tmp/ccYv732b.s", line 7057: error: constant value must be between -4096 and 4095 make[3]: *** [plot3d.o] Error 1 make[3]: Leaving directory `/bge/penel/R-devel/src/main' make[2]: *** [R] Error 2 make[2]: Leaving directory `/bge/penel/R-devel/src/main' make[1]: *** [R] Error 1 make[1]: Leaving directory `/bge/penel/R-devel/src' make: *** [R] Error 1 I did not found any report about this problem in the R-devel archives . Should I wait and try a next version of R-devel? thanks for your help, I hope this mail is not irrelevant Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Spurious output white line in R script (PR#8631)
On Thu, 23 Feb 2006, Prof Brian Ripley wrote:
On Wed, 22 Feb 2006, Fran?ois Pinard wrote:
[...]
So, I was not expecting R, running with that option activated, to
"volunteer" white lines. :-)
But Simon said `with the documentation'. Not doing what you expected is
not a bug. Can you please point us to documentation which says that
end-of-file produces no output?
This does appear to be deliberate behaviour from
void end_Rmainloop(void)
{
Rprintf("\n");
/* run the .Last function. If it gives an error, will drop back to main
loop. */
R_CleanUp(SA_DEFAULT, 0, 1);
}
and I think it is necessary, as R might well have a partial line of output
queued up for the console. So this is probably `as quietly as possible'.
(While agreeing entirely on the "bug" issue), couldn't we have
fflush() instead of sending a newline?
-thomas__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Spurious output white line in R script (PR#8631)
On Thu, 23 Feb 2006, Thomas Lumley wrote:
On Thu, 23 Feb 2006, Prof Brian Ripley wrote:
On Wed, 22 Feb 2006, François Pinard wrote:
[...]
So, I was not expecting R, running with that option activated, to
"volunteer" white lines. :-)
But Simon said `with the documentation'. Not doing what you expected is
not a bug. Can you please point us to documentation which says that
end-of-file produces no output?
This does appear to be deliberate behaviour from
void end_Rmainloop(void)
{
Rprintf("\n");
/* run the .Last function. If it gives an error, will drop back to main
loop. */
R_CleanUp(SA_DEFAULT, 0, 1);
}
and I think it is necessary, as R might well have a partial line of output
queued up for the console. So this is probably `as quietly as possible'.
(While agreeing entirely on the "bug" issue), couldn't we have fflush()
instead of sending a newline?
Well, we might not be outputting to a file ... (I did say console), and
.Last() might well produce output so we need to leave the console in a
suitable state. I do think we need a \n unless we can be sure that we are
currently at the left margin of the console (and I am not sure we can be
unless we assume all output went through R[E]printf, and even in that
case we do not currently collect the information).
Consider the script
gannet% cat foo
#!/bin/sh
R --slave --vanilla
[Rd] Links to non-vignette documentation
Section 1.4 of Writing R Extensions says: In addition to the help files in Rd format, R packages allow the inclusion of documents in arbitrary other formats. The standard location for these is subdirectory inst/doc of a source package, the contents will be copied to subdirectory doc when the package is installed. Pointers from package help indices to the installed documents are automatically created. Documents in inst/doc can be in arbitrary format, however we strongly recommend to provide them in PDF format, such that users on all platforms can easily read them. Where are these pointers created? I have a package with a pdf file (introduction.pdf) in inst/doc but I can't find a link to it from the documentation (eg. from help.start() or help(package=...) Is there anyway to have my pdf documentation listed under vignettes other than making it a sweave file? Hadley __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Utilizing the internet module
Hello all, I'd like to utilize the R_Sock* functions from R_ext/R-ftp-http.h in my R package. The intent is to use these in conjunction with R_serialize() to store R objects in a remote data store. I'm aware that version 2.2.1 of "Writing R extensions" explains that these may be undocumented and unstable, but I have a couple of questions: 1) are they platform independent? I presume they are... 2) What's the appropriate way to link against them? On Linux x86, I can do this with the Makevars: PKG_LIBS=$(R_HOME)/modules/internet$(SHLIB_EXT) but that doesn't work on Mac OS X 10.3.9 powerpc G4: gcc -bundle -flat_namespace -undefined suppress -L/sw/lib -L/usr/local/lib -o rmemcache.so rmemcache.o /Users/hornerjr/src/R-2.2.1/modules/internet.so -lcc_dynamic -L/Users/hornerjr/src/R-2.2.1/lib -lR ld: /Users/hornerjr/src/R-2.2.1/modules/internet.so is input for the dynamic link editor, is not relocatable by the static link editor again Thanks in advance, -- Jeffrey Horner Computer Systems Analyst School of Medicine 615-322-8606 Department of Biostatistics Vanderbilt University __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Spurious output white line in R script (PR#8631)
On Feb 23, 2006, at 11:14 AM, Thomas Lumley wrote:
> On Thu, 23 Feb 2006, Prof Brian Ripley wrote:
>
>> On Wed, 22 Feb 2006, François Pinard wrote:
> [...]
>>> So, I was not expecting R, running with that option activated, to
>>> "volunteer" white lines. :-)
>>
>> But Simon said `with the documentation'. Not doing what you
>> expected is
>> not a bug. Can you please point us to documentation which says that
>> end-of-file produces no output?
>>
>> This does appear to be deliberate behaviour from
>>
>> void end_Rmainloop(void)
>> {
>>Rprintf("\n");
>>/* run the .Last function. If it gives an error, will drop back
>> to main
>> loop. */
>>R_CleanUp(SA_DEFAULT, 0, 1);
>> }
>>
>> and I think it is necessary, as R might well have a partial line
>> of output queued up for the console. So this is probably `as
>> quietly as possible'.
>
> (While agreeing entirely on the "bug" issue), couldn't we have
> fflush() instead of sending a newline?
>
It's not really about fflush - the rationale is to not leave non-
terminated lines on the output before quitting via EOF, which has its
merits. If you remove it, you get this:
...
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
> caladan:Rdev$
instead of
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
>
caladan:Rdev$
fflush won't change this.
Cheers,
Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] rnorm returning NA's (PR#8635)
Full_Name: Josh McNutt Version: 2.2.1 OS: Win XP Submission from: (NULL) (192.88.209.232) > which(is.na(rnorm(2000))) [1] 15242377 > which(is.na(rnorm(1000))) [1] 3692029 > which(is.na(rnorm(4000))) [1] 5560337 5938719 3322 > which(is.na(rnorm(5000))) [1] 25231754 42397181 45085564 45363557 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Spurious output white line in R script (PR#8631)
On Thu, 23 Feb 2006, Simon Urbanek wrote:
On Feb 23, 2006, at 11:14 AM, Thomas Lumley wrote:
On Thu, 23 Feb 2006, Prof Brian Ripley wrote:
On Wed, 22 Feb 2006, François Pinard wrote:
[...]
So, I was not expecting R, running with that option activated, to
"volunteer" white lines. :-)
But Simon said `with the documentation'. Not doing what you expected is
not a bug. Can you please point us to documentation which says that
end-of-file produces no output?
This does appear to be deliberate behaviour from
void end_Rmainloop(void)
{
Rprintf("\n");
/* run the .Last function. If it gives an error, will drop back to main
loop. */
R_CleanUp(SA_DEFAULT, 0, 1);
}
and I think it is necessary, as R might well have a partial line of output
queued up for the console. So this is probably `as quietly as possible'.
(While agreeing entirely on the "bug" issue), couldn't we have fflush()
instead of sending a newline?
It's not really about fflush - the rationale is to not leave non-terminated
lines on the output before quitting via EOF, which has its merits.
I would have thought that, at least with --slave, you might want the
ability to produce output that didn't end with any newline (in contrast to
the original question, which was about one vs two newlines, which is easy
to fix).
-thomas
Thomas Lumley Assoc. Professor, Biostatistics
[EMAIL PROTECTED] University of Washington, Seattle__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Links to non-vignette documentation
On 2/23/2006 11:53 AM, hadley wickham wrote: > Section 1.4 of Writing R Extensions says: > > In addition to the help files in Rd format, R packages allow the > inclusion of documents in arbitrary other formats. The standard > location for these is subdirectory inst/doc of a source package, the > contents will be copied to subdirectory doc when the package is > installed. Pointers from package help indices to the installed > documents are automatically created. Documents in inst/doc can be in > arbitrary format, however we strongly recommend to provide them in PDF > format, such that users on all platforms can easily read them. > > Where are these pointers created? I have a package with a pdf file > (introduction.pdf) in inst/doc but I can't find a link to it from the > documentation (eg. from help.start() or help(package=...) > > Is there anyway to have my pdf documentation listed under vignettes > other than making it a sweave file? A manually written inst/doc/index.html file will be linked into the help system. I don't know if the sentence about pointers being created is true otherwise. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Tiny documentation error for ?options (PR#8633)
[Brian Ripley]
>This is already corrected in the the development version of R:
Good, thanks!
P.S. - More generally, huge thanks to all developers of this impressive
R system. I have an idea of the constant courage and long dedication it
takes for reaching the usability and maturity R already has.
>(The FAQ does suggest you check there before sending a bug report.)
Yes, I know (and even checked the FAQ first, as I could quickly do it).
I had to choose between putting more time in research that I had at my
disposal, and not sending a report. If I did the wrong choice, just
tell me, and I'll merely refrain in similar circumstances.
I may be a very patient nit-picker, and while this is advantageous for
a system, it is sometimes irritating for those maintaining it.
[Reminder of original message follows]
>It is a question of defaults being changed frequently (because C stack
>overflow was occuring on some platforms) and the documentation being
>behind.
>On Thu, 23 Feb 2006, [EMAIL PROTECTED] wrote:
>>Hi, people. The output produced by "?options" contains:
>> 'expressions': sets a limit on the number of nested expressions
>> that will be evaluated. Valid values are 25...50 with
>> default 1000. [...]
>>and a bit further down:
>> The 'factory-fresh' default settings of some of these options are
>> [...]
>> 'expressions' '5000'
>>Is there a distinction between "default" and "factory-fresh default"?
>>If not, then 1000 might be the correct value instead of 5000, as 1000 is
>>contained in the list returned by R when given "options('expressions')".
>>--please do not edit the information below--
>>Version:
>>platform = i686-pc-linux-gnu
>>arch = i686
>>os = linux-gnu
>>system = i686, linux-gnu
>>status =
>>major = 2
>>minor = 2.1
>>year = 2005
>>month = 12
>>day = 20
>>svn rev = 36812
>>language = R
>>Locale:
>>LC_CTYPE=fr_CA.UTF-8;LC_NUMERIC=C;LC_TIME=fr_CA.UTF-8;LC_COLLATE=fr_CA.UTF-8;LC_MONETARY=fr_CA.UTF-8;LC_MESSAGES=fr_CA.UTF-8;LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C;LC_IDENTIFICATION=C
>>Search Path:
>>.GlobalEnv, package:methods, package:stats, package:graphics,
>>package:utils, package:datasets, fp.etc, package:grDevices, Autoloads,
>>package:base
>>__
>>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
--
François Pinard http://pinard.progiciels-bpi.ca
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Utilizing the internet module
On Thu, 23 Feb 2006, Jeffrey Horner wrote: > Hello all, > > I'd like to utilize the R_Sock* functions from R_ext/R-ftp-http.h in my > R package. The intent is to use these in conjunction with R_serialize() > to store R objects in a remote data store. I'm aware that version > 2.2.1 of "Writing R extensions" explains that these may be undocumented > and unstable, but I have a couple of questions: > > 1) are they platform independent? I presume they are... Only in sense that they have a common interface. > 2) What's the appropriate way to link against them? On Linux x86, I can > do this with the Makevars: You can, but that is a module and not a library and so it does not work on MacOS X and may well not work on Windows (you would be lucky prior to R 2.3.0). I wonder why you need a C interface at all. There is serialize() and socket connections are available at R level. Below that, Rsockopen etc are exported from R itself and underly make.socket etc. -- 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] rnorm returning NA's (PR#8635)
This is not reproducible, and you have not told us the seed you used which is what is needed to make random results reproducible. Please supply a reproducible example (if you can). I ran the first line 100 times (about 15 minutes) without encountering any NAs. If you found these fairly easily it indicates a bug in your Windows installation, not one in R. Further, if it were at all common then other people would have encountered it and surely mentioned it. On Thu, 23 Feb 2006, [EMAIL PROTECTED] wrote: > Full_Name: Josh McNutt > Version: 2.2.1 > OS: Win XP > Submission from: (NULL) (192.88.209.232) > > >> which(is.na(rnorm(2000))) > [1] 15242377 > >> which(is.na(rnorm(1000))) > [1] 3692029 > >> which(is.na(rnorm(4000))) > [1] 5560337 5938719 3322 > >> which(is.na(rnorm(5000))) > [1] 25231754 42397181 45085564 45363557 > > __ > 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] Links to non-vignette documentation
On Thu, 23 Feb 2006, Duncan Murdoch wrote: > On 2/23/2006 11:53 AM, hadley wickham wrote: >> Section 1.4 of Writing R Extensions says: >> >> In addition to the help files in Rd format, R packages allow the >> inclusion of documents in arbitrary other formats. The standard >> location for these is subdirectory inst/doc of a source package, the >> contents will be copied to subdirectory doc when the package is >> installed. Pointers from package help indices to the installed >> documents are automatically created. Documents in inst/doc can be in >> arbitrary format, however we strongly recommend to provide them in PDF >> format, such that users on all platforms can easily read them. >> >> Where are these pointers created? I have a package with a pdf file >> (introduction.pdf) in inst/doc but I can't find a link to it from the >> documentation (eg. from help.start() or help(package=...) >> >> Is there anyway to have my pdf documentation listed under vignettes >> other than making it a sweave file? No, a vignette is regarded as an Sweave file. > A manually written inst/doc/index.html file will be linked into the help > system. .install_package_vignette_index does create an index, and info does get put on the packages html page. I just tried this by adding inst/doc/foo.pdf to windlgs. If there is an pdf file but no .[RS]nw vignettes, the index is fairly useless but browsing is available. > I don't know if the sentence about pointers being created is true otherwise. It seems to be. -- 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] rnorm returning NA's (PR#8635)
On 2/23/2006 1:04 PM, [EMAIL PROTECTED] wrote: > Full_Name: Josh McNutt > Version: 2.2.1 > OS: Win XP > Submission from: (NULL) (192.88.209.232) > > >> which(is.na(rnorm(2000))) > [1] 15242377 > >> which(is.na(rnorm(1000))) > [1] 3692029 > >> which(is.na(rnorm(4000))) > [1] 5560337 5938719 3322 > >> which(is.na(rnorm(5000))) > [1] 25231754 42397181 45085564 45363557 > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel I don't see these. Could you use set.seed() to put the RNG in a reproducible state, and show us the results then? Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Links to non-vignette documentation
> >> Is there anyway to have my pdf documentation listed under vignettes > >> other than making it a sweave file? > > No, a vignette is regarded as an Sweave file. It would be useful if there was a mechanism to allow arbitrary pdf files to be included as vignettes. There are many other ways to include R code/output in pdf files other than through Sweave. > I just tried this by adding inst/doc/foo.pdf to windlgs. If there is an > pdf file but no .[RS]nw vignettes, the index is fairly useless but > browsing is available. > > > I don't know if the sentence about pointers being created is true otherwise. > > It seems to be. A link to the directory where the pdf is located, only available in the html version of help, rather stretches the definition of a pointer. Hadley __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Links to non-vignette documentation
On Thu, 23 Feb 2006, hadley wickham wrote: Is there anyway to have my pdf documentation listed under vignettes other than making it a sweave file? >> >> No, a vignette is regarded as an Sweave file. > > It would be useful if there was a mechanism to allow arbitrary pdf > files to be included as vignettes. There are many other ways to > include R code/output in pdf files other than through Sweave. I think you need to define `vignette'. I understand the usage to mean an Sweave file. There are ways to include other PDF files, and you can write your own index file. R can't do that for you as it cannot read PDF (it can read Sweave). >> I just tried this by adding inst/doc/foo.pdf to windlgs. If there is an >> pdf file but no .[RS]nw vignettes, the index is fairly useless but >> browsing is available. >> >>> I don't know if the sentence about pointers being created is true otherwise. >> >> It seems to be. > > A link to the directory where the pdf is located, only available in > the html version of help, rather stretches the definition of a > pointer. What is a link if not a pointer? What it actually says is Pointers from package help indices to the installed documents are automatically created. I am not aware of any other sort of `package help index', although one could arge the toss about Compiled HTML. -- 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] Problem during "make" with the devel version R-2.3.0 under Sun OS
This is a compiler error (generating invalid assembler), not an R error. What compiler version is this? I have no problem compiling the current R-devel (37422) on Solaris with gcc-3.4.5 or gcc-4.0.2 (and using the Sun assembler as you are). I have seen problems with plot3d with earlier versions of gcc-4. On Thu, 23 Feb 2006, Simon Penel wrote: > Hello R users and developers, > > I had a problem when I tried to install the last version of R-devel. > I know that this R version is an unstable version and that this problem > may be irrelevant. > I am maintaining a R package thus I check if this package can be > installed with the development version. > ( Everinthing is fine with the R-patched) > > The details are the following: > > My machine: > System: SunOS > Release: 5.9 > Kernel ID : Generic_117171-07 > Machine : sun4u > Processor :sparc > Platform : SUNW Sun-Fire-880 > > R version > 2.3.0 Under development (unstable) > > SVN: > Revision: 37414 > Last Changed Date: 2006-02-22 > > Resultsaffer configure: > > R is now configured for sparc-sun-solaris2.9 > > Source directory: . > Installation directory:/usr/local > > C compiler:gcc -g -O2 -std=gnu99 > Fortran 77 compiler: g77 -g -O2 > > C++ compiler: g++ -g -O2 > Fortran 90/95 compiler:f90 > > Interfaces supported: X11, tcltk > External libraries:readline > Additional capabilities: PNG, JPEG, iconv, MBCS, NLS > Options enabled: R profiling > > > The problem during make: > > > 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 -g -O2 -std=gnu99 -c plot.c -o plot.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 -g -O2 -std=gnu99 -c plot3d.c -o > plot3d.o > /usr/ccs/bin/as: "/tmp/ccYv732b.s", line 7057: error: constant value > must be between -4096 and 4095 > make[3]: *** [plot3d.o] Error 1 > make[3]: Leaving directory `/bge/penel/R-devel/src/main' > make[2]: *** [R] Error 2 > make[2]: Leaving directory `/bge/penel/R-devel/src/main' > make[1]: *** [R] Error 1 > make[1]: Leaving directory `/bge/penel/R-devel/src' > make: *** [R] Error 1 > > I did not found any report about this problem in the R-devel archives . > Should I wait and try a next version of R-devel? > > thanks for your help, I hope this mail is not irrelevant > > Simon > > __ > 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
[Rd] Wishlist: browser and traceback should trim callstack when printing (PR#8638)
Full_Name: Hadley Wickham Version: 2.2.0 OS: OS X Submission from: (NULL) (129.186.195.213) Example: f <- function(...) browser() do.call(f, mtcars) Entire contents of mtcars is printed on callstack. When you are using do.call with large data.frames this is a frustrating as it easily wipes out your entire buffer. While it is useful to be able to see all the arguments when looking for the cause of the bug, manual inspection is impractical when dealing with very long arguments. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Links to non-vignette documentation
> I think you need to define `vignette'. I understand the usage to mean an
> Sweave file. There are ways to include other PDF files, and you can write
> your own index file. R can't do that for you as it cannot read PDF (it
> can read Sweave).
How can I write an index file with a pointer to my pdf? Should I
provide a code snippet to run system(paste(getOption("pdfviewer"),
system.file("doc/my.pdf", package="mypackage"), "&"))?
Perhaps my problem is thinking of a vignette as a "A brief verbal
description of a person, place, etc.; a short descriptive or evocative
episode in a play, etc." rather than a Sweave document.
> I am not aware of any other sort of `package help index', although one
> could arge the toss about Compiled HTML.
What about (eg.) help(package=grid)? This is where vignettes are
listed by name (and location). I would like to be able put my pdf
into a similar list.
Hadley
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Links to non-vignette documentation
On Thu, 23 Feb 2006, hadley wickham wrote:
>> I think you need to define `vignette'. I understand the usage to mean an
>> Sweave file. There are ways to include other PDF files, and you can write
>> your own index file. R can't do that for you as it cannot read PDF (it
>> can read Sweave).
>
> How can I write an index file with a pointer to my pdf? Should I
> provide a code snippet to run system(paste(getOption("pdfviewer"),
> system.file("doc/my.pdf", package="mypackage"), "&"))?
Just add a hyperlink in inst/doc/index.html to foo.pdf and let the browser
do the rest. The grid/doc/index.html is a suitable template.
> Perhaps my problem is thinking of a vignette as a "A brief verbal
> description of a person, place, etc.; a short descriptive or evocative
> episode in a play, etc." rather than a Sweave document.
>
>> I am not aware of any other sort of `package help index', although one
>> could arge the toss about Compiled HTML.
>
> What about (eg.) help(package=grid)? This is where vignettes are
> listed by name (and location). I would like to be able put my pdf
> into a similar list.
Which is really library(help=grid). Vignettes there are a recent
addition, and we need the author to tell us. It looks to me as if that
means strict-sense vignettes (it gets the info from the vignette
metadata). If there were a mechanism for authors to list PDF docs and
titles in a two-column format in some file in inst/docs, the installation
tools could provide more support. (I think this is Kurt's area.)
[I am not arguing that this could not be better documented, but I think
most things are possible by digging around.]
--
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] Links to non-vignette documentation
On 2/23/2006 4:23 PM, hadley wickham wrote:
>> I think you need to define `vignette'. I understand the usage to mean an
>> Sweave file. There are ways to include other PDF files, and you can write
>> your own index file. R can't do that for you as it cannot read PDF (it
>> can read Sweave).
>
> How can I write an index file with a pointer to my pdf? Should I
> provide a code snippet to run system(paste(getOption("pdfviewer"),
> system.file("doc/my.pdf", package="mypackage"), "&"))?
We were referring to an HTML index file. If you want to have a
reference from your package man page (foo-package.Rd) or some other man
page, you can use \url{../doc/my.pdf} and the link will work in HTML
versions of help, and won't be too misleading in other versions
(especially if you explain how to use it).
> Perhaps my problem is thinking of a vignette as a "A brief verbal
> description of a person, place, etc.; a short descriptive or evocative
> episode in a play, etc." rather than a Sweave document.
>
>> I am not aware of any other sort of `package help index', although one
>> could arge the toss about Compiled HTML.
>
> What about (eg.) help(package=grid)? This is where vignettes are
> listed by name (and location). I would like to be able put my pdf
> into a similar list.
I don't think you can do that, but you should be using a package man
page anyway.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Links to non-vignette documentation
> We were referring to an HTML index file. If you want to have a
> reference from your package man page (foo-package.Rd) or some other man
> page, you can use \url{../doc/my.pdf} and the link will work in HTML
> versions of help, and won't be too misleading in other versions
> (especially if you explain how to use it).
Ok, I'll give that a go.
> I don't think you can do that, but you should be using a package man
> page anyway.
Can you suggest a good example of a package man page? I've tried a
few packages and haven't been able to find one. The example generated
by promptPackage suggests I need to duplicate the contents of
DESCRIPTION and INDEX.
Hadley
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Utilizing the internet module
Prof Brian Ripley wrote: > On Thu, 23 Feb 2006, Jeffrey Horner wrote: > >> Hello all, >> >> I'd like to utilize the R_Sock* functions from R_ext/R-ftp-http.h in my >> R package. The intent is to use these in conjunction with R_serialize() >> to store R objects in a remote data store. I'm aware that version >> 2.2.1 of "Writing R extensions" explains that these may be undocumented >> and unstable, but I have a couple of questions: >> >> 1) are they platform independent? I presume they are... > > > Only in sense that they have a common interface. > >> 2) What's the appropriate way to link against them? On Linux x86, I can >> do this with the Makevars: > > > You can, but that is a module and not a library and so it does not work > on MacOS X and may well not work on Windows (you would be lucky prior to > R 2.3.0). > > I wonder why you need a C interface at all. There is serialize() and > socket connections are available at R level. Below that, Rsockopen etc > are exported from R itself and underly make.socket etc. I may not need it (or get to use it portably), but as far as using Rsockopen, etc. am I right in assuming that a package writer would have to copy the declarations from src/main/basedecl.h into his/her own code in order to utilize them? This seems odd when there's already an exposed (although undocumented) interface with R_Sock*, so what's the point of having R_ext/R-ftp-http.h? Is it just for some xml package? On a related note, how do I serialize() an R object to a database table column of type BLOB? I've tried using RODBC but was unsuccessfully (see R-sig-DB in Feb archive). I've also looked into RMySQL/DBI but I don't think it's supported yet. -- Jeffrey Horner Computer Systems Analyst School of Medicine 615-322-8606 Department of Biostatistics Vanderbilt University __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Spurious output white line in R script (PR#8631)
[Brian Ripley]
>[François Pinard]
>>Within the output resulting of command "man R", one reads:
>> --slave
>> Make R run as quietly as possible
>>So, I was not expecting R, running with that option activated, to
>>"volunteer" white lines. :-)
>Can you please point us to documentation which says that end-of-file
>produces no output?
I just did. However, you state that "as quietly as possible" should not
be interpreted as "no output". Our interpretations differ.
>This does appear to be deliberate behaviour from
>void end_Rmainloop(void)
>{
> Rprintf("\n");
> /* run the .Last function. If it gives an error, will drop back to
>main
>loop. */
> R_CleanUp(SA_DEFAULT, 0, 1);
>}
>and I think it is necessary, as R might well have a partial line of output
>queued up for the console. So this is probably `as quietly as possible'.
I do not doubt that it is deliberate, and I suspected as much even
before submitting my initial report on this topic, as I do the same in
some interactive programs I wrote, so the shell prompt shows at the
left. However, I'm careful at not doing it outside human-interactive
contexts.
It is likely unusual that R users starts an R session with "--slave",
when that session is really meant to be human-interactive. Whatever the
documentation says or does not say, the spurious '\n' kludge has no good
reason to apply with "--slave". Let's both be trying to have
a reasonable and intelligent conversation here, keeping in mind that the
documentation is not necessarily perfect either, and not the last word
of everything.
The argument that it is necessary to write a '\n' because a partial line
of output may be queued up for the console, does not fully hold. Proof
is, following Simon Urbanek's suggestion, that the following valid
R script:
#!/bin/sh
R --slave --vanilla
Re: [Rd] Spurious output white line in R script (PR#8631)
[François Pinard, clarifying himself] >Adding a newline when "--slave" has not been selected, and whenever the >output is connected to a tty, is also wise, regardless if termination >is effected through q() or through hitting end-of-file. Just to make sure I'm not misinterpreted, the "and" of the first line above should be read as a logical conjunction. -- François Pinard http://pinard.progiciels-bpi.ca __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Links to non-vignette documentation
G'day all,
seems as if I must have slept through most of this most interesting
discussion. :)
> "BR" == Prof Brian Ripley <[EMAIL PROTECTED]> writes:
BR> On Thu, 23 Feb 2006, hadley wickham wrote:
>> How can I write an index file with a pointer to my pdf? Should
>> I provide a code snippet to run
>> system(paste(getOption("pdfviewer"), system.file("doc/my.pdf",
>> package="mypackage"), "&"))?
BR> Just add a hyperlink in inst/doc/index.html to foo.pdf and let
BR> the browser do the rest. The grid/doc/index.html is a
BR> suitable template.
Editing this file by hand is certainly an option, but one more think
to remember while maintaining a package. Thus, I think it is
preferable to automate process as much as possible. I ran into a
similar problem as Hadley with a package that I am currently developing
(since some time) and offer my solution below.
> "DM" == Duncan Murdoch <[EMAIL PROTECTED]> writes:
DM> On 2/23/2006 4:23 PM, hadley wickham wrote:
>> What about (eg.) help(package=grid)? This is where vignettes
>> are listed by name (and location). I would like to be able put
>> my pdf into a similar list.
DM> I don't think you can do that, but you should be using a
DM> package man page anyway.
I believe this can be done, albeit not directly.
In my case, I wanted to include a PDF, whose source is not in Sweave
format, with the documentation of the package and have the links to
this documentation created automatically. My solution, in the end was
to create a "dummy" Rnw vignette which has a link to the pdf file. I
include that dummy vignette below. Hence, in the directory inst/doc
of my package there are the following files:
interface96.pdf The PDF file I actually want to include
as part of the documentation
interface96-vignette.RnwThe dummy vignette file
Using hyperref with a "file:" url, the dummy vignette file links to
the actual files.
For the user, this means that she/he sees the dummy vignette and
access it first and then has to click once more on a link to get to
the actual document. Slightly inconvenient for the user, but I
believe it is a fair price to pay to make my life as developer
easier. ;-))
If you want to distribute binary copies (e.g. for the various version
of Windows that exists) of your package, then you need of course all
the tools that are necessary to handle vignettes.
Cheers,
Berwin
- Source of dummy vignette -
\documentclass[a4paper]{article}
%\VignetteIndexEntry{Interface '96 paper by Marron et al. (1997)}
%\VignettePackage{clps}
\usepackage{hyperref}
\usepackage{natbib}
\title{Interface '96 paper by \cite{mar:tur:wan:96}}
\author{Berwin A Turlach}
\date{September 25, 2004}
\begin{document}
\maketitle
This is just a dummy vignette with a link to the
\href{file:interface96.pdf}{PDF file} of \cite{mar:tur:wan:96} which
is part of the \textit{CLPS} package. The dummy vignette should
appear in the automatically generated index, but I did not succeed in
getting the actual paper to appear in that index.
\bibliographystyle{dcunsp}
\bibliography{clps}
\end{document}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Links to non-vignette documentation
On 2/23/2006 5:49 PM, hadley wickham wrote:
>> We were referring to an HTML index file. If you want to have a
>> reference from your package man page (foo-package.Rd) or some other man
>> page, you can use \url{../doc/my.pdf} and the link will work in HTML
>> versions of help, and won't be too misleading in other versions
>> (especially if you explain how to use it).
>
> Ok, I'll give that a go.
>
>> I don't think you can do that, but you should be using a package man
>> page anyway.
>
> Can you suggest a good example of a package man page? I've tried a
> few packages and haven't been able to find one. The example generated
> by promptPackage suggests I need to duplicate the contents of
> DESCRIPTION and INDEX.
All of the base packages have them; some contain more than others. I
don't know which ones I'd consider to be "good".
They are meant to replace the INDEX, which you shouldn't need to create
any more. The DESCRIPTION file is still needed, but it contains more
structured information meant for mechanical reading and processing; the
package man page is meant to be the place to put things intended for
people to read.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Links to non-vignette documentation
> They are meant to replace the INDEX, which you shouldn't need to create > any more. The DESCRIPTION file is still needed, but it contains more > structured information meant for mechanical reading and processing; the > package man page is meant to be the place to put things intended for > people to read. Do I need to keep the list of functions on the package man page in sync myself, or will they be automatically rebuilt? Is the intention to eventually change help(package=XXX) to point to the package man page? Hadley __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Links to non-vignette documentation
I haven't followed this whole thread but note that if your package is called mypkg then you can create an .Rd file called mypkg-package.Rd which will be called up when the user issues: package?mypkg and that can contain links to whatever you are interested in. Try library(dyn) package?dyn for an example. The R command, promptPackage, can be used to facilitate the creation of the -package.Rd file. On 2/23/06, hadley wickham <[EMAIL PROTECTED]> wrote: > > They are meant to replace the INDEX, which you shouldn't need to create > > any more. The DESCRIPTION file is still needed, but it contains more > > structured information meant for mechanical reading and processing; the > > package man page is meant to be the place to put things intended for > > people to read. > > Do I need to keep the list of functions on the package man page in > sync myself, or will they be automatically rebuilt? Is the intention > to eventually change help(package=XXX) to point to the package man > page? > > Hadley > > __ > 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] Utilizing the internet module
On Thu, 23 Feb 2006, Jeffrey Horner wrote: > Prof Brian Ripley wrote: >> On Thu, 23 Feb 2006, Jeffrey Horner wrote: >> >>> Hello all, >>> >>> I'd like to utilize the R_Sock* functions from R_ext/R-ftp-http.h in my >>> R package. The intent is to use these in conjunction with R_serialize() >>> to store R objects in a remote data store. I'm aware that version >>> 2.2.1 of "Writing R extensions" explains that these may be undocumented >>> and unstable, but I have a couple of questions: >>> >>> 1) are they platform independent? I presume they are... >> >> >> Only in sense that they have a common interface. >> >>> 2) What's the appropriate way to link against them? On Linux x86, I can >>> do this with the Makevars: >> >> >> You can, but that is a module and not a library and so it does not work on >> MacOS X and may well not work on Windows (you would be lucky prior to R >> 2.3.0). >> >> I wonder why you need a C interface at all. There is serialize() and >> socket connections are available at R level. Below that, Rsockopen etc are >> exported from R itself and underly make.socket etc. > > I may not need it (or get to use it portably), but as far as using Rsockopen, > etc. am I right in assuming that a package writer would have to copy the > declarations from src/main/basedecl.h into his/her own code in order to > utilize them? This seems odd when there's already an exposed (although > undocumented) interface with R_Sock*, so what's the point of having > R_ext/R-ftp-http.h? Is it just for some xml package? Yes. It was written as an internal header. As you have discovered, the interface is not actually exposed. > On a related note, how do I serialize() an R object to a database table > column of type BLOB? I've tried using RODBC but was unsuccessfully (see > R-sig-DB in Feb archive). I've also looked into RMySQL/DBI but I don't think > it's supported yet. Since BLOB is not a standard SQL type (AFAIK), ODBC seems not to support it. -- 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
