Re: [Rd] windows 64-bit package build on 32-bit machine

[Simon Urbanek]

On Oct 26, 2010, at 11:10 PM, Michael Spiegel wrote:

> Hmm.  So our package does not have no src/Makefile.win and only an
> empty configure.win.  We usually build a binary version with R CMD
> INSTALL --build.
> 
> R --arch x64 CMD INSTALL --build yields the message "The system cannot
> find the path specified."
> 

Well, it probably means you don't have x64 binaries in your R - that has 
nothing to do with cross-compilation. You should make sure that you have both 
i386 and x64 archs in your R to start with.

Also I would not expect R --arch x64 to work regardless since you can't run 
64-bit binary of R on 32-bit Windows. The same applies on OS X - you can cross 
compile for ppc64 (i.e. install multi-arch if the package has no 
Makefile/configure) but you can't run ppc64 R on Intel Macs (and hence you 
cannot install packages with configure/Makefile).

Cheers,
Simon



> On Tue, Oct 26, 2010 at 10:41 PM, Simon Urbanek
>  wrote:
>> 
>> On Oct 26, 2010, at 9:04 PM, Michael Spiegel wrote:
>> 
>>> Hello,
>>> 
>>> Is it possible to build a 64-bit package on a 32-bit machine on
>>> windows? I can cross-compile for x86, x86_64, and ppc on a 32-bit OS X
>>> machine.  And it looks like I could build a 32-bit library on a 64-bit
>>> windows machine.  But it doesn't look possible to build a 64-bit
>>> library on a 32-bit windows machine?
>>> 
>> 
>> Why not? It works for me without problems ...
>> 
>> Cheers,
>> Simon
>> 
>> 
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> 

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

Re: [Rd] Link to R 2.12.0 patched build for windows

[Duncan Murdoch]

On 26/10/2010 7:38 PM, Brian Diggs wrote:

On the download page for windows builds of R 2.12.0:

http://cran.r-project.org/bin/windows/base/

The link for "r-patched snapshot build" goes to:

http://cran.r-project.org/bin/windows/base/rpatched.html

which has a link for R-2.11.1 patched.  I believe that link should go to:

http://cran.r-project.org/bin/windows/base/rtest.html

which does have a link for R-2.12.0 patched. Or the "rpatched.html" page
should be updated with a link to R-2.12.0 patched.



There was a typo in one of the build scripts, which has now been fixed.  
The files should be fine later today or tomorrow.


Duncan Murdoch

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

Re: [Rd] R-2.12.0 hangs while loading RGtk2 on FreeBSD

[Michael Lawrence]

On Sat, Oct 23, 2010 at 2:49 AM, Rainer Hurling  wrote:

> On 22.10.2010 22:10 (UTC+1), Rainer Hurling wrote:
>
>> On 22.10.2010 16:18 (UTC+2), Rainer Hurling wrote:
>>
>>> On 22.10.2010 14:57 (UTC+1), Michael Lawrence wrote:
>>>


 On Thu, Oct 21, 2010 at 9:42 AM, Rainer Hurling >>> > wrote:

 [moved from R-help]

 On 21.10.2010 18:09 (UTC+1), Prof Brian Ripley wrote:

 If you do R CMD INSTALL --no-test-load this will skip the part
 that is
 hanging and you can try loading in stages (e.g. dyn.load on the
 RGtk2.so).


 With '--no-test-load' it installs and ends normal. Loading per
 dyn.load("RGtk2.so") works, just as dyn.load("RGtk2.so",F) and
 dyn.load("RGtk2.so",,F). Unloading works, too.

 Normal loading over library(RGtk2) within R does not work. R than is
 hanging.

 It seems the problem is not with the library itself?


 It looks like something is happening when initializing GTK+ and the
 event loop. This happens in the function R_gtkInit in Rgtk.c. If you
 could run R -d gdb and break on that function, perhaps you could step
 through until it hangs.

