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 tr
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.
>
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 Maind
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:
(g
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 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
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=0x15f876
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=) at
>> Shape.cpp:13
>> warning:
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=) at
>> Shape.cpp:13
>> warning: Source file is more recent than executable.
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 some
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" declarati
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 {
|
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
us
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 avoid
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 pack
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 5.0-
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.
17 matches
Mail list logo
