[Rd] debugging C/Fortran code with Visual Studio and Intel compilers
Hello, My R code calles a C/Fortran dll and I want to debug C code using Visual Studio and Intel compilers /debugger Debugging with Rcpp and RInsight does not work correctly on Windows. Is there some other way to set breakpoints in C code and access to variables ? Thank you ! Kind regards, Vitaliy [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] debugging C/Fortran code with Visual Studio and Intel compilers
On 13-01-18 6:24 AM, Vitaliy FEOKTISTOV wrote:
Hello,
My R code calles a C/Fortran dll and I want to debug C code using Visual
Studio and Intel compilers /debugger
Debugging with Rcpp and RInsight does not work correctly on Windows.
Is there some other way to set breakpoints in C code and access to
variables ?
I've rarely used those compilers, but I've used two strategies for
situations like that.
1. Start Rgui.exe in some debugger that works with your compiler. It
won't know how to handle R debug info (and unless you've recompiled R
there won't be any), but you should be able to set breakpoints in your
own code. If your debugger won't set code in an unloaded DLL, you can
run R, attach the package, then interrupt R to set breakpoints.
2. If you want to trigger a call to the debugger from your code, there
are Windows API functions to do that (but I never had any luck with
them); you may also be able to execute
asm("int $3");
in your function to trigger a debug interrupt. This is a little
dangerous, because I think it will crash R if a debugger is not attached.
Or you can use the old fashioned debugging methods, and just insert lots
of Rprintf() calls into your C code. This is quite painful, but
sometimes is necessary.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Trouble building package using R in development
> To what end is the --vanilla here? Writing R Extensions says that R CMD > check (and R CMD build) are invoked via R --vanilla so that would seem > redundant, although my experience from several hours working this > through today suggests there is a difference between R --vanilla CMD > check and R CMD check. Maybe that's new? We've certainly had problems with R CMD reading user startup files, which is why we starting using --vanilla. Hadley -- Chief Scientist, RStudio http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] maintaining multiple R versions
(somewhat related to thread [Rd] R CMD check not reading R_LIBS ) For many years I have maintained R versions by building R (./configure ; make) in a directory indicating the version number, putting the directory/bin on my path, and setting R_LIBS_SITE. It seems only one version can easily be installing in /usr/bin, and in any case that requires root, so I do not do that. There may be an advantage to installing somewhere in a directory with the version number, but that does not remove the need to set my path. (If there is an advantage to installing I would appreciate someone explaining briefly what it is.) My main question is whether there is a better ways to maintaining multiple versions, in some way that lets users choose which one they are using? (The only problem I am aware of with my current way of doing this is: if the system has some R in /usr/bin then I have to set my preferred version first, which means shell commands like "man" find R's pager first, and do not work.) Thanks, Paul __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] maintaining multiple R versions
Have you looked at Environment Modules (http://modules.sourceforge.net/)? I use it to maintain multiple versions of R. Users can choose their default and switch among them at the command line. Aaron On Fri, Jan 18, 2013 at 02:04:13PM -0500, Paul Gilbert wrote: > (somewhat related to thread [Rd] R CMD check not reading R_LIBS ) > > For many years I have maintained R versions by building R > (./configure ; make) in a directory indicating the version number, > putting the directory/bin on my path, and setting R_LIBS_SITE. > > It seems only one version can easily be installing in /usr/bin, and > in any case that requires root, so I do not do that. There may be an > advantage to installing somewhere in a directory with the version > number, but that does not remove the need to set my path. (If there > is an advantage to installing I would appreciate someone explaining > briefly what it is.) > > My main question is whether there is a better ways to maintaining > multiple versions, in some way that lets users choose which one they > are using? > > (The only problem I am aware of with my current way of doing this is: > if the system has some R in /usr/bin then I have to set my preferred > version first, which means shell commands like "man" find R's pager > first, and do not work.) > > Thanks, > Paul > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Aaron A. King, Ph.D. Ecology & Evolutionary Biology Mathematics Center for the Study of Complex Systems University of Michigan GPG Public Key: 0x15780975 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] utils::tar() and files >= 2GB
Hi,
The current implementation for utils::tar() seems to generate broken
tarballs when some of the files to include in the tarball are >= 2GB.
For example, when running 'R CMD build' on a big Bioconductor data
package, we see this warning:
* checking for file ‘ChIPXpressData/DESCRIPTION’ ... OK
* preparing ‘ChIPXpressData’:
* checking DESCRIPTION meta-information ... OK
* checking for LF line-endings in source and make files
* checking for empty or unneeded directories
* building ‘ChIPXpressData_0.99.1.tar.gz’
Warning in sprintf("%011o", as.integer(size)) :
NAs introduced by coercion
probably because 'size' was > .Machine$integer.max for one of the files
included in the tarball. This suggests that the resulting tarball might
be incorrect. Which is confirmed later when running 'tar ztvf' on that
tarball from the Unix comand line:
-rw-r--r-- biocbuild/phs_compbio 38 2012-12-11 09:37
ChIPXpressData/.BBSoptions
-rw-r--r-- biocbuild/phs_compbio 442 2013-01-18 12:04
ChIPXpressData/DESCRIPTION
-rw-r--r-- biocbuild/phs_compbio 0 2012-12-11 09:37
ChIPXpressData/NAMESPACE
-rw-r--r-- biocbuild/phs_compbio 14 2012-12-11 09:37
ChIPXpressData/external_data_store.txt
drwxr-xr-x biocbuild/phs_compbio 0 2012-12-20 13:00
ChIPXpressData/inst/
drwxr-xr-x biocbuild/phs_compbio 0 2012-12-20 13:15
ChIPXpressData/inst/extdata/
-rw-r--r-- biocbuild/phs_compbio 1601278008 2012-12-20 13:15
ChIPXpressData/inst/extdata/DB_GPL1261.bigmemory
-rw-r--r-- biocbuild/phs_compbio 210497 2012-12-20 13:14
ChIPXpressData/inst/extdata/DB_GPL1261.bigmemory.desc
tar: Archive contains ` ' where numeric off_t value expected
-rw-r--r-- biocbuild/phs_compbio 18446744073709551615 2012-12-20
13:15 ChIPXpressData/inst/extdata/DB_GPL570.bigmemory
tar: Skipping to next header
-rw-r--r-- biocbuild/phs_compbio 193165 2012-12-20
13:14 ChIPXpressData/inst/extdata/DB_GPL570.bigmemory.desc
drwxr-xr-x biocbuild/phs_compbio0 2012-12-11 09:37
ChIPXpressData/man/
-rw-r--r-- biocbuild/phs_compbio 863 2012-12-11
09:37 ChIPXpressData/man/ChIPXpressData-package.Rd
-rw-r--r-- biocbuild/phs_compbio 1891 2012-12-11
09:37 ChIPXpressData/man/DB_GPL1261.bigmemory.Rd
-rw-r--r-- biocbuild/phs_compbio 1888 2012-12-11
09:37 ChIPXpressData/man/DB_GPL570.bigmemory.Rd
tar: Exiting with failure status due to previous errors
Also, not too surprisingly, 'R CMD check' on this tarball fails, but
with a somewhat obscure error message:
Error in getOct(block, 124, 12) : invalid octal digit
Execution halted
Would it make sense to support files that are >= 2GB, possibly with a
warning about portability issues, if there are any? If not, maybe
utils::tar() (and consequently 'R CMD build') should just fail, with
an informative error message.
Thanks,
H.
> sessionInfo()
R Under development (unstable) (2013-01-03 r61544)
Platform: x86_64-unknown-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=C LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fhcrc.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
