Rtools43 is bleeding edge, and it is possible I was working with a stale
version.
On Tue, May 30, 2023 at 3:25 PM Dominick Samperi
wrote:
> Thanks for the feedback. I don't remember making such mods, and I am using
> the latest Rcpp, but to be safe I reinstalled Rtools43 and R 4.
; #> month 04
>> #> day21
>> #> svn rev84292
>> #> language R
>> #> version.string R version 4.3.0 (2023-04-21 ucrt)
>> #> nickname Already Tomorrow
>> packageVersion("Rcpp")
>> #> [1] &#x
Looks like the recent update to R 4.3 broke Rcpp::sourceCpp.
Here is a simple example...
library(Rcpp)
Rcpp::sourceCpp(code='
#include
using namespace Rcpp;
// [[Rcpp::export()]]
SEXP cpptest(NumericVector v) {
return v;
}'
)
cpptest(1:5)
This works without problems under R 4.2.3,
re you use RInside (see Win32 documentation). You may want
> to to have a look at src/gnuwin32/front-ends in R.
>
> Cheers,
> Simon
>
>
> > On Feb 4, 2023, at 2:02 PM, Dominick Samperi
> wrote:
> >
> > I'm sorry to say that the RInline::repl() issues
I'm sorry to say that the RInline::repl() issues are not resolved, and to
resolve them would likely require help from R core.
Here's the test case:
library(sphereplot)
rgl.sphgrid(longtype="D")
Under Linux there is no problem, a sphere is drawn, and you can
rotate with mouse motions.
Under Windo
Since I am not aware of an R-internals mailing list, and since this
question is related to the behavior of RInside::repl(), perhaps this is the
appropriate place to post this question.
The function Rstd_ReadConsole() in src/unix/sys-std.c results in the
user command being echoed when R_Interactive
ently implemented using R_ReplDLLinit()
and R_ReplDLLdo1() is implemented instead by calling run_Rmainloop().
There is a comment in main.c noting that R_ReplDLLdo1()
can get out of sync, so it is not suitable for use as part
of the API.
Dominick
On Thu, Jan 26, 2023 at 2:26 PM Dominick Samperi
Dominick
except that RInline::repl() often terminates
immediately after a plot(0,0) command. This happens about 10% of the time.
On Wed, Jan 25, 2023 at 9:14 AM Dominick Samperi
wrote:
> Just today I simply started R in a CMD window (no Rcpp/RInside), and a new
> window po
this is a bug or a side-effect of a virus infection.
Dominick
On Mon, Jan 23, 2023 at 8:38 PM Dominick Samperi
wrote:
> The problems I have reported have three possible causes, individually, or
> in combination. Feedback from experts on this might help.
>
> 1. Changes to R int
inick
On Mon, Jan 23, 2023 at 1:43 PM Dirk Eddelbuettel wrote:
>
> Maintainer of affected package here:
>
> On 23 January 2023 at 12:20, Dominick Samperi wrote:
> | On the changes for R 4.2.0, it is not clear how to distinguish
> | R API functions from R internal funct
MSVC for this purpose should understand that they are completely
on their own, as you say. There may be some advantages to testing
with MSVC given its good support for the newer runtime UCRT.
Dominick
On Mon, Jan 23, 2023 at 4:38 AM Tomas Kalibera
wrote:
>
> On 1/21/23 16:53, Domin
Video Studio, which I am using for
debugging. I had some problems with gdb.
Dominick
On Fri, Jan 20, 2023 at 7:56 PM Dirk Eddelbuettel wrote:
>
> On 20 January 2023 at 19:11, Dominick Samperi wrote:
> | You are right Dirk, RInside overrides what is specified because the
>
Under
Linux the confirmation message appears.
The current status is that the example seems to work using R-devel,
but not using R-4.2.2.
Dominick
On Fri, Jan 20, 2023 at 1:40 PM Dominick Samperi
wrote:
> As I said, everything is fine using R-devel, so R_LIBS just took care of a
emove' was spurious as I suspected
> all
> along but it was trickily hiding the actual issue. Any clever thought on
> how
> we could check for missing .libPaths() etc when RInside starts?
>
> On 20 January 2023 at 17:22, Tomas Kalibera wrote:
> | On 1/20/23 16:35, Do
t happen,
but I haven't been able
to build with modified R source to find out why.
Dominick
On Fri, Jan 20, 2023 at 4:28 AM Tomas Kalibera
wrote:
> On 1/20/23 02:40, Dirk Eddelbuettel wrote:
> > On 19 January 2023 at 19:41, Dominick Samperi wrote:
> > | I narrowed the probl
quared away an Rcpp release or two ago so as a first
> step please make sure _all_ involved packaes are current with CRAN and
> rebuilt.
>
> On 17 January 2023 at 21:15, Dominick Samperi wrote:
> | I think I found a problem under Windows with the repl code from RInside.
> |
Hello,
I think I found a problem under Windows with the repl code from RInside.
The problem appears if I simply compile the code in
RInside/inst/examples/standard using the Makefile.win there,
after a few hacks to deal with spaces in file names and the direction of
slashes.
The problem appears wi
Forcing source install of the latest versions of Rcpp and RInside is
required
under MacOS. By default MacOS installs binary versions of the latest
versions, 1.0.7 and 0.2.16, resp., and a simple repl app seg faults.
It appears that there is a problem with the current binary distribution
under
MacO
Hello Dirk,
I have what appears to be a reproducible example of the
"Rcpp_precious_remove"
problem that a few people have complained about. It is reproducible on my
Mac Mini, but may not appear when you try because it is OS and compiler
dependent. There is no problem under Windows, for example. Th
I forgot to mention, this testing was done using R 4.1.1, Rcpp 1.0.7, and
RInside 0.2.16, using MacOS version 10.15.7 (Catalina), and Apple clang
version 12.0.0.
On Fri, Oct 1, 2021 at 9:50 PM Dominick Samperi wrote:
> Hello Dirk,
>
> I have what appears to be a reproducible examp
Hello Dirk,
I have what appears to be a reproducible example of the
"Rcpp_precious_remove"
problem that a few people have complained about. It is reproducible on my
Mac Mini, but may not appears when you try because it is OS and compiler
dependent. There is no problem under Windows, for example. T
Is this really the important thing? Seems like -g0 saves disk space, not memory?
(Loading the symbols into a debugger may require lots of memory, but that
is not the issue here.)
Header-only C++ packages require the compiler to effectively process one
huge source file instead of a bunch of smaller
Correction: my assumption was not completely wrong. RcppOctave works
now with a minor tweak (.Call('octave_end') before terminating R). So
cleaning up the Mac OS X environment did indeed fix this issue.
On Fri, Nov 1, 2013 at 4:24 PM, Dominick Samperi wrote:
> I assumed inc
c libraries … this could of course be caused
> by “older tools” like the llvm-gcc4.2 “laying” around…. though locate does
> not find them….
>
>
>
> On 01 Nov 2013, at 20:33, Dominick Samperi wrote:
>
> > My original attempt to update to Mavericks failed (unrelated hardware
headerpad_max_install_names” lets the
> compileAttributes function do its work without any exception. My next guess
> is: possibly the gettext library…
>
> Best
>
> Simon
>
> On 01 Nov 2013, at 19:20, Dominick Samperi wrote:
>
> > In your original post you menti
most of us. I thought about using the
> xcrun —find gcc/g++ etc. to get what is needed in a Makevars but this does
> not give anything so far.
>
>
> On 01 Nov 2013, at 17:50, Dominick Samperi wrote:
>
> > With Apple moving from gcc/g++ to LLVM/clang++ I guess it makes sen
tools" under Windows...
On Fri, Nov 1, 2013 at 12:12 PM, Simon Zehnder wrote:
> Hi Dominick,
>
> I did install files from brew but instead used the gcc from
> http://hpc.sourceforge.net
>
>
> On 01 Nov 2013, at 16:55, Dominick Samperi wrote:
>
> > If you depe
If you depend on tools installed using brew, you might want to try
removing those that were installed before the Mavericks update,
using:
rm -rf /usr/local/Cellar
brew prune
brew doctor
brew install
On Fri, Nov 1, 2013 at 11:19 AM, Simon Zehnder wrote:
> Point landing J.J.!
>
> I already compi
Apple is rapidly moving away from gcc/g++ towards clang/clang++,
resulting in some tricky versioning issues. I tried to update to
Mavericks but had to backtrack due to technical problems (Paragon
NTFS filesystem support fails).
After reinstalling Mac OS X 10.8 and installing R for Mac OS I found
t
Hello Romain,
I tested Rcpp11 under Mac OS (10.8.5) using Apple's
clang-500.2.75 (Xcode 5), and also under Linux. Here are
some results:
1. The recommended install method
devtools::install_github("romainfrancois/Rcpp11")
did not work. The problem seems to be that it looks at
hadley's
et it you've got to "tap"
> their science repository by following the instructions here:
>
> https://github.com/Homebrew/homebrew-science
>
> I had forgotten that I added those a while ago, so thanks again Dominick!
>
> -steve
>
> On Thu, Oct 10, 2013 at 12:44 PM, S
for Apple
changes and deprecated features. See, for example:
http://wiki.octave.org/Octave_for_Mac
On Thu, Oct 10, 2013 at 1:01 AM, Dominick Samperi wrote:
> It appears that there is some conflict between Rcpp and Octave under
> Mac OS X that doesn't depend on the design of RcppOctave.
It appears that there is some conflict between Rcpp and Octave under
Mac OS X that doesn't depend on the design of RcppOctave. Just
drop the files strtest.cpp and Makevars (attached) into Rcpp/src and
run R CMD INSTALL Rcpp. This leads to a memory error. The file
strtest.cpp was stripped out of rcp
e on their Windows machine. On my box I am getting
> strange errors when checking about not being able to read the DESCRIPTION
> file... very weird.
>
> Bests,
> Renaud
>
>
>
>
> On 8 October 2013 15:47, Dominick Samperi wrote:
>
>> I just installed the bin
s, and the linker removes the multiple defs and
does not
complain about multiple definitions. This does not seem to be necessary with
meta-linking.
On Tue, Oct 8, 2013 at 11:30 AM, Romain Francois
wrote:
> Le 08/10/13 17:12, Dominick Samperi a écrit :
>
> That is interesting Roma
making a library and non portably link against it) it is not
> likely to happen.
>
> Romain
>
> Le 08/10/13 15:47, Dominick Samperi a écrit :
>
>> I just installed the binary with Rtools not on my path (but with R in
>> PATH)
>> and the first time I tried to loa
ath specified. Most users will use the binary and not build it from source
> (which requires Rtools and possibly more config.
>
> Did you try installing the binary directly from the repo (with only octave
> bin/ in the path, not Rtools nor R)?
>
> Renaud
>
>
> On Monday, O
p://web.cbio.uct.ac.za/~renaud/CRAN'))
> library(RcppOctave)
> .O$rand()
>
> Note that this version (0.10.1) was linked against the .dll.a files, but
> will load the .dll files... I will try later to link against the .dll files
> as you suggested.
>
> Bests,
> Renaud
&
Hello Renaud,
Here is a summary of my testing results.
1. Your binary and source distribution is currently setup to use DLL's
instead
of static libs. This is tricky to do under Windows, and this is why Rcpp
provides a static lib to link against. You may want to consider using
the same
I sent you an overly complicated reply. Take a look
at R/include/R_ext/Arith.h where REAL_NA is defined...
On Mon, Feb 7, 2011 at 5:33 PM, Dominick Samperi wrote:
> R has its own way of representing NA's. See, for example, the fts
> package at CRAN,
> in particular, the file s
R has its own way of representing NA's. See, for example, the fts
package at CRAN,
in particular, the file src/tslib/tslib/utils/numeric.traits.hpp.
Dominick
On Mon, Feb 7, 2011 at 5:23 PM, WEI ZHANG wrote:
> I would like to know how can I pass NA from C++ to R.
>
> For example, for any integer
On Sat, Feb 5, 2011 at 9:52 AM, Douglas Bates wrote:
> As Dirk and Romain know I have been struggling to debug a memory
> protection problem that I encounter in code based on Rcpp Modules. As
> with all memory protection problems, it is very difficult to track
> down and I have kind-of run out of
On Sun, Jan 30, 2011 at 4:47 PM, Douglas Bates wrote:
> As the Grateful Dead said, "What a long, strange trip it's been." I
> have spent over a month trying to debug some code in the lme4a package
> that uses Rcpp modules. Partly I was getting the wrong numerical
> answer, which was due to a dum
R_LATER is defined should probably be unconditionally
ifdef-ed out.
Dominick
>
> Romain
>
> Le 25/01/11 02:58, Dominick Samperi a écrit :
>>
>> I reported a problem in another thread that I thought only surfaced
>> under Windows,
>> but I was wrong (see Su
I reported a problem in another thread that I thought only surfaced
under Windows,
but I was wrong (see Subject line). The problem also appears under GCC 4.5+,
and it appears that somebody already noticed problems with this version of GCC
and introduced the compiler define IS_GCC_450_OR_LATER to na
2011 at 4:46 PM, Dominick Samperi wrote:
> Opps, I was too quick to declare victory here. That warning about
> temporary reference initialization is not innocuous: crashes still
> occur under VC++ (even with the updated RcppCommon.h) but
> it is difficult to predict when they will
.
The question that remains unanswered is: is this a quirk of
VC++ or is the warning something that applies more generally?
Dominick
On Tue, Jan 18, 2011 at 4:18 PM, Dominick Samperi wrote:
> To finish up this thread, it turns out that the VC++ problems did
> help to reveal an architecture-dep
ier has since been redefined to apply to
ints (and long ints) only, and "%Lf" is intended for use
with 'long double' type.
Dominick
On Sun, Jan 16, 2011 at 3:34 PM, Dominick Samperi wrote:
> It appears that this is a matter of compiler interpretation of the C++
>
15, 2011 at 10:55 PM, Dominick Samperi wrote:
> Romain,
>
> I found a work-around for the VC++ problem. All I have to do
> is make sure the code that is currently ifdef-ed in Extractor.h
> is NOT enabled under VC++ (when _MSC_VER is defined).
> Currently this code is conditionally compi
related low-level issues.
Thanks,
Dominick
On Sat, Jan 15, 2011 at 2:27 PM, Dominick Samperi wrote:
> So that there is no confusion, I should add that the problems that I report
> here do not occur under Linux/g++ or under MinGW/g++ (the supported
> environments), where Rcpp/sugar seems to
So that there is no confusion, I should add that the problems that I report
here do not occur under Linux/g++ or under MinGW/g++ (the supported
environments), where Rcpp/sugar seems to work fine.
On Sat, Jan 15, 2011 at 1:23 PM, Dominick Samperi wrote:
>
>
> On Sat, Jan 15, 2011 a
On Sat, Jan 15, 2011 at 4:15 AM, Romain Francois
wrote:
> Le 13/01/11 16:29, Dominick Samperi a écrit :
>
> The template expression code is very interesting, but it
>> does not work as expected under
>> Windows/g++/MinGW/32bit/Rterm.exe. The problem
>> does not appear
The template expression code is very interesting, but it
does not work as expected under
Windows/g++/MinGW/32bit/Rterm.exe. The problem
does not appear when I use Rgui.exe, or if I use
64bit Windows!
Consider the following C++ code called using
.Call('testsugar',1:5,1:5):
RcppExport SEXP testsuga
On Tue, Jan 11, 2011 at 2:41 PM, Romain Francois
wrote:
> Le 11/01/11 19:57, Romain Francois a écrit :
>
> Le 11/01/11 19:46, Douglas Bates a écrit :
>>
>>> On Tue, Jan 11, 2011 at 12:27 PM, Dominick
>>> Samperi wrote:
>>>
>>>>
>>&
On Tue, Jan 11, 2011 at 1:20 PM, Romain Francois
wrote:
> Le 11/01/11 19:12, Davor Cubranic a écrit :
>
> I think an important point from Doug has been lost in the subsequent
>> 20-odd messages of flamebombing:
>>
>> I do not see this as compatible with the C++ Design principle we use
where
On Mon, Jan 10, 2011 at 3:59 PM, Dirk Eddelbuettel wrote:
>
> On 10 January 2011 at 15:39, Dominick Samperi wrote:
> |
> |
> | On Mon, Jan 10, 2011 at 3:18 PM, Dirk Eddelbuettel
> wrote:
> |
> |
> | On 10 January 2011 at 14:55, Dominick Samperi wrote:
> |
On Mon, Jan 10, 2011 at 3:18 PM, Dirk Eddelbuettel wrote:
>
> On 10 January 2011 at 14:55, Dominick Samperi wrote:
> | For those who may be tempted to release "free software," this is an
> | illustration of the greatest hazard. Imagine seeing your prior work
> | &quo
On Mon, Jan 10, 2011 at 2:11 PM, Dirk Eddelbuettel wrote:
>
> On 10 January 2011 at 13:30, Dominick Samperi wrote:
> | Is the fix that I proposed and that was confirmed by the three of us a
> dream?
>
> A 'fix'? Where is posting a ten-liner that exhibits a perceiv
On Mon, Jan 10, 2011 at 12:02 PM, Dirk Eddelbuettel wrote:
>
> On 10 January 2011 at 11:36, Dominick Samperi wrote:
> |
> |
> | On Mon, Jan 10, 2011 at 11:09 AM, Dirk Eddelbuettel
> wrote:
> |
> |
> | On 10 January 2011 at 11:04, Dominick Samperi wrote:
> |
On Mon, Jan 10, 2011 at 11:09 AM, Dirk Eddelbuettel wrote:
>
> On 10 January 2011 at 11:04, Dominick Samperi wrote:
> | On Mon, Jan 10, 2011 at 10:32 AM, Dirk Eddelbuettel
> wrote:
> | We (somewhat breathlessly) await your patches.
> |
> | I already submitted a clear
On Mon, Jan 10, 2011 at 10:32 AM, Dirk Eddelbuettel wrote:
>
> On 10 January 2011 at 10:10, Dominick Samperi wrote:
> |
> |
> | On Sun, Jan 9, 2011 at 1:52 PM, Dirk Eddelbuettel
> wrote:
> |
> |
> | On 9 January 2011 at 12:41, Douglas Bates wrote:
> | | I&#
On Sun, Jan 9, 2011 at 1:52 PM, Dirk Eddelbuettel wrote:
>
> On 9 January 2011 at 12:41, Douglas Bates wrote:
> | I'm sorry to say that I will need to abandon the debugging of this.
> |
> | I have converted the code in Rcpp/R/exceptions.R to using a R
> | functions with a common environment to ke
On Sun, Jan 9, 2011 at 1:07 PM, Dirk Eddelbuettel wrote:
>
> On 9 January 2011 at 12:12, Dominick Samperi wrote:
> | Actually, the problem seems to be pretty transparent, and the
> | solution is the same (see below). This gets you through Evaluator,
> | but you fail in SlotProxy
On Sun, Jan 9, 2011 at 9:21 AM, Dominick Samperi wrote:
>
>
> On Sun, Jan 9, 2011 at 8:02 AM, Douglas Bates wrote:
>
>> On Sun, Jan 9, 2011 at 12:45 AM, Dominick Samperi
>> wrote:
>> > Doug,
>> >
>> > I think the problem is resolved. I w
On Sun, Jan 9, 2011 at 8:02 AM, Douglas Bates wrote:
> On Sun, Jan 9, 2011 at 12:45 AM, Dominick Samperi
> wrote:
> > Doug,
> >
> > I think the problem is resolved. I wasted a lot of time trying to debug
> the
> > new
> > Module code, and didn't think
Dominick Samperi
> wrote:
> >
> >
> > On Sat, Jan 8, 2011 at 9:48 AM, Douglas Bates
> wrote:
> >>
> >> On Sat, Jan 8, 2011 at 7:49 AM, Douglas Bates
> wrote:
> >> > On Sat, Jan 8, 2011 at 12:45 AM, Dominick Samperi <
> djsamp...@gm
Let's focus on problem solving, not (you know what I want to say).
On Sat, Jan 8, 2011 at 2:40 PM, Dirk Eddelbuettel wrote:
>
> On 8 January 2011 at 14:19, Dominick Samperi wrote:
> | Gabor brought up the topic of Promises a few days ago and it
>
> There is absolutely no re
On Sat, Jan 8, 2011 at 2:06 PM, Douglas Bates wrote:
> On Sat, Jan 8, 2011 at 12:57 PM, Dominick Samperi
> wrote:
> >
> >
> > On Sat, Jan 8, 2011 at 9:48 AM, Douglas Bates
> wrote:
> >>
> >> On Sat, Jan 8, 2011 at 7:49 AM, Douglas Bates
&g
On Sat, Jan 8, 2011 at 9:48 AM, Douglas Bates wrote:
> On Sat, Jan 8, 2011 at 7:49 AM, Douglas Bates wrote:
> > On Sat, Jan 8, 2011 at 12:45 AM, Dominick Samperi
> wrote:
> >> I checked things under Linux and Windows (using GCC and VC++ DLL's) and
> the
> &g
I checked things under Linux and Windows (using GCC and VC++ DLL's) and the
same problem occurs at the same place, which is a good sign when it comes to
memory issues. Basically, the Rcpp::Reference(std::string) constructor that
is
part of S4_field, or S4_CppOverloadedMethods constructors fails, de
The Module function in Module.R is mysterious because it is not clear from
the code itself or from the docs that the second argument can be a DLLInfo,
yet that is what appears in your example. Also, this function is re-entered
for the same object, with different logic each time. When the module
par
On Sat, Dec 25, 2010 at 4:08 PM, Gabor Grothendieck wrote:
> On Sat, Dec 25, 2010 at 3:58 PM, Dominick Samperi
> wrote:
> > Using .Call appears to force the promise:
> >
> > msg="old"
> > delayedAssign("x",msg)
> > msg="new"
&g
Using .Call appears to force the promise:
msg="old"
delayedAssign("x",msg)
msg="new"
.Call('sexpType',x) # promise triggered here, returns 16
msg="even newer" # will not change already fired promise
.Call('sexpType',x) # returns 16
y = x
y # "new" (not "even newer")
Here's sexpType:
RcppExport S
The Module function documentation does not say anything about specifying
the DLL directly, as in:
mod = Module("Foo", dyn.load('mylib.so'))
instead of
mod = Module("Foo", PACKAGE="mypack").
But the first variant works, and it is not clear from the code in Module.R
why it does. Is this an undocumen
, Dominick Samperi wrote:
> On Fri, Dec 17, 2010 at 12:37 PM, Romain Francois <
> rom...@r-enthusiasts.com> wrote:
>
>> Le 17/12/10 01:28, Dominick Samperi a écrit :
>>
>> Hello,
>>>
>>> I managed to create a new plugin by copy/paste
On Fri, Dec 17, 2010 at 12:37 PM, Romain Francois
wrote:
> Le 17/12/10 01:28, Dominick Samperi a écrit :
>
> Hello,
>>
>> I managed to create a new plugin by copy/paste/adapt
>> Rcpp.plugin.maker. Is there a better way?
>>
>> Thanks,
>> Dominick
>&
In the process of migrating from the classic API I have
found what appears to be a problem with Rcpp::Datetime.
There is no unit test for this situation.
Rcpp::Datetime dt("2015-04-15 06:00:00")
and
Rcpp::Datetime dt("2015-04-15 06:00:00.0")
both fail due to a type conversion error.
Here is the o
Hello,
I managed to create a new plugin by copy/paste/adapt
Rcpp.plugin.maker. Is there a better way?
Thanks,
Dominick
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-d
Class('C++Class')
etc.
And the modules defined by the client package seem to work fine.
Thus it appears that the fact that Rcpp exports the necessary
classes and the client package runs library(Rcpp) is enough.
But perhaps there are situations where this will not work...
Thanks,
This works without the importClassFrom() directive.
On Wed, Dec 8, 2010 at 1:55 PM, Dominick Samperi wrote:
> I have a question about the modules vignette.
>
> At the end it says client packages must importClassesFrom(...),
> and there are comments about using .onLoad() as well.
>
I have a question about the modules vignette.
At the end it says client packages must importClassesFrom(...),
and there are comments about using .onLoad() as well.
But before reading this I already implemented the use of
modules in another (client) package without using these
constructions. They
On Sat, Dec 4, 2010 at 3:22 PM, Dirk Eddelbuettel wrote:
>
> On 4 December 2010 at 15:04, Dominick Samperi wrote:
> | getYear() method adds 1900 when it shouldn't, so 2001 becoms 3901,
> | for example.
>
> Confirmed:
>
> R> require(inline, quiet=TRUE, warn=FALS
Since RcppDate (classic class) is moving out of Rcpp I'm trying
to use Rcpp::Date and there seems to be a small problem.
getYear() method adds 1900 when it shouldn't, so 2001 becoms 3901,
for example.
I assume that Rcpp::Date and Rcpp::Datetime are intended to be
replacements for RcppDate and Rcp
Romain,
On the proposal to release the Classic Rcpp API as a separate
package can you please say a few words about how packages
that make use of these classic features (as well as the newer
features of Rcpp) can make the transition?
When do you plan to release this change?
How may people out the
gt;
> Regards,
>
> Romain
>
>
>
>
> $ grep -R Samperi * | grep -v .svn
> DESCRIPTION: 'classic Rcpp API' was written during 2005 and 2006 by
> Dominick Samperi.
> debian/copyright:R / C++ interface package. Rcpp was written by Dominick
> Samperi,
> debi
(to
the delight of many readers I am sure).
Sorry for the inconvenience,
Dominick
>
>
>
> On Sat, Dec 4, 2010 at 7:49 AM, Dominick Samperi
> wrote:
> > Dirk,
> >
> > Please let me know whether or not you will comply with my request to
> remove
> > refere
Dirk,
Please let me know whether or not you will comply with my request to remove
references to my name in Rcpp (except copyright notices).
Thanks,
Dominick
On Thu, Dec 2, 2010 at 6:28 PM, Dominick Samperi wrote:
>
>
> On Thu, Dec 2, 2010 at 5:58 PM, Dirk Eddelbuettel wrote:
>
On Tue, Nov 30, 2010 at 3:20 PM, Dirk Eddelbuettel wrote:
>
> The Rcpp (and RInside) documentation attempts to make it clear that the set
> of supported compilers is definied by R Core via the support in R and its
> tools.
>
> Rcpp is first and foremost an extension package for R, it does not liv
On Thu, Dec 2, 2010 at 6:43 PM, Joris Meys wrote:
> On Fri, Dec 3, 2010 at 12:38 AM, Dominick Samperi
> wrote:
>
> > We? Romain did not arrive on the scene until after November of 2009.
> >
> > To live outside the law you must be honest --- Bob Dylan.
> >
>
On Thu, Dec 2, 2010 at 5:58 PM, Dirk Eddelbuettel wrote:
>
> On 2 December 2010 at 17:23, Dominick Samperi wrote:
> | OK, since you are so accomodating, then please remove all reference to
> | my name from Rcpp as I do not want to be subject to arbitrary revisions
> of
> | my
On Thu, Dec 2, 2010 at 5:58 PM, Dirk Eddelbuettel wrote:
>
> On 2 December 2010 at 17:23, Dominick Samperi wrote:
> | OK, since you are so accomodating, then please remove all reference to
> | my name from Rcpp as I do not want to be subject to arbitrary revisions
> of
> | my
anch", not sure what else to call it). The one constant in all of
this is Rcpp the C++ library.
On Thu, Dec 2, 2010 at 5:23 PM, Dominick Samperi wrote:
>
>
> On Thu, Dec 2, 2010 at 4:35 PM, Dirk Eddelbuettel wrote:
>
>>
>> There are repeated claims concerning a "Rc
On Thu, Dec 2, 2010 at 4:35 PM, Dirk Eddelbuettel wrote:
>
> There are repeated claims concerning a "Rcpp fork". Let's address both
> terms
> in turn.
>
> i) Rcpp was used in November 2008 as the name for a re-launch of a package
>which had seen releases on CRAN in 2005/2006 during which it
On Thu, Dec 2, 2010 at 2:47 PM, Romain Francois wrote:
> Le 02/12/10 20:34, Dominick Samperi a écrit :
>
>> On Thu, Dec 2, 2010 at 2:31 PM, Andrew Redd > <mailto:amr...@gmail.com>> wrote:
>>
>>That exposes the data3 class, but does not solve the poi
On Thu, Dec 2, 2010 at 2:31 PM, Andrew Redd wrote:
> That exposes the data3 class, but does not solve the pointer problem.
Add a default contructor.
>
>
> On Thu, Dec 2, 2010 at 12:24 PM, Romain Francois > wrote:
>
>> Le 02/12/10 20:05, Andrew Redd a écrit :
>>
>> I updated to the new Rcpp
On Thu, Dec 2, 2010 at 10:47 AM, Joris Meys wrote:
> On Thu, Dec 2, 2010 at 4:31 PM, Dominick Samperi
> wrote:
> >
> > Worst yet is having to compete with your own work.
> >
> About which competition are we talking then? I'm sorry, but the vast
> majority of
proverbial
>> bus and their software dies with them.
>>
>
> Somewhere close to the worst is that no one every uses your software.
>
Worst yet is having to compete with your own work.
> Martyn
>>
>> On Wed, 2010-12-01 at 13:21 -0500, Dominick Samperi wrote:
two of my original post.
Dominick
>
> On Wed, 2010-12-01 at 13:21 -0500, Dominick Samperi wrote:
> > This post asks members of the R community, users and developers,
> > to comment on issues related to the GNU Public License
> > and R community policies more generally.
&
On Thu, Dec 2, 2010 at 2:51 AM, Gavin Simpson wrote:
> On Wed, 2010-12-01 at 20:24 -0500, Dominick Samperi wrote:
>
> > > Just to be clear I have never used the package and am not truly
> > > commenting on this particular case but only the general ideas in this
>
>> have a good memory so I don't need another reminder email on this topic.
>>
>> I'm sure there are other projects that you can work on, alone or with
>> collaborators, that would benefit the R community.
>>
>> Cheers, Adrian
>>
>>
>>
&g
1 - 100 of 158 matches
Mail list logo