>>>
>>> Michael, thank you for answering. As I wrote earlier (on R-help@),
>>> unfortunately I have no experience with debugging (I am not a
>>> programmer). So I would need some more assistence.
>>>
>>> Is there a difference between 'library(RGtk2)' and 'dyn.load(RGtk2)' in
>>> initializing GTK+? I am able to dyn.load, but library does not work.
>>>
>>> After starting with 'R -d gdb' is the following right?
>>>
>>> (gdb) break R_gtkInit
>>> Function "R_gtkInit" not defined.
>>> Make breakpoint pending on future shared library load? (y or [n]) y
>>> Breakpoint 1 (R_gtkInit) pending.
>>>
>>> When I try to proceed, it gives me the following message
>>>
>>> (gdb) run
>>> Starting program: /usr/local/lib/R/bin/exec/R
>>> /libexec/ld-elf.so.1: Shared object "libRblas.so" not found,
>>> required by "R"
>>> Program exited with code 01.
>>>
>>
>> Ok, I am one step further now:
>>
>>
>> (gdb) run
>> Starting program: /usr/local/lib/R/bin/exec/R
>> [..SNIP..]
>>  > library(RGtk2)
>> [New LWP 100174]
>> Breakpoint 2 at 0x318bd490: file Rgtk.c, line 104.
>> Pending breakpoint "R_gtkInit" resolved
>> [New Thread 2f408b00 (LWP 100174)]
>> [Switching to Thread 2f408b00 (LWP 100174)]
>>
>> Breakpoint 2, R_gtkInit (rargc=0x30b11d10, rargv=0x30a98458,
>> success=0x30afbad0) at Rgtk.c:104
>> 104 Rgtk.c: No such file or directory.
>> in Rgtk.c
>> (gdb)
>>
>>
>> What do you suggest I should do next?
>>
>
> Rgtk.c was not found from gdb because RGtk2 was not build with DEBUG=T and
> R_KEEP_PKG_SOURCE=yes.
>
> So this is the next try. I can trace the code until it hangs:
>
>
> library(RGtk2)
> [New LWP 100250]
> Breakpoint 2 at 0x458bd490: file Rgtk.c, line 104.
>
> Pending breakpoint "R_gtkInit" resolved
> [New Thread 4322ef00 (LWP 100250)]
> [Switching to Thread 4322ef00 (LWP 100250)]
>
> Breakpoint 2, R_gtkInit (rargc=0x446d0980, rargv=0x44698618,
> success=0x446d09e0) at Rgtk.c:104
> 104 {
> (gdb) n
> 107   argc = (int) *rargc;
> (gdb) n
> 104 {
> (gdb) n
> 107   argc = (int) *rargc;
> (gdb) n
> 109   if (!gdk_display_get_default()) {
> (gdb) n
> 110 gtk_disable_setlocale();
> (gdb) n
> 111 if (!gtk_init_check(&argc, &rargv)) {
> (gdb) n
> 121 if (!GDK_DISPLAY()) {
> (gdb) n
> 127 addInputHandler(R_InputHandlers,
> ConnectionNumber(GDK_DISPLAY()),
> (gdb) n
> 132 if (!pipe(fds)) {
> (gdb) n
> 133   ifd = fds[0];
> (gdb) n
> 134   ofd = fds[1];
> (gdb) n
> 135   addInputHandler(R_InputHandlers, ifd,
> R_gtk_timerInputHandler, 32);
> (gdb) n
> 133   ifd = fds[0];
> (gdb) n
> 134   ofd = fds[1];
> (gdb) n
> 135   addInputHandler(R_InputHandlers, ifd,
> R_gtk_timerInputHandler, 32);
> (gdb) n
> 136   if (!g_thread_supported ()) g_thread_init (NULL);
> (gdb) n
> 137   g_thread_create(R_gtk_timerThreadFunc, NULL, FALSE, NULL);
> (gdb) n
>
> Line 138 (R_CStackLimit = -1;) is hanging. It seems there is something
> wrong with piping the file descriptor?
>
>
>

Thanks for looking into this. It looks like the g_thread_create line is
hanging. I wonder if your version of GTK+/GLib is not built with threading
support? But if that were the case, g_thread_init() should have aborted. You
could try breaking on the R_gtk_timerThreadFunc just to see if the thread is
executed at all or where it is hanging.

Thanks again for taking the time to work on this. Sorry I have been
non-responsive.

Michael


>  Thanks again,
>>> Rainer
>>>
>>>
>>>  Thanks,
 Michael

 I think this is rather technical for R-help, so maybe move to
 R-devel?


 I moved to R-devel.

 And can you check the RGtk2 version? A recent but not current
 version
 (2.12.17?) did hang initializing Gtk+ on some platforms and Micha

[Rd] documentation for representation() typo

[Roebuck,Paul L]

50c50
<  The value of \code{representation} is just the list of arguments
---
>  The value pf \code{representation}  is just the list of arguments, after
these have been checked


51c51
<  after these have been checked for validity.
---
>  for validity.

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

Re: [Rd] Sections 5.8.1 and 5.8.2 of Writing R Extensions (LinkingTo)

[Simon Urbanek]

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"))‚
> \
> | ${R_HOME}/bin/R --vanilla --slaveŒ
> 
> Is the library(packB) really needed here?

Not that I'm aware of - it's just a check that that package can be used. If you 
omit it you will get an empty string and no error on failure.


> It is not needed on two systems
> that
> I have tested: Windows and Linux. What about MacOS?
> 
> If loading packB requires loading many other packages or doing expensive
> initialization it would be much more efficient if we could omit
> library(packB)
> here.
> 
> On the other hand, keeping library(packB) has one possible advantage,
> namely,
> it may eliminate the need to add packB.dll to the loader's search path.

Not really since that sub-process will die when finished so it won't have any 
effect on any search path.


BTW: system.file("libs",...)  doesn't do the job these days since it will be 
missing R_ARCH so you need something like
system.file("libs",.Platform$r_arch, package=...)
for any more recent R.

Cheers,
Simon


> So
> there
> is a trade-off of convenience vs efficiency.
> 
> Thanks,
> Dominick
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [Rd] R-2.12.0 hangs while loading RGtk2 on FreeBSD

[Rainer Hurling]

On 27.10.2010 15:07 (UTC+1), Michael Lawrence wrote:

On Sat, Oct 23, 2010 at 2:49 AM, Rainer Hurling mailto:rhur...@gwdg.de>> wrote:
On 22.10.2010 22:10 (UTC+1), Rainer Hurling wrote:
On 22.10.2010 16:18 (UTC+2), Rainer Hurling wrote:
On 22.10.2010 14:57 (UTC+1), Michael Lawrence wrote:

On Thu, Oct 21, 2010 at 9:42 AM, Rainer Hurling
mailto:rhur...@gwdg.de>
>> wrote:

[moved from R-help]

On 21.10.2010 18:09 (UTC+1), Prof Brian Ripley wrote:

If you do R CMD INSTALL --no-test-load this will skip
the part
that is
hanging and you can try loading in stages (e.g. dyn.load
on the
RGtk2.so).

With '--no-test-load' it installs and ends normal.
Loading per
dyn.load("RGtk2.so") works, just as
dyn.load("RGtk2.so",F) and
dyn.load("RGtk2.so",,F). Unloading works, too.

Normal loading over library(RGtk2) within R does not
work. R than is
hanging.

It seems the problem is not with the library itself?

It looks like something is happening when initializing
GTK+ and the
event loop. This happens in the function R_gtkInit in
Rgtk.c. If you
could run R -d gdb and break on that function, perhaps
you could step
through until it hangs.

Michael, thank you for answering. As I wrote earlier (on
R-help@),
unfortunately I have no experience with debugging (I am not a
programmer). So I would need some more assistence.

Is there a difference between 'library(RGtk2)' and
'dyn.load(RGtk2)' in
initializing GTK+? I am able to dyn.load, but library does
not work.

After starting with 'R -d gdb' is the following right?

(gdb) break R_gtkInit
Function "R_gtkInit" not defined.
Make breakpoint pending on future shared library load? (y or
[n]) y
Breakpoint 1 (R_gtkInit) pending.

When I try to proceed, it gives me the following message

(gdb) run
Starting program: /usr/local/lib/R/bin/exec/R
/libexec/ld-elf.so.1: Shared object "libRblas.so" not found,
required by "R"
Program exited with code 01.

Ok, I am one step further now:

(gdb) run
Starting program: /usr/local/lib/R/bin/exec/R
[..SNIP..]
 > library(RGtk2)
[New LWP 100174]
Breakpoint 2 at 0x318bd490: file Rgtk.c, line 104.
Pending breakpoint "R_gtkInit" resolved
[New Thread 2f408b00 (LWP 100174)]
[Switching to Thread 2f408b00 (LWP 100174)]

Breakpoint 2, R_gtkInit (rargc=0x30b11d10, rargv=0x30a98458,
success=0x30afbad0) at Rgtk.c:104
104 Rgtk.c: No such file or directory.
in Rgtk.c
(gdb)

What do you suggest I should do next?

Rgtk.c was not found from gdb because RGtk2 was not build with
DEBUG=T and R_KEEP_PKG_SOURCE=yes.

So this is the next try. I can trace the code until it hangs:

library(RGtk2)
[New LWP 100250]
Breakpoint 2 at 0x458bd490: file Rgtk.c, line 104.

Pending breakpoint "R_gtkInit" resolved
[New Thread 4322ef00 (LWP 100250)]
[Switching to Thread 4322ef00 (LWP 100250)]

Breakpoint 2, R_gtkInit (rargc=0x446d0980, rargv=0x44698618,
success=0x446d09e0) at Rgtk.c:104
104 {
(gdb) n
107   argc = (int) *rargc;
(gdb) n
104 {
(gdb) n
107   argc = (int) *rargc;
(gdb) n
109   if (!gdk_display_get_default()) {
(gdb) n
110 gtk_disable_setlocale();
(gdb) n
111 if (!gtk_init_check(&argc, &rargv)) {
(gdb) n
121 if (!GDK_DISPLAY()) {
(gdb) n
127 addInputHandler(R_InputHandlers,
ConnectionNumber(GDK_DISPLAY()),
(gdb) n
132 if (!pipe(fds)) {
(gdb) n
133   ifd = fds[0];
(gdb) n
134   ofd = fds[1];
(gdb) n
135   addInputHandler(R_InputHandlers, ifd,
R_gtk_timerInputHandler, 32);
(gdb) n
133   ifd = fds[0];
(gdb) n
134   ofd = fds[1];
(gdb) n
135   addInputHandler(R_InputHandlers, ifd,
R_gtk_timerInputHandler, 32);
(gdb) n
136   if (!g_thread_supported ()) g_thread_init (NULL);
(gdb) n
137   g_thread_create(R_gtk_timerThreadFunc, NULL, FALSE, NULL);
(gdb) n

Line 138 (R_CStackLimit = -1;) is hanging. It seems there is
something wrong with piping the file descriptor?

Thanks for looking into this. It looks like 

Re: [Rd] Sections 5.8.1 and 5.8.2 of Writing R Extensions (LinkingTo)

[Dominick Samperi]

On Wed, Oct 27, 2010 at 2:43 PM, Simon Urbanek
wrote:

>
> 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"))‚
> > \
> > | ${R_HOME}/bin/R --vanilla --slaveŒ
> >
> > Is the library(packB) really needed here?
>
> Not that I'm aware of - it's just a check that that package can be used. If
> you omit it you will get an empty string and no error on failure.
>

I did not tell the whole story here. Assume the packB depends on packC in
the sense that packB.dll links to packC.dll.
Then library(packB) will trigger library(packC), and this appears to have
the side effect of eliminating the need to place
the directories containing packB.dll and packC.dll on the search path.

If the library(packB) is not used in this situation there will be a failure
if instead of
cat(sytem.file("libs", package="packB") one uses cat(packB:::getLibs()),
where packB:::getLibs() is defined by system.file("libs",package="packB").

The lesson here (for me) is that packB:::getLibs() has the side-effect of
loading packB.dll,
and this will fail if the OS cannot find packC.dll (so the directory
containing the latter would
have to be placed on the search path if library(packB) is not used above).

Dominick

[[alternative HTML version deleted]]

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

[Rd] Documentation of option 'help.ports' not in help("options")

[Henrik Bengtsson]

FYI,

the option 'help.ports' is not document under help("options").  Should
it?  It is documented under help("startDynamicHelp", package="tools").

This is for for R v2.13.0dev and Rv2.12.0.

/Henrik

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

[Rd] must .Call C functions return SEXP?

[Andrew Piskorski]

For using R's .Call interface to C functions, all the examples I've
seen have the C function return type SEXP.  Why?  What does R actually
do with this return type?  What happens if I *don't* return a SEXP?

Reason I ask, is I've written some R code which allocates two long
lists, and then calls a C function with .Call.  My C code writes to
those two pre-allocated lists, thus, I thought I should NOT need to
return any SEXP from my C function.  However, if I do that, it
segfaults somewhere in "src/main/memory.c".

If I instead return the SEXP for one of my two result lists it appears
to work fine...  But of course I don't understand what's going on here
and so don't trust it.  The list SEXP I am returning was allocated by
R, not by my C code, so why does it make any difference whether my C
function returns it or not?

>From "src/main/names.c" I see that .Call is implemented by do_dotcall
in "src/main/dotcode.c".  I don't necessarily understand what that
really does, but AFAICT if my C function returns nothing, the
do_dotcall's retval should simply remain set to R_NilValue, which
should be fine.

I must be misunderstanding something here, but I don't know what, and
would definitely appreciate any help.  Thanks!


My R code looks like this:

  result.1 <- vector("list" ,1e6)
  result.2 <- vector("list" ,1e6)
  .Call("my_C_function", result.1, result.2, other.input)

My C code looks like this:

  SEXP result_v; 
  result_v = Rf_allocVector(REALSXP, 5); 
  SET_VECTOR_ELT(result_list_1, k1, result_v); 
  REAL(result_v)[0] = some_number; 
  REAL(result_v)[1] = another_number; 
  /* Also do the same sort of thing for result_list_2. */
  return(result_list_1);  /* Appears to work ok. */
  /* return; */  /* Segfaults. */

-- 
Andrew Piskorski 
http://www.piskorski.com/

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

Re: [Rd] must .Call C functions return SEXP?

[Dirk Eddelbuettel]

On 27 October 2010 at 19:43, Andrew Piskorski wrote:
| For using R's .Call interface to C functions, all the examples I've
| seen have the C function return type SEXP.  Why?  What does R actually
| do with this return type?  What happens if I *don't* return a SEXP?
| 
| Reason I ask, is I've written some R code which allocates two long
| lists, and then calls a C function with .Call.  My C code writes to
| those two pre-allocated lists, thus, I thought I should NOT need to
| return any SEXP from my C function.  However, if I do that, it
| segfaults somewhere in "src/main/memory.c".
| 
| If I instead return the SEXP for one of my two result lists it appears
| to work fine...  But of course I don't understand what's going on here
| and so don't trust it.  The list SEXP I am returning was allocated by
| R, not by my C code, so why does it make any difference whether my C
| function returns it or not?
| 
| >From "src/main/names.c" I see that .Call is implemented by do_dotcall
| in "src/main/dotcode.c".  I don't necessarily understand what that
| really does, but AFAICT if my C function returns nothing, the
| do_dotcall's retval should simply remain set to R_NilValue, which
| should be fine.
| 
| I must be misunderstanding something here, but I don't know what, and
| would definitely appreciate any help.  Thanks!
| 
| 
| My R code looks like this:
| 
|   result.1 <- vector("list" ,1e6)
|   result.2 <- vector("list" ,1e6)
|   .Call("my_C_function", result.1, result.2, other.input)
| 
| My C code looks like this:
| 
|   SEXP result_v; 
|   result_v = Rf_allocVector(REALSXP, 5); 
|   SET_VECTOR_ELT(result_list_1, k1, result_v); 
|   REAL(result_v)[0] = some_number; 
|   REAL(result_v)[1] = another_number; 
|   /* Also do the same sort of thing for result_list_2. */
|   return(result_list_1);  /* Appears to work ok. */
|   /* return; */  /* Segfaults. */


I don't deal with the C API when I can avoid it. Here is your setup in a
simple, self-contanined Rcpp example using inline:

-

library(inline)

# body of C++ function
src <- 'Rcpp::NumericVector vc = Rcpp::NumericVector(vr);
Rcpp::IntegerVector wc = Rcpp::IntegerVector(wr);

vc[1] = 2*vc[1];
wc[2] = 3*wc[2];

return Rcpp::wrap(0L);
'

# create it
fun <- cxxfunction(signature(vr="numeric", wr="integer"), src, plugin="Rcpp")

vr <- seq(1.5, 3.5)
wr <- seq(1L,  3L)

# call it 
print(fun(vr, wr))
print(vr)
print(wr)

-

We create 'vr' and 'wr' at the R level, pass them to C++ where they are taken
as numeric and int vectors (with type checking and casts).   

Your hunch is correct -- SEXP pointer changes continue back to the R level.
We do return something (R_NilValue is an option too) as that is how .Call()
declared, pure and simple.

If I run this in my emacs shell buffer, I get this:

-
e...@max:~$ r /tmp/andrew.R 
Loading required package: methods
[1] 0
[1] 1.5 5.0 3.5
[1] 1 2 9
e...@max:~$ 
-

First the zero, then the two (changed) vectors even though I didn't
explicitly return them. So this does work -- but I don't like hidden side
effects.  Much better, in my book, to explicitly return as you'd do with

return Rcpp::List::create(Rcpp::Named("newv"=vc,
  Rcpp::Named("neww"=wc)));

which will get you a named list at the R level.

Feel free to come over to rcpp-devel is you have questions about the Rcpp and
inline parts.

Dirk

-- 
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com

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

[Rd] Rbuildignore and mercurial

[Terry Therneau]

  I've changed to Mercurial for my working copies of survival for a number or 
resons not relevant to this post.  When I do R CMD check, I get some warnings
about certain files in the .hg directory with odd names.  I've added the 
following 2 lines to my .Rbuildignore file without effect
^\.hg$
^\.hg.*

I'm not a Perl user so perhaps I'm reading the help page wrong.  Any pointers?
This doesn't affect Rforge since I don't push any of those files up to there.

Terry T.

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

Re: [Rd] Rbuildignore and mercurial

[Gabor Grothendieck]

On Wed, Oct 27, 2010 at 10:43 PM, Terry Therneau  wrote:
>  I've changed to Mercurial for my working copies of survival for a number or 
> resons not relevant to this post.  When I do R CMD check, I get some warnings
> about certain files in the .hg directory with odd names.  I've added the 
> following 2 lines to my .Rbuildignore file without effect
> ^\.hg$
> ^\.hg.*
>
> I'm not a Perl user so perhaps I'm reading the help page wrong.  Any pointers?
> This doesn't affect Rforge since I don't push any of those files up to there.
>

.hg files are automatically excluded from the build so if you were to
check your built file, i.e. your .tar.gz file, instead then you should
not need any .Rbuildignore file in the first place.

-- 
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com

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

Re: [Rd] Rbuildignore and mercurial

[Hadley Wickham]

>  I've changed to Mercurial for my working copies of survival for a number or 
> resons not relevant to this post.  When I do R CMD check, I get some warnings
> about certain files in the .hg directory with odd names.  I've added the 
> following 2 lines to my .Rbuildignore file without effect
> ^\.hg$
> ^\.hg.*

Unfortunately that only affects building, not checking.  You have two
options: (1) ignore the warning (2) check the built package.

Hadley

-- 
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/

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

Re: [Rd] must .Call C functions return SEXP?

[Simon Urbanek]

On Oct 27, 2010, at 7:43 PM, Andrew Piskorski wrote:

> For using R's .Call interface to C functions, all the examples I've
> seen have the C function return type SEXP.  Why?  What does R actually
> do with this return type?  What happens if I *don't* return a SEXP?
> 

You are breaking the API = bad things happen.

.Call behaves like any function in R which means it takes arguments are returns 
a value. The result of .Call will be exactly the SEXP that you return from your 
C code hence you have to return something. It's quite common to R_NilValue 
which is NULL in R if you have nothing to do.


> Reason I ask, is I've written some R code which allocates two long
> lists, and then calls a C function with .Call.  My C code writes to
> those two pre-allocated lists,

That's bad! All arguments are essentially read-only so you should never write 
into them! R has pass-by-value(!) semantics, so semantically you code has 
nothing to do with the result.1 and result.2 variables since only their 
*values* are guaranteed to be passed (possibly a copy). The fact that 
internally R attempts to avoid copying for performance reasons is the only 
reason why your code may have appeared to work, but it's invalid!

So what you really want to do is to have just

.Call("my_C_function", other.input)

and in your C code you have

SEXP result_1 = PROTECT(allocVector(VECSXP, 1e6));
SEXP result_2 = PROTECT(allocVector(VECSXP, 1e6));

/* do something ... */

and in order to pass it out you just create a list and return it:

SEXP result = PROTECT(allocVector(VECSXP, 2));
SET_VECTOR_ELT(result, 0, result_1);
SET_VECTOR_ELT(result, 1, result_2);
UNPROTECT(3);
return result;


Accordingly you get:
l = .Call("my_C_function", other.input)
result_1 = l[[1]]
result_2 = l[[2]]


Cheers,
Simon



> thus, I thought I should NOT need to
> return any SEXP from my C function.  However, if I do that, it
> segfaults somewhere in "src/main/memory.c".
> 
> If I instead return the SEXP for one of my two result lists it appears
> to work fine...  But of course I don't understand what's going on here
> and so don't trust it.  The list SEXP I am returning was allocated by
> R, not by my C code, so why does it make any difference whether my C
> function returns it or not?
> 
>> From "src/main/names.c" I see that .Call is implemented by do_dotcall
> in "src/main/dotcode.c".  I don't necessarily understand what that
> really does, but AFAICT if my C function returns nothing, the
> do_dotcall's retval should simply remain set to R_NilValue, which
> should be fine.
> 
> I must be misunderstanding something here, but I don't know what, and
> would definitely appreciate any help.  Thanks!
> 
> 
> My R code looks like this:
> 
>  result.1 <- vector("list" ,1e6)
>  result.2 <- vector("list" ,1e6)
>  .Call("my_C_function", result.1, result.2, other.input)
> 
> My C code looks like this:
> 
>  SEXP result_v; 
>  result_v = Rf_allocVector(REALSXP, 5); 
>  SET_VECTOR_ELT(result_list_1, k1, result_v); 
>  REAL(result_v)[0] = some_number; 
>  REAL(result_v)[1] = another_number; 
>  /* Also do the same sort of thing for result_list_2. */
>  return(result_list_1);  /* Appears to work ok. */
>  /* return; */  /* Segfaults. */
> 
> -- 
> Andrew Piskorski 
> http://www.piskorski.com/
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> 

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

[Rd] TEXINPUTS and Sweave

[Dominick Samperi]

Is there a way to set TEXINPUTS for CRAN builds so that style files shipped
with
packages can be found if they are not in the working directory?

Apparently there is an additional problem under Windows/MikTeX because
recent versions of MikTeX ignore TEXINPUTS!

Thanks,
Dominick

[[alternative HTML version deleted]]

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