What you are reporting as missing would be *forwards* compatibility, and
of an unstated representation (dump? save?) of objects of class
"data.frame", not the object data.frame() itself.
The correct terminology is 'a data frame', not 'the data.frame' (which
means something different).
No one h
On Wed, 11 Apr 2007, Vivek Rao wrote:
>
> --- Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
>
>> On Wed, 11 Apr 2007, Vivek Rao wrote:
>
>
>
>> Note that currently we expect only Fortran 77 to be used in R and
>> (preferably) its packages, as there still are users with a Fortran 77
>> compiler a
--- Hin-Tak Leung <[EMAIL PROTECTED]>
wrote:
> (2) g77, gfortran are not the only fortran compilers
> out there!
> "...it is standard Fortran 90 and is supported by
> g77", is just not
> good enough - what do you mean by "...also conforms
> to later standards"?
> Some piece of code is either fo
--- Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
> On Wed, 11 Apr 2007, Vivek Rao wrote:
> Note that currently we expect only Fortran 77 to be
> used in R and
> (preferably) its packages, as there still are users
> with a Fortran 77
> compiler and nothing later. One major group are
> those
It would appear that printing the error message to stderr() is what is
causing the build to fail; replace
try(stop('err'))
with
cat('Error in try(stop("err")) : err\n', file = stderr())
and I get the same failure.
Best,
luke
On Wed, 11 Apr 2007, Martin Morgan wrote:
> A vign
A vignette in /inst/doc with
\documentclass[]{article}
\begin{document}
<>=
try(stop('err'))
@
\end{document}
produces an error with R CMD build :
...
** building package indices ...
* DONE (testPkg)
* creating vignettes ... ERROR
Error in try(stop("err")) : err
This is not seen with Sweave al
Prof Brian Ripley wrote:
> This is a configurable option 'R_check_force_suggests' documented in
> 'Writing R Extensions'.
Thanks for pointing this to me. I tried "R-2.5 CMD check --help" but was not
very successful with it...
>
> This package should be using Enhances: Rmpi, it seems.
Yep this s
Paul Gilbert wrote:
> Peter Dalgaard wrote:
>
>
>> Well, there's make check-all...
>>
> Ok, this is what I should be running. It reports
>
> running tests of LAPACK-based functions
> make[3]: Entering directory `/home/mfa/gilp/toolchain/R/src/R-beta/tests'
> running code in 'lapa
I'd like to be able to access unexported functions in the testing code
for a package with a namespace. I know that one way to do this is to
use the ":::" operator, but I'd prefer to avoid cluttering up my testing
code with lots of repetitions of "myPackageName:::".
One way I found to do this w
Peter Dalgaard wrote:
> Well, there's make check-all...
Ok, this is what I should be running. It reports
running tests of LAPACK-based functions
make[3]: Entering directory `/home/mfa/gilp/toolchain/R/src/R-beta/tests'
running code in 'lapack.R' ...make[3]: *** [lapack.Rout] Error 1
make
Paul Gilbert wrote:
> Prof Brian Ripley wrote:
>
>> On Wed, 11 Apr 2007, Paul Gilbert wrote:
>>
>>> Hmmm. It is a bit disconcerting that make check passes and I can get
>>> a fairly seriously wrong answer. Perhaps this test could be added to
>>> make check.
>>>
>> Well, you have l
> "PaulG" == Paul Gilbert <[EMAIL PROTECTED]>
> on Wed, 11 Apr 2007 10:51:22 -0400 writes:
PaulG> Hmmm. It is a bit disconcerting that make check passes and I can
get a
PaulG> fairly seriously wrong answer. Perhaps this test could be added to
make
PaulG> check.
Yes.
Prof Brian Ripley wrote:
> On Wed, 11 Apr 2007, Paul Gilbert wrote:
>> Hmmm. It is a bit disconcerting that make check passes and I can get
>> a fairly seriously wrong answer. Perhaps this test could be added to
>> make check.
> Well, you have learnt something new about software engineering! 'm
On Wed, 11 Apr 2007, Paul Gilbert wrote:
Hmmm. It is a bit disconcerting that make check passes and I can get a
fairly seriously wrong answer. Perhaps this test could be added to make
check.
Well, you have learnt something new about software engineering! 'make
check' is supposed to test th
Hmmm. It is a bit disconcerting that make check passes and I can get a
fairly seriously wrong answer. Perhaps this test could be added to make
check. Whether or not the one answer is correct may be questionable, but
there is no question that
prod(eigen(z, symmetric = FALSE, only.values = TRU
A further improvement to apropos() would be to sort the output.
Currently, the output of apropos is in the order found on the search
list and this will rarely be useful to the user.
All that is needed is a sort(x) at the end of the function.
+ seth
--
Seth Falcon | Computational Biology | Fred
Hi Vivek,
> "Vivek" == Vivek Rao <[EMAIL PROTECTED]>
> on Wed, 11 Apr 2007 06:20:21 -0700 (PDT) writes:
Vivek> I have some comments on the Fortran code in the
Vivek> fseries package in file 4A-GarchModelling.f ,
this is "fSeries" {and case does matter in R - contrary to Fortr
I am not familiar with fseries, nor the other routines you
mentioned, but can I make a few points:
(1) A good part of R's fortran code are "borrowed" from elsewhere.
When one is "borrowing", it is customary to keep deviation minimum
and strictly necessary i.e. bug-fixes only, and no re-indentation
On Wed, 11 Apr 2007, Vivek Rao wrote:
> I have some comments on the Fortran code in the
> fseries package in file 4A-GarchModelling.f ,
> especially the subroutine GARCHFIT and function
> DSNORM.
> I appended the code to the end of an earlier message,
> but it was rejected by some rule. Let me fir
I have some comments on the Fortran code in the
fseries package in file 4A-GarchModelling.f ,
especially the subroutine GARCHFIT and function
DSNORM.
I appended the code to the end of an earlier message,
but it was rejected by some rule. Let me first say
that I am grateful that packages for financi
I have some comments on the Fortran code in the
fseries package in file 4A-GarchModelling.f ,
especially the subroutine GARCHFIT and function
DSNORM.
I appended the code to the end of an earlier message,
but it was rejected by some rule. Let me first say
that I am grateful that packages for financi
Dear all,
For my package "ref" I have implemented extensive regression testing. It now
fails to compile since primitives "dim" and "dimnames" (and their assignment
methods) no longer allow for additional arguments. I was using an additional
argument "ref" with several methods. For "].refdata" i
Your aggressive tone would be inacceptable even if your comments were
relevant.
What's more they are not.
The point here is that under Windows it is very likely that fortran
compiled code is not being properly loaded unless g77 is used, and that
is.loaded() would trigger the dynamic loading. I
I've also tried
on Redhat EL4(x86_64) [but with /usr/local/.. gcc/gfortran 4.1.1]
and FC6 (ix86 & x86_64)
and Ubuntu dapper (x86_64)
and never got the wrong results.
> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]>
> on Wed, 11 Apr 2007 07:43:38 +0100 (BST) write
All the systems I tried this on give the 'correct' answer, including
x86_64 Linux, FC5 (gcc 4.1.1)
i686 Linux, FC5
ix86 Windows (both gcc 3.4.5 and gcc pre-4.3.0)
Sparc Solaris, with gcc3, gcc4 and SunPro compilers.
Mainly with R 2.5.0 beta, some with R-devel (where the code is unchanged).
We h
25 matches
Mail list logo
