Hello Ryan,
You may be interested in the function sclapply(...) located in the
HTSeqGenie package. sclapply is a multicore dispatcher that accepts 3 main
arguments (inext, fun, max.parallel.jobs). The data produced by the
function inext, executed in the main thread, is dispatched to fun(),
On 10/02/2013 11:58 AM, Gregoire Pau wrote:
Hello Ryan,
You may be interested in the function sclapply(...) located in the
HTSeqGenie package. sclapply is a multicore dispatcher that accepts 3 main
arguments (inext, fun, max.parallel.jobs). The data produced by the
function inext, executed in
I saw something like this.
x - 5183
print(x, digits=20)
[1] 5183
as.character(x)
[1] 5.18e+15
I thought it was because, when x is numeric, as.character(x) represents x
rounded to 15 significant digits.
print(signif(x, 15), digits=20)
[1] 5180.
I've had reports lately about segfaults in the rgl package. I've only
been able to reproduce these on Linux. I am not so familiar with C++
details, so I have a couple of questions way down below. But first some
background info.
One recipe to recreate the crash works with a new version
A quick addition:
If I add
#define Shape rglShape
near the top of my Shape.hpp header file, the bug goes away. But I
can't believe that would be necessary. These are in separate packages,
don't they have separate namespaces in C++? How can I avoid clashes
with types declared in other
Le 02/10/13 17:05, Duncan Murdoch a écrit :
A quick addition:
If I add
#define Shape rglShape
near the top of my Shape.hpp header file, the bug goes away. But I
can't believe that would be necessary. These are in separate packages,
don't they have separate namespaces in C++? How can I
In C++, everything goes in the global namespace unless the programmer
explicitly creates one. So when you dynamically load two dynamic shared
libraries with a Shape object they clash.
The solution here is to put
namespace rgl {
...
}
around your class definitions in the rglm package, and
On 2 October 2013 at 15:45, Martyn Plummer wrote:
| In C++, everything goes in the global namespace unless the programmer
| explicitly creates one. So when you dynamically load two dynamic shared
| libraries with a Shape object they clash.
|
| The solution here is to put
|
| namespace rgl {
|
Thanks Dirk, Martyn and Romain. I'm planning to do a temporary
workaround release with the Shape class renamed to rglShape, but over
the longer term I'll put everything that's supposed to be local inside
an rgl namespace. First I need to learn how namespaces interact with
extern C
Duncan,
extern C just means that the function(s) below it have C calling
conventions, so that .Call, .External, ... can find them. Without this,
your function names would be c++ mangled to disambiguate different
overloads.
What is inside can use namespace without any issue. You'd have
On Wed, Oct 02, 2013 at 11:05:19AM -0400, Duncan Murdoch wrote:
Up to entry #4 this all looks normal. If I go into that stack frame, I
see this:
(gdb) up
#4 Shape::~Shape (this=0x15f8760, __in_chrg=optimized out) at
Shape.cpp:13
warning: Source file is more recent than executable.
On 02/10/2013 4:01 PM, Ross Boylan wrote:
On Wed, Oct 02, 2013 at 11:05:19AM -0400, Duncan Murdoch wrote:
Up to entry #4 this all looks normal. If I go into that stack frame, I
see this:
(gdb) up
#4 Shape::~Shape (this=0x15f8760, __in_chrg=optimized out) at
Shape.cpp:13
warning:
Le 02/10/13 22:15, Duncan Murdoch a écrit :
On 02/10/2013 4:01 PM, Ross Boylan wrote:
On Wed, Oct 02, 2013 at 11:05:19AM -0400, Duncan Murdoch wrote:
Up to entry #4 this all looks normal. If I go into that stack
frame, I
see this:
(gdb) up
#4 Shape::~Shape (this=0x15f8760,
On Wed, 2013-10-02 at 16:15 -0400, Duncan Murdoch wrote:
On 02/10/2013 4:01 PM, Ross Boylan wrote:
On Wed, Oct 02, 2013 at 11:05:19AM -0400, Duncan Murdoch wrote:
Up to entry #4 this all looks normal. If I go into that stack frame, I
see this:
(gdb) up
#4
On 13-10-02 4:26 PM, Romain Francois wrote:
Le 02/10/13 22:15, Duncan Murdoch a écrit :
On 02/10/2013 4:01 PM, Ross Boylan wrote:
On Wed, Oct 02, 2013 at 11:05:19AM -0400, Duncan Murdoch wrote:
Up to entry #4 this all looks normal. If I go into that stack
frame, I
see this:
(gdb) up
On 13-10-02 4:37 PM, Ross Boylan wrote:
On Wed, 2013-10-02 at 16:15 -0400, Duncan Murdoch wrote:
On 02/10/2013 4:01 PM, Ross Boylan wrote:
On Wed, Oct 02, 2013 at 11:05:19AM -0400, Duncan Murdoch wrote:
Up to entry #4 this all looks normal. If I go into that stack frame, I
see this:
In Section 1.4.2 of Writing R Extensions
%\VignetteEngine{knitr::knitr}
should be
%\VignetteEngine{knitr::knit}
sessionInfo()
R version 3.0.2 (2013-09-25)
Platform: x86_64-apple-darwin10.8.0 (64-bit)
Is this sort of thing best reported here, or is a huge report in order?
John
The double colon :: can be confusing here, but the R-exts manual is
actually correct. :: does not imply anything about the package
namespace; it is merely a separator. The vignette engines are written
in the form package::engine, and the engine name _happens_ to be
knitr as well in this case.
Can anyone explain what I'm missing here?
max(pp1 - package_version(c(0.9911.3,1.0.4,1.0.5)))
## [1] ‘1.0.4’
max(pp2 - package_version(c(1.0.3,1.0.4,1.0.5)))
## [1] ‘1.0.5’
I've looked at ?package_version , to no avail.
Since max() goes to .Primitive(max)
I'm having trouble figuring
19 matches
Mail list logo
