On 01/23/2015 06:22 PM, Michael Lawrence wrote:
Here is a quote from Brian's email to CRAN maintainers:
The set of make programs in use for R is shifting (BSD make seems to
be no longer in use by Apple or FreeBSD; dmake and pmake variants are
appearing) and we have taken the POSIX
Here is a quote from Brian's email to CRAN maintainers:
The set of make programs in use for R is shifting (BSD make seems to
be no longer in use by Apple or FreeBSD; dmake and pmake variants are
appearing) and we have taken the POSIX standard as the baseline for
portability.
---
On Fri, Jan 23, 2015 at 5:18 PM, Dan Tenenbaum wrote:
>
>
> - Original Message -
>> From: "Kevin Ushey"
>> To: "Laurent Gatto"
>> Cc: "bioc-devel"
>> Sent: Friday, January 23, 2015 4:58:40 PM
>> Subject: Re: [Bioc-devel] portable make syntax
>>
>> If I understand correctly, all versions
I have found and fixed the affected initialize cases and will begin
checking in fixes.
Affected packages: RDAVIDWebService, flowCore (as we know), Gviz,
ChIPseqR, Pviz, VanillaICE, flowFit.
As an aside, in all of these cases, initialize is implementing logic
that really belongs in a constructor f
- Original Message -
> From: "Kevin Ushey"
> To: "Laurent Gatto"
> Cc: "bioc-devel"
> Sent: Friday, January 23, 2015 4:58:40 PM
> Subject: Re: [Bioc-devel] portable make syntax
>
> If I understand correctly, all versions of `make` on the BioC build
> systems will support GNU extension
If I understand correctly, all versions of `make` on the BioC build
systems will support GNU extensions to Makefiles, and so it's probably
not worth your time to make this 'portable' -- just add the
SystemRequirements bit.
However, you could work around this by (following R-exts at
http://cran.r-p
Dear all,
I have been using the following in various vignettes/Makefile
ifeq (${R_HOME},)
R_HOME= $(shell R RHOME)
endif
This syntax is GNU specific and now results in warnings when checking
the package:
* checking for GNU extensions in Makefiles ... WARNING
Found the following file(s) contain
That's right.
On Fri, Jan 23, 2015 at 12:22 PM, Mike wrote:
> Sorry, I just want to clarify some more on this.(maybe useful for others as
> well)
> What you actually mean is callNextMethod() used to drop both ... and the
> other arguments explicitly supplied from the parent call (in my case,
> pa
On Fri, Jan 23, 2015 at 1:58 PM, Dan Tenenbaum wrote:
> However, you should consider using Rlecuyer as it has no external
> dependencies (see Levi's post to this thread). Then your package should build
> on windows.
I think so too - it's also a standard solution in R, implemented
natively in r-
Sorry, I just want to clarify some more on this.(maybe useful for others
as well)
What you actually mean is callNextMethod() used to drop both |...| and
the other arguments explicitly supplied from the parent call (in my
case, |parameters| argument).
And now after your fix, both gets passed on a
The bug has existed forever. The commit log may be confusing. The
actual bug (or at least a very undesirable behavior) was in
match.call(), not callNextMethod().
I think it's still true that callNextMethod() is the natural
invocation. When adding arguments to initialize that you do not want
to pas
Michael,
Thanks for the confirmation of the issue. I see you were trying to
tackle it in the latest commits |r67467:67472| which apparently haven’t
fixed the bug yet (instead it triggers the error of the existing legacy
code in other R packages like flowCore). I can certainly change the code
t
- Original Message -
> From: "Martin Morgan"
> To: "avinash sahu" , "Steve Lianoglou"
>
> Cc: bioc-devel@r-project.org
> Sent: Friday, January 23, 2015 10:52:32 AM
> Subject: Re: [Bioc-devel] Package submission with library requirement
>
> On 01/21/2015 11:16 AM, avinash sahu wrote:
>
On 01/23/2015 10:52 AM, Michael Lawrence wrote:
First let me apologize for my failure to read emails. There was a
long-standing bug in the methods package where arguments passed as
"..." to a method would be dropped by callNextMethod(). It turns out
that in all known cases this affects calls to i
On 01/21/2015 11:16 AM, avinash sahu wrote:
Both the libraries are not thread safe. Although boost random genrator in
limited situation can be thread safe. I have tried them earlier they were
failing with multi-threading.
One way out might be, if I include the source code of ransampl with package
First let me apologize for my failure to read emails. There was a
long-standing bug in the methods package where arguments passed as
"..." to a method would be dropped by callNextMethod(). It turns out
that in all known cases this affects calls to initialize(), probably
because there are many initi
16 matches
Mail list logo
