Skip to content

bad interaction between RandomFields 1.1.11 and Sweave

8 messages · Ben Bolker, Martin Schlather, Martin Maechler +3 more

Ben Bolker
# 
Not really a bug (I eventually discovered), but ...
  When running GaussRF()/DoSimulateRF() with n>1, the default pch="!" 
prints backspaces to the terminal, which causes problems (LaTeX barfs) if 
you're running this within an Sweave() job.  Setting RFparameters(pch="") 
fixes the problem.  
   Could put this in the documentation, but I don't know where you could 
put it that it would attract attention -- wouldn't have occurred to me to 
look at RFparameters before poking through the code to see where the ^H 
was coming from.
  
  I was going to suggest testing interactive() to see if the code was 
running in batch mode or not, but I just tried that with Sweave() and it 
thinks that interactive() is TRUE when running Sweave.  Oh well.  
Any one else have a solution?

  Ben Bolker
Martin Schlather
# 
Dear Ben,

I do not know how to solve the general problem that backspaces
cause within Sweave, but which are needed to implement running
counters.

To avoid the specific problems for RandomFields, a new version
of RandomFields is uploaded with default "pch="*" instead of
pch="!".

Cheers,
Martin
Ben Bolker wrote:

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Martin Maechler
    

    

      
      #
    

  


  

          

      
      
      
    

        
MartinS> Dear Ben,

    MartinS> I do not know how to solve the general problem that
    MartinS> backspaces cause within Sweave, but which are
    MartinS> needed to implement running counters.

aha!  now I understand more what you are talking about.

This is a more interesting problem, in general: It's not quite a
matter of if(interactive()) that Ben tried, but really you want
to find out if the stdout() connection you are using is a normal file
(where you don't need or want a running counter) or a 
user terminal where Martin Schlather applied the  1^H2^H... ('1' Backspace
'2' Backspace ..) trick.

Any ideas what can be done here, using our current  connection
tools -- or is there the need for something new?
Interesting topic!

Martin M?chler

PS. I know that strictly speaking the subject question is
 non-sense, since, at least on Unix-alikes, a console is a
 special file as well, and stdout is always a file.

  
  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
First, on an R console, stdout() is normally neither a `normal file' nor a 
`user terminal'.  Let alone under an embedded R ... or use under ESS
(where for you, Martin, it is neither).

On vanilla R under Unix-alikes (and Rterm but not otherwise) what stdout
is is a function of the C runtime system.  It's up to the C system if it
tells you what stdout has been redirected to, and if it can tell you
whether it is a terminal, or a pty (as used under some versions of Emacs) 
or a file or a socket ....  The information is at best unreliable.

interactive() is as good a test as we have, and I think if a better test 
is required in the interactive case, the user should be asked.

        
On Wed, 12 May 2004, Martin Maechler wrote:

        

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Martin Maechler
    

    

      
      #
    

  


  

          

      
      
      
    

        
BDR> First, on an R console, stdout() is normally neither a
    BDR> `normal file' nor a `user terminal'.  

strictly yes, but that was not the point.
I have been looking for an API we could use to find some useful
information, and the original topic was about Sweave where
there will a file {when in normal use}.

    BDR> Let alone under an embedded R ... or use under ESS (where for you,
    BDR> Martin, it is neither).

well, I knew this, but ESS (i.e. 'comint' in Emacs) is quite
good at behaving like a user terminal in many situations;
e.g the 'scp' (secure copy) "visual counter" works very nicely
in Emacs' *shell* buffers.

    BDR> On vanilla R under Unix-alikes (and Rterm but not
    BDR> otherwise) what stdout is is a function of the C
    BDR> runtime system.  It's up to the C system if it tells
    BDR> you what stdout has been redirected to, and if it can
    BDR> tell you whether it is a terminal, or a pty (as used
    BDR> under some versions of Emacs) or a file or a socket
    BDR> ....  The information is at best unreliable.

ok; that (the unreliabilty of the info you get) is bad news.
Thank you for the clarification.

    BDR> interactive() is as good a test as we have, and I think
    BDR> if a better test is required in the interactive case,
    BDR> the user should be asked.

we can live with that, but I think other softwares at least try
to do better here.

------------------

A completely different way, less nice in several ways, but maybe
more reliable:  There's a workaround we could start using here:
ESS has been setting
     options(STERM= ...)
for a while now to indicate to the S process which kind of
"terminal" (excuse the term) it is running in.

The ESS manual currently contains

            

      
      
      
    

        
and maybe we (R developers) should also consider setting some of
these (e.g. STERM = "Rgui" in that case) -- at least when the
info is available (and somewhat reliable) and even better think
about what else (better) could be done, working with  options()
settings as a workaround for this problem.

Also (for the original topic), maybe  Sweave() could set
options(STERM = 'Sweave') if options(STERM = 'BATCH) is not good
enough.  Then, code like Martin Schlather's use
      switch(getOption("STERM"), 
             "BATCH" =  { .........},
	     ....
	     )

        
BDR> On Wed, 12 May 2004, Martin Maechler wrote:

        
>> >>>>> "MartinS" == Martin Schlather <schlather@cu.lu>
    >> >>>>> on Wed, 12 May 2004 09:15:17 +0100 writes:
    >> 
    MartinS> Dear Ben,
    >>
    MartinS> I do not know how to solve the general problem that
    MartinS> backspaces cause within Sweave, but which are
    MartinS> needed to implement running counters.
    >>  aha!  now I understand more what you are talking about.
    >> 
    >> This is a more interesting problem, in general: It's not
    >> quite a matter of if(interactive()) that Ben tried, but
    >> really you want to find out if the stdout() connection
    >> you are using is a normal file (where you don't need or
    >> want a running counter) or a user terminal where Martin
    >> Schlather applied the 1^H2^H... ('1' Backspace '2'
    >> Backspace ..) trick.
    >> 
    >> Any ideas what can be done here, using our current
    >> connection tools -- or is there the need for something
    >> new?  Interesting topic!
    >> 
    >> Martin M?chler
    >> 
    >> PS. I know that strictly speaking the subject question is
    >> non-sense, since, at least on Unix-alikes, a console is a
    >> special file as well, and stdout is always a file.

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

  
  


  


      

    

    

      
      

        


  

        

      Friedrich Leisch
    

    

      
      #
    

  


  

          

      
      
      
    

        
> and maybe we (R developers) should also consider setting some of
  > these (e.g. STERM = "Rgui" in that case) -- at least when the
  > info is available (and somewhat reliable) and even better think
  > about what else (better) could be done, working with  options()
  > settings as a workaround for this problem.

yes

  > Also (for the original topic), maybe  Sweave() could set
  > options(STERM = 'Sweave')

fine with me, but ...

  > if options(STERM = 'BATCH) is not good
  > enough.  Then, code like Martin Schlather's use
  >       switch(getOption("STERM"), 
  >              "BATCH" =  { .........},
  > 	     ....
  > 	     )

... for applications like this we might want to keep the list of
possible "terminals" as short as possible (and of course as long as
necessary), so we should come up with a list of possible typoes and
then try to set the option wherever necessary.

.f

  
  


  


      

    

    

      
      

        


  

        

      Simon Urbanek
    

    

      
      #
    

  


  

      
while the topic is on, something remotely related although the same:

        
On May 12, 2004, at 10:04 AM, Prof Brian Ripley wrote:

        

            

      
      
      
    

        
There may be a little problem in the current sources (talking unix for 
now) - R sets the interactive flag like this:

system.c@248:    R_Interactive = isatty(0);

Unfortunately right after this there comes:

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

Now speaking of embedded R - the above leaves (afaik) no way of telling 
R to use interactive mode before this suicide attempt if stdout is no 
tty (it doesn't have to if the embedding app provides its own 
Read/WriteConsole etc.). Any thoughts on this? (btw: aqua uses a hack 
to circumvent this... whenever aqua needs a hack it may be worth 
thinking about something more general ;))

Cheers,
Simon

---
Simon Urbanek
Department of computer oriented statistics and data analysis
University of Augsburg
Universit?tsstr. 14
86135 Augsburg
Germany

Tel: +49-821-598-2236
Fax: +49-821-598-2200

Simon.Urbanek@Math.Uni-Augsburg.de
http://simon.urbanek.info

  
  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
On Wed, 12 May 2004, Simon Urbanek wrote:

        

            

      
      
      
    

        
Not R per se, but the Unix front-end in Rf_initialize_R, which is a hack
from the terminal-like Unix front-end. As in the comment

    /* On Unix the console is a file; we just use stdio to write on it */

An embedding application can (and probably should) set argv when it calls
Rf_initEmbeddedR, or it can call its own version of Rf_initialize_R (which
is what happens under Windows).

BTW, this is in the process of being broken up (and aqua and gnome 
support moved to Rmain.c) so it is a good time for a better solution.
OTOH, it is not particularly good to break the API of which 
Rf_initialize_R is probably considered part.

I agree with your comment about aqua, but then those of us not using Raqua 
are often unaware of the hacks which have been used.

Brian