similar to: gdb problem resolved

Right, I'm talking about C code. Do you remember if you had to set specific CFLAGS or other settings to get gdb working? I wasn't able to get gdb() working with the standard build settings. Otherwise, Rprintf() would work for sure. Thank you! On Thu, Feb 23, 2017 at 10:55 AM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > On 23/02/2017 1:36 PM, Javier Luraschi wrote:

On 16 December 2016 at 11:00, Duncan Murdoch wrote: | On 16/12/2016 10:40 AM, Dirk Eddelbuettel wrote: | > On 16 December 2016 at 10:14, Duncan Murdoch wrote: | > | On 16/12/2016 8:37 AM, Dirk Eddelbuettel wrote: | > | > | > | > On 16 December 2016 at 08:20, Duncan Murdoch wrote: | > | > | Perhaps the solution is to recommend that packages which export their | > | > |

On Thu, Feb 23, 2017 at 7:49 PM, Tomas Kalibera <tomas.kalibera at gmail.com> wrote: > The R for Windows FAQ suggests "make DEBUG=T" and has some more hints > https://cran.r-project.org/bin/windows/base/rw-FAQ.html > > Tomas > > > > On 02/23/2017 08:10 PM, Javier Luraschi wrote: > >> Right, I'm talking about C code. >> >> Do you

This bot seems kind of flaky. In the last 100 builds, it has failed "gdb-75-check" 22 times with what is either a linker error or a missing header (or both?): gdb compile failed, /usr/bin/ld: error: /home/buildslave/osuosl_slave/clang-x86_64-ubuntu-gdb-75/clang-tests/build/gdb/testsuite/gdb.trace/pendshr1.c.o: requires dynamic R_X86_64_PC32 reloc against 'pendfunc1' which

On Mon, Jul 15, 2013 at 3:18 AM, Michal Privoznik <mprivozn@redhat.com>wrote: > > Interesting. If you are still able to reproduce the crash, can you try to > get the line number within virSecurityManagerGenLabel where the crash > happened? I think it's the STREQ line (440 linenr). Question is whether > model or name is NULL. > > I'll try. I'm not sure why

I have found the use of save( ) and attach( ) when supported by a pair of functions written by my colleague John Miyamoto, move( ) and rm.sv( ) quite useful in managing (1) collections of useful homebrew functions, (2) project workspaces, and (3) "packages" under development. An .Rdata file containing these and other handy functions together with a brief supporting document can be

On 16 December 2016 at 10:14, Duncan Murdoch wrote: | On 16/12/2016 8:37 AM, Dirk Eddelbuettel wrote: | > | > On 16 December 2016 at 08:20, Duncan Murdoch wrote: | > | Perhaps the solution is to recommend that packages which export their | > | C-level entry points either guarantee them not to change or offer | > | (require?) version checks by user code. So dplyr should start out by

I have been using R under Linux for more than a year and I think that it is great. Last week, I downloaded the binary Ms Windows version. I wanted to test it for my students. Our labs are under Bill Gates. I am not happy but I can do nothing. R worked. But, I could not use the dyn.load command with some dll built with one of the ports of gcc for windows 95/nt (I used the ecgs-mingw32 ports

I have been using R under Linux for more than a year and I think that it is great. Last week, I downloaded the binary Ms Windows version. I wanted to test it for my students. Our labs are under Bill Gates. I am not happy but I can do nothing. R worked. But, I could not use the dyn.load command with some dll built with one of the ports of gcc for windows 95/nt (I used the ecgs-mingw32 ports

Apologies if this has been asked before. Does anyone know if I can simply recompile * 1.4.34 over 1.4.24.1? Ie. perform an upgrade from 1.4.24.1 to 1.4.34 by just rebuilding the source files for 1.4.34 over the top of the existing 1.4.24.1 files. Obviously, I will need to keep my config files (and sound files etc) - so I'll back them up first. Also, will I need to stop * to perform this

A couple of points: - rebuilding dependent packages is needed if there is an ABI change, not just an API change. For packages like Rcpp which export inline functions or macros that might have changed, this is potentially any change to existing functions, but for packages like Matrix, it isn't really an issue at all IIUC. - If we're looking into a way to check if package APIs are

The R for Windows FAQ suggests "make DEBUG=T" and has some more hints https://cran.r-project.org/bin/windows/base/rw-FAQ.html Tomas On 02/23/2017 08:10 PM, Javier Luraschi wrote: > Right, I'm talking about C code. > > Do you remember if you had to set specific CFLAGS or other settings to get > gdb working? I wasn't able to get gdb() working with the standard build

I'm trying to track down a bug in some experimental code, where an object's attribute is getting messed up. This means I'd like to examine R objects while within gdb. One of the things I'd like to do is to examine the names of all the attributes. This is exactly what an example in the R Extensions manual section 4.11.2 "Inspecting R objects when debugging" does,

Hi,? I have a Fortran 77 subroutine (dll). On windows XP, how ?would I 'debug it(Fortran) within R' using gdb? This is how I made it. ---------------------- R CMD SHLIB main.f gfortran -m32 ? ? -O3 ?-mtune=core2 -c main.f -o main.o gcc -m32 -shared -s -static-libgcc -o main.dll tmp.def main.o -Ld:/RCompile/CRANpkg/extralibs64/local/lib/i386 -Ld:/RCompile/CRANpkg/extralibs64/local/lib

Are there any users of Insight with gdb out there? I was debugging r-patched tonight, and after quitting and restarting, suddenly Insight won't start!!? It prints a very long error dialog (which doesn't allow cut and paste @%$!), starting out like this: > Can't find a usable main.tcl in the following directories .... This is followed by a search list of directories, one of

Because almost no other piece of software out there doesn't have 'check' depend on rebuilding the target it's testing and it's bitten people whereas other than the lameness of our build system needing to recurse all the directories to figure out that all has already been rebuilt there's no penalty to requiring the dependency. :) -eric On Wed, Apr 17, 2013 at 9:35 AM, Bob

On 13 November 2016 at 00:13, Kirill M?ller wrote: | On 13.11.2016 00:00, Dirk Eddelbuettel wrote: | > On 12 November 2016 at 22:54, Kirill M?ller wrote: | > | > [... lots of stuff deleted ...] | > | > | I noticed this because plogr logging crashed in dplyr (compiled with gcc | > | 6) right after upgrading to yakkety; I still had a gcc-5 built version | > | of Rcpp installed.

I'm trying to debug some C functions I've written for use with R. Until recently debugging them with gdb was no problem. But since I switched to R-1.2.0 (from R-1.0.1) gdb can no longer find the entry points of my functions. It either pretends to set break points but doesn't stop there or it only stops at the end of the function. R version R-1.2.0 gdb version GNU gdb 4.18 gcc version

Thanks for the detailed feedback Tomas, I ran the command 'pacman -Syuu' again, just to be sure, and this time it says "there is nothing to do." It appears that gdb is working. I was spooked by the diagnostics that you say is a known (not serious) issue. My mistake was not setting a breakpoint on main, so I confused problems with gdb with problems with the program I'm

Dear R users I have started to use gdb for debugging dynloaded C code as described in `Writing R Extensions'. Unfortunately I have run into several problems that I haven't been able to solve: - using `n': how comes that the same line of code appears up to three times (and inbetween the next line and maybe even the second next one?) - using `print' resp. `display': How