I've posted an MRE at https://github.com/klutometis/roxygen/issues/362.
The issue occurs when a function and an S4 generic have the same name;
I imagine this is fairly uncommon? Wouldn't the function be masked by
the S4 generic and effectively be invisible after the package was
loaded?
On Thu, Ju
On Thursday, July 30, 2015, Duncan Murdoch wrote:
> On 30/07/2015 9:14 PM, Duncan Murdoch wrote:
> > On 30/07/2015 8:49 PM, Glenn Schultz wrote:
> >> Hi All,
> >>
> >> I have a package stable and working. Now, I am trying to consolidate
> some functions that share similar inputs. Example below.
On 30/07/2015 9:14 PM, Duncan Murdoch wrote:
> On 30/07/2015 8:49 PM, Glenn Schultz wrote:
>> Hi All,
>>
>> I have a package stable and working. Now, I am trying to consolidate some
>> functions that share similar inputs. Example below. So, I branched on
>> github and work with the branch but
On 30/07/2015 8:49 PM, Glenn Schultz wrote:
> Hi All,
>
> I have a package stable and working. Now, I am trying to consolidate some
> functions that share similar inputs. Example below. So, I branched on
> github and work with the branch but now when I run the R check in studio I
> get the f
Hi All,
I have a package stable and working. Now, I am trying to consolidate some
functions that share similar inputs. Example below. So, I branched on github
and work with the branch but now when I run the R check in studio I get the
following warning:
* checking Rd \usage sections ... WA
On 30 July 2015 at 17:42, Russell Almond wrote:
| Thanks for the suggestion. I do have a configure script (that is what
| is reading the --with-netica arg) but I didn't think about searching the
| standard install locations. I can probably use that to work around this
| problem.
|
| However,
Thanks for the suggestion. I do have a configure script (that is what
is reading the --with-netica arg) but I didn't think about searching the
standard install locations. I can probably use that to work around this
problem.
However, that doesn't completely solve the problem. If I want to fo
Besides what Duncan said, relying on user to supply arguments is pretty bad
as it more or less guarantees _any_ automated test will not succeed (for lack
of involvement of the sage user).
Writing configure scripts feels like yet another painful step, but it really
is not that hard if you know a l
On 30/07/2015 4:52 PM, Russell Almond wrote:
> The behavior changed somewhere along the line.
If you don't want to spend the time to answer a simple question like
"when did you see that?", why do you expect others to spend time solving
your problem?
Duncan Murdoch
I think it is related to
> th
The behavior changed somewhere along the line. I think it is related to
the version bump from 3.1 to 3.2, but it could have been earlier.
It used to be when I wanted to release a version of my package I would run:
INSTALL
check
build
INSTALL --build (on each of a Windows and Mac box).
to crea
On 30/07/2015 2:53 PM, Russell Almond wrote:
>
> I've got a package that uses C code to link R to a third-party library.
>
> I've set up my configure script to take an argument --with-netica
> which passes the location of the library, header files, &c.
>
> So I can install the package using:
>
I've got a package that uses C code to link R to a third-party library.
I've set up my configure script to take an argument --with-netica
which passes the location of the library, header files, &c.
So I can install the package using:
$ R CMD INSTALL RNetica
--configure-args='--with-netica=/h
12 matches
Mail list logo
