Re: [Rd] Listing Packages in Depends or Imports
On Fri, Jun 27, 2014 at 3:00 AM, Dario Strbenac wrote: > Hello, > > The Writing R Extensions manual gives confusing advice. Compare > > Packages listed in imports or importFrom directives in the NAMESPACE file > should almost always be in ‘Imports’ and not ‘Depends’. > > with > > Almost always packages mentioned in ‘Depends’ should also be imported from in > the NAMESPACE file Why is that confusing? Its perfectly logical. First line says that packages imported in the NAMESPACE should usually be in "Imports" in the DESCRIPTION. It implies there are special cases when "Depends" may be correctly used. Second line is that packages that are listed as Depends in DESCRIPTION should usually be imported in the NAMESPACE file, but implies there may be exceptions - you might correctly have a "Depends" that doesn't have an import in the NAMESPACE. In themselves, those two statements are perfectly logical and consistent. As an attempt to explain **when** you'd put a reference in Depends or Imports or why you'd use one of those get-out exceptions, it makes no claims! Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Need help on calling Head from C
> >The code is actually not safe. Both "install" and "SalarLogical/Integer"
> >potentially allocate memory, so at least one needs to be protected before
> >callling lang3. (Passing one such argument would be OK, since lang3
> >protects its arguments, but it doesn't get a chance to do that while they
> >are still being evaluated.)
>
> How true but who can blame him? The Writing R Extensions manual
> contains the same mistake:
>
> SEXP mkans(double x)
> {
> SEXP ans;
> ans = PROTECT(allocVector(REALSXP, 1));
> REAL(ans)[0] = x;
> UNPROTECT(1);
> return ans;
> }
>
> double feval(double x, SEXP f, SEXP rho)
> {
> defineVar(install("x"), mkans(x), rho);
> return REAL(eval(f, rho))[0];
> }
A further comment on this... Currently, symbols are never garbage
collected, so you might think the above is OK, since the result
of install("x") can't be lost wen mkans(x) is called. However, I
think it's not a good idea to rely on symbols never being collected.
In any case, though, even if you are relying on that, the code isn't
safe because C doesn't specify the order of evaluation of argments,
so mkans(x) might be called before install("x").
One should also note that the PROTECT within mkans is unnecessary,
and must surely be confusing to anyone who thought (correctly)
that they had understood what PROTECT is for.
Radford Neal
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Listing Packages in Depends or Imports
On 27.06.2014 04:00, Dario Strbenac wrote: Hello, The Writing R Extensions manual gives confusing advice. Compare Packages listed in imports or importFrom directives in the NAMESPACE file should almost always be in ‘Imports’ and not ‘Depends’. with Almost always packages mentioned in ‘Depends’ should also be imported from in the NAMESPACE file Right. In the DESCRIPTION file, you should try to be in "Imports" only, but even you have to declare in "Depends", you still need to import with appropriate directives in the NAMESPACE file. Best, Uwe Ligges -- Dario Strbenac PhD Student University of Sydney Camperdown NSW 2050 Australia __ 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] blas test problem
dear developers I myself am not a prog-devel, I found this http://devgurus.amd.com/message/1255852#1255852 Most R compilations/installations I use seem to fail this test, is this a problem and if yes then how serious is it? regards __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD SHLIB failure (Win7 64-bit OS)
Dear all,
I am struggling to get the 'Rtools' tool chain to successfully build .dlls
using the "R CMD SHLIB" method on my home Win7 64-bit (Ultimate) PC.
Strangely I did get it working on my work PC (also Win7 64-bit but
Enterprise) so I am totally at a loss as to what to do.
When I type, "R CMD SHLIB foo.c" using the Command Prompt I get:
make: *** No rule to make target 'foo.o', needed by 'foo.dll'. Stop.
Warning message:
running command 'make -f "C:/R/R-3.1.0/etc/x64/Makeconf" -f
"C:/R/R-3.1.0/share/make/winshlib.mk" SHLIB="filename.dll" WIN=64 TCLBIN=64
OBJECTS="filename.o"' has status 2
NB: I am using R-3.1.0 and the most current Rtools suitable for R-3.1.0 as
directed.
To clarify, I installed R-3.1.0 (64-bit) on "C:\R\R-3.1.0". I installed
Rtools to "C:\R\Rtools". I have placed these at the front of my PATH as
directed as well.
Here is my path:
PATH=C:\R\Rtools\bin;C:\R\Rtools\gcc-4.6.3\bin;C:\R\R-3.1.0\bin\x64;C:\Progr
am Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files
(x86)\Intel\iCLS Client\;C:\Program
Files\Intel\iCLS
Client\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\S
ystem32\WindowsPowerShell\v1.0\;C:\Windows\System32\WindowsPowerShell\v1.0\;
C:
\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program
Files\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files
(x86)\Intel\Intel(R)
Management Engine Components\DAL;C:\Program Files (x86)\Intel\Intel(R)
Management Engine Components\IPT;C:\Program Files\MiKTeX
2.9\miktex\bin\x64\;C:\SDE\TDM-GCC-64\bin;C:
\Anaconda;C:\Anaconda\Scripts;C:\Program
Files\MATLAB\R2013b\runtime\win64;C:\Program Files\MATLAB\R2013b\bin
There does not seem to be any spaces which might cause an issue.
Strangely, if I type: "R --version" at the Command Prompt I get the usual
notice saying I have R version 3.1.0 (2014-04-10)
If I type: "R CMD config CC" I get:
gcc -m64
If I type: "R CMD config CFLAGS" I get:
-O2 -Wall -std=gnu99 -mtune=core2
If I manually type in:
gcc -m64 -I"C:/R/R-3.1.0/include" -O2 -Wall -std=gnu99 -mtune=core2 -c
-o
gcc -m64 -shared -s -static-libgcc -o
-LC:/R/R-3.1.0/bin/x64 -lR
I do get a .dll file which does work in R using dynload("filename.dll"), so
I am wondering if it might be related to the "Makeconf" file?
As another test, if I type in R:
library(devtools)
has_deve()
I get:
make: *** No rule to make target `foo.o', needed by `foo.dll'. Stop.
Warning message:
running command 'make -f "C:/R/R-3.1.0/etc/x64/Makeconf" -f
"C:/R/R-3.1.0/share/make/winshlib.mk" SHLIB="foo.dll" WIN=64 TCLBIN=64
OBJECTS="foo.o"' had status 2
Error: Command failed (1)
I would greatly appreciate any suggestions on how I could get this to work
or what I am doing wrong.
Many thanks,
Luke
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Need help on calling Head from C
On 06/27/2014 02:23 AM, Radford Neal wrote:
The code is actually not safe. Both "install" and "SalarLogical/Integer"
potentially allocate memory, so at least one needs to be protected before
callling lang3. (Passing one such argument would be OK, since lang3
protects its arguments, but it doesn't get a chance to do that while they
are still being evaluated.)
How true but who can blame him? The Writing R Extensions manual
contains the same mistake:
SEXP mkans(double x)
{
SEXP ans;
ans = PROTECT(allocVector(REALSXP, 1));
REAL(ans)[0] = x;
UNPROTECT(1);
return ans;
}
double feval(double x, SEXP f, SEXP rho)
{
defineVar(install("x"), mkans(x), rho);
return REAL(eval(f, rho))[0];
}
A further comment on this... Currently, symbols are never garbage
collected, so you might think the above is OK, since the result
of install("x") can't be lost wen mkans(x) is called. However, I
think it's not a good idea to rely on symbols never being collected.
In any case, though, even if you are relying on that, the code isn't
safe because C doesn't specify the order of evaluation of argments,
so mkans(x) might be called before install("x").
One should also note that the PROTECT within mkans is unnecessary,
and must surely be confusing to anyone who thought (correctly)
that they had understood what PROTECT is for.
I understand what PROTECT is for and I don't find the PROTECT in mkans
confusing.
Maybe it's not necessary now. But it's so much simpler/safer to just
systematically protect any freshly allocated SEXP. One day
someone might need to modify mkans(), say, add a call to warning() or
Rprintf() after the call to allocVector(), and will most likely forget
to add the PROTECT/UNPROTECT that will then become necessary. So at
least there should be a comment next to the allocVector() call in
mkans() to explain why in this particular case the returned value
doesn't need to be protected (but writing the comment probably takes
as much time as doing the PROTECT/UNPROTECT anyway).
Even now, why should I rely on the fact that the REAL() macro doesn't
allocate memory and will never do so?
So with systematic protection:
SEXP mkans(double x)
{
SEXP ans;
PROTECT(ans = allocVector(REALSXP, 1));
REAL(ans)[0] = x;
UNPROTECT(1);
return ans;
}
double feval(double x, SEXP f, SEXP rho)
{
SEXP symbol, value;
PROTECT(symbol = install("x"));
PROTECT(value = mkans(x));
defineVar(symbol, value, rho);
UNPROTECT(2);
return(REAL(eval(f, rho))[0]);
}
I doubt you'll ever be able to detect any difference in terms of speed
or memory usage because the cost of PROTECT/UNPROTECT is virtually 0.
Furthermore, one could imagine a static code checker would be able to
verify this and warn me about missing PROTECTs.
BTW I appreciate the work you're doing on pqR and hopefully more of the
stuff you've done will get merged into R at some point.
Cheers,
H.
Radford Neal
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fhcrc.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] using 2D array of SEXP for creating dataframe
Thanks a lot . Appreciate your time . I am sorry for missing snippets of
the code , trying to copy back and forth . My bad .sorry for that .
The dataframe df is to be of VECSXP .
PROTECT(df = allocVector(VECSXP,2));
What I am trying to do ?
Lets say you read a huge table , with each column is different datatype
some integer , some real,some string , some raw . And you have to return a
dataframe after reading it . So what I did lets create a array of SEXP (
SEXP dataframevalues[noOfCols] ) . Now from table each column is read and
also the datatype is obtained. I allocate each array with number of values
to be inserted .
Now there is one outer vector of type VECSXP , which will hold the
dataframe[noOfCols] . So VECSXP is of length noOfCols.
. After that a R internal call is performed to convert it to a data frame
format .
And yes , i want to set for column Names, not row names.
Thanks,
On Thu, Jun 26, 2014 at 6:35 PM, Hervé Pagès wrote:
> On 06/26/2014 05:18 PM, Sandip Nandi wrote:
>
>> Hi ,
>>
>> I have asked a question , whether the data structure I am using to
>> create a dataframe is fine or there is anyother way i can use. My aim is
>> to read a database and write it to dataframe and do operation on it .
>> The dataframe creation ,output everything works . The code I put is
>> wrong , trying to adding pieces and do it ,sorry for that.I feel my
>> way of doing , creating a 2D array may not be the best, so if someone
>> can point out any drawback of my method will be great . My code in
>> production can read 100k rows and write in 15 seconds . But one case ,
>> when I try to assign NA_REAL to a real vector it causes floating point
>> exception. So I doubt something is not wrong . People may be doing
>> faster,efficient way.
>>
>>
> Please understand that the code you send is useful for the discussion
> only if we can understand it. And for this it needs to make sense.
> The code below still makes little sense. Did you try it? For example
> you're calling SET_VECTOR_ELT() and setAttrib() on an SEXP ('df') that
> you didn't even allocate. Sounds maybe like a detail but because of
> that the code will segfault and, more importantly, it's not clear what
> kind of SEXP you want 'df' to be.
>
> Also the following line makes no sense:
>
> setAttrib(df,R_RowNamesSymbol,lsnm);
>
> given that 'lsnm' is c("int", "string") so it looks more like the col
> names than the row names (and also because you're apparently trying to
> make a 3x2 data.frame, not a 2x2).
>
> Anyway, once you realize that a data.frame is just a list with 3
> attributes:
>
> > attributes(data.frame(int=c(99,89,12), string=c("aa", "vv", "gy")))
> $names
> [1] "int""string"
>
> $row.names
> [1] 1 2 3
>
> $class
> [1] "data.frame"
>
> everything becomes simple at the C level i.e. just make that list
> and stick these 3 attributes on it. You don't need to call R code
> from C (which BTW will protect you from random changes in the behavior
> of the data.frame() constructor). You don't need the intermediate
> 'valueVector' data structure (what you seem to be referring to as the
> "2D array of SEXP", don't know why, doesn't look like a 2D array to me,
> but you never explained).
>
> Cheers,
> H.
>
>
> This is a sample code
>> */**
>> *
>> *
>> *dfm is a dataframe which i assume as list of list . So I created a SEXP
>>
>> array valueVector[2] where each one can hold different datatype . Now
>> values are assigned and dataframe is generated at end*
>> *
>> *
>> **/*
>>
>>
>> SEXP formDF() {
>>
>> SEXP dfm ,head,df , dfint , dfStr,lsnm;
>> SEXP valueVector[2];
>> char *ab[3] = {"aa","vv","gy"};
>> int sn[3] ={99,89,12};
>> char *listnames[2] = {"int","string"};
>> int i,j;
>>
>>
>> PROTECT(valueVector[0] = allocVector(REALSXP,3));
>> PROTECT(valueVector[1] = allocVector(STRSXP,3));
>> PROTECT(lsnm = allocVector(STRSXP,2));
>>
>> SET_STRING_ELT(lsnm,0,mkChar("int"));
>> SET_STRING_ELT(lsnm,1,mkChar("string"));
>>
>> for ( i = 0 ; i < 3; i++ ) {
>> SET_STRING_ELT(valueVector[1],i,mkChar(ab[i]));
>> REAL(valueVector[0])[i] = sn[i];
>> }
>>
>>
>> SET_VECTOR_ELT(df,1,valueVector[0]);
>> SET_VECTOR_ELT(df,0,valueVector[1]);
>> setAttrib(df,R_RowNamesSymbol,lsnm);
>>
>> PROTECT(dfm=lang3(install("data.frame"),df,ScalarLogical(FALSE)));
>> SET_TAG(CDDR(dfm), install("stringsAsFactors")) ;
>> SEXP res = PROTECT(eval(dfm,R_GlobalEnv));
>>
>> UNPROTECT(7);
>> return res;
>>
>> }
>>
>>
>> On Thu, Jun 26, 2014 at 4:52 PM, Hervé Pagès > > wrote:
>>
>> Hi Sandip,
>>
>>
>> On 06/26/2014 04:21 PM, Sandip Nandi wrote:
>>
>> Hi ,
>>
>> I have put incomplete code here . The complete code works , My
>> doubt is
>> , what I am doing logical/safe ? Any memory leak going to happen
>> ? is
>> there any way to create dataframe ?
>>
>>
>> I still don't believe it "works". It doesn't even compile. More
>> below...
>>
>>
>>
>>
>>
>> SEXP formDF()
Re: [Rd] Need help on calling Head from C
> >> SEXP mkans(double x)
> >> {
> >> SEXP ans;
> >> ans = PROTECT(allocVector(REALSXP, 1));
> >> REAL(ans)[0] = x;
> >> UNPROTECT(1);
> >> return ans;
> >> }
> >One should also note that the PROTECT within mkans is unnecessary,
> >and must surely be confusing to anyone who thought (correctly)
> >that they had understood what PROTECT is for.
>
> I understand what PROTECT is for and I don't find the PROTECT in mkans
> confusing.
>
> Maybe it's not necessary now. But it's so much simpler/safer to just
> systematically protect any freshly allocated SEXP. One day
> someone might need to modify mkans(), say, add a call to warning() or
> Rprintf() after the call to allocVector(), and will most likely forget
> to add the PROTECT/UNPROTECT that will then become necessary.
There's certainly something to be said in favour of the "better safe
than sorry" approach to using PROTECT. But in the context of a tutorial,
one shouldn't put one in that's unnecessary without a comment saying,
"not needed at the moment, but would be if code that allocates more
memory is added later, so let's be safe and do it now too". Otherwise,
the reader may infer an incorrect model of when to PROTECT, such as
"you should PROTECT every allocated object, then UNPROTECT at the end of
the procedure - do that and you'll be OK". Of course, that's not
enough to be OK. And to illustrate the correct model, one needs some
negative examples as well as positive examples.
Radford Neal
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Listing Packages in Depends or Imports
Hello, What I meant was that the second rule implies that Depends packages should be in the NAMESPACE file, but the first rule implies that packages in the NAMESPACE file should not be in the Depends field, but Imports field. It would be a logical contradiction if it wasn't preceded by "almost always". -- Dario Strbenac PhD Student University of Sydney Camperdown NSW 2050 Australia __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] user defined macros in Rd files
Hi Duncan,
Thanks a lot for eventually implementing this and making the Rd world
greener! https://github.com/wch/r-source/commit/ff3ea81ae87
Regards,
Yihui
--
Yihui Xie
Web: http://yihui.name
On Wed, Oct 9, 2013 at 3:55 PM, Duncan Murdoch wrote:
> On 13-10-09 4:34 PM, Yihui Xie wrote:
>>
>> +1. As an example, there are 91 instances of \newcommand{\CRANpkg} in
>> R source, and this number is still growing as I see:
>>
>> $ grep "newcommand{CRANpkg}" -r . | wc
>> 91 91 10317
>>
>
> So you're saying if I ever get around to doing this, I'll have to track down
> 91+ files to make use of it? This sounds like an argument why someone else
> should do it. ;-)
>
> Duncan Murdoch
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check warning with S3 method
Hi Duncan, Again, thanks a lot for making this change (help requests are tried over all loaded instead of attached packages): https://github.com/wch/r-source/commit/21d2f7430b4 This makes what I proposed last time possible now: if pkg B imports FUN from A and re-exports it, ?FUN will work after B is attached because A will also be at least attached. Then it will be perfect if `R CMD check` can stop warning against the missing documentation, which is not really missing. Regards, Yihui -- Yihui Xie Web: http://yihui.name On Fri, Jun 20, 2014 at 1:34 AM, Yihui Xie wrote: > but note that you will have to document it even if it is a function > imported from another package... Perhaps help() should be intelligent > enough to link the documentation of `FUN` from package A for package B > when B imports `FUN` from A, and exports it in B's NAMESPACE. The > package name of A may be obtained from > environmentName(environment(FUN)). At the moment, since R CMD check > will warn against the missing documentation of `FUN` in B, I have to > copy FUN.Rd from A to B in this case, which seems to be inefficient > and not a best way to maintain. Did I miss anything in the R-exts > manual? > > Regards, > Yihui > -- > Yihui Xie > Web: http://yihui.name > > > On Fri, Jun 20, 2014 at 12:19 AM, Winston Chang > wrote: >> On Thu, Jun 19, 2014 at 3:15 PM, Martyn Plummer wrote: >> >>> Export filter in the NAMESPACE file *without copying it* in the R source >>> code. >>> >>> >> Ah, it works! Thank you! >> __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
