[Rd] generic function argument list problem
Hi it says in R-exts that A method must have all the arguments of the generic, including ... if the generic does. A method must have arguments in exactly the same order as the generic. A method should use the same defaults as the generic. So, how come the arguments for rep() are (x, times, ...) and the arguments for rep.default() are (x, times, length.out, each, ...) ? Shouldn't these be the same? I am writing a rep() method for objects with class "octonion", and my function rep.octonion() has argument list (x, times, length.out, each, ...) just like rep.default(), but R CMD check complains about it, pointing out that rep() and rep.octonion() have different arguments. What do I have to do to my rep.octonion() function to make my package pass R CMD check without warning? -- Robin Hankin Uncertainty Analyst National Oceanography Centre, Southampton European Way, Southampton SO14 3ZH, UK tel 023-8059-7743 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] generic function argument list problem
> "Robin" == Robin Hankin <[EMAIL PROTECTED]> > on Wed, 31 Aug 2005 08:09:15 +0100 writes: Robin> Hi it says in R-exts that 1) A method must have all the arguments of the generic, including ... if the generic does. 2) A method must have arguments in exactly the same order as the generic. 3) A method should use the same defaults as the generic. Robin> So, how come the arguments for rep() are (x, times, ...) and the Robin> arguments Robin> for rep.default() are (x, times, length.out, each, ...) ? Shouldn't Robin> these be the same? no. If they should be the same, the "R-exts" manual would use a much shorter formulation than the carefully crafted points 1--3 above! The point is that methods often have *extra* arguments which match the "..." of the generic. That's one of the points about "..." ! Martin Maechler, ETH Zurich Robin> I am writing a rep() method for objects with class "octonion", and Robin> my function rep.octonion() has argument list (x, times, length.out, Robin> each, ...) Robin> just like rep.default(), but R CMD check complains about it, pointing Robin> out that rep() and rep.octonion() have different arguments. Robin> What do I have to do to my rep.octonion() function to make my package Robin> pass R CMD check without warning? Robin> -- Robin> Robin Hankin Robin> Uncertainty Analyst Robin> National Oceanography Centre, Southampton Robin> European Way, Southampton SO14 3ZH, UK Robin> tel 023-8059-7743 Robin> __ Robin> R-devel@r-project.org mailing list Robin> https://stat.ethz.ch/mailman/listinfo/r-devel Robin> A method must have all the arguments of the Robin> generic, including ... if the generic does. A method Robin> must have arguments in exactly the same order as the Robin> generic. A method should use the same defaults as Robin> the generic. Robin> So, how come the arguments for rep() are (x, times, Robin> ...) and the arguments for rep.default() are (x, Robin> times, length.out, each, ...) ? Shouldn't these be Robin> the same? Robin> I am writing a rep() method for objects with class Robin> "octonion", and my function rep.octonion() has Robin> argument list (x, times, length.out, each, ...) just Robin> like rep.default(), but R CMD check complains about Robin> it, pointing out that rep() and rep.octonion() have Robin> different arguments. Robin> What do I have to do to my rep.octonion() function to Robin> make my package pass R CMD check without warning? Robin> -- Robin Hankin Uncertainty Analyst National Robin> Oceanography Centre, Southampton European Way, Robin> Southampton SO14 3ZH, UK tel 023-8059-7743 Robin> __ Robin> R-devel@r-project.org mailing list Robin> https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] pos option to function 'library'
At the moment, the 'pos' argument to 'library' defaults to 2. Would it be possible to change this default to something functionally like the following? pos= if( is.null( pos.expr <- getOption( 'library.pos.default.expr'))) 2 else eval( pos.expr) The proposal is fully back-compatible in that 'pos' still defaults to 2 unless the user (or a package) sets the option. The point of the change is to allow flexibility in the default attachment position. The 'mvbutils' package needs to be able to attach packages at default positions lower than 2, otherwise its chain of workspaces gets confused. For the last three years, I've done this by modifying 'library' itself so that 'pos' defaults to the functional equivalent of the above, but I'd prefer not to have to hack a system function. Slightly more readable would be pos=default.lib.pos() where default.lib.pos <- function() if( is.null( pos.expr <- getOption( 'library.pos.default.expr'))) 2 else eval( pos.expr) is defined inside 'library'. Mark Bravington CSIRO Mathematical & Information Sciences Marine Laboratory Castray Esplanade Hobart 7001 TAS ph (+61) 3 6232 5118 fax (+61) 3 6232 5012 mob (+61) 438 315 623 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] generic function argument list problem
> "Robin" == Robin Hankin <[EMAIL PROTECTED]>
> on Wed, 31 Aug 2005 08:09:15 +0100 writes:
Robin> I am writing a rep() method for objects with class "octonion", and
Robin> my function rep.octonion() has argument list (x, times, length.out,
Robin> each, ...)
Robin> just like rep.default(), but R CMD check complains about it,
pointing
Robin> out that rep() and rep.octonion() have different arguments.
Hmm, not exactly, ``like rep.default'', I'm pretty sure.
Why not peek into R's /src/library/base/man/rep.Rd
which has
\usage{
rep(x, times, \dots)
\method{rep}{default}(x, times, length.out, each, \dots)
}
and definitely passes R CMD check without a warning.
Robin> What do I have to do to my rep.octonion() function to make my package
Robin> pass R CMD check without warning?
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] generic function argument list problem
On Wed, 2005-08-31 at 08:09 +0100, Robin Hankin wrote:
> Hi
>
> it says in R-exts that
>
>
> A method must have all the arguments of the generic,
> including ... if the generic does.
> A method must have arguments in exactly the same order as the
> generic.
> A method should use the same defaults as the generic.
>
>
> So, how come the arguments for rep() are (x, times, ...) and the
> arguments
> for rep.default() are (x, times, length.out, each, ...) ?
Shouldn't
> these be the same?
>
>
> I am writing a rep() method for objects with class "octonion", and
> my function rep.octonion() has argument list (x, times, length.out,
> each, ...)
> just like rep.default(), but R CMD check complains about it,
pointing
> out that rep() and rep.octonion() have different arguments.
>
> What do I have to do to my rep.octonion() function to make my package
> pass R CMD check without warning?
>
I cannot repeat your problem. Probably you did something differently
than you said (like omitted "..." , misspelled times as time or
something else in your rep.octonion).
This is what I tried.
In R:
> str(rep)
function (x, times, ...)
> rep.octonion <- function(x, times, length.out, each, ...) {}
> package.skeleton("octonion", "rep.octonion")
Creating directories ...
Creating DESCRIPTION ...
Creating READMEs ...
Saving functions and data ...
Making help files ...
Created file named './octonion/man/rep.octonion.Rd'.
Edit the file and move it to the appropriate directory.
Done.
Further steps are described in ./octonion/README
Then I edited octonion/man/rep.octonion.Rd so that it uses the generic
and passes R CMD check (virgin Rd files produced by package.skeleton
fail the test, which I found a bit weird). Here are the minimum changes
you need to pass the tests.
--- rep.octonion.Rd.orig2005-08-31 10:56:36.0 +0300
+++ rep.octonion.Rd 2005-08-31 10:55:25.0 +0300
@@ -7,5 +7,5 @@
}
\usage{
-rep.octonion(x, times, length.out, each, ...)
+\method{rep}{octonion}(x, times, length.out, each, ...)
}
%- maybe also 'usage' for other objects documented here.
@@ -18,5 +18,5 @@
}
\details{
- ~~ If necessary, more details than the __description__ above ~~
+ ~~ If necessary, more details than the description above ~~
}
\value{
@@ -31,7 +31,7 @@
\note{ ~~further notes~~ }
- ~Make other sections like Warning with \section{Warning }{} ~
-\seealso{ ~~objects to See Also as \code{\link{~~fun~~}}, ~~~ }
+
+\seealso{ ~~objects to See Also as \code{\link{rep}}, ~~~ }
\examples{
## Should be DIRECTLY executable !!
@@ -42,4 +42,4 @@
function(x, time, length.out, each, ...) {}
}
-\keyword{ ~kwd1 }% at least one, from doc/KEYWORDS
-\keyword{ ~kwd2 }% __ONLY ONE__ keyword per line
+\keyword{ models }% at least one, from doc/KEYWORDS
+
So this replaces rep.octonion with \method{rep}{octonion}, removes __
from description (these cause latex errors), remove a hanging top level
text "Make other sections...", and removes a link to non-existent
~~fun~~ (I'm not sure if adding a real keyword is necessary).
This passes tests. Including
* checking S3 generic/method consistency ... OK
Conclusion: check your files. (It is pain: been there, done that.)
cheers, jari oksanen
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] generic function argument list problem
On Wed, Aug 31, 2005 at 09:30:37AM +0200, Martin Maechler wrote: > > "Robin" == Robin Hankin <[EMAIL PROTECTED]> > > on Wed, 31 Aug 2005 08:09:15 +0100 writes: > > Robin> Hi it says in R-exts that > > 1) A method must have all the arguments of the generic, >including ... if the generic does. > > 2) A method must have arguments in exactly the same order as the generic. > > 3) A method should use the same defaults as the generic. > > > Robin> So, how come the arguments for rep() are (x, times, ...) and the > Robin> arguments > Robin> for rep.default() are (x, times, length.out, each, ...) ? > Shouldn't > Robin> these be the same? > > no. If they should be the same, the "R-exts" manual would use > a much shorter formulation than the carefully crafted points > 1--3 above! Martin, sorry if I am pedantic, but is 2. above that clear? Suppose that the generic has arguments (a, b, ...). Then, if I want to add an argument 'X' to a method, the argument list (a, b, X, ...) for the method would be OK, right? But how about (a, X, b, ...) or (a, b, ..., X)? I guess that would be wrong (but I haven't checked; is it maybe ok?!). The point is: What does it mean that two lists "have arguments in exactly the same order", when one list is a proper subset of the other? Maybe one should add "The common arguments, except ..., must have exactly the same _position_ in the generic and the method." Göran __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fwd: segfault
There's definitely something a bit strange going on. The arguments as
passed to wireframePanelCalculations from the code snippet show only
6060 elements for the z vector (51,101,16 respectively for x,y,rot)
while the function routinely tries to access at positions in the z
vector >20,000... until it eventually falls over (how long this takes
seems to depend on circumstances, I can actually get it to complete a
run while running in gdb).
On Aug 30, 2005, at 10:12 AM, stefano iacus wrote:
>
> On 29/ago/05, at 10:35, Prof Brian Ripley wrote:
>
>
>> It does not crash for me on either Windows or Linux, but it does
>> take a
>> long time and the plot is a mess, so there does seem to be a
>> lattice-related problem (maybe a usage one).
>>
>> However, I think the crash is a Mac (presumably quartz()) problem.
>>
>>
>
> no, it also happens with the X11 device. BTW, it seems to be OS X
> specific.
> I'll try to debug
> stefano
>
>
>> On Mon, 29 Aug 2005, stefano iacus wrote:
>>
>>
>>
>>> This segfaults on OS X (10.4) on both X11 and quartz devices.
>>> Seems a problem with lattice but I cannot test on other platforms
>>> stefano
>>>
>>>
>>> Begin forwarded message:
>>>
>>>
>>>
From: "G. Sawitzki" <[EMAIL PROTECTED]>
Date: 28 agosto 2005 14:11:18 GMT+02:00
To: [EMAIL PROTECTED]
Dear Stefano,
this small exaple leads to a crash of R. I did not try it on
versions other than the Mac version. So I am sending it to you
directly. If it is a littice problem, could you pass it to Deepayan
Sarkar? Thank you.
g.
==
#pbinom
library(grid)
library(lattice)
n<-20
psteps<-50
binomtable<- function (n,psteps){
x<-(0:(10*n))/10
p<- (0:psteps)/psteps
dd<-expand.grid(x=x,p=p)
dd$F<- pbinom(dd$x,n,dd$p)
dd$x0<-trunc(dd$x)
dd
}
bt<-binomtable(n=5,psteps=100)
bt[bt$x-bt$x0>=0.9,]$F<-NA
wireframe(bt$F~bt$x*bt$p,bt,groups=bt$x0,shade=TRUE) # leads to R
crash
#wireframe(bt$F~bt$x*bt$p,bt,shade=TRUE) #ok
>>
>> --
>> 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
>>
>>
>>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
---
Byron Ellis ([EMAIL PROTECTED])
"Oook" -- The Librarian
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Why should package.skeleton() fail R CMD check?
I find it a bit peculiar that a package skeleton created with a utils
function package.skeleton() fails subsequent R CMD check. I do
understand that the function is intended to produce only a skeleton that
should be edited by the package author. I think that it would be
justified to say that the skeleton *should* fail the test. However, I
have two arguments against intentional failure:
* When you produce a skeleton, a natural thing is to see if it works and
run R CMD check. It is is baffling (but educating) if this fails.
* The second argument is more major: If you produce a package with
several functions, you want to edit one Rd file in time to see what
errors you made. You don't want to correct errors in other Rd files not
yet edited by you to see your own errors. This kind of incremental
editing is much more pleasant, as following strict R code is painful
even with your own mistakes.
The failure comes only from Rd files, and it seems that the violating
code is produced by prompt.default function hidden in the utils
namespace. I attach a uniform diff file which shows the minimal set of
changes I had to do make utils:::prompt.default to produce Rd files
passing R CMD check. There are still two warnings: one on missing source
files and another on missing keywords, but these are not fatal. This
still produces bad looking latex. These are the changes I made
* I replaced "__description__" with "description", since "__" will give
latex errors.
* I enclosed ""Make other sections" within Note, so that it won't give
error on stray top level text. It will now appear as numbered latex
\section{} in dvi file, but that can the package author correct.
* I replaced reference to a non-existent function ~~fun~~ with a
reference to function help.
I'm sorry for the formatting of the diff file: my emacs/ESS is cleverer
than I and changes indentation and line breaks against my will.
cheers, jari oksanen
--
Jari Oksanen -- Dept Biology, Univ Oulu, 90014 Oulu, Finland
Ph. +358 8 5531526, cell +358 40 5136529, fax +358 8 5531061
email [EMAIL PROTECTED], homepage http://cc.oulu.fi/~jarioksa/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Why should package.skeleton() fail R CMD check?
> "Jari" == Jari Oksanen <[EMAIL PROTECTED]>
> on Wed, 31 Aug 2005 11:58:10 +0300 writes:
Jari> I find it a bit peculiar that a package skeleton created with a utils
Jari> function package.skeleton() fails subsequent R CMD check. I do
Jari> understand that the function is intended to produce only a skeleton
that
Jari> should be edited by the package author. I think that it would be
Jari> justified to say that the skeleton *should* fail the test. However, I
Jari> have two arguments against intentional failure:
Jari> * When you produce a skeleton, a natural thing is to see if it works
and
Jari> run R CMD check. It is is baffling (but educating) if this fails.
yes, and the ``but educating'' part has at least kept me from
fixing the problem in the past.
However, I nowadays rather agree with you.
Jari> * The second argument is more major: If you produce a package with
Jari> several functions, you want to edit one Rd file in time to see what
Jari> errors you made. You don't want to correct errors in other Rd files
not
Jari> yet edited by you to see your own errors. This kind of incremental
Jari> editing is much more pleasant, as following strict R code is painful
Jari> even with your own mistakes.
Jari> The failure comes only from Rd files, and it seems that the violating
Jari> code is produced by prompt.default function hidden in the utils
Jari> namespace. I attach a uniform diff file which shows the minimal set of
Jari> changes I had to do make utils:::prompt.default to produce Rd files
Jari> passing R CMD check. There are still two warnings: one on missing
source
Jari> files and another on missing keywords, but these are not fatal. This
Jari> still produces bad looking latex.
both is *desired*; a package author *should* get some urge to
edit the files, but I now agree that she should only get
warnings, not errors.
Jari> These are the changes I made
Jari> * I replaced "__description__" with "description", since "__" will
give
Jari> latex errors.
Jari> * I enclosed ""Make other sections" within Note, so that it won't give
Jari> error on stray top level text. It will now appear as numbered latex
Jari> \section{} in dvi file, but that can the package author correct.
Jari> * I replaced reference to a non-existent function ~~fun~~ with a
Jari> reference to function help.
sounds all reasonable
Jari> I'm sorry for the formatting of the diff file: my emacs/ESS is
cleverer
Jari> than I and changes indentation and line breaks against my will.
hmm; did you *edit* the *source*
or did you just edit a ``dump'' of the function definition?
Since you didn't use text/plain as content type, your
attachment didn't make it to the list anyway, and you have a
second chance:
Please use a "diff -u" against
https://svn.R-project.org/R/trunk/src/library/utils/R/prompt.R
or maybe even a "diff -ubBw ..." one.
Thank you for your proposition and willingness to contribute!
Martin Maechler, ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Why should package.skeleton() fail R CMD check?
One thing I forgot to add:
Did you try to include
- data frames
- other data
- S3 generics and methods
- S4 generics and methods
in the objects you gave to package.skeleton() ?
If we want to change the prompt*() functions such that
package.skeleton() produces a package that only gives warnings
{for the case of no ./src/ dependence; no NAMESPACE ; no other
package dependencies; ...}
I think we'd also need patches for the above objects' prompt*()
results.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] robustness of install.packages/update.packages
On Mon, 29 Aug 2005, Prof Brian Ripley wrote:
> On Sun, 28 Aug 2005, Prof Brian Ripley wrote:
>
>>> After redirecting R 2.1.1 on my laptop to use
>>>http://cran.au.r-project.org/
>>> for the CRAN repository, the install.packages() command ran without
>>> problems. I issued the command `library(MASS)' and tried out the
>>> example from fitdistr on that machine (same strange result for second
>>> command and warning messages were issued). So I said
>>> update.packages() and that command failed when it wanted to update
>>> the MASS package. So I detach()'ed MASS and re-ran update.packages()
>>> and again it failed. So I exited R 2.1.1 and restarted it again
>>> (probably I should have unloaded the namespace of MASS??) and then the
>>> update.packages command worked.
>>
>> Yes, and that *is* in the rw-FAQ.
>>
>>> However, update.packages() wanted to update quite a few packages
>>> besides MASS (the other packages in the VR bundle, nlme, lattice &c).
>>> Once it failed on MASS, it terminated with an error and did not update
>>> any of the other packages. Would it be possible to robustify
>>> update.packages behaviour such that it would continue in such
>>> situations with updating the remaining packages?
>>
>> Not a good idea. Better to follow the FAQ. At that point the dependencies
>> have been worked out and will not be re-computed if a package installation
>> fails.
>
> I checked, and I am unable to reproduce this. I get
The difference here was that it is install.packages("VR") which
update.packages() uses, not install.packages("MASS"), and of course "VR"
is not a package.
I've altered the code to check if any package in a bundle is in use. We
can only do that if installing from a repository (not a local zip file),
but at least we can cover than base.
I've also changed the code to use warning() and not stop() if moving fails
(although that is likely to be quite a serious problem).
>
>> library(MASS)
>> install.packages(c("MASS", "tree"))
> trying URL
> 'http://cran.at.r-project.org/bin/windows/contrib/2.2/tree_1.0-19.zip'
> Content type 'application/zip' length 144676 bytes
> opened URL
> downloaded 141Kb
>
> package 'tree' successfully unpacked and MD5 sums checked
>
> The downloaded packages are in
>C:\Documents and Settings\ripley\Local
> Settings\Temp\Rtmp13777\downloaded_packages
> updating HTML package descriptions
> Warning message:
> package MASS is in use and will not be installed
>
> which seems perfectly reasonable.
>
>
>
> --
> 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
>
--
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] Why should package.skeleton() fail R CMD check?
On Wed, 2005-08-31 at 11:23 +0200, Martin Maechler wrote:
> Since you didn't use text/plain as content type, your
> attachment didn't make it to the list anyway,
Yeah, I noticed.
> and you have a
> second chance:
>
> Please use a "diff -u" against
>
>https://svn.R-project.org/R/trunk/src/library/utils/R/prompt.R
>
> or maybe even a "diff -ubBw ..." one.
>
Here comes a uniform diff against svn source of prompt.R. I hope I made
all the same changes as previously. At least package.skeletons with this
pass R CMD check with the same two warnings as previously (after you
beat the namespace -- oh how I hate namespaces):
--- prompt.R2005-08-31 12:30:28.0 +0300
+++ prompt.R.new2005-08-31 12:32:13.0 +0300
@@ -96,5 +96,5 @@
details = c("\\details{",
paste(" ~~ If necessary, more details than the",
- "__description__ above ~~"),
+ "description above ~~"),
"}"),
value = c("\\value{",
@@ -108,11 +108,11 @@
"literature/web site here ~ }"),
author = "\\author{ ~~who you are~~ }",
- note = c("\\note{ ~~further notes~~ }",
+ note = c("\\note{ ~~further notes~~ ",
"",
paste(" ~Make other sections like Warning with",
"\\section{Warning }{} ~"),
- ""),
+ "}"),
seealso = paste("\\seealso{ ~~objects to See Also as",
- "\\code{\\link{~~fun~~}}, ~~~ }"),
+ "\\code{\\link{help}}, ~~~ }"),
examples = c("\\examples{",
"## Should be DIRECTLY executable !! ",
Cheers,
Jari Oksanen
--
Jari Oksanen -- Dept Biology, Univ Oulu, 90014 Oulu, Finland
Ph. +358 8 5531526, cell +358 40 5136529, fax +358 8 5531061
email [EMAIL PROTECTED], homepage http://cc.oulu.fi/~jarioksa/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] So-called 'bug' reports PR#8102 and PR#8103
Neither of these have reached me on R-devel (and only PR#8103 is on the archive), and they seem to be the same error although neither mentions the other. That's 'odd', to quote one of them. "EDT" is not a valid POSIX timezone (but, say, EST5EDT is). R's docs are quite clear that what happens with invalid inputs is system-specific. (Windows seems often to run home to PST8PDT.) You can have timezones without DST, but not one permanently in DST. In short, these were user errors compounded by unhelpful error-recovery by the OS the users were using. As to why tm + 3600 and tm + c(0, 1) * 3600 differ: one time is in one timezone, but two can be in different timezones so they must be handled differently. This is handled slightly differently in the R-devel version, which both the posting guide and the FAQ do ask you to try out (as well as consulting the NEWS file which has a relevant entry). Next time, please show some consideration for those who have to clear up after you, and do as we ask in the posting guide and FAQ. -- 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] Old times (PR#8111)
* * THIS IS AN AUTOMATED RESPONSE * * FROM [EMAIL PROTECTED] * * You have been sent this email because you responded to a Trade Me=20 automated email. =20 We send out a number of emails automatically including: * To the top bidder and seller at the conclusion of an auction * To bidders when they are outbid * To the seller when a question is placed on their auction =20 TO CONTACT THE SELLER OR TOP BIDDER *** If you are wanting to contact the seller or the top bidder in an=20 auction, their email address is contained within the email we send=20 you at the conclusion of the auction. Full details of all of your=20 auctions can be found under the My Trade Me tab on Trade Me. =20 My Trade Me: http://www.trademe.co.nz/structure/my_trademe.asp =20 TO ANSWER A QUESTION ON YOUR AUCTION To answer questions posted on your auction, visit Trade Me, login=20 and go to the auction the question was asked on. The link to do this=20 was contained in the email we sent when the question was asked.=20 Your answer will be immediately posted on the auction and forwarded=20 to the trader who asked the question. =20 TO CONTACT TRADE ME *** If you were wanting to contact Trade Me Support, please visit the=20 site at: http://www.trademe.co.nz/structure/helpdocs/crm_choose_subject.asp [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] So-called 'bug' reports PR#8102 and PR#8103
Windows XP, R-devel (2005-08-31 r35465)
> tm <- ISOdate(2005, 08, 29, hour = 12, tz = "EST5EDT")
> tm
[1] "2005-08-29 12:00:00 EDT"
> tm + 0
[1] "2005-08-29 12:00:00 EDT"
> tm + 3600
[1] "2005-08-29 13:00:00 EDT"
> tm + c(0,1) * 3600
[1] "2005-08-29 12:00:00 EDT" "2005-08-29 13:00:00 EDT"
(R 2.1.1 gives on my machine
> tm + c(0,1) * 3600
[1] "2005-08-29 17:00:00 BST" "2005-08-29 18:00:00 BST"
which is also valid.)
> tstamp <- strptime("2005-07-31 23:59:59", format="%Y-%m-%d %H:%M:%S")
> attr(tstamp,"tzone") <- "EST5EDT"
> tstamp
[1] "2005-07-31 23:59:59 EST5EDT"
> tstamp-3600
[1] "2005-07-31 22:59:59 EDT"
so once the user error is corrected this works as expected even on
Windows. (Even with the user error it works correctly in FC3 Linux,
which seems smart enough to know that EST5EDT was meant..)
On Windows, the routine used (_tzset) does not indicate user error, so
there is no way for R to know that an invalid value was given. Linux
(quoting POSIX) says `No errors are defined.' So users do need to read
their system documentation. For reference, see TZ in
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html#tag_08
On Wed, 31 Aug 2005, Prof Brian Ripley wrote:
> Neither of these have reached me on R-devel (and only PR#8103 is on the
> archive), and they seem to be the same error although neither mentions the
> other. That's 'odd', to quote one of them.
>
> "EDT" is not a valid POSIX timezone (but, say, EST5EDT is). R's docs are
> quite clear that what happens with invalid inputs is system-specific.
> (Windows seems often to run home to PST8PDT.) You can have timezones
> without DST, but not one permanently in DST.
>
> In short, these were user errors compounded by unhelpful error-recovery by
> the OS the users were using.
>
> As to why tm + 3600 and tm + c(0, 1) * 3600 differ: one time is in one
> timezone, but two can be in different timezones so they must be handled
> differently. This is handled slightly differently in the R-devel version,
> which both the posting guide and the FAQ do ask you to try out (as well as
> consulting the NEWS file which has a relevant entry).
>
> Next time, please show some consideration for those who have to clear up
> after you, and do as we ask in the posting guide and FAQ.
--
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 272860 (secr)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] .Call and Segmentation Fault
I suggest you look at the code for .Call() in dotcode.c. I suspect the problem is in dealing with R objects, however. You don't show how you get from SEXPs to pointers to pass to Fortran, or what the Fortran routine requires. I don't understand how you can call the "same" function from C. How do you deal with SEXPs? Reid Huntsinger Reid Huntsinger -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ricardo Luiz Andrade Abrantes Sent: Tuesday, August 30, 2005 4:33 PM To: r-devel@r-project.org Subject: Re: [Rd] .Call and Segmentation Fault Hello to everybody! After reading all the C code, checking for problems, and find nothing, I decided something a little bit different... If my ".so" library works in a wrog way in R it should do the same in C. So I created a C program that loads my library file and the executes the same function R is executing. The program worked perfectly! In fact I changed two things in my library: The function I call now return an int, not a SEXP, and the return value is 0 not R_NilValue. Valgrind's output is ok too... If .Call has no problems, and if my function works perfect when called from a C program, where the problem lies? Why my program becomes "crazy" when I run it from R? I would apreciate very much your help! I don't where else I could find help on this. I can provide any piece of code that may help, Its just ask! Thanks, Ricardo On 8/28/05, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > > On Sat, 27 Aug 2005, Ricardo Luiz Andrade Abrantes wrote: > > > Hi! > > Yes, I am returning a SEXP from the functions called from R, and the > > problem occurs before (thousands of iterations before) the return > > point. > > In fact I runned valgrind into R and when I call ".Call(...) " I got > > many errors like: > > ==4324== Use of uninitialised value of size 8 > > ==4324== at 0x1CB0766D: tnls_ (gencan.f:4101) > > ==4324== by 0x1CB01962: gencan_ (gencan.f:1876) > > ==4324== by 0x1CAFECA5: easygencan_ (gencan.f:440) > > ==4324== by 0x1CB0B47D: algencan_ (algencan.f:517) > > ==4324== by 0x1CB09E74: easyalgencan_ (algencan.f:76) > > ==4324== by 0x1CAFE5B3: main (algencanma.c:808) > > what does not happens when I compile the algencanma as a regular > > program (not a library) and run it from shell. Valgrind does not find > > anything wrong when I run the program directly, except 2 missing > > free() calls. > > Do you have any ideas where the problem lies (R .Call function or C > program)? > > It cannot be .Call: your .Call passed no parameters so there was nothing > to be uninitialized. I did ask you why you were doing that. > > .Call is very heavily tested in lots of R applications, so the prior > probability of innocence must be very high. > > -- > 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, UK Fax: +44 1865 272595 > [[alternative HTML version deleted]] __ 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] Bug in copying of S4 objects (PR#8112)
If I have an S4 object, and I make a copy, changes to the original
aren't reflected in the copy:
> setClass("foo", representation(slot="numeric"))
> x <- new("foo", slot=1)
> y <- x
> [EMAIL PROTECTED] <- 2
> y
An object of class "foo"
Slot "slot":
[1] 1
This is as it should be. However, if I call the slot assignment
function in a funny way, y *does* receive the changes:
> x <- new("foo", slot=1)
> y <- x
> assign("x", "@<-"(x, "slot", 2))
> y
An object of class "foo"
Slot "slot":
[1] 2
This happens in the current R-devel in Windows, and R-patched too.
> version
_
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status Under development (unstable)
major2
minor2.0
year 2005
month08
day 31
svn rev 35467
language R
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Email failure for forwards from [EMAIL PROTECTED] to r-de vel
I just sent a bug report to [EMAIL PROTECTED] Unfortunately, the
message forwarding to r-devel failed. It appears that this occurred due an
interaction between the forwarding setup and SPF:
1) The forwarded message had From as [EMAIL PROTECTED],
2) Pfizer has SPF records in DNS
3) the forwarding host's IP address is (correctly) not listed in
these SPF records.
I suspect that this will increasingly occur as other organizations deploy
SPF. Hence some re-configuration of the r-bugs forwarding needs to be
performed. Perhaps something like appropriately setting the "Sender" field
might help.
-Greg
Gregory R. Warnes, Ph.D.
Associate Director, Non-Clinical Statistics
Pfizer Global Research and Development
LEGAL NOTICE\ Unless expressly stated otherwise, this messag...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD check example problem (PR#8113)
[Automatic forwarding from R-bugs failed. This message has been manually
forwarded.]
Hi all!
I'm trying to add Thomas Lumley's defmacro() function Lumley T.
"Programmer's Niche: Macros in {R}", R News, 2001, Vol 1,
No. 3, pp 11--13, \url{http://CRAN.R-project.org/doc/Rnews/} to the gtools
package (provided that Thomas gives his OK). And I've encountered an error
in how R CMD check is extracting the example code I have in the .Rd file.
The example section contains the lines
# An equivalent function is somewhat messier, since it must either
explicitly
# construct the y axis label, duplicating some of the work of the plot
# function:
plotit <- function( df, var, col="red", title="" )
{
dname <- deparse(substitute(df))
vname <- deparse(substitute(var))
plot( df[[vname]] ~ df$Grp, type="b", col=col, title=title,
ylab=paste( dname, "$", vname, sep='' ) )
}
# or we explicitly construct the call and then call eval. The code for
# the latter approach is # omiited since this is quite messy and
# requires a lot of work.
which is getting extracted for testing into gtools.Rcheck/gtools-Ex.R as
# An equivalent function is somewhat messier, since it must either
explicitly
# construct the y axis label, duplicating some of the work of the plot
# function:
plotit <- function( df, var, col="red", title=""
)normal-bracket43bracket-normal
dname <- deparse(substitute(df))
vname <- deparse(substitute(var))
plot( df[[vname]] ~ df$Grp, type="b", col=col, title=title,
ylab=paste( dname, "$", vname, sep='' ) )
normal-bracket43bracket-normal
# or we explicitly construct the call and then call eval. The code for
# the latter approach is # omiited since this is quite messy and
# requires a lot of work.
Note that the opening and closing curly brakkets are converted to the string
"normal-bracket43bracket-normal". [I assume that this is happeing
somewhere to check for brace-matches, and isn't being properly undone.] As
a consequence, R CMD check is failing:
> # An equivalent function is somewhat messier, since it must either
explicitly
> # construct the y axis label, duplicating some of the work of the plot
> # function:
> plotit <- function( df, var, col="red", title=""
)normal-bracket43bracket-normal
> dname <- deparse(substitute(df))
> vname <- deparse(substitute(var))
> plot( df[[vname]] ~ df$Grp, type="b", col=col, title=title,
+ ylab=paste( dname, "$", vname, sep='' ) )
Error in df[[vname]] : object is not subsettable
Execution halted
I've checked, and this occurs under R-2.1.0, R-2.1.1, and today's
R-2.2.0-devel on my
platform i686-pc-linux-gnu
arch i686
os linux-gnu
system i686, linux-gnu
I'm attaching the probelmatic .Rd file to this email.
<>
(For the record, I've simply enclosed the problematic section in \dontrun as
a workaround.)
-Greg
Gregory R. Warnes, Ph.D.
Associate Director, Non-Clinical Statistics
Pfizer Global Research and Development
LEGAL NOTICE
Unless expressly stated otherwise, this message is confidential and may be
privileged. It is intended for the addressee(s) only. Access to this E-mail by
anyone else is unauthorized. If you are not an addressee, any disclosure or
copying of the contents of this E-mail or any action taken (or not taken) in
reliance on it is unauthorized and may be unlawful. If you are not an
addressee, please inform the sender immediately.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R --gui doesn't work, but R --help says it does
This was reported on r-devel in April for 2.1.0, but isn't fixed in 2.1.1 see http://tolstoy.newcastle.edu.au/~rking/R/devel/05/04/0586.html # R --help [ output omitted, until] -g, --gui=TYPEUse TYPE as GUI; possible values are 'X11' (default), 'none', 'Tk' and 'gnome' solzhenitsyn:~# R --gui=none ERROR: unknown GUI none solzhenitsyn:~# R --gui=none ERROR: unknown GUI none solzhenitsyn:~# R --gui='none' ERROR: unknown GUI none solzhenitsyn:~# R --gui=X11 ERROR: unknown GUI X11 solzhenitsyn:~# R --gui=Tk ERROR: unknown GUI Tk solzhenitsyn:~# R --gui='Tk' ERROR: unknown GUI Tk solzhenitsyn:~# R --gui='X11' ERROR: unknown GUI X11 solzhenitsyn:~# R --gui="none" ERROR: unknown GUI none -- Robert King, Statistics, School of Mathematical & Physical Sciences, University of Newcastle, Australia Room V133 ph +61 2 4921 5548 [EMAIL PROTECTED] http://maths.newcastle.edu.au/~rking/ "It might be in the basement, I'll go upstairs and check .." Escher __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] update.packages forces Tcl/Tk interface despite ask=TRUE if the DISPLAY environment variable is set (PR#8115)
Full_Name: Robert King Version: 2.1.1 OS: Linux (debian stable, with backport R) Submission from: (NULL) (142.58.147.28) update.packages documentation (and code, from what I can make out) says: ask: logical indicating whether to ask user before packages are actually downloaded and installed, or the character string '"graphics"', which brings up a widget to allow the user to (de-)select from the list of packages which could be updated. The latter only works on systems with a GUI version of 'select.list', and is otherwise equivalent to 'ask = TRUE'. But, if I try ask=TRUE, it tries loading the Tcl/Tk interface (which I found out because I'm doing this remotely and it crashed. > update.packages(ask=TRUE) --- Please select a CRAN mirror for use in this session --- Loading Tcl/Tk interface ... Error in fun(...) : Tcl already loaded Error: .onLoad failed in 'loadNamespace' for 'tcltk' On the other hand, if I log out and ssh back with X forwarding turned off, it does the right thing, __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] update.packages forces Tcl/Tk interface despite ask=TRUE if the DISPLAY environment variable is set (PR#8115)
[EMAIL PROTECTED] writes: > Full_Name: Robert King > Version: 2.1.1 > OS: Linux (debian stable, with backport R) > Submission from: (NULL) (142.58.147.28) > > > update.packages documentation (and code, from what I can make out) says: > > ask: logical indicating whether to ask user before packages are > actually downloaded and installed, or the character string > '"graphics"', which brings up a widget to allow the user to > (de-)select from the list of packages which could be updated. >The latter only works on systems with a GUI version of > 'select.list', and is otherwise equivalent to 'ask = TRUE'. > > But, if I try ask=TRUE, it tries loading the Tcl/Tk interface (which I found > out > because I'm doing this remotely and it crashed. > > > update.packages(ask=TRUE) > --- Please select a CRAN mirror for use in this session --- > Loading Tcl/Tk interface ... Error in fun(...) : Tcl already loaded > Error: .onLoad failed in 'loadNamespace' for 'tcltk' > > On the other hand, if I log out and ssh back with X forwarding turned off, it > does the right thing, This is unrelated to ask=TRUE. It is during the choice of CRAN site that R is trying to fire up a Tk listbox (it might be debated whether this is a good idea, but it _is_ intentional). If you set the repository yourself, this won't happen. The error looks a bit odd though. The logic is supposed to be that either you have Tcl/Tk capabilities and you get the popup, or you don't and get a text menu. So something appears not right with your Tcl/Tk configuration. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Build Portland Group Compiler
Hi, I built R with Portland Group compiler, but I noticed one thing that when I ran configure for the first time on AMD machine, I got the following error: checking whether the C compiler works... configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details. so I tried to set host=x86_64-unknown-linux-gnu, which seems to work, except what puzzles me is that there is warning messages indicating C longs are 4 bytes. *** % configure --host=x86_64-unknown-linux-gnu . . . R is now configured for x86_64-unknown-linux-gnu Source directory: . Installation directory:/usr/local/R.pgcc C compiler:/usr/pgi/linux86-64/6.0/bin/pgcc -g -O2 -mieee-fp C++ compiler: /usr/pgi/linux86-64/6.0/bin/pgCC -g Fortran compiler: /usr/pgi/linux86-64/6.0/bin/pgf77 -O2 Interfaces supported: X11 External libraries:readline Additional capabilities: PNG, JPEG, MBCS, NLS Options enabled: R profiling Recommended packages: yes configure: WARNING: assuming C ints are 4 byte on x86_64-unknown-linux-gnu configure: WARNING: assuming C longs are 4 byte on x86_64-unknown-linux-gnu configure: WARNING: you cannot build info or html versions of the R manuals Am I defining a wrong host? Thanks, Jennifer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Build Portland Group Compiler
Jennifer Lai <[EMAIL PROTECTED]> writes: > Hi, > I built R with Portland Group compiler, but I noticed one thing that > when I ran configure for the first time on AMD machine, I got the > following error: > > > checking whether the C compiler works... configure: error: cannot run C > compiled programs. > If you meant to cross compile, use `--host'. > See `config.log' for more details. > > > > so I tried to set host=x86_64-unknown-linux-gnu, which seems to work, > except what puzzles me is that there is warning messages indicating C > longs are 4 bytes. > > *** > % configure --host=x86_64-unknown-linux-gnu > . > . > . > R is now configured for x86_64-unknown-linux-gnu > > Source directory: . > Installation directory:/usr/local/R.pgcc > > C compiler:/usr/pgi/linux86-64/6.0/bin/pgcc -g -O2 > -mieee-fp > C++ compiler: /usr/pgi/linux86-64/6.0/bin/pgCC -g > Fortran compiler: /usr/pgi/linux86-64/6.0/bin/pgf77 -O2 > > Interfaces supported: X11 > External libraries:readline > Additional capabilities: PNG, JPEG, MBCS, NLS > Options enabled: R profiling > > Recommended packages: yes > > configure: WARNING: assuming C ints are 4 byte on x86_64-unknown-linux-gnu > configure: WARNING: assuming C longs are 4 byte on x86_64-unknown-linux-gnu > configure: WARNING: you cannot build info or html versions of the R manuals > > > Am I defining a wrong host? You're not doing yourself a favour, anyway. 4-byte longs are definitely not a good idea on Linux. What is worse, you are building a cross-target, which means that configure is not even going to try running any compiled programs, not that they work any better than before. The thing to do is to look inside config.log and see what causes configure to conclude that you cannot run C compiled programs. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Build Portland Group Compiler
I can't duplicate the error message. After running "configure --host=x86_64-unknow-linux-gnu" for the first time, I was able to run configure without providing --host argument. Even start with a fresh copy of R-devel didn't help me to get the original error. Is the host info been cached somewhere in R? Regards, Jennifer Peter Dalgaard wrote: >Jennifer Lai <[EMAIL PROTECTED]> writes: > > > >>Hi, >>I built R with Portland Group compiler, but I noticed one thing that >>when I ran configure for the first time on AMD machine, I got the >>following error: >> >> >>checking whether the C compiler works... configure: error: cannot run C >>compiled programs. >>If you meant to cross compile, use `--host'. >>See `config.log' for more details. >> >> >> >>so I tried to set host=x86_64-unknown-linux-gnu, which seems to work, >>except what puzzles me is that there is warning messages indicating C >>longs are 4 bytes. >> >>*** >>% configure --host=x86_64-unknown-linux-gnu >>. >>. >>. >>R is now configured for x86_64-unknown-linux-gnu >> >> Source directory: . >> Installation directory:/usr/local/R.pgcc >> >> C compiler:/usr/pgi/linux86-64/6.0/bin/pgcc -g -O2 >>-mieee-fp >> C++ compiler: /usr/pgi/linux86-64/6.0/bin/pgCC -g >> Fortran compiler: /usr/pgi/linux86-64/6.0/bin/pgf77 -O2 >> >> Interfaces supported: X11 >> External libraries:readline >> Additional capabilities: PNG, JPEG, MBCS, NLS >> Options enabled: R profiling >> >> Recommended packages: yes >> >>configure: WARNING: assuming C ints are 4 byte on x86_64-unknown-linux-gnu >>configure: WARNING: assuming C longs are 4 byte on x86_64-unknown-linux-gnu >>configure: WARNING: you cannot build info or html versions of the R manuals >> >> >>Am I defining a wrong host? >> >> > >You're not doing yourself a favour, anyway. 4-byte longs are >definitely not a good idea on Linux. What is worse, you are building a >cross-target, which means that configure is not even going to try >running any compiled programs, not that they work any better than >before. > >The thing to do is to look inside config.log and see what causes >configure to conclude that you cannot run C compiled programs. > > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Build Portland Group Compiler
Forgot to mention, here are #define long and int value in config.log from second configure run (without --host argument) | #define SIZEOF_INT 4 | #define INT_32_BITS 1 | #define SIZEOF_LONG 8 | #define SIZEOF_LONG_LONG 8 | #define SIZEOF_LONG_DOUBLE 16 Regards, Jennifer Jennifer Lai wrote: > I can't duplicate the error message. After running "configure > --host=x86_64-unknow-linux-gnu" for the first time, I was able to run > configure without providing --host argument. Even start with a fresh > copy of R-devel didn't help me to get the original error. Is the host > info been cached somewhere in R? > > Regards, > Jennifer > > Peter Dalgaard wrote: > >> Jennifer Lai <[EMAIL PROTECTED]> writes: >> >> >> >>> Hi, >>>I built R with Portland Group compiler, but I noticed one thing >>> that when I ran configure for the first time on AMD machine, I got >>> the following error: >>> >>> >>> checking whether the C compiler works... configure: error: cannot >>> run C compiled programs. >>> If you meant to cross compile, use `--host'. >>> See `config.log' for more details. >>> >>> >>> >>> so I tried to set host=x86_64-unknown-linux-gnu, which seems to >>> work, except what puzzles me is that there is warning messages >>> indicating C longs are 4 bytes. >>> >>> *** >>> % configure --host=x86_64-unknown-linux-gnu >>> . >>> . >>> . >>> R is now configured for x86_64-unknown-linux-gnu >>> >>> Source directory: . >>> Installation directory:/usr/local/R.pgcc >>> >>> C compiler:/usr/pgi/linux86-64/6.0/bin/pgcc -g -O2 >>> -mieee-fp >>> C++ compiler: /usr/pgi/linux86-64/6.0/bin/pgCC -g >>> Fortran compiler: /usr/pgi/linux86-64/6.0/bin/pgf77 -O2 >>> >>> Interfaces supported: X11 >>> External libraries:readline >>> Additional capabilities: PNG, JPEG, MBCS, NLS >>> Options enabled: R profiling >>> >>> Recommended packages: yes >>> >>> configure: WARNING: assuming C ints are 4 byte on >>> x86_64-unknown-linux-gnu >>> configure: WARNING: assuming C longs are 4 byte on >>> x86_64-unknown-linux-gnu >>> configure: WARNING: you cannot build info or html versions of the R >>> manuals >>> >>> >>> Am I defining a wrong host? >>> >> >> >> You're not doing yourself a favour, anyway. 4-byte longs are >> definitely not a good idea on Linux. What is worse, you are building a >> cross-target, which means that configure is not even going to try >> running any compiled programs, not that they work any better than >> before. >> >> The thing to do is to look inside config.log and see what causes >> configure to conclude that you cannot run C compiled programs. >> >> >> > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Build Portland Group Compiler
Jennifer Lai <[EMAIL PROTECTED]> writes: > I can't duplicate the error message. After running "configure > --host=x86_64-unknow-linux-gnu" for the first time, I was able to run > configure without providing --host argument. Even start with a fresh > copy of R-devel didn't help me to get the original error. Is the host > info been cached somewhere in R? Not that I know of... Back in the old days we had config.cache playing tricks on people, but it shouldn't be there anymore. If you're not already doing so, do yourself a favour and build in a separate directory, keeping the sources untouched. It's much easier to clean up and start over that way. > >>Hi, > >>I built R with Portland Group compiler, but I noticed one thing > >> that when I ran configure for the first time on AMD machine, I got > >> the following error: > >> > >> > >> checking whether the C compiler works... configure: error: cannot > >> run C compiled programs. > >>If you meant to cross compile, use `--host'. > >>See `config.log' for more details. > >> > >> > >> > >> so I tried to set host=x86_64-unknown-linux-gnu, which seems to > >> work, except what puzzles me is that there is warning messages > >> indicating C longs are 4 bytes. > >> > >>*** > >>% configure --host=x86_64-unknown-linux-gnu > >>. > >>. > >>. > >>R is now configured for x86_64-unknown-linux-gnu > >> > >> Source directory: . > >> Installation directory:/usr/local/R.pgcc > >> > >> C compiler:/usr/pgi/linux86-64/6.0/bin/pgcc -g > >> -O2 -mieee-fp > >> C++ compiler: /usr/pgi/linux86-64/6.0/bin/pgCC -g > >> Fortran compiler: /usr/pgi/linux86-64/6.0/bin/pgf77 -O2 > >> > >> Interfaces supported: X11 > >> External libraries:readline > >> Additional capabilities: PNG, JPEG, MBCS, NLS > >> Options enabled: R profiling > >> > >> Recommended packages: yes > >> > >>configure: WARNING: assuming C ints are 4 byte on x86_64-unknown-linux-gnu > >>configure: WARNING: assuming C longs are 4 byte on x86_64-unknown-linux-gnu > >>configure: WARNING: you cannot build info or html versions of the R manuals > >> > >> > >>Am I defining a wrong host? > >> > > > >You're not doing yourself a favour, anyway. 4-byte longs are > >definitely not a good idea on Linux. What is worse, you are building a > >cross-target, which means that configure is not even going to try > >running any compiled programs, not that they work any better than > >before. > > > >The thing to do is to look inside config.log and see what causes > >configure to conclude that you cannot run C compiled programs. > > > > > > > -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 64 bit R for Windows
Duncan: Thanks for your reply. Not being a part of the R world and having to assist with these purchases, I have to ask what "not yet" means. I realize that this is a difficult question to answer even for commercial software, but I am hoping you or someone else on the list may shed some additional light on the subject. Thanks in advance. Milton F. López IT Guy Inter-American Tuna Commission (IATTC) 8604 La Jolla Shores Drive La Jolla, CA 92037 Tel: (858) 546-7041, Fax: (858) 546-7133 [EMAIL PROTECTED] http://www.iattc.org -Original Message- From: Duncan Murdoch [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 30, 2005 5:39 PM To: Milton Lopez Cc: r-devel@r-project.org Subject: Re: [Rd] 64 bit R for Windows Milton Lopez wrote: > I am assisting in the purchase of 64-bit Windows XP system for researchers > who run R. These systems will have AMD Opteron processors and at least 4GB of > RAM. I'd appreciate advice on whether there is a working version of R that > can take full advantage of such systems. No, there are no 64 bit Windows versions yet. You'll need to install some 64 bit version of Linux on those machines to take full advantage of the chips. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Build Portland Group Compiler
My silly mistake. I didn't get the error message the second time is because I have set LD_LIBRARY_PATH. If this value is unset, I would have gotten the same error message, checking for C compiler default output file name... a.out checking whether the C compiler works... configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. Thank you for the help! Sincerely, Jennifer Peter Dalgaard wrote: >Jennifer Lai <[EMAIL PROTECTED]> writes: > > > >>I can't duplicate the error message. After running "configure >>--host=x86_64-unknow-linux-gnu" for the first time, I was able to run >>configure without providing --host argument. Even start with a fresh >>copy of R-devel didn't help me to get the original error. Is the host >>info been cached somewhere in R? >> >> > >Not that I know of... Back in the old days we had config.cache playing >tricks on people, but it shouldn't be there anymore. > >If you're not already doing so, do yourself a favour and build in a >separate directory, keeping the sources untouched. It's much easier to >clean up and start over that way. > > > Hi, I built R with Portland Group compiler, but I noticed one thing that when I ran configure for the first time on AMD machine, I got the following error: checking whether the C compiler works... configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details. so I tried to set host=x86_64-unknown-linux-gnu, which seems to work, except what puzzles me is that there is warning messages indicating C longs are 4 bytes. *** % configure --host=x86_64-unknown-linux-gnu . . . R is now configured for x86_64-unknown-linux-gnu Source directory: . Installation directory:/usr/local/R.pgcc C compiler:/usr/pgi/linux86-64/6.0/bin/pgcc -g -O2 -mieee-fp C++ compiler: /usr/pgi/linux86-64/6.0/bin/pgCC -g Fortran compiler: /usr/pgi/linux86-64/6.0/bin/pgf77 -O2 Interfaces supported: X11 External libraries:readline Additional capabilities: PNG, JPEG, MBCS, NLS Options enabled: R profiling Recommended packages: yes configure: WARNING: assuming C ints are 4 byte on x86_64-unknown-linux-gnu configure: WARNING: assuming C longs are 4 byte on x86_64-unknown-linux-gnu configure: WARNING: you cannot build info or html versions of the R manuals Am I defining a wrong host? >>>You're not doing yourself a favour, anyway. 4-byte longs are >>>definitely not a good idea on Linux. What is worse, you are building a >>>cross-target, which means that configure is not even going to try >>>running any compiled programs, not that they work any better than >>>before. >>> >>>The thing to do is to look inside config.log and see what causes >>>configure to conclude that you cannot run C compiled programs. >>> >>> >>> >>> >> >> >> > > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: "loop connections"
Martin Maechler <[EMAIL PROTECTED]> wrote:
> I think the main point of David's proposal is still worth
> consideration: One way to see text connections is as a way to
> treat some kind of R objects as "generalized files" i.e., connections.
To summarize the motivation for the proposal, again:
- There are two modes of connections: text and binary. The operations
supported on text and binary connections are mostly disjoint. Most
connection classes (socket, file, etc) support both modes.
- textConnection() binds a character vector to a text connection.
There is no equivalent for a binary connection. there are
workarounds (i.e. anonymous connections, equivalent to temporary
files), but these have substantial performance penalties.
- Both connection modes have useful applications. textConnection() is
useful, or it would not exist. Orthogonality is good, special cases
are bad.
- Only about 50 lines of code are required to implement a binary form
of textConnection() in the R core. Implementing this functionality
in a separate package requires substantially more code.
- I need it, and in at least one case, another R package developer has
implemented it using temporary files (caTools). I also just noticed
that Duncon Murdoch recently proposed the EXACT SAME feature on
r-help:
https://stat.ethz.ch/pipermail/r-help/2005-April/067651.html
I think that just about sums it up. I've attached a smaller patch
that makes fewer changes to R source, doesn't change any existing
function names, etc. The feature adds 400 bytes to the size of R.dll.
-- Dave
--- src/main/connections.c.orig 2005-06-17 19:05:02.0 -0700
+++ src/main/connections.c 2005-08-31 15:26:19.947195100 -0700
@@ -1644,7 +1644,7 @@
return ans;
}
-/* --- text connections - */
+/* --- text and raw connections - */
/* read a R character vector into a buffer */
static void text_init(Rconnection con, SEXP text)
@@ -1668,6 +1668,22 @@
this->cur = this->save = 0;
}
+/* read a R raw vector into a buffer */
+static void raw_init(Rconnection con, SEXP raw)
+{
+int nbytes = length(raw);
+Rtextconn this = (Rtextconn)con->private;
+
+this->data = (char *) malloc(nbytes);
+if(!this->data) {
+ free(this); free(con->description); free(con->class); free(con);
+ error(_("cannot allocate memory for raw connection"));
+}
+memcpy(this->data, RAW(raw), nbytes);
+this->nchars = nbytes;
+this->cur = this->save = 0;
+}
+
static Rboolean text_open(Rconnection con)
{
con->save = -1000;
@@ -1702,41 +1718,60 @@
static double text_seek(Rconnection con, double where, int origin, int rw)
{
-if(where >= 0) error(_("seek is not relevant for text connection"));
+if(where >= 0) error(_("seek is not relevant for this connection"));
return 0; /* if just asking, always at the beginning */
}
-static Rconnection newtext(char *description, SEXP text)
+static size_t raw_read(void *ptr, size_t size, size_t nitems,
+ Rconnection con)
+{
+Rtextconn this = (Rtextconn)con->private;
+if (this->cur + size*nitems > this->nchars) {
+ nitems = (this->nchars - this->cur)/size;
+ memcpy(ptr, this->data+this->cur, size*nitems);
+ this->cur = this->nchars;
+} else {
+ memcpy(ptr, this->data+this->cur, size*nitems);
+ this->cur += size*nitems;
+}
+return nitems;
+}
+
+static Rconnection newtext(char *description, SEXP data)
{
Rconnection new;
+int isText = isString(data);
new = (Rconnection) malloc(sizeof(struct Rconn));
-if(!new) error(_("allocation of text connection failed"));
-new->class = (char *) malloc(strlen("textConnection") + 1);
-if(!new->class) {
- free(new);
- error(_("allocation of text connection failed"));
-}
-strcpy(new->class, "textConnection");
+if(!new) goto f1;
+new->class = (char *) malloc(strlen("Connection") + 1);
+if(!new->class) goto f2;
+sprintf(new->class, "%sConnection", isText ? "text" : "raw");
new->description = (char *) malloc(strlen(description) + 1);
-if(!new->description) {
- free(new->class); free(new);
- error(_("allocation of text connection failed"));
-}
+if(!new->description) goto f3;
init_con(new, description, "r");
new->isopen = TRUE;
new->canwrite = FALSE;
new->open = &text_open;
new->close = &text_close;
new->destroy = &text_destroy;
-new->fgetc = &text_fgetc;
new->seek = &text_seek;
new->private = (void*) malloc(sizeof(struct textconn));
-if(!new->private) {
- free(new->description); free(new->class); free(new);
- error(_("allocation of text connection failed"));
+if(!new->private) goto f4;
+new->text = isText;
+if (new->text) {
+ new->fgetc = &text_fgetc;
+ text_init(new, data);
+} else {
+ new->re
Re: [Rd] 64 bit R for Windows
Milton Lopez wrote: > Duncan: > > Thanks for your reply. Not being a part of the R world and having to assist > with these purchases, I have to ask what "not yet" means. I realize that this > is a difficult question to answer even for commercial software, but I am > hoping you or someone else on the list may shed some additional light on the > subject. I would say it will be at least a year, and most likely longer. The tools used to build R haven't been ported to 64 bit Windows yet. After those are done (by the MinGW project, not us), we'll need someone with a 64 bit Windows machine to handle builds there. Duncan Murdoch > Thanks in advance. > > Milton F. López > IT Guy > Inter-American Tuna Commission (IATTC) > 8604 La Jolla Shores Drive > La Jolla, CA 92037 > Tel: (858) 546-7041, Fax: (858) 546-7133 > [EMAIL PROTECTED] > http://www.iattc.org > > -Original Message- > From: Duncan Murdoch [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 30, 2005 5:39 PM > To: Milton Lopez > Cc: r-devel@r-project.org > Subject: Re: [Rd] 64 bit R for Windows > > Milton Lopez wrote: > >>I am assisting in the purchase of 64-bit Windows XP system for researchers >>who run R. These systems will have AMD Opteron processors and at least 4GB of >>RAM. I'd appreciate advice on whether there is a working version of R that >>can take full advantage of such systems. > > > No, there are no 64 bit Windows versions yet. You'll need to install > some 64 bit version of Linux on those machines to take full advantage of > the chips. > > Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 64 bit R for Windows
On Wed, 31 Aug 2005, Duncan Murdoch wrote: Milton Lopez wrote: Duncan: Thanks for your reply. Not being a part of the R world and having to assist with these purchases, I have to ask what "not yet" means. I realize that this is a difficult question to answer even for commercial software, but I am hoping you or someone else on the list may shed some additional light on the subject. I would say it will be at least a year, and most likely longer. The tools used to build R haven't been ported to 64 bit Windows yet. After those are done (by the MinGW project, not us), we'll need someone with a 64 bit Windows machine to handle builds there. Duncan Murdoch An additional factor is that MinGW will almost certainly follow the MS idea that long's are 4 bytes even under Win64, unlike what every other 64-bit OS does. It will take a fair bit of time and someonw with the motivation to do so to sort out the consequences (which may not be very great but even establishing that may be non-trivial). luke Thanks in advance. Milton F. López IT Guy Inter-American Tuna Commission (IATTC) 8604 La Jolla Shores Drive La Jolla, CA 92037 Tel: (858) 546-7041, Fax: (858) 546-7133 [EMAIL PROTECTED] http://www.iattc.org -Original Message- From: Duncan Murdoch [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 30, 2005 5:39 PM To: Milton Lopez Cc: r-devel@r-project.org Subject: Re: [Rd] 64 bit R for Windows Milton Lopez wrote: I am assisting in the purchase of 64-bit Windows XP system for researchers who run R. These systems will have AMD Opteron processors and at least 4GB of RAM. I'd appreciate advice on whether there is a working version of R that can take full advantage of such systems. No, there are no 64 bit Windows versions yet. You'll need to install some 64 bit version of Linux on those machines to take full advantage of the chips. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Luke Tierney Chair, Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: [EMAIL PROTECTED] Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu__ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: "loop connections"
[EMAIL PROTECTED] wrote:
> Martin Maechler <[EMAIL PROTECTED]> wrote:
>
>
>>I think the main point of David's proposal is still worth
>>consideration: One way to see text connections is as a way to
>>treat some kind of R objects as "generalized files" i.e., connections.
>
>
> To summarize the motivation for the proposal, again:
>
> - There are two modes of connections: text and binary. The operations
> supported on text and binary connections are mostly disjoint. Most
> connection classes (socket, file, etc) support both modes.
>
> - textConnection() binds a character vector to a text connection.
> There is no equivalent for a binary connection. there are
> workarounds (i.e. anonymous connections, equivalent to temporary
> files), but these have substantial performance penalties.
>
> - Both connection modes have useful applications. textConnection() is
> useful, or it would not exist. Orthogonality is good, special cases
> are bad.
>
> - Only about 50 lines of code are required to implement a binary form
> of textConnection() in the R core. Implementing this functionality
> in a separate package requires substantially more code.
>
> - I need it, and in at least one case, another R package developer has
> implemented it using temporary files (caTools). I also just noticed
> that Duncon Murdoch recently proposed the EXACT SAME feature on
> r-help:
>
> https://stat.ethz.ch/pipermail/r-help/2005-April/067651.html
Since you quote me:
I would implement it differently from the way you did. I'd call it a
rawConnection, taking a raw variable (or converting something else using
as.raw) as the input, and providing both text and binary read/write
modes (using the same conventions for text mode as a file connection
would). It *should* support seek, at least in binary mode.
I would like an implementation that didn't necessarily duplicate the
whole raw vector into a buffer (it might be big, and people who deal
with big objects are always short of memory), but this isn't essential,
it would just be a nice feature.
Now, it would be nice to have something like this, but I'm not likely to
have time to do it in the near future. If you are interested in doing
this (and documenting it), I'd be willing to take a look at your code
and commit it when it looked okay.
The deadline for this to make it into 2.2.0 is that I'd want to commit
it by Sept 6, so there's not a lot of time left.
Duncan Murdoch
>
> I think that just about sums it up. I've attached a smaller patch
> that makes fewer changes to R source, doesn't change any existing
> function names, etc. The feature adds 400 bytes to the size of R.dll.
>
> -- Dave
>
>
>
> --- src/main/connections.c.orig 2005-06-17 19:05:02.0 -0700
> +++ src/main/connections.c2005-08-31 15:26:19.947195100 -0700
> @@ -1644,7 +1644,7 @@
> return ans;
> }
>
> -/* --- text connections - */
> +/* --- text and raw connections - */
>
> /* read a R character vector into a buffer */
> static void text_init(Rconnection con, SEXP text)
> @@ -1668,6 +1668,22 @@
> this->cur = this->save = 0;
> }
>
> +/* read a R raw vector into a buffer */
> +static void raw_init(Rconnection con, SEXP raw)
> +{
> +int nbytes = length(raw);
> +Rtextconn this = (Rtextconn)con->private;
> +
> +this->data = (char *) malloc(nbytes);
> +if(!this->data) {
> + free(this); free(con->description); free(con->class); free(con);
> + error(_("cannot allocate memory for raw connection"));
> +}
> +memcpy(this->data, RAW(raw), nbytes);
> +this->nchars = nbytes;
> +this->cur = this->save = 0;
> +}
> +
> static Rboolean text_open(Rconnection con)
> {
> con->save = -1000;
> @@ -1702,41 +1718,60 @@
>
> static double text_seek(Rconnection con, double where, int origin, int rw)
> {
> -if(where >= 0) error(_("seek is not relevant for text connection"));
> +if(where >= 0) error(_("seek is not relevant for this connection"));
> return 0; /* if just asking, always at the beginning */
> }
>
> -static Rconnection newtext(char *description, SEXP text)
> +static size_t raw_read(void *ptr, size_t size, size_t nitems,
> +Rconnection con)
> +{
> +Rtextconn this = (Rtextconn)con->private;
> +if (this->cur + size*nitems > this->nchars) {
> + nitems = (this->nchars - this->cur)/size;
> + memcpy(ptr, this->data+this->cur, size*nitems);
> + this->cur = this->nchars;
> +} else {
> + memcpy(ptr, this->data+this->cur, size*nitems);
> + this->cur += size*nitems;
> +}
> +return nitems;
> +}
> +
> +static Rconnection newtext(char *description, SEXP data)
> {
> Rconnection new;
> +int isText = isString(data);
> new = (Rconnection) malloc(sizeof(struct Rconn));
> -if(!new) error(_("allocation of text connection failed"));
> -new->class = (char
Re: [Rd] RFC: rawConnection (was "loop connections")
Duncan Murdoch <[EMAIL PROTECTED]> wrote: > I would implement it differently from the way you did. I'd call it > a rawConnection, taking a raw variable (or converting something else > using as.raw) as the input, and providing both text and binary > read/write modes (using the same conventions for text mode as a file > connection would). It *should* support seek, at least in binary > mode. I was trying to reuse as much of the textConnection semantics and underlying code as possible... Having a rawConnection() entry point is simple enough. Seeking also seems straightforward. I'm not so sure about using as.raw(). I wondered about that, but also thought that rather than coercing to raw, it might make more sense to cast atomic vector types to raw, byte-for-byte. Can you given an example of where a text-mode raw connection would be a useful thing? -- Dave __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
