[Rd] "note: symbols.rds is not available"

2012-03-13 Thread Ben Bolker

  I've encountered this note in checking packages with the latest
R-devel. Googling finds it only in other package checks; searching the
source tree finds in src/library/tools/R/sotools.R , but I'm not sure
what it's doing there.


'symbols.rds' shows up in the SVN log here:

r58591 | ripley | 2012-03-05 07:25:58 -0500 (Mon, 05 Mar 2012) | 1 line

treat non-symbols.rds reports on base packages differently

r58539 | ripley | 2012-03-01 04:54:39 -0500 (Thu, 01 Mar 2012) | 1 line

comment if expecting symbols.rds and not found


  Any thoughts? Is it harmless?  How would I fix the issue/suppress
the note?

  thanks
Ben Bolker

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] "note: symbols.rds is not available"

2012-03-13 Thread Uwe Ligges
This is used for checking unsave symbols in compiled code (such as 
abort, exit or printf calls). For some reason you could not generate the 
symbols and hence a note. Therefore, this does not indicate a problem 
with the package.


Uwe Ligges


On 13.03.2012 17:52, Ben Bolker wrote:


   I've encountered this note in checking packages with the latest
R-devel. Googling finds it only in other package checks; searching the
source tree finds in src/library/tools/R/sotools.R , but I'm not sure
what it's doing there.


'symbols.rds' shows up in the SVN log here:

r58591 | ripley | 2012-03-05 07:25:58 -0500 (Mon, 05 Mar 2012) | 1 line

treat non-symbols.rds reports on base packages differently

r58539 | ripley | 2012-03-01 04:54:39 -0500 (Thu, 01 Mar 2012) | 1 line

comment if expecting symbols.rds and not found


   Any thoughts? Is it harmless?  How would I fix the issue/suppress
the note?

   thanks
 Ben Bolker

__
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] 111 FIXMEs in main/src

2012-03-13 Thread Matthew Dowle
Hi,

We sometimes see offers to contribute, asking what needs to be done. If
they know C, how about the 111 FIXMEs? But which ones would be most
useful to fix? Which are difficult and which are easy? Does R-core have
a process to list and prioritise the FIXMEs?

~/R/Rtrunk/src/main$ grep "[^/]FIXME" * | wc -l
111
~/R/Rtrunk/src/main$ grep -A 1 "[^/]FIXME" *
arithmetic.c:/* FIXME: consider using
arithmetic.c-tmp = (long double)x1 - floor(q) * (long double)x2;
--
arithmetic.c:/* FIXME: with the y == 2.0 test now at the top that case
isn't
arithmetic.c-   reached here, but i have left it for someone who
understands the
--
arithmetic.c:/* FIXME: Danger Will Robinson.
arithmetic.c- * -  We might be trashing arguments here.
--
array.c:/* FIXME: the following is desirable, but pointless as long as
array.c-   subset.c & others have a contrary version that leaves the
--
attrib.c:/* FIXME:  1.e-5 should rather be == option('ts.eps') !! */
attrib.c-if (fabs(end - start - (n - 1)/frequency) > 1.e-5)
--
attrib.c:   /* FIXME : The whole "classgets" may as well die. */
attrib.c-
--
attrib.c:/* FIXME */
attrib.c-if (nvalues <= 0)
--
attrib.c:/* FIXME */
attrib.c-PROTECT(namesattr);
--
attrib.c:/* FIXME: the code below treats pair-based structures */
attrib.c-/* in a special way.  This can probably be dropped down */
--
base.c:/* FIXME: Make this a macro to avoid function call overhead?
base.c-   Inline it if you really think it matters.
--
bind.c:/* FIXME : is there another possibility? */
bind.c-
--
bind.c: /* FIXME: I'm not sure what the author intended when the
sequence was
bind.c-defined as raw < logical -- it is possible to represent
logical as
--
builtin.c:  /* FIXME -- Rstrlen allows for double-width chars */
builtin.c-  width += Rstrlen(STRING_ELT(labs, nlines % lablen), 0) 
+ 1;
--
builtin.c:/* FIXME:  call EncodeElement() for every element of
s.
builtin.c-
--
builtin.c:  /* FIXME : cat(...) should handle ANYTHING */
builtin.c-  w = strlen(p);
--
character.c:slen = strlen(ss); /* FIXME -- should handle embedded
nuls */
character.c-buf = R_AllocStringBuffer(slen+1, &cbuff);
--
character.c:   FIXME: could prefer UTF-8 here
character.c- */
--
character.c:/* FIXME: could use R_Realloc instead */
character.c-cbuf = CallocCharBuf(strlen(tmp) + 1);
--
character.c:/* FIXME use this buffer for new string as well */
character.c-wc = (wchar_t *)
--
coerce.c:/* FIXME: Use
coerce.c-   =
--
complex.c:/* FIXME: maybe add full IEC60559 support */
complex.c-static double complex clog(double complex x)
--
complex.c:/* FIXME: check/add full IEC60559 support */
complex.c-static double complex cexp(double complex x)
--
connections.c:/* FIXME: is this correct for consoles? */
connections.c-checkArity(op, args);
--
connections.c:/* FIXME: could do any MBCS locale, but would need
pushback */
connections.c-static SEXP
--
connections.c:  outlen = 1.01 * inlen + 600; /* FIXME, copied from bzip2
*/
connections.c-  buf = (unsigned char *) R_alloc(outlen, sizeof(unsigned
char));
--
datetime.c: /* FIXME some of this should be outside the loop */
datetime.c- int ns, nused = 4;
--
dcf.c:  /* FIXME:
dcf.c- Why are we doing this?
--
debug.c:/* FIXME: previous will have <0x> whereas other values
are
debug.c-   without the < > */
--
deriv.c:/* FIXME: simplify exp(lgamma( E )) = gamma( E ) */
deriv.c-ans = lang2(ExpSymbol, arg1);
--
deriv.c:/* FIXME: simplify log(gamma( E )) = lgamma( E ) */
deriv.c-ans = lang2(LogSymbol, arg1);
--
deriv.c:/* FIXME */
deriv.c-#ifdef NOTYET
--
devices.c:/*  Disable this for now */
devices.c-/*
--
devices.c:/* FIXME: There should really be a formal graphics
finaliser
devices.c- * but this is a good proxy for now.
--
devices.c:/* FIXME:  there should be a way for a device to declare
its own
devices.c-   events, and return information on how to set
them */
--
dounzip.c: filename is in UTF-8, so FIXME */
dounzip.c-  SET_STRING_ELT(names, i, mkChar(filename_inzip));
--
duplicate.c:   : surely memcpy would be faster here?
duplicate.c-*/
--
engine.c:/* FIXME: what about clipping? (if the device can't) 
engine.c-*/
--
engine.c:/* FIXME: what about clipping? (if the device can't) 
engine.c- * Maybe not too bad because it is just a matter of shaving
off
--
engine.c:   /* FIXME: This assumes that 
wchar_t is UCS-2/4,
engine.c-  since that is what 
GEMetricInfo expects */
--
engine.c:/* FIXME: should we warn on more than one character here? */
engine.c-int GEstring_to_pch(SEXP pch)
--
envir.c:  FIXME ? should this also