Dan,
I don't know why, but something is off in the recent R-devel build for ppc. The
result is that the installed binary ppc is older than the other ones, so it
doesn't have paste0 while the others do.
The really strange thing is that the build logs show success, but the build
directory is old
On 12/15/2011 03:40 PM, Martin Morgan wrote:
In
> R.version.string
[1] "R Under development (unstable) (2011-12-15 r57901)"
PkgA promotes 'unique' to a generic and exports that
DESCRIPTION:
Imports: methods
R/f.R:
setGeneric("unique")
NAMESPACE:
export(unique)
and PkgB creates and exports
In
> R.version.string
[1] "R Under development (unstable) (2011-12-15 r57901)"
PkgA promotes 'unique' to a generic and exports that
DESCRIPTION:
Imports: methods
R/f.R:
setGeneric("unique")
NAMESPACE:
export(unique)
and PkgB creates and exports a method on unique
DESCRIPTION
In
> R.version.string
[1] "R Under development (unstable) (2011-12-15 r57901)"
section 1.6.6 of 'Writing R Extensions' says
Note that exporting methods on a generic in the namespace will
also export the generic, and exporting a generic in the
namespace will also export its methods.
and
Hi Duncan,
On 11-12-14 03:57 AM, Duncan Murdoch wrote:
On 11-12-13 6:41 PM, Hervé Pagès wrote:
Hi Duncan,
On 11-12-10 05:27 AM, Duncan Murdoch wrote:
On 11-12-09 4:41 PM, Hervé Pagès wrote:
Hi Duncan,
On 11-12-09 11:39 AM, Duncan Murdoch wrote:
On 09/12/2011 1:40 PM, Hervé Pagès wrote:
Hi
When I try and start R-devel as follows:
R --vanilla --arch ppc
I see this, over and over again, ^C does not interrupt it and I have
to close the terminal window:
> Error in paste0(prefix, conditionMessage(e), "\n") :
not a BUILTIN function
In addition: Warning message:
An unusual circumstance
If it is only in the Suggests and you test for its existence before its
usage, it should be OK.
For old R versions my CRAN checks set the nvironment variable:
_R_CHECK_FORCE_SUGGESTS_=FALSE
Best,
Uwe Ligges
On 15.12.2011 19:53, Roebuck,Paul L wrote:
How should the Suggests entry be written
How should the Suggests entry be written in this case?
Have package that supports parallel processing available
for multiple R versions. Original package DESCRIPTION
Suggests entry only listed 'multicore' and life was good.
Since R-2.14+ includes 'parallel' package, thought I could
reference that
> I put the header in the /include. Was that right?
>Probably not. I would expect something like /usr/local/include, and maybe a
-I option to make sure it was >found before the Solaris-supplied one. Does
make install (for iconv) not do that for you?
Wow! Thanks! That was it! I checked out /us
Why not use package.skeleton() to construct empty help files?
But if you're determined to change the function names instead, grep and sed are
very useful tools for that sort of thing. (The OS versions, not the R grep()).
Sarah
On Thu, Dec 15, 2011 at 7:01 AM, Nicola Sturaro Sommacal
wrote:
> Hi
Use namespaces and only export the functions at the user level. The
rest will be hidden in the namespace and doesn't require a help page.
See 'Package Namespaces' in the manual Writing R Extensions.
Cheers
On Thu, Dec 15, 2011 at 1:01 PM, Nicola Sturaro Sommacal
wrote:
> Hi!
>
> I am building a
Nicola Sturaro Sommacal nicolasturaro.com> writes:
>
> Hi!
>
> I am building a package. This package will not submitted to CRAN.
>
> I write the help files for the most important functions of my package, I
> cannot write it for all functions. This may sounds strange, but so there!
>
> I know
> peter dalgaard
> on Thu, 15 Dec 2011 11:40:23 +0100 writes:
> On Dec 15, 2011, at 02:51 , Hervé Pagès wrote:
>> Hi Peter,
>>
>> On 11-12-14 08:19 AM, peter dalgaard wrote:
>>>
>>> On Dec 14, 2011, at 16:19 , John C Nash wrote:
>>>
F
Hi!
I am building a package. This package will not submitted to CRAN.
I write the help files for the most important functions of my package, I
cannot write it for all functions. This may sounds strange, but so there!
I know that all user-level functions should be documented, so I have to
move my
On Dec 15, 2011, at 02:51 , Hervé Pagès wrote:
> Hi Peter,
>
> On 11-12-14 08:19 AM, peter dalgaard wrote:
>>
>> On Dec 14, 2011, at 16:19 , John C Nash wrote:
>>
>>>
>>> Following this thread, I wondered why nobody tried cumsum to see where the
>>> integer
>>> overflow occurs. On the shorte
15 matches
Mail list logo
