[Rd] Rscript temp file

[Vadim Organovich]

Hi,

It seems that Rscript creates a temporary file to store the commands passed 
with the -e  option, under normal circumstances the temp  file gets deleted at 
some point.

Here is an example of a call I use:
q:/R/R-2.6.1/bin/Rscript.exe -e ".libPaths(\"q:/R/vogranovich/library\"); 
params <- list(a=1); source(foo)"

The temp files seem to be a problem when multiple jobs are run simultaneously. 
I suspect that when two Rscripts are run at almost the same time they try to 
create the same tepm file and clash over it, which causes one or both of them 
to die.

Is my guesswork corect? If yes, is there a way to avoid the clash, say by 
specifying which directory to use for temp files?

Thanks,
Vadim

[[alternative HTML version deleted]]

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

[Rd] crash in library(gbm) was: Rscript temp file

[Vadim Organovich]

The crashes turned out to have nothing to do with the temp files. They seem to 
be caused by loading library(gbm). That is when many R sessions nearly 
simultaneously load the library R crashes with the message "The instruction at 
'0x63422398' referenced memory at '0x63422398'. The required data was not 
placed into memory because of an I/O error status of '0xc20c'".

Does anyone have an idea what that might mean?

I am not able to reproduce it in controlled environment. This is Windows.

Thanks,
Vadim



From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Vadim Organovich [EMAIL 
PROTECTED]
Sent: Friday, February 15, 2008 2:29 PM
To: r-devel@r-project.org
Subject: [Rd] Rscript temp file

Hi,

It seems that Rscript creates a temporary file to store the commands passed 
with the -e  option, under normal circumstances the temp  file gets deleted at 
some point.

Here is an example of a call I use:
q:/R/R-2.6.1/bin/Rscript.exe -e ".libPaths(\"q:/R/vogranovich/library\"); 
params <- list(a=1); source(foo)"

The temp files seem to be a problem when multiple jobs are run simultaneously. 
I suspect that when two Rscripts are run at almost the same time they try to 
create the same tepm file and clash over it, which causes one or both of them 
to die.

Is my guesswork corect? If yes, is there a way to avoid the clash, say by 
specifying which directory to use for temp files?

Thanks,
Vadim

[[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

[Rd] forcing gc() to do its work

[Vadim Organovich]

Hi,

At some points of my computations I want gc() to try really hard and collect as 
many objects as possible even though the triggering limits are not hit. Will it 
help if I temporarily set the limits to some small values, call gc() and then 
reset them back to their original values? What variables exactly need to be 
set?  Does anyone have a prototype of such function?

I tried to read the R help, e.g. Memory and memory.limits(), but I am not sure 
I understand how this applies to my case.

Thanks,
Vadim

[[alternative HTML version deleted]]

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

[Rd] how to write dput-able objects

[Vadim Organovich]

Hi,

One way of doing object-oriented programming in R is to use function 
environment to hold object's data, see for example
@Article{Rnews:Chambers+Lang:2001a,
  author   = {John M. Chambers and Duncan Temple Lang},
  title= {Object-Oriented Programming in {R}},
  journal  = {R News},
  year= 2001,
  volume   = 1,
  number   = 3,
  pages= {17--19},
  month= {September},
  url= http,
  pdf= Rnews2001-3
}

One deficiency of this approach is that dput() does not export all data 
pertained to the object. For example

> objfactory <- function(nm) {
+   list(name = function() nm)
+ }
>
>
> obj <- objfactory('foo')
>
> obj$name()
[1] "foo"
> dput(obj)
structure(list(name = function ()
nm), .Names = "name")
As one can see the data piece of the obj, nm='foo', is not exported. Is there a 
way to modify the original approach so that dput() will produce a 
self-sufficient dump of the object?

Thanks,
Vadim

[[alternative HTML version deleted]]

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

Re: [Rd] how to write dput-able objects

[Vadim Organovich]

Thank you Gabor! This is very close indeed to what I need. If dput() were 
generic one could code dput.proto() and that would be it.

Anyway, it is so close to what I need that I should be able to hack someting to 
make it work for my purposes. Thanks again!

Vadim


From: Gabor Grothendieck [EMAIL PROTECTED]
Sent: Monday, February 25, 2008 12:16 PM
To: Vadim Organovich
Cc: r-devel@r-project.org
Subject: Re: [Rd] how to write dput-able objects

You might want to look at the proto package.  proto objects won't
immediately dput either but it would not be hard to convert them to
restorable character strings because the proto methods normally
have their object as their parent environment so its implicit in the
definition.  First define a proto object p with one variable 'a' and one
method 'f' and a child object, q, whose 'a' component overrides the
'a' in its parent.

> library(proto)
> p <- proto(a=1, f = function(.) .$a <- .$a + 1)
> q <- p$proto(a = 2)
> p$as.list()
$a
[1] 1

$f
function(.) .$a <- .$a + 1


> name.proto(p)
[1] "p"
> name.proto(p$parent.env())
[1] "R_GlobalEnv"
> q$as.list()
$a
[1] 2

> name.proto(q)
[1] "q"
> name.proto(q$parent.env())
[1] "p"

Note that the strings above have everything
you would need to restore them.  We don't
need the environment since we already know that
f's environment must be p as it belongs to p.

On Mon, Feb 25, 2008 at 12:47 PM, Vadim Organovich
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> One way of doing object-oriented programming in R is to use function 
> environment to hold object's data, see for example
> @Article{Rnews:Chambers+Lang:2001a,
>  author   = {John M. Chambers and Duncan Temple Lang},
>  title= {Object-Oriented Programming in {R}},
>  journal  = {R News},
>  year= 2001,
>  volume   = 1,
>  number   = 3,
>  pages= {17--19},
>  month= {September},
>  url= http,
>  pdf= Rnews2001-3
> }
>
> One deficiency of this approach is that dput() does not export all data 
> pertained to the object. For example
>
> > objfactory <- function(nm) {
> +   list(name = function() nm)
> + }
> >
> >
> > obj <- objfactory('foo')
> >
> > obj$name()
> [1] "foo"
> > dput(obj)
> structure(list(name = function ()
> nm), .Names = "name")
> As one can see the data piece of the obj, nm='foo', is not exported. Is there 
> a way to modify the original approach so that dput() will produce a 
> self-sufficient dump of the object?
>
> Thanks,
> Vadim
>
>[[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

[Rd] error loading library

[Vadim Organovich]

Hi,

I am debugging intermittent crashes of R that seem to happen when multiple R 
sessions nearly summaltaneously load same dll-based library.

I have R and my libraries installed on a network drive (everything is Windows). 
The drive is visible from a farm of servers. I have an R script, foo.R, that 
just loads a dll-based library (to be precise it loads a library that requires 
a dll-based library). When I start R (via Rscript --vanilla foo.R) from all of 
the farm computers summaltaneously some of the sessions often crash. It doesn't 
seem to be specific to the library, I was able to reproduce this with the gbm 
library as well as with my own library. It feels that the longer it takes to 
load the library the higher the probability of the crash.

foo.R :
library(vmisc)

The most informative error message I've got so far looks like this, here vmisc 
dll is the required library that dynamically loads a dll.

Loading required package: vmiscdll
Error in file(file, "r") : unable to open connection
In addition: Warning message:
In file(file, "r") :
  cannot open file 'q:/R/vogranovich/library/vmisc/R/vmisc', reason 'Permission 
denied'
Error : unable to load R code in package 'vmisc'
Error: package/namespace load failed for 'vmisc'
Execution halted
Exit Code 1 - Process forcefully killed by the TestMaster
In stand alone sessions, interactive or not, everything loads fine.

Does loading a library place some sort of a lock?

I would appreciate any help with this matter.

Regards,
Vadim

[[alternative HTML version deleted]]

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

[Rd] clean-up actions after non-local exits

[Vadim Organovich]

Dear R-devel,



Some time ago I started a thread that boiled down to clean-up actions after 
non-local exits in R, see below. I wonder if there has been any progress on 
this? R-ext 2.6.1 doesn't say much on the subject.



How, for example, do people deal with a situation where their C (C++) function 
opens a file and then receives a signal or  longjump-s on error(), how do they 
make sure the file is eventually closed?



Thanks,

Vadim



On Mon, 14 Jun 2004, Vadim Ogranovich wrote:

> This is disappointing. How on Earth can mkChar know when it is safe or
> not to make a long jump? For example if I just opened a file how am I
> supposed to close it after the long jump? I am not even talking about
> C++ where long jumps are simply devastating... (and this is the language
> I am coding in :-( )
>
> Ok. A practical question: is it possible to somehow block
> R_CheckUserInterrupt? I am ready to put up with out-of-memory errors,
> but Ctrl-C is too common to be ignored.

Interrupts are not the issue. The issue is making sure that cleanup
actions occur even if there is a non-local exit. A solution that
addresses that issue will work for any non-local exit, whether it
comes from an interrupt or an exception. So you don't have to put up
with anything if you approach this the right way,

Currently there is no user accessible C level try/finally mechanism
for insuring that cleanup code is executed during a non-local exit.
We should make such a mechanicm available; maybe one will make it into
the next major release.

For now you have two choices:

You can create an R level object and attach a finalizer to the object
that will arrange for the GC to close the file at some point in the
future if a non-local exit occurs. Search developer.r-project.org for
finalization and weak references for some info on this.

One other option is to use the R_ToplevelExec function. This has some
drawbacks since it effectively makes invisible all other error
handlers, but it is an option. It is also not officially documented
and subject to change.

> And I think it makes relevant again the question I asked in another
> related thread: how is memory allocated by Calloc() and R_alloc() stand
> up against long jumps?

R_alloc is stack-based; the stack is unwound on a non-local exit, so
this is released on regular exits and non-local ones. It uses R
allocation, so it could itself cause a non-local exit.

Calloc is like calloc but will never return NULL. If the allocation
fails, then an error is signaled, which will result in a non-local
exit. If the allocation succeeds, you are responsable for calling
Free.

luke

> > -Original Message-
> > From: Luke Tierney [mailto:[EMAIL PROTECTED] > PROTECTED]:%20%5BR%5D%20mkChar%20can%20be%20interrupted>]
> > Sent: Monday, June 14, 2004 5:43 PM
> > To: Vadim Ogranovich
> > Cc: R-Help
> > Subject: RE: [R] mkChar can be interrupted
> >
> > On Mon, 14 Jun 2004, Vadim Ogranovich wrote:
> >
> > > I am confused. Here is an excerpt from R-exts:
> > >
> > > "As from R 1.8.0 no port of R can be interrupted whilst
> > running long
> > > computations in compiled code,..."
> > >
> > > Doesn't it imply that the primitive functions like allocVector,
> > > mkChar, etc., which are likely to occur in any compiled code called
> > > via .Call, are not supposed to handle interrupts in any way?
> >
> > No it does not. Read the full context. It says that if you
> > wite a piece of C code that may run a long time and you want
> > to guarantee that users will be able to interrupt your code
> > then you should insure that R_CheckUserInterrupt is called
> > periodically. If your code already periodically calls other
> > R code that checks for interrupts then you may not need to do
> > this yourself, but in general you do.
> >
> > Prior to 1.8.0 on Unix-like systems the asynchronous signal
> > handler for SIGINT would longjmp to the nearest top level or
> > browser context, which meant that on these sytems any code
> > was interruptible at any point unless it was explicitly
> > protected by a construct that suspended interrupts. Allowing
> > interrupts at any point meant that inopportune interrupts
> > could and did crash R, which is why this was changed.
> >
> > Unless there is explicit documentation to the contrary you
> > should assume that every function in the R API might allocate
> > and might cause a non-local exit (i.e. a longjmp) when an
> > exception is raised (and an interrupt is one of, but only one
> > of, the exceptions that might occur).
> >
> > luke
> >
> > > Thanks,
> > > Vadim
> > >
> > >
> > > > From: Luke Tierney [mailto:[EMAIL PROTECTED] > > > PROTECTED]:%20%5BR%5D%20mkChar%20can%20be%20interrupted>]
> > > >
> > > > On Mon, 14 Jun 2004, Vadim Ogranovich wrote:
> > > >
> > > > > > From: Luke Tierney [mailto:[EMAIL PROTECTED] > > > > > PROTECTED]:%20%5BR%5D%20mkChar%20can%20be%20interrupted>]
> > > ...
> > > > > >
> >

Re: [Rd] clean-up actions after non-local exits

[Vadim Organovich]

This is good, thanks!

I'd like to be able to make sure that the resource is released in conrolled 
fasion rather than at some arbitrary gc() call time. Will the following trick 
achieve the goal:

foo <-function(whatever) {
 on.exit(gc())
 ## arrange for an external pointer, don't know how yet
 ...
 ## actual call
 .Call(whatever)
}

The idea is to have gc() called on exit.

I seem to recall that a call to gc() doesn't guarantee that all possibly 
collectable objects are actually collected, which will defeat my solution. Is 
that correct?

Thanks,
Vadim


From: Duncan Murdoch [EMAIL PROTECTED]
Sent: Monday, April 14, 2008 3:53 PM
To: Vadim Organovich
Cc: r-devel@r-project.org
Subject: Re: [Rd] clean-up actions after non-local exits

On 14/04/2008 4:33 PM, Vadim Organovich wrote:
> Dear R-devel,
>
>
>
> Some time ago I started a thread that boiled down to clean-up actions after 
> non-local exits in R, see below. I wonder if there has been any progress on 
> this? R-ext 2.6.1 doesn't say much on the subject.
>
>
>
> How, for example, do people deal with a situation where their C (C++) 
> function opens a file and then receives a signal or  longjump-s on error(), 
> how do they make sure the file is eventually closed?

The finalizer code that Luke mentioned is more easily accessible now
than it was in 2004.  See the section on external pointers and weak
references in the Writing R Extensions manual.

The idea would be to create an external pointer object that controls the
resource.  If there's an error, at the next GC the external pointer will
be finalized and that's where the cleanup can happen.

Duncan Murdoch

>
>
> Thanks,
>
> Vadim
>
>
>
> On Mon, 14 Jun 2004, Vadim Ogranovich wrote:
>
>> This is disappointing. How on Earth can mkChar know when it is safe or
>> not to make a long jump? For example if I just opened a file how am I
>> supposed to close it after the long jump? I am not even talking about
>> C++ where long jumps are simply devastating... (and this is the language
>> I am coding in :-( )
>>
>> Ok. A practical question: is it possible to somehow block
>> R_CheckUserInterrupt? I am ready to put up with out-of-memory errors,
>> but Ctrl-C is too common to be ignored.
>
> Interrupts are not the issue. The issue is making sure that cleanup
> actions occur even if there is a non-local exit. A solution that
> addresses that issue will work for any non-local exit, whether it
> comes from an interrupt or an exception. So you don't have to put up
> with anything if you approach this the right way,
>
> Currently there is no user accessible C level try/finally mechanism
> for insuring that cleanup code is executed during a non-local exit.
> We should make such a mechanicm available; maybe one will make it into
> the next major release.
>
> For now you have two choices:
>
> You can create an R level object and attach a finalizer to the object
> that will arrange for the GC to close the file at some point in the
> future if a non-local exit occurs. Search developer.r-project.org for
> finalization and weak references for some info on this.
>
> One other option is to use the R_ToplevelExec function. This has some
> drawbacks since it effectively makes invisible all other error
> handlers, but it is an option. It is also not officially documented
> and subject to change.
>
>> And I think it makes relevant again the question I asked in another
>> related thread: how is memory allocated by Calloc() and R_alloc() stand
>> up against long jumps?
>
> R_alloc is stack-based; the stack is unwound on a non-local exit, so
> this is released on regular exits and non-local ones. It uses R
> allocation, so it could itself cause a non-local exit.
>
> Calloc is like calloc but will never return NULL. If the allocation
> fails, then an error is signaled, which will result in a non-local
> exit. If the allocation succeeds, you are responsable for calling
> Free.
>
> luke
>
>>> -Original Message-
>>> From: Luke Tierney [mailto:[EMAIL PROTECTED]<mailto:[EMAIL 
>>> PROTECTED]:%20%5BR%5D%20mkChar%20can%20be%20interrupted>]
>>> Sent: Monday, June 14, 2004 5:43 PM
>>> To: Vadim Ogranovich
>>> Cc: R-Help
>>> Subject: RE: [R] mkChar can be interrupted
>>>
>>> On Mon, 14 Jun 2004, Vadim Ogranovich wrote:
>>>
>>>> I am confused. Here is an excerpt from R-exts:
>>>>
>>>> "As from R 1.8.0 no port of R can be interrupted whilst
>>> running long
>>>> computations in compiled code,..."
>>>>

Re: [Rd] clean-up actions after non-local exits

[Vadim Organovich]

Thank you, Luke!

Regarding user interrupts. R-ext mentions that those could be suppressed by 
setting R_SignalHandlers to 0. So if I do so in my clean up code I should be 
good, shouldn't I?

Thanks,
Vadim


From: Luke Tierney [EMAIL PROTECTED]
Sent: Monday, April 14, 2008 6:57 PM
To: Vadim Organovich
Cc: r-devel@r-project.org
Subject: Re: [Rd] clean-up actions after non-local exits

On Mon, 14 Apr 2008, Vadim Organovich wrote:

> This is good, thanks!
>
> I'd like to be able to make sure that the resource is released in conrolled 
> fasion rather than at some arbitrary gc() call time. Will the following trick 
> achieve the goal:
>
> foo <-function(whatever) {
> on.exit(gc())
> ## arrange for an external pointer, don't know how yet
> ...
> ## actual call
> .Call(whatever)
> }
>
> The idea is to have gc() called on exit.
>
> I seem to recall that a call to gc() doesn't guarantee that all possibly 
> collectable objects are actually collected, which will defeat my solution. Is 
> that correct?

It would not be safe to rely on gc runing the finalizer at precisely
this time.  Probably it does now, but that may not always remain true.

If you are prepared to use R level wrappers with on.exit code, or
tryCatch with a finally clause, the I would use those to call your
cleanup code directly.  That is nearly guaranteed to succeed.  The
exception is that it is currently possible for a user interrupt (or a
timer interrupt in R 2.7 and up) to be handled in the running of the
interpreted part of the on.exit/finally code.  At some point there
will be an R-level mechanism for selectively disabling and then
re-enabling interrupts (and maybe that will be used by default in
conjunction with tryCatch or on.exit, but that needs thinking
though).  Until then if you need a stronger guarantee I would add the
finalizer option as a backup and let the GC call it when it gets to
it.

luke


>
> Thanks,
> Vadim
>
> ____
> From: Duncan Murdoch [EMAIL PROTECTED]
> Sent: Monday, April 14, 2008 3:53 PM
> To: Vadim Organovich
> Cc: r-devel@r-project.org
> Subject: Re: [Rd] clean-up actions after non-local exits
>
> On 14/04/2008 4:33 PM, Vadim Organovich wrote:
>> Dear R-devel,
>>
>>
>>
>> Some time ago I started a thread that boiled down to clean-up actions after 
>> non-local exits in R, see below. I wonder if there has been any progress on 
>> this? R-ext 2.6.1 doesn't say much on the subject.
>>
>>
>>
>> How, for example, do people deal with a situation where their C (C++) 
>> function opens a file and then receives a signal or  longjump-s on error(), 
>> how do they make sure the file is eventually closed?
>
> The finalizer code that Luke mentioned is more easily accessible now
> than it was in 2004.  See the section on external pointers and weak
> references in the Writing R Extensions manual.
>
> The idea would be to create an external pointer object that controls the
> resource.  If there's an error, at the next GC the external pointer will
> be finalized and that's where the cleanup can happen.
>
> Duncan Murdoch
>
>>
>>
>> Thanks,
>>
>> Vadim
>>
>>
>>
>> On Mon, 14 Jun 2004, Vadim Ogranovich wrote:
>>
>>> This is disappointing. How on Earth can mkChar know when it is safe or
>>> not to make a long jump? For example if I just opened a file how am I
>>> supposed to close it after the long jump? I am not even talking about
>>> C++ where long jumps are simply devastating... (and this is the language
>>> I am coding in :-( )
>>>
>>> Ok. A practical question: is it possible to somehow block
>>> R_CheckUserInterrupt? I am ready to put up with out-of-memory errors,
>>> but Ctrl-C is too common to be ignored.
>>
>> Interrupts are not the issue. The issue is making sure that cleanup
>> actions occur even if there is a non-local exit. A solution that
>> addresses that issue will work for any non-local exit, whether it
>> comes from an interrupt or an exception. So you don't have to put up
>> with anything if you approach this the right way,
>>
>> Currently there is no user accessible C level try/finally mechanism
>> for insuring that cleanup code is executed during a non-local exit.
>> We should make such a mechanicm available; maybe one will make it into
>> the next major release.
>>
>> For now you have two choices:
>>
>> You can create an R level object and attach a finalizer to the object
>> that will arrange for the GC to close the file at some point in the
>>

[Rd] C++ complains abouct Rprintf signature

[Vadim Organovich]

Dear R-devel,

My g++ complains about the first argument to Rprintf being non-const char *. 
For example when compiling the line

Rprintf("hello world\n");

the following warning is emitted:
warning: deprecated conversion from string constant to 'char*'



Is there a reason for the non-const? It is curious that Rf_error, which is 
similar to RPrintf, is const.



If there is a need to keep it non-const in C please consider using the patch 
below in future releases.



Thanks,

Vadim

Patch to R-2.6.1/include/R_ext/Print.h

#ifdef  __cplusplus
extern "C" {
#define CONST const
#endif
void Rprintf(CONST char *, ...);
void REprintf(CONST char *, ...);
void Rvprintf(const char *, va_list);
void REvprintf(const char *, va_list);
#ifdef  __cplusplus
}
#undef CONST
#endif

[[alternative HTML version deleted]]

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

Re: [Rd] [R] shQuote and cat

[Vadim Organovich]

I feel like it now belongs to r-devel more than to r-help.

My output was garbled because I sent the original message as HTML, sorry about 
that.

Your output, "\"\\"a\\"\"", is what I get too. That is
 > cat(shQuote(shQuote(shQuote("a"))), '\n')
"\"\\"a\\"\""
, which I think should be "\"\\\"a\\\"\"".

Actually, the R's output, "\"\\"a\\"\"", is not even a valid string literal, 
that is
> x <- "\"\\"a\\"\""
fails.


Now, by cat() being the inverse of shQuote() I mean printing the same literal 
as it goes into shQuote, quotes included:
> cat(shQuote("a"), '\n')
"a"

whereas
> cat("a", '\n')
a  ## no quotes

If cat() is not the inverse of shQuote() in the above sense, what is?

Thanks,
Vadim

From: Duncan Murdoch [EMAIL PROTECTED]
Sent: Wednesday, July 23, 2008 1:10 PM
To: Vadim Organovich
Cc: [EMAIL PROTECTED]
Subject: Re: [R] shQuote and cat

On 7/23/2008 12:20 PM, Vadim Organovich wrote:
> Dear R-users,
>
> It is my understanding that cat(shQuote(a.string)) should print the origintal 
> a.string. Is this right?

No, cat(a.string) should print the original a.string.  shQuote(a.string)
adds quotes so that a.string can be used in the shell.

> I am not sure cat() correctly prints strings which are generated by 
> triple-shQuote():
>
>> shQuote(shQuote("a"))
> [1] "\"\\\"a\\\"\""
>> cat(shQuote(shQuote(shQuote("a"))), '\n')
> "\"\\"a\\"\""

That's a very strange result.  I tried the obsolete version of R that
you're using, and I didn't see it. I get this:

 > cat(shQuote(shQuote(shQuote("a"))), '\n')
"\"\\"a\\"\""

Duncan Murdoch

> As you can see the latter string has fewer quoting '\' than the former.
> cat() of double shQuote works as expected:
>
>> shQuote("a")
> [1] "\"a\""
>> cat(shQuote(shQuote("a")), '\n')
> "\"a\""
>> version
>_
> platform   i386-pc-mingw32
> arch   i386
> os mingw32
> system i386, mingw32
> status
> major  2
> minor  6.1
> year   2007
> month  11
> day26
> svn rev43537
> language   R
> version.string R version 2.6.1 (2007-11-26)
> Am I missing something?
>
> Thanks,
> Vadim
>
> 
> Note: This email is for the confidential use of the named addressee(s) only 
> and may contain proprietary, confidential or privileged information. If you 
> are not the intended recipient, you are hereby notified that any review, 
> dissemination or copying of this email is strictly prohibited, and to please 
> notify the sender immediately and destroy this email and any attachments. 
> Email transmission cannot be guaranteed to be secure or error-free. Jump 
> Trading, therefore, does not make any guarantees as to the completeness or 
> accuracy of this email or any attachments. This email is for informational 
> purposes only and does not constitute a recommendation, offer, request or 
> solicitation of any kind to buy, sell, subscribe, redeem or perform any type 
> of transaction of a financial product.
>
>   [[alternative HTML version deleted]]
>
> __
> [EMAIL PROTECTED] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

Note: This email is for the confidential use of the named addressee(s) only and 
may contain proprietary, confidential or privileged information. If you are not 
the intended recipient, you are hereby notified that any review, dissemination 
or copying of this email is strictly prohibited, and to please notify the 
sender immediately and destroy this email and any attachments.  Email 
transmission cannot be guaranteed to be secure or error-free.  Jump Trading, 
therefore, does not make any guarantees as to the completeness or accuracy of 
this email or any attachments.  This email is for informational purposes only 
and does not constitute a recommendation, offer, request or solicitation of any 
kind to buy, sell, subscribe, redeem or perform any type of transaction of a 
financial product.

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

Re: [Rd] [R] shQuote and cat

[Vadim Organovich]

It is precizely a shell command that I am trying to generate. To be specific 
let's try to have R 'output' the following shell command: 'echo "\"a\""'. This 
is is a valid command, at least in bash:
bash-3.2$ echo "\"a\""
"a"

Now in R:
> x <- 'echo "\"a\""'
> cat(x, '\n')
echo ""a""
> cat(shQuote(x), '\n')
"echo \"\"a\"\""

Whichever way you do it it is not right. Again I think cat('echo "\"a\""') 
should be printing *echo "\"a\""* (asterics are not a part of the output)

____
From: Duncan Murdoch [EMAIL PROTECTED]
Sent: Wednesday, July 23, 2008 2:38 PM
To: Vadim Organovich
Cc: r-devel@r-project.org
Subject: Re: [Rd] [R] shQuote and cat

On 7/23/2008 2:53 PM, Vadim Organovich wrote:
> I feel like it now belongs to r-devel more than to r-help.
>
> My output was garbled because I sent the original message as HTML, sorry 
> about that.
>
> Your output, "\"\\"a\\"\"", is what I get too. That is
>  > cat(shQuote(shQuote(shQuote("a"))), '\n')
> "\"\\"a\\"\""
> , which I think should be "\"\\\"a\\\"\"".
>
> Actually, the R's output, "\"\\"a\\"\"", is not even a valid string literal, 
> that is
>> x <- "\"\\"a\\"\""
> fails.

It's not intended to be a string literal in R, it's intended to be input
to the Windows CMD shell.  If you want a string literal in R, don't use
cat().  cat() shows you the naked contents of the string without any
quoting to make it a valid string literal.

>
>
> Now, by cat() being the inverse of shQuote() I mean printing the same literal 
> as it goes into shQuote, quotes included:
>> cat(shQuote("a"), '\n')
> "a"
>
> whereas
>> cat("a", '\n')
> a  ## no quotes
>
> If cat() is not the inverse of shQuote() in the above sense, what is?

On Unix-like systems I think asking the shell to echo the output, i.e.

system(paste("echo", shQuote(input)), intern=TRUE)

is intended to reproduce the input.  However, the Windows CMD shell is
different.  I don't know how to strip quotes off a string in it, e.g. I see

C:\WINDOWS\system32 echo "a"
"a"

Nevertheless, the quotes *are* necessary when passing filenames to
commands, and they'll typically be stripped off when doing that, e.g.

echo hi >"a"

will create a file named a, not named "a", and

echo hi >"a b"

will create a file with a space in the name.

Duncan Murdoch

Note: This email is for the confidential use of the named addressee(s) only and 
may contain proprietary, confidential or privileged information. If you are not 
the intended recipient, you are hereby notified that any review, dissemination 
or copying of this email is strictly prohibited, and to please notify the 
sender immediately and destroy this email and any attachments.  Email 
transmission cannot be guaranteed to be secure or error-free.  Jump Trading, 
therefore, does not make any guarantees as to the completeness or accuracy of 
this email or any attachments.  This email is for informational purposes only 
and does not constitute a recommendation, offer, request or solicitation of any 
kind to buy, sell, subscribe, redeem or perform any type of transaction of a 
financial product.

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

[Rd] names of return value of median

[Vadim Organovich]

Dear R-devel,

The median() function assigns a name, "NA", to its return value if the return 
value is NA and the input vector has names, otherwise the names attribute is 
NULL. This looks strange and inconsistent with the behavior of mean().

This inconsistency becomes a problem when median() is used inside user code 
that relies on consistent naming convention.

Thanks,
Vadim

> foo <- c(x=as.numeric(NA), y=as.numeric(NA), z=as.numeric(NA))
> names(mean(foo))
NULL
> names(median(foo))
[1] NA

## no names in input
> foo <- rep(as.numeric(NA), 3)
> names(median(foo))
NULL


> version
   _
platform   i386-pc-mingw32
arch   i386
os mingw32
system i386, mingw32
status
major  2
minor  7.1
year   2008
month  06
day23
svn rev45970
language   R
version.string R version 2.7.1 (2008-06-23)
>

Note: This email is for the confidential use of the named addressee(s) only and 
may contain proprietary, confidential or privileged information. If you are not 
the intended recipient, you are hereby notified that any review, dissemination 
or copying of this email is strictly prohibited, and to please notify the 
sender immediately and destroy this email and any attachments.  Email 
transmission cannot be guaranteed to be secure or error-free.  Jump Trading, 
therefore, does not make any guarantees as to the completeness or accuracy of 
this email or any attachments.  This email is for informational purposes only 
and does not constitute a recommendation, offer, request or solicitation of any 
kind to buy, sell, subscribe, redeem or perform any type of transaction of a 
financial product.

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

[Rd] row.names in data.frame with row.names NULL

[Vadim Organovich]

Dear R-devel,

It appears that data.frame ignores row.names=NULL argument if it can guess the 
names from the first column. This behavior seems to contradict what the help 
page says, see the last sentence:

 If row names are not supplied in the call to 'data.frame', the row
 names are taken from the first component that has suitable names,
 for example a named vector or a matrix with rownames or a data
 frame. (If that component is subsequently recycled, the names are
 discarded with a warning.)  If 'row.names' was supplied as 'NULL'
 or no suitable component was found the row names are the integer
 sequence starting at one (and such row names are considered to be
 'automatic', and not preserved by 'as.matrix').

Probably it should read "AND no suitable component was found ...", but I like 
the promise of the original description better.

Thanks,
Vadim


> row.names(data.frame(x=c(a=1,b=2), row.names=NULL))
[1] "a" "b"
> version
   _
platform   i386-pc-mingw32
arch   i386
os mingw32
system i386, mingw32
status
major  2
minor  7.1
year   2008
month  06
day23
svn rev45970
language   R
version.string R version 2.7.1 (2008-06-23)
>

Note: This email is for the confidential use of the named addressee(s) only and 
may contain proprietary, confidential or privileged information. If you are not 
the intended recipient, you are hereby notified that any review, dissemination 
or copying of this email is strictly prohibited, and to please notify the 
sender immediately and destroy this email and any attachments.  Email 
transmission cannot be guaranteed to be secure or error-free.  Jump Trading, 
therefore, does not make any guarantees as to the completeness or accuracy of 
this email or any attachments.  This email is for informational purposes only 
and does not constitute a recommendation, offer, request or solicitation of any 
kind to buy, sell, subscribe, redeem or perform any type of transaction of a 
financial product.

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

[Rd] lapply(NULL, ...) returns empty list

[Vadim Organovich]

Dear R-devel,

Is there a reason that lapply(NULL, ...) returns the empty list, rather than 
NULL? It seems intuitive to expect the latter, and rather counterintuitive that 
lapply(list(), ... ) returns the same value as lapply(NULL, ...).

> lapply(list(), function(x) 1)
list()
>  lapply(NULL, function(x) 1)
list()
> version
   _
platform   i386-pc-mingw32
arch   i386
os mingw32
system i386, mingw32
status
major  2
minor  7.1
year   2008
month  06
day23
svn rev45970
language   R
version.string R version 2.7.1 (2008-06-23)
>

Regards,
Vadim

Note: This email is for the confidential use of the named addressee(s) only and 
may contain proprietary, confidential or privileged information. If you are not 
the intended recipient, you are hereby notified that any review, dissemination 
or copying of this email is strictly prohibited, and to please notify the 
sender immediately and destroy this email and any attachments.  Email 
transmission cannot be guaranteed to be secure or error-free.  Jump Trading, 
therefore, does not make any guarantees as to the completeness or accuracy of 
this email or any attachments.  This email is for informational purposes only 
and does not constitute a recommendation, offer, request or solicitation of any 
kind to buy, sell, subscribe, redeem or perform any type of transaction of a 
financial product.

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