Re: [Rd] R-Forge?
Gregor Gorjanc wrote: > I have recently found RForge.net (http://www.rforge.net/) by Simon > Urbanek and found out today that the site is accepting subscriptions. > Great! However, browsing a bit on the site I found a link to another > forge: R-Forge (http://r-forge.r-project.org/). > > Is/will the last one be the "offcial" forge for R packages, given that > it has domain r-project.org? Perhaps one is the real forge and the other is a forgery? Or a forge-R-y? I'll get my coat... Barry __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] printf capture
printf capture
Dear All,
I'm running R-2.4.1 on WindowsXP.
I wrote a small C++ DLL using Rprintf() and all works fine
dyn.load(), is.loaded('f1'), Rprintf(), .C(), all is ok.
Now, the worry :
I use also a 3rd party piece of C++ program which was not designed
for R and uses printf().
I though on sink(...) before .C('f1'), but it doesn't work.
I call sink(file="res.txt") and only the Rprintf() are catched
Is there any way to however capture those printf() outputs ?
Thanks for any hint/pointer (... and i apologize
if i missed something obvious !).
Vincent
(for what may be worth, a "minimal" stuff is at www.khi.fr/IB/rp2)
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] printf capture
If you are using Rgui (it should work under rterm) there is no C-level
'stdout' file stream (the normal state for Windows GUI programs), so no
way to capture it inside R.
On Thu, 12 Apr 2007, mel wrote:
> printf capture
>
> Dear All,
>
> I'm running R-2.4.1 on WindowsXP.
> I wrote a small C++ DLL using Rprintf() and all works fine
> dyn.load(), is.loaded('f1'), Rprintf(), .C(), all is ok.
>
> Now, the worry :
> I use also a 3rd party piece of C++ program which was not designed
> for R and uses printf().
If you have the program, can you not edit it before compiling it?
Adding
#define printf Rprintf
will probably do the trick.
> I though on sink(...) before .C('f1'), but it doesn't work.
> I call sink(file="res.txt") and only the Rprintf() are catched
>
> Is there any way to however capture those printf() outputs ?
>
> Thanks for any hint/pointer (... and i apologize
> if i missed something obvious !).
>
> Vincent
>
> (for what may be worth, a "minimal" stuff is at www.khi.fr/IB/rp2)
>
> __
> [EMAIL PROTECTED] 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
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug in Stangle(split=TRUE)
> On Sat, 07 Apr 2007 07:56:40 -0400, > Roger Peng (RP) wrote: > [I originally emailed this to Friedrich Leisch but got no response Sorry, was on easter vacation and have not fully suceeded to go through all mails in my inbox yet. > and I > just wanted to make sure it made it in before release.] > While working with Stangle(), I noticed a problem when using 'split = > TRUE'. Particularly, when there are two chunks where one chunk's name > is a prefix of another chunk's name, then the two chunks will be written > to a single file rather than two separate files (if the chunk who's name > is a prefix comes after the other chunk). Running 'Stangle(split=TRUE)' > with the attached 'test1.Rnw' file should reproduce the problem. > I think it boils down to a partial matching problem in 'RtangleRuncode'. > I've attached a patch against R-alpha (r41020) which I think fixes > this problem but I'm not sure it's necessarily the best approach (there > are other instances of this construction in the code). Same bug was also affecting Sweave. Fixed in the 2.5 and 2.6 branches, thanks a lot for the report. Best, Fritz __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build fails with try(stop()) in vignette
> On Wed, 11 Apr 2007 17:28:31 -0500 (CDT),
> Luke Tierney (LT) wrote:
> 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.
Yes, both R CMD check and R CMD build "analyse" the textual output
from running R (on examples, vigenttes, ...) to locate
problems. Reason is a chicken&egg problem: You cannot use the same R
process which runs the code to spot all problems, because it may not
survive until the point where you are able to spot the problem.
Having errors thrown in code chunks is still in many ways an open
problem in Sweave files, because it is hard to distinguish problems
the user wants to show to the reader from ones that are not deliberate
...
Best,
Fritz
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] printf capture
Prof Brian Ripley wrote:
> If you are using Rgui (it should work under rterm) there is no C-level
> 'stdout' file stream (the normal state for Windows GUI programs), so no
> way to capture it inside R.
>
> On Thu, 12 Apr 2007, mel wrote:
>
>
>> printf capture
>>
>> Dear All,
>>
>> I'm running R-2.4.1 on WindowsXP.
>> I wrote a small C++ DLL using Rprintf() and all works fine
>> dyn.load(), is.loaded('f1'), Rprintf(), .C(), all is ok.
>>
>> Now, the worry :
>> I use also a 3rd party piece of C++ program which was not designed
>> for R and uses printf().
>>
>
> If you have the program, can you not edit it before compiling it?
> Adding
>
> #define printf Rprintf
>
> will probably do the trick.
>
>
If not:
If it really is a standalone program, look into variations of system()
and shell().
If it is a DLL, you might get away with explicitly opening a file
descriptor for stdout on entry and closing it on exit. Not sure exactly
how this works, though, especially on Windows.
>> I though on sink(...) before .C('f1'), but it doesn't work.
>> I call sink(file="res.txt") and only the Rprintf() are catched
>>
>> Is there any way to however capture those printf() outputs ?
>>
>> Thanks for any hint/pointer (... and i apologize
>> if i missed something obvious !).
>>
>> Vincent
>>
>> (for what may be worth, a "minimal" stuff is at www.khi.fr/IB/rp2)
>>
>> __
>> [EMAIL PROTECTED] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
>
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build fails with try(stop()) in vignette
On Thu, 12 Apr 2007, Friedrich Leisch wrote:
>> On Wed, 11 Apr 2007 17:28:31 -0500 (CDT),
>> Luke Tierney (LT) wrote:
>
> > 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.
>
> Yes, both R CMD check and R CMD build "analyse" the textual output
> from running R (on examples, vigenttes, ...) to locate
> problems. Reason is a chicken&egg problem: You cannot use the same R
> process which runs the code to spot all problems, because it may not
> survive until the point where you are able to spot the problem.
>
> Having errors thrown in code chunks is still in many ways an open
> problem in Sweave files, because it is hard to distinguish problems
> the user wants to show to the reader from ones that are not deliberate
> ...
Just to clarify: this means for now the recommendation would be for
authors of vignettes using try() to arrange to suppress the error
message either by adding silent=TRUE to the call or setting the
show.error.messages option to FALSE?
Best,
luke
>
>
> Best,
> Fritz
>
--
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
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build fails with try(stop()) in vignette
> On Thu, 12 Apr 2007 07:35:28 -0500 (CDT),
> Luke Tierney (LT) wrote:
> On Thu, 12 Apr 2007, Friedrich Leisch wrote:
>>> On Wed, 11 Apr 2007 17:28:31 -0500 (CDT),
>>> Luke Tierney (LT) wrote:
>>
>> > 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.
>>
>> Yes, both R CMD check and R CMD build "analyse" the textual output
>> from running R (on examples, vigenttes, ...) to locate
>> problems. Reason is a chicken&egg problem: You cannot use the same R
>> process which runs the code to spot all problems, because it may not
>> survive untilthe point where you are able to spot the problem.
>>
>> Having errors thrown in code chunks is still in many ways an open
>> problem in Sweave files, because it is hard to distinguish problems
>> the user wants to show to the reader from ones that are not deliberate
>> ...
> Just to clarify: this means for now the recommendation would be for
> authors of vignettes using try() to arrange to suppress the error
> message either by adding silent=TRUE to the call or setting the
> show.error.messages option to FALSE?
Yes. We should try to get a better system, but I'm not sure what that
should be (and definetely not for 2.5).
Most of the stuff is by Kurt, so we should wait for his opinion. If
you look at the R CMD check code you will see a lot of grep's for
"^Error", so merely inserting a blank before the error message may do
the trick, but we have no means to automate that yet.
.f
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] printf capture
Prof Brian Ripley a écrit : > If you are using Rgui (it should work under rterm) yes indeed, it works under rterm > there is no C-level 'stdout' file stream (the normal state > for Windows GUI programs), so no way to capture it inside R. Aie ! (I feared this answer). Thanks however for the explanation. I was looking at pipe(), scan() etc. So, no hope from this side. > If you have the program, can you not edit it before compiling it? > Adding > #define printf Rprintf > will probably do the trick. yes thanks, I already though on that, and it works. But i would have preferred not touching this 3rd party code. = There is another little annoyance (always on WindowsXP + R-2.4.1) When including both and #include #include There is a #define ERROR redefinition #define ERROR ),error(R_problem_buf);} // this one in Rs.h #define ERROR 0// in MinGW/.../wingdi.h It's only a warning, but i would prefer to avoid it and i'm searching how to avoid it. Thanks for any idea. PS : compilation details : g++ -IJ:/softs/R-2.4.1/include -c f1.cpp -o f1.o In file included from J:/softs/R-2.4.1/include/R.h:49, from f1.cpp:11: J:/softs/R-2.4.1/include/R_ext/RS.h:40:1: warning: "ERROR" redefined In file included from f:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/windows.h:52, from f1.cpp:10: f:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/wingdi.h:313:1: warning: this is the location of the previous definition __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] printf capture
On Thu, 12 Apr 2007, mel wrote:
Prof Brian Ripley a écrit :
If you are using Rgui (it should work under rterm)
yes indeed, it works under rterm
there is no C-level 'stdout' file stream (the normal state
for Windows GUI programs), so no way to capture it inside R.
Aie ! (I feared this answer). Thanks however for the explanation.
I was looking at pipe(), scan() etc.
So, no hope from this side.
If you have the program, can you not edit it before compiling it?
Adding
#define printf Rprintf
will probably do the trick.
yes thanks, I already though on that, and it works.
But i would have preferred not touching this 3rd party code.
You can always link in a wrapper that defined printf and passes the
arguments to Rprintf.
=
There is another little annoyance (always on WindowsXP + R-2.4.1)
When including both and
#include
#include
There is a #define ERROR redefinition
#define ERROR ),error(R_problem_buf);} // this one in Rs.h
#define ERROR 0// in MinGW/.../wingdi.h
It's only a warning, but i would prefer to avoid it
and i'm searching how to avoid it.
Thanks for any idea.
It's documented in 'Writing R Extensions'.
The defines used for compatibility with @Sl{} sometimes causes
conflicts (notably with Windows headers), and the known
problematic defines can be removed by defining @code{STRICT_R_HEADERS}.
PS : compilation details :
g++ -IJ:/softs/R-2.4.1/include -c f1.cpp -o f1.o
In file included from J:/softs/R-2.4.1/include/R.h:49,
from f1.cpp:11:
J:/softs/R-2.4.1/include/R_ext/RS.h:40:1: warning: "ERROR" redefined
In file included from
f:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/windows.h:52,
from f1.cpp:10:
f:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/wingdi.h:313:1:
warning: this is the location of the previous definition
__
[EMAIL PROTECTED] 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__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Milestone: 1000 packages on CRAN as of today(?)
Hi, I was just looking at the "CRAN Daily Package Check Results" [http://cran.r-project.org/src/contrib/checkSummary.html], and realized there are 1000 packages on CRAN as of today (look at row 3 in the table below). Yet another quite extraordinary milestone in R history. Last updated on 2007-04-12 11:48:32 Results for installing and checking packages using the three current flavors of R on systems running Debian GNU/Linux testing (r-devel ix86: AMD Athlon(tm) XP 2400+ (2GHz), r-devel x86_64: Dual Core AMD Opteron(tm) Processor 280, r-prerel/r-release: Intel(R) Pentium(R) 4 CPU 2.66GHz), MacOS X 10.4.7 (iMac, Intel Core Duo 1.83GHz), and Windows Server 2003 SP2 (32-bit) (AMD Athlon64 X2 5000+). Flavor OS CPU OK WARNERROR Total 1 r-devel Linux ix86769 135 32 936 2 r-devel Linux x86_64 523 101 36 660 3 r-prerelLinux ix86816 154 30 1000 4 r-prerelMacOS_X ix86738 160 95 993 5 r-prerelWindows x86_64 787 142 36 965 6 r-release Linux ix86919 63 15 997 7 r-release Windows x86_64 908 50 19 977 Hope those WARN and ERROR packages will turn into OK before the 2.5.0 release. I've tried to do my contribution ;) While maintaining R at my previous place, I kept track on the number of package installed, which included almost all CRAN packages, except a few hard-to-install ones, plus some Bioconductor packages. This is my summary: 20020917 68, R v1.5.1 20030326 206, R v1.6.2 20030424 269, R v1.6.2 20030903 298, R v1.7.1 20031015 306, R v1.7.1 20031126 352, R v1.7.1 20040310 370, R v1.8.1 20040525 411, R v1.9.0 20041005 459, R v1.9.1 20041217 506, R v2.0.1 20060217 698, R v2.2.1 Quite a growth. Are there any "official" records like these? Cheers Henrik __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Milestone: 1000 packages on CRAN as of today(?)
The number of packages on CRAN usable with the current version of R is recorded from time to time in the file tests/internet.Rout.save. So e.g. on 2001-05-30 there were 106 and on 2004-12-27 there were 433 (rather less than you recorded) and on 2005-12-17, 647 (rather more), assuming I got the correct versions. Note that progress is not monotone: there may be 1000 packages but some are uninstallable under R 2.5.0 and are likely to be moved to the Archive. On Thu, 12 Apr 2007, Henrik Bengtsson wrote: > Hi, > > I was just looking at the "CRAN Daily Package Check Results" > [http://cran.r-project.org/src/contrib/checkSummary.html], and > realized there are 1000 packages on CRAN as of today (look at row 3 in > the table below). Yet another quite extraordinary milestone in R > history. > > Last updated on 2007-04-12 11:48:32 > > Results for installing and checking packages using the three current > flavors of R on systems running Debian GNU/Linux testing (r-devel > ix86: AMD Athlon(tm) XP 2400+ (2GHz), r-devel x86_64: Dual Core AMD > Opteron(tm) Processor 280, r-prerel/r-release: Intel(R) Pentium(R) 4 > CPU 2.66GHz), MacOS X 10.4.7 (iMac, Intel Core Duo 1.83GHz), and > Windows Server 2003 SP2 (32-bit) (AMD Athlon64 X2 5000+). > > Flavor OS CPU OK WARNERROR Total > 1 r-devel Linux ix86769 135 32 936 > 2 r-devel Linux x86_64 523 101 36 660 > 3 r-prerelLinux ix86816 154 30 1000 > 4 r-prerelMacOS_X ix86738 160 95 993 > 5 r-prerelWindows x86_64 787 142 36 965 > 6 r-release Linux ix86919 63 15 997 > 7 r-release Windows x86_64 908 50 19 977 > > Hope those WARN and ERROR packages will turn into OK before the 2.5.0 > release. I've tried to do my contribution ;) > > While maintaining R at my previous place, I kept track on the number > of package installed, which included almost all CRAN packages, except > a few hard-to-install ones, plus some Bioconductor packages. This is > my summary: > > 20020917 68, R v1.5.1 > 20030326 206, R v1.6.2 > 20030424 269, R v1.6.2 > 20030903 298, R v1.7.1 > 20031015 306, R v1.7.1 > 20031126 352, R v1.7.1 > 20040310 370, R v1.8.1 > 20040525 411, R v1.9.0 > 20041005 459, R v1.9.1 > 20041217 506, R v2.0.1 > 20060217 698, R v2.2.1 > > Quite a growth. Are there any "official" records like these? > > Cheers > > Henrik > > __ > [EMAIL PROTECTED] 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 __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package incompatibility under 2.5.0 (p lease respond directly, I am not on r-devel)
Unfortunately a claim of 'extensive regression testing' is not going to
help you if the original contains the mistake. It seems that your package
is not using these functions as they are (and always have been, AFAIK)
documented in R or the Blue and White Books.
A summary would be that new checks in R 2.5.0 have found several
long-standing incompatibilities of your code with R.
R 2.5.0 is in feature freeze, and changing the argument list of basic
functions is not something we would do lightly (and certainly not at this
late stage). In essence you are asking everyone else to change their
usage to conform to yours, since if we change these many other packages
(and R itself) will show warnings in 'R CMD check'.
There is an advantage in not having a '...' argument in generics that
Martin Maechler often points out: it means that errors in actual argument
names are caught. And these new checks have caught unintended usage
errors in other packages.
On Wed, 11 Apr 2007, Jens Oehlschlägel wrote:
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"
If you mean '[.refdata', '[' is really part of the language and documented
to allow zero or more arguments.
it still works, with "dim.refdata" no longer. Could you please allow for
additional arguments for the following generic functions (or
primitives):
dim <- function (x, ...)
UseMethod("dim")
"dim<-" <- function (x, ..., value)
UseMethod("dim<-")
dimnames <- function (x, ...)
UseMethod("dimnames")
"dimnames<-" <- function (x, ..., value)
UseMethod("dimnames<-")
row.names <- function (x, ...)
UseMethod("row.names")
"row.names<-" <- function (x, ..., value)
UseMethod("row.names<-")
names <- function (x, ...)
UseMethod("names")
"names<-" <- function (x, ..., value)
UseMethod("names<-")
BTW: why does get("dim") returns
function (x) .Primitive("dim")
and args() works on it,
while get("[") returns
.Primitive("[")
and args() doesn't work on it?
It is regarded as part of the language (like '{' and '(', which equally
are primitives). It would be unusual to apply them as functions, and
args() applies to functions.
Furthermore, until now "rownames", "colnames" have been convenience
wrappers for "dimnames". Consequently implementing "dimnames" and
"dimnames<-" would indirectly implement "rownames", "colnames" and their
assignment methods. This no longer works for classes inheriting from
"data.frame" because the assignment methods no longer work via
"dimnames<-". I can imagine that this change breaks existing code in
other packages as well - without formally throwing errors at package
check time (as I said, I have unusually strict regression testing
included in the example section, that other packages may not have).
If it is really necessary to treat data.frames differently, I'd
It is.
recommend to change "rownames" and "colnames" accordingly, in order to
have symmetry between accessor and assignment functions. That would mean
defining "names" and "row.names" and their assignment methods for any
classes inheriting from data.frame, instead of "dimnames", correct?
Maybe *all* package maintainers should be warned about this or R CMD
CHECK should check whether anyone defines "dimnames" or "dimnames<-" for
any class inheriting from "data.frame".
The documentation says (and used to say)
For a data frame, 'rownames' and
'colnames' are equivalent to 'row.names' and 'names' respectively,
but the latter are preferred (and can be much faster).
and it now works as documented.
Best regards
Jens Oehlschlägel
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
Gesendet: 08.04.07 16:50:29
An: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED],[EMAIL PROTECTED]
Betreff: Package ref_0.92.tar.gz did not pass R CMD check
Dear package maintainer,
this notification has been generated automatically.
Your package ref_0.92.tar.gz did not pass 'R CMD check' on
Windows and will be omitted from the corresponding CRAN directory
(CRAN/bin/windows/contrib/2.5/).
Please check the attached log-file and consider to resubmit a version
with increased version number that passes R CMD check on Windows.
R version 2.5.0 alpha (2007-04-05 r41063)
[...]
Error in identical(dim(rx3, ref = TRUE), dim(x)) :
2 arguments passed to 'dim' which requires 1
Execution halted
--
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__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
