Re: [Rd] a R_PV problem

[Gang Liang]

Thanks for the pointer, and the problem solved.

I double checked that Rf_PrintValue works when the option
"unwindonsignal" is turned on in gdb. I also found that without "set
unwindonsignal on", both "p Rf_PrintValue(colNames)" and "p
R_PV(colNames)" could result in SIGTRAP or SIGSEGV sometimes. But not
sure what caused the signal and why... because if I stepped into these
functions, nothing would happen.

Thanks, Gang

On Tue, May 6, 2008 at 8:30 AM, Bill Dunlap <[EMAIL PROTECTED]> wrote:
> On Tue, 6 May 2008, Duncan Murdoch wrote:
>
>
>
> > On 06/05/2008 3:02 AM, pseudo wrote:
>  > > Dear all,
>  > >
>  > > When using gdb to debug my C code, I use R_PV to show the content of
>  > > SEXP variables:
>  > >
>  > >   SEXP sexp; // it is a data.frame
>  > >   SEXP colNames = getAttrib(sexp, R_NameSymbol);
>  > >
>  > > A strange thing is that after halting the program:
>  > >
>  > >   (gdb) p R_PV(colNames)
>  > >
>  > > does not show the content of colNames. I am positive my code is right
>  > > because if I insert "PrintValue(colNames);" in the c code, it will
>  > > print the right value. My debug result shows that the variable
>  > > "colNames" failed the "isObject" call. I am not sure whether this is a
>  > > new feature or bug. Anyone can help?
>  >
>  > Are you sure that getAttrib has been called?  Depending on the
>  > optimization level under which your code was compiled, instructions may
>  > be re-ordered.  gdb may show the instruction pointer after that line,
>  > even though that line hasn't been run yet.
>
>  R_PV(sexp) only prints if isObject(sexp) is true, i.e., if it
>  is "internally classed".  Try using Rf_PrintValue(colNames) from
>  the debugger.
>
>  src/main/print.c contains:
>/* Print an S-expression using global options */
>void PrintValue(SEXP s)
>{
>PrintValueEnv(s, R_GlobalEnv);
>
>}
>/* Ditto, but only for objects, for use in debugging */
>void R_PV(SEXP s)
>{
>if(isObject(s)) PrintValueEnv(s, R_GlobalEnv);
>}
>  and include/Internals.h has the usual add-Rf_ #define:
>#define PrintValue  Rf_PrintValue
>
>  
>  Bill Dunlap
>  Insightful Corporation
>  bill at insightful dot com
>  360-428-8146
>
>   "All statements in this message represent the opinions of the author and do
>   not necessarily reflect Insightful Corporation policy or position."
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] a package installation problem on windows

[Gang Liang]

Dear all,

I encountered a problem when test installing a package of my own under
the windows platform. The latest Rtools is installed, and Makefile.win
is used for directing the compilation of C++ codes under the src
directory. A sketch of the Makefile.win is as follows:

--- Makefile.win (old) -
all: part1.dll part2.dll

%.dll: %.cpp
R CMD SHLIB $<
---

When I run "R CMD build --binary pakname", the Makefile.win is
executed without error, but to my surprise, the wanted dll files are
not produced as expected; thus, the binary package will be created
without dlls. While if I run make in the src directory manually, all
dll files will be created. This problem can be by-passed using my
updated Makefile.win,

--- Makefile.win (new) -
all: part1.dll part2.dll copy

%.dll: %.cpp
R CMD SHLIB $<

copy: part1.dll part2.dll
mkdir -p ../inst/libs
cp *.dll ../inst/libs
---

It is ugly because I have to access the libs directory directly. My
question is what is the right syntax to compile codes using Makefile
then? Thanks very much!

Gang Liang

PS: Re the missing dll problem, my guess is that the command "R CMD
SHLIB ..." is doing the compilation on a memory disk, and the final
result is discarded right away. I even interrupted the compilation
midway, and am still not able to find any intermediate files on my
harddrive. On the other hand, the compilation is clearly done.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel