[Rd] "size of shared memory region" messages show up with Rtools 3.1.0.1939

2013-11-20 Thread Dan Tenenbaum
Hi,

After installing Rtools 3.1.0.1939 into c:\rtools31, when I call any (most?) of 
the commands in c:\rtools31\bin, I see strange messages printed to stderr. 
Example:

C:\Rtools31>bin\tar
  0 [main] tar 6084 shared_info::initialize: size of shared memory region 
changed from 27984 to 21136
bin/tar: You must specify one of the `-Acdtrux' options
Try `bin/tar --help' or `bin/tar --usage' for more information.


Sometimes I see quite a few of these just from running a single command.

Can this be fixed?

Thanks,
Dan

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


Re: [Rd] "size of shared memory region" messages show up with Rtools 3.1.0.1939

2013-11-20 Thread Dan Tenenbaum


- Original Message -
> From: "Dan Tenenbaum" 
> To: "R-devel" 
> Sent: Wednesday, November 20, 2013 2:41:36 PM
> Subject: [Rd] "size of shared memory region" messages show up with Rtools 
> 3.1.0.1939
> 
> Hi,
> 
> After installing Rtools 3.1.0.1939 into c:\rtools31, when I call any
> (most?) of the commands in c:\rtools31\bin, I see strange messages
> printed to stderr. Example:
> 
> C:\Rtools31>bin\tar
>   0 [main] tar 6084 shared_info::initialize: size of shared
>   memory region changed from 27984 to 21136
> bin/tar: You must specify one of the `-Acdtrux' options
> Try `bin/tar --help' or `bin/tar --usage' for more information.
> 
> 
> Sometimes I see quite a few of these just from running a single
> command.
> 

It seems this is more than cosmetic; simple commands seem to fail:

E:\sandbox>cp c:\Users\biocbuild\Downloads\iClusterPlus_0.99.8.2.tar.gz .
  1 [main] cp 3348 shared_info::initialize: size of shared memory region 
changed from 27984 to 21136
15001297 [main] cp 3348 c:\Rtools31\bin\cp.exe: *** fatal error - add_item 
("\??\c:\Rtools 31", "/", ...) failed, errno 1
Stack trace:
Frame Function  Args

I am reverting back to my previous version of Rtools for now, till I hear that 
this has been addressed.

Thanks,
Dan



> Can this be fixed?
> 
> Thanks,
> Dan
> 
> __
> 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] "size of shared memory region" messages show up with Rtools 3.1.0.1939

2013-11-20 Thread Dan Tenenbaum


- Original Message -
> From: "Dan Tenenbaum" 
> To: "R-devel" 
> Sent: Wednesday, November 20, 2013 2:49:24 PM
> Subject: Re: [Rd] "size of shared memory region" messages show up with Rtools 
> 3.1.0.1939
> 
> 
> 
> - Original Message -
> > From: "Dan Tenenbaum" 
> > To: "R-devel" 
> > Sent: Wednesday, November 20, 2013 2:41:36 PM
> > Subject: [Rd] "size of shared memory region" messages show up with
> > Rtools 3.1.0.1939
> > 
> > Hi,
> > 
> > After installing Rtools 3.1.0.1939 into c:\rtools31, when I call
> > any
> > (most?) of the commands in c:\rtools31\bin, I see strange messages
> > printed to stderr. Example:
> > 
> > C:\Rtools31>bin\tar
> >   0 [main] tar 6084 shared_info::initialize: size of shared
> >   memory region changed from 27984 to 21136
> > bin/tar: You must specify one of the `-Acdtrux' options
> > Try `bin/tar --help' or `bin/tar --usage' for more information.
> > 
> > 
> > Sometimes I see quite a few of these just from running a single
> > command.
> > 
> 
> It seems this is more than cosmetic; simple commands seem to fail:
> 
> E:\sandbox>cp
> c:\Users\biocbuild\Downloads\iClusterPlus_0.99.8.2.tar.gz .
>   1 [main] cp 3348 shared_info::initialize: size of shared memory
>   region changed from 27984 to 21136
> 15001297 [main] cp 3348 c:\Rtools31\bin\cp.exe: *** fatal error -
> add_item ("\??\c:\Rtools 31", "/", ...) failed, errno 1
> Stack trace:
> Frame Function  Args
> 
> I am reverting back to my previous version of Rtools for now, till I
> hear that this has been addressed.
> 

Rebooting the machine seems to have cleared up the problem. I'm now running 
version 3.1.0.1939 without any issues.
Dan


> Thanks,
> Dan
> 
> 
> 
> > Can this be fixed?
> > 
> > Thanks,
> > Dan
> > 
> > __
> > 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
>

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


[Rd] [PATCH] suggestions for R-lang manual

2013-11-20 Thread Scott Kostyshak
Attached is a patch with suggestions for the R-lang manual at r64277.

Below are a few comments (some are implemented in the patch):

In the section "Objects", there is a table introduced by "The
following table describes the possible values returned by typeof". One
of the results is "any". Can "any" be returned by "typeof()" ?

Regarding the "Recycling rules" section,

-One exception is that when adding vectors to matrices, a warning is not
-given if the lengths are incompatible.
-@c Is that a bug?
-

was this a bug that was fixed? I see the following behavior:

> myvec <- 1:3
> mymat <- matrix(1:12, ncol=2)
> myvec <- 1:5
> myvec + mymat
 [,1] [,2]
[1,]29
[2,]4   11
[3,]6   13
[4,]8   15
[5,]   10   12
[6,]7   14
Warning message:
In myvec + mymat :
  longer object length is not a multiple of shorter object length
>

Regarding

-The arguments in the call to the generic are rematched with the
-arguments for the method using the standard argument matching mechanism.
-The first argument, i.e.@: the object, will have been evaluated.
-

this information is duplicated. See a few paragraphs up "When the
method is invoked it is called..."

Scott


--
Scott Kostyshak
Economics PhD Candidate
Princeton University
Index: trunk/doc/manual/R-lang.texi
===
--- trunk/doc/manual/R-lang.texi(revision 64277)
+++ trunk/doc/manual/R-lang.texi(working copy)
@@ -1064,7 +1064,7 @@
 @cindex function
 @cindex function arguments
 Function calls can have @emph{tagged} (or @emph{named}) arguments, as in
-@code{plot(x, y, pch = 3)} arguments without tags are known as
+@code{plot(x, y, pch = 3)}.  Arguments without tags are known as
 @emph{positional} since the function must distinguish their meaning from
 their sequential positions among the arguments of the call, e.g., that
 @code{x} denotes the abscissa variable and @code{y} the ordinate.  The
@@ -1308,10 +1308,10 @@
 ignored.  If @var{value1} has any type other than a logical or a numeric
 vector an error is signalled.
 
-If/else statements can be used to avoid numeric problems such as taking
-the logarithm of a negative number.  Because if/else statements are the
-same as other statements you can assign the value of them.  The two
-examples below are equivalent.
+@code{if}/@code{else} statements can be used to avoid numeric problems
+such as taking the logarithm of a negative number.  Because
+@code{if}/@code{else} statements are the same as other statements you
+can assign the value of them.  The two examples below are equivalent.
 
 @example
 > if( any(x <= 0) ) y <- log(1+x) else y <- log(x)
@@ -1327,7 +1327,7 @@
 compound statement wrapped in braces, putting the @code{else} on the
 same line as the closing brace that marks the end of the statement.
 
