On Feb 22, 2011, at 12:32 PM, Dirk Eddelbuettel wrote:
>
> On 22 February 2011 at 11:26, ken.willi...@thomsonreuters.com wrote:
> | On 2/22/11 11:13 AM, "Dirk Eddelbuettel" wrote:
> | >Just a quick note to say that ...
> | >
> | >On 22 February 2011 at 10:53, ken.willi...@thomsonreuters.com wro
On Feb 22, 2011, at 3:21 PM, Dirk Eddelbuettel wrote:
>
> On 22 February 2011 at 13:49, ken.willi...@thomsonreuters.com wrote:
> | On 2/22/11 11:45 AM, "Simon Urbanek" wrote:
> |
> |
> | >
> | >On Feb 22, 2011, at 12:32 PM, Dirk Eddelbuettel wrote:
>
On Feb 22, 2011, at 3:56 PM, Dirk Eddelbuettel wrote:
>
> On 22 February 2011 at 15:32, Simon Urbanek wrote:
> |
> | On Feb 22, 2011, at 3:21 PM, Dirk Eddelbuettel wrote:
> |
> | >
> | > On 22 February 2011 at 13:49, ken.willi...@thomsonreuters.com wrote:
> | &
On Feb 22, 2011, at 5:12 PM, Dirk Eddelbuettel wrote:
>
> On 22 February 2011 at 16:53, Simon Urbanek wrote:
> | i386 = 32-bit (not that is matters) and the CRAN specs are listed in "CRAN
> Package Check Flavors" saying OS X 10.5.8, gcc 4.2.1 (5577 to be precise).
> |
On Feb 22, 2011, at 5:29 PM,
wrote:
>
>
>
>
> On 2/22/11 4:25 PM, "Simon Urbanek" wrote:
>
>> On Feb 22, 2011, at 5:12 PM, Dirk Eddelbuettel wrote:
>>
>>>
>>> Anyway---I will point our OS X user to source installs.
>>>
On Feb 22, 2011, at 5:32 PM, Dirk Eddelbuettel wrote:
>
> On 22 February 2011 at 17:25, Simon Urbanek wrote:
> | On Feb 22, 2011, at 5:12 PM, Dirk Eddelbuettel wrote:
> |
> | >
> | > On 22 February 2011 at 16:53, Simon Urbanek wrote:
> | > | i386 = 32-bit (not
On Feb 22, 2011, at 5:51 PM,
wrote:
>
>
> On 2/22/11 4:33 PM, "Simon Urbanek" wrote:
>
>>
>> On Feb 22, 2011, at 5:29 PM,
>> wrote:
>>
>>>
>>>
>>>
>>>
>>> On 2/22/11 4:25
On Feb 22, 2011, at 6:03 PM, Simon Urbanek wrote:
>
> On Feb 22, 2011, at 5:51 PM,
> wrote:
>
>>
>>
>> On 2/22/11 4:33 PM, "Simon Urbanek" wrote:
>>
>>>
>>> On Feb 22, 2011, at 5:29 PM,
>>> wrote:
>
On Feb 22, 2011, at 5:46 PM,
wrote:
> On 2/22/11 4:32 PM, "Dirk Eddelbuettel" wrote:
>>
>> What boolean test for 'am I on OS X 10.5' can you suggest?
>
> You could use system("uname -r"), which on my system gives 10.6.0 (even
> though my system is 10.6.6)
uname -r (and Sys.info()['release']
On Feb 22, 2011, at 6:28 PM, Dirk Eddelbuettel wrote:
>
> Ken,
>
> Could you test the 0.9.1 tarball? Then in
> inst/unitTests/runit.Module.client.package.R, apply the diff below:
>
> -- ie add the new .badOSX function (maybe I'll rename it 'oldOSX')
>
You have a typo in the call (.basOSX v
On Feb 22, 2011, at 7:35 PM, Dirk Eddelbuettel wrote:
>
> On 22 February 2011 at 18:56, Simon Urbanek wrote:
> |
> | On Feb 22, 2011, at 6:28 PM, Dirk Eddelbuettel wrote:
> |
> | >
> | > Ken,
> | >
> | > Could you test the 0.9.1
It passes on R-devel, OS X 10.5.8
On Feb 23, 2011, at 10:32 AM, Dirk Eddelbuettel wrote:
>
> On 23 February 2011 at 09:27, ken.willi...@thomsonreuters.com wrote:
> |
> |
> | On 2/23/11 8:05 AM, "Dirk Eddelbuettel" wrote:
> |
> | >
> | >Thanks again to Simon, Ken and Baptiste for help yester
On Apr 5, 2011, at 1:09 PM, Romain Francois wrote:
> Le 05/04/11 18:58, Jay Emerson a écrit :
>> I'm making a guess that the R-Forge setup is having the same problems
>> as we are, though -- more than just RcppModels show that same bus
>> error. Executive summary: I now have a local success, wit
On Apr 5, 2011, at 2:31 PM, Dirk Eddelbuettel wrote:
>
> On 5 April 2011 at 14:00, Simon Urbanek wrote:
> | Nope - we do support 10.5 (Leopard) of course. The difference above is that
> the latter student has probably an ancient Xcode installed (2.x) whereas we
> recommend
On Apr 5, 2011, at 3:24 PM, Jay Emerson wrote:
> Is there some possibility 4.2 might be included in addition to 4.0,
> but that 4.0 could be the default behavior?
Xcode 3.1.x has definitely both. Unless they messed around with the
installation, g++-4.2 will always call gcc 4.2 and g++-4.0 will
On Jun 4, 2011, at 10:31 AM, soeren.vo...@uzh.ch wrote:
> Hello
>
> Apologies for cross-posting, the discussion should (if) go to R-devel, but I
> also want to reach the rcpp-devel people.
>
> My C++ class FOO is a module available through Rcpp, and it works fine and is
> -- so far -- bug fre
On Feb 17, 2012, at 10:22 AM, Dirk Eddelbuettel wrote:
>
> Via Twitter I came across this post
>
>http://kennethreitz.com/xcode-gcc-and-homebrew.html
>
> which implies that there is now a new, official, supported gcc available for
> OS X. Could some Rcpp users comment on this?
>
This
On Apr 26, 2013, at 6:38 PM, Valentin Kuznetsov wrote:
> Dirk,
>
> having hard-coded path is usually lead to trouble regardless of the OS. Users
> may have dedicated system with specific compiler/tools in different location.
> What you need is auto-detection of required components. Since /usr/b
On Apr 27, 2013, at 8:47 PM, Valentin Kuznetsov wrote:
> Hi Dirk,
> environment variable is not that bad and I'm ok with such solution.
I'd say something along the lines of
: ${INSTALL_NAME_TOOL=/usr/bin/install_name_tool}
should be clear enough ...
Cheers,
S
> Valentin.
>
> On Apr 27, 20
On Jul 13, 2010, at 8:13 AM, Ken Knoblauch wrote:
> Thanks. I'm in mode d'attente...
>
I did not see the exact OS version mentioned anywhere but as Romain pointed out
it's working just fine on OS X 10.5.8 with gcc 5577:
hagal:~$ gcc --version
i686-apple-darwin9-gcc-4.2.1 (GCC) 4.2.1 (Apple I
On Oct 27, 2010, at 1:22 PM, Dominick Samperi wrote:
> Hello,
>
> In Sections 5.8.1 and 5.8.2 of Writing R Extensions the following pattern is
> suggested
> for getting the path to a file in another package:
>
> PKGB_PATH=Œecho ‚library(packB); cat(system.file("libs", package="packB"))‚
> \
> |
The symlink is now there. The issue was caused by hiredis is not supporting
either configure or DESTDIR so I had to build the tar ball by hand. There may
be more issues caused by the lack of basic build features in hiredis, so let me
know how it goes.
Cheers,
Simon
Sent from my iPhone
> On Ma
One package (guitar) that happens to use Rcpp started breaking recently without
any change to its own code as follows:
> install.packages("guitar",,"http://rforge.net";)
> library(guitar)
> Repository$new(".")
terminate called after throwing an instance of 'Rcpp::not_compatible'
what(): exp
> On Nov 19, 2015, at 3:59 PM, Qiang Kou wrote:
>
> Hi, Simon,
>
> Is there any specific reason to use this?
>
This is OT, but, yes, git2r didn't exist when we wrote gitgist so we couldn't
use it, obviously. Now, someone would have to re-write gitgist to use git2r -
if you want to volunteer
Many thanks, Dirk! It does indeed fix the problem, very much appreciated!
Simon
On Nov 21, 2015, at 5:01 PM, Dirk Eddelbuettel wrote:
>
> On 21 November 2015 at 15:47, Dirk Eddelbuettel wrote:
> |
> | Simon, Carlos, Prateek,
> |
> | It's an issue between R and guitar. Rcpp is an bystander.
> On Feb 28, 2016, at 2:59 PM, Kevin Ushey wrote:
>
> What about having a 'configure' script that generates this header file
> on package install?
> https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Configure-and-cleanup
>
You don't even need that - it's much easier to simply add a
Note that macOS doesn't include debugging info in the objects so stripping is
meaningless there.
I wasn't on the full thread - which package are we talking about?
Cheers,
Simon
> On Sep 18, 2017, at 5:34 PM, Qiang Kou wrote:
>
> On OSX, "-strip-all" or "-strip-debug" should work.
>
> See [1
Fernando,
there was a pretty big follow-up discussion on R-devel that's worth reading:
https://stat.ethz.ch/pipermail/r-devel/2019-March/077560.html
but I want to point out that people may have misunderstood the recommendation -
if you just use Rcpp (or other means) to get data from R, run some
Robin,
this is unlikely a Mac issue, merely newer compilers give you better error
handling pointing to issues in the code that may not have been detected before.
If you post the code we can have a look.
Also check your tools - the RcppArmadillo error points out that your compiler
setup is brok
ns/3.6/Resources/library/Rcpp/include"
> -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
> -I/usr/local/include -fPIC -Wall -g -O2 -c mod_client.cc
> <http://mod_client.cc/> -o mod_client.o
> | >>
> | >> In file included from mod_client.cc <http://
Fatima,
it means you don't have command line tools installed (they are independent of
Xcode and Apple OS upgrades delete things, unfortunately) - try
sudo xcode-select —install
That should fix the error you see. However, Catalina broke more things so you
may look at the links Dirk pointed out
Have removed old installation files, installed command line tools, upgraded
> to clang-7 and gfotron6.1. I have added set of compilation files to
> ~/.R/Makevars
> as mentioned and the file exist there (attached) but there is still no
> CommandLineTools directory in Library/Developer
Paul,
as Kevin pointed out you have a big mess in /usr/local - I'd recommend renaming
/usr/local/include and /usr//local/lib -- then you shouldn't need to set any
custom flags at all (at least in R 4.0.0).
Cheers,
Simon
> On 4/05/2020, at 9:34 AM, Paul Fishwick wrote:
>
> @Kevin: This worke
Toby,
Rcpp simply calls allocVector() so regular R rules apply. R's SEXP can hold
vectors up to length 1 inside without additional allocations*, therefore from
memory management perspective writes to the first element of a 0-length vector
are not invalid. The valgrind instrumentation of R doesn
Naeem,
I'm not sure which issues are you talking about specifically. If your package
is well written, the instructions at https://mac.r-project.org/openmp/ should
be sufficient with regular CRAN installation of R and standard tools.
Cheers,
Simon
> On Jul 15, 2021, at 02:41, Naeem Khoshnevis
Naeem,
you cannot assume that OpenMP is available as that is an optional capability,
so make sure you make the inclusion of omp.h optional. Please read section
1.2.1.1 OpenMP support of the Writing R Extensions manual:
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#OpenMP-support
Dominick,
in that case this would be best reported on R-SIG-Mac. I just happen to be on
this list so it worked ;).
Re-building RInside seems to fix the issue, now updated.
While I have you here, unrelated, but please note that linking to packages
dynamically is not supported (see R-exts 5.8),
Simon,
this is not a build issue, it breaks on all platforms in clang (tested on macOS
and Debian+clang-11). There are tons of warnings in the C++ code (way over 1000
lines!) which lead to an error at link time (most of them are type mismatches
leading to overrides of virtual methods). The part
d ()
> {
> }
> virtual void update(const PriorStudentInd&);
> };
> #endif /* __FINMIX_PARSTUDENTIND_H__ */
>
> Can you give me a hint, what might be the reason here. I have an intuition
> that it is due to either the "virtual" class inheritance or/and t
Juan,
you should never use byte pointer arithmetic in C to create pointers to
non-byte types since they cause unaligned memory access as you found out. In
most architecture unaligned access is a fatal error (arm64 is just one of
many), in some architectures (e.g. x86_64) it will succeed with a
> On Feb 2, 2023, at 11:41 AM, Dirk Eddelbuettel wrote:
>
>
> On 1 February 2023 at 17:23, Dominick Samperi wrote:
> | Since I am not aware of an R-internals mailing list, and since this
>
> AFAIK there is no such mailing list. There is a manual of that name:
> https://rstudio.github.io/r-man
Dominick,
again, it's hard to give you advice when you don't post the code, but note that
for graphical Windows applications you may need to implement WinMain and make
sure you setup the Windows event loop (which is separate from R's event loop)
before you use RInside (see Win32 documentation).
The copy constructor doesn't actually create a copy, it only acts as a wrapper
that preserves the same EXTPTR object, it is akin to increasing the reference
count, so the C++ class wrapped in the EXTPTR is only released when the EXTPTR
can be garbage-collected, i.e. all references are gone (incl
43 matches
Mail list logo