-If/else statements can be nested.
+@code{if}/@code{else} statements can be nested.
 
 @example
 if ( @var{statement1} ) @{
@@ -1342,7 +1342,7 @@
 
 One of the even numbered statements will be evaluated and the resulting
 value returned.  If the optional @code{else} clause is omitted and all
-the odd numbered @var{statement}'s evaluate to @code{FALSE} no statement
+the odd numbered @var{statement}s evaluate to @code{FALSE} no statement
 will be evaluated and @code{NULL} is returned.
 
 The odd numbered @var{statement}s are evaluated, in order, until one
@@ -1378,7 +1378,7 @@
 of the loop (if there is one) is then executed.  No statement below
 @code{next} in the current loop is evaluated.
 
-The value returned by a loop statement statement is always @code{NULL}
+The value returned by a loop statement is always @code{NULL}
 and is returned invisibly.
 
 @node repeat, while, Looping, Control structures
@@ -1451,7 +1451,7 @@
 where the elements of @var{list} may be named.  First, @var{statement}
 is evaluated and the result, @var{value}, obtained.  If @var{value} is a
 number between 1 and the length of @var{list} then the corresponding
-element @var{list} is evaluated and the result returned.  If @var{value}
+element of @var{list} is evaluated and the result returned.  If @var{value}
 is too large or too small @code{NULL} is returned.
 
 @example
@@ -1530,10 +1530,6 @@
 As from @R{} 1.4.0, any arithmetic operation involving a zero-length
 vector has a zero-length result.
 
-One exception is that when adding vectors to matrices, a warning is not
-given if the lengths are incompatible.
-@c Is that a bug?
-
 @node Propagation of names, Dimensional attributes, Recycling rules, 
Elementary arithmetic operations
 @subsection Propagation of names
 @cindex name
@@ -1842,7 +1838,7 @@
 matching.
 
 The most important example of a class method for @code{[} is that used
-for data frames.  It is not be described in detail here (see the help
+for data frames.  It is not described in detail here (see the help
 page for @code{[.data.frame}, but in broad terms, if two indices are
 supplied (even if one is empty) it creates matrix-like indexing

[Rd] Running R embedded in an mpiexec spawned process - Fatal error: you must specify '--save', '--no-save' or '--vanilla'

2013-11-20 Thread Jean-Michel.Perraud
I'd like someone familiar with the R options initialization to comment on a 
difference of behavior within/without mpiexec

I have a (.NET) application with embedded R that is proven to run in a single 
process:

./Sample1.exe

on a Debian Linux with R 3.0.2

Running the same code with mpiexec, it fails at the R engine initialization:

mpiexec -n 1 ./Sample1.exe
Fatal error: you must specify '--save', '--no-save' or '--vanilla'
-

The behavior is actually reproducible with the straight R 
mpiexec -n 1 R
Fatal error: you must specify '--save', '--no-save' or '--vanilla'
-
The following is working:
mpiexec -n 1 R --no-save

However in my Sample1 application, I do set up R init options that should be 
suitable AFAIK:

rEngine = REngine.CreateInstance("RDotNet");
StartupParameter rStartParams = new StartupParameter
{
Quiet = true,
SaveAction = StartupSaveAction.NoSave,
Slave = false,
Interactive = true,
Verbose = false,
LoadInitFile = true,
LoadSiteFile = true,
RestoreAction = StartupRestoreAction.NoRestore,
NoRenviron = false
};
rEngine.Initialize(rStartParams); // calls the R API R_SetParams, 
then setup_Rmainloop


I gather that the following is hit in src/R-3.0.2/src/unix/system.c, in the 
function Rf_initialize_R:

if (!R_Interactive && Rp->SaveAction != SA_SAVE &&
Rp->SaveAction != SA_NOSAVE)
R_Suicide(_("you must specify '--save', '--no-save' or '--vanilla'"));

I don't understand why it would complain if spawned by mpiexec and fine 
otherwise. 

I do not have a suitable debugging environment to step through a R with debug 
symbols, and no stack trace is given as console output.
As an aside, the same code (barring platform specifics) works on Windows.

Thanks




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


Re: [Rd] Running R embedded in an mpiexec spawned process - Fatal error: you must specify '--save', '--no-save' or '--vanilla'

2013-11-20 Thread Prof Brian Ripley

On 21/11/2013 06:39, jean-michel.perr...@csiro.au wrote:

I'd like someone familiar with the R options initialization to comment on a 
difference of behavior within/without mpiexec



I have a (.NET) application with embedded R that is proven to run in a single 
process:

 ./Sample1.exe

on a Debian Linux with R 3.0.2

Running the same code with mpiexec, it fails at the R engine initialization:

 mpiexec -n 1 ./Sample1.exe
 Fatal error: you must specify '--save', '--no-save' or '--vanilla'
 -

The behavior is actually reproducible with the straight R
 mpiexec -n 1 R
 Fatal error: you must specify '--save', '--no-save' or '--vanilla'
 -
The following is working:
 mpiexec -n 1 R --no-save

However in my Sample1 application, I do set up R init options that should be 
suitable AFAIK:

 rEngine = REngine.CreateInstance("RDotNet");
 StartupParameter rStartParams = new StartupParameter
 {
 Quiet = true,
 SaveAction = StartupSaveAction.NoSave,
 Slave = false,
 Interactive = true,
 Verbose = false,
 LoadInitFile = true,
 LoadSiteFile = true,
 RestoreAction = StartupRestoreAction.NoRestore,
 NoRenviron = false
 };
 rEngine.Initialize(rStartParams); // calls the R API R_SetParams, 
then setup_Rmainloop


I gather that the following is hit in src/R-3.0.2/src/unix/system.c, in the 
function Rf_initialize_R:

 if (!R_Interactive && Rp->SaveAction != SA_SAVE &&
Rp->SaveAction != SA_NOSAVE)
R_Suicide(_("you must specify '--save', '--no-save' or '--vanilla'"));

I don't understand why it would complain if spawned by mpiexec and fine 
otherwise.


Most likely because the way you are running R is considered to be batch 
use, and R_Interactive is false.  You've mixed up two scenarios here: 
one an embedded use where we don't have all the code, and mpiexec.  In 
the mpiexec case, it is likely that stdin is not a ptty.



I do not have a suitable debugging environment to step through a R with debug 
symbols, and no stack trace is given as console output.
As an aside, the same code (barring platform specifics) works on Windows.


Deciding if Rterm is interactive is clearly done differently on an OS 
without pttys.



--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

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


Re: [Rd] Running R embedded in an mpiexec spawned process - Fatal error: you must specify '--save', '--no-save' or '--vanilla'

2013-11-20 Thread Gabriel Becker
I don't have any real answers for you. Perhaps someone with more experience
will.

This may be an R.NET issue though. I'm suprised that from your comment, and
a very brief glance at R.NET's sourcecode,  it is calling setup_Rmainloop.
I've successfully embedded R in C programs and the entrypoint I always used
was Rf_initEmbeddedR. My understanding is that setup_Rmainloop is for the
non-embedded case (R running itself).

Perhaps I'm wrong and using setup_Rmainloop is supported in the embedded
case as well as Rf_initEmbeddedR. If not I can't offer any insight to why
it usually works anyway other than Dr. Ripleys suggestion about stdin and
mpiexec.

Sorry I can't be of more help.
~G


On Wed, Nov 20, 2013 at 10:39 PM,  wrote:

> I'd like someone familiar with the R options initialization to comment on
> a difference of behavior within/without mpiexec
>
> I have a (.NET) application with embedded R that is proven to run in a
> single process:
>
> ./Sample1.exe
>
> on a Debian Linux with R 3.0.2
>
> Running the same code with mpiexec, it fails at the R engine
> initialization:
>
> mpiexec -n 1 ./Sample1.exe
> Fatal error: you must specify '--save', '--no-save' or '--vanilla'
>
> -
>
> The behavior is actually reproducible with the straight R
> mpiexec -n 1 R
> Fatal error: you must specify '--save', '--no-save' or '--vanilla'
>
> -
> The following is working:
> mpiexec -n 1 R --no-save
>
> However in my Sample1 application, I do set up R init options that should
> be suitable AFAIK:
>
> rEngine = REngine.CreateInstance("RDotNet");
> StartupParameter rStartParams = new StartupParameter
> {
> Quiet = true,
> SaveAction = StartupSaveAction.NoSave,
> Slave = false,
> Interactive = true,
> Verbose = false,
> LoadInitFile = true,
> LoadSiteFile = true,
> RestoreAction = StartupRestoreAction.NoRestore,
> NoRenviron = false
> };
> rEngine.Initialize(rStartParams); // calls the R API
> R_SetParams, then setup_Rmainloop
>
>
> I gather that the following is hit in src/R-3.0.2/src/unix/system.c, in
> the function Rf_initialize_R:
>
> if (!R_Interactive && Rp->SaveAction != SA_SAVE &&
> Rp->SaveAction != SA_NOSAVE)
> R_Suicide(_("you must specify '--save', '--no-save' or
> '--vanilla'"));
>
> I don't understand why it would complain if spawned by mpiexec and fine
> otherwise.
>
> I do not have a suitable debugging environment to step through a R with
> debug symbols, and no stack trace is given as console output.
> As an aside, the same code (barring platform specifics) works on Windows.
>
> Thanks
>
>
>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis

[[alternative HTML version deleted]]

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