Skip to content

RAqua, Darwin/X11 R, and tcltk

5 messages · Jan de Leeuw, Thomas Lumley, Simon Urbanek +1 more

Original
Jan de Leeuw
# 
What does not work:

 From the terminal, use quartz(). The quartz device does not receive
events and cannot be made the front window. This does not work
because the API to access the windowmanager from the command line
is hidden by Apple. Would be nice if it worked, though.

 From the terminal, use library(tcltk). This gives a segmentation error.
Now I wonder what would happen if I replaced tcltk.so in  
/usr/local/lib/R
by a  version build by using X11 tcltk. More generally, since R is  
compiled with
both X11 and Aqua support, and since there are two copies of tcltk.so
anyway (one in RAqua and one in /usr/local/lib/R) it would make sense
to configure in such a way that these two versions were indeed the
Aqua and X11 versions.

 From RAqua, use library(tcltk) and demo(tkdensity). This creates the
windows nicely, but they cannot handle events. This is the one that  
really
should work.

What does work:

 From RAqua, use library(tcltk), tkStartGUI(). This creates a tk  
terminal,
where you can say demo(tkdensity). This is obviously not elegant --  
because
tkStartGUI() is not a serious GUI, and because you don't want two  
consoles
active at the same time.

Use IDLE, load Rpy. Then R.library("tcltk") and R.demo("tkdensity")  
works.
That's a bad hack, of course, but it's interesting anyway.
===
Jan de Leeuw; Professor and Chair, UCLA Department of Statistics;
Editor: Journal of Multivariate Analysis, Journal of Statistical  
Software
US mail: 8130 Math Sciences Bldg, Box 951554, Los Angeles, CA 90095-1554
phone (310)-825-9550;  fax (310)-206-5658;  email: deleeuw@stat.ucla.edu
homepage: http://gifi.stat.ucla.edu
   
------------------------------------------------------------------------ 
-------------------------
           No matter where you go, there you are. --- Buckaroo Banzai
                    http://gifi.stat.ucla.edu/sounds/nomatter.au
Thomas Lumley
#
On Thu, 9 Oct 2003, Jan de Leeuw wrote:

            

      
      
      
    

        
You should get
Error in quartz() : quartz() currently works only under RAqua

I put that in a couple of weeks ago because the alternative was often a
bus error.

            

      
      
      
    

        
Not with CRAN's RAqua, there aren't.

            

      
      
      
    

        
Yes, although it is documented that you have to use tkStartGUI.


	-thomas

Thomas Lumley			Assoc. Professor, Biostatistics
tlumley@u.washington.edu	University of Washington, Seattle

  
  


  


      

    

    

      
      

        


  

        

      Thomas Lumley
    

    

      
      #
    

  


  

      
I am (unfortunately) in a position to say that RAqua seems to install and
work perfectly well on a clean install of OS X on a G4 PowerBook, so we
have been successful in getting rid of dependencies.

	-thomas


Thomas Lumley			Assoc. Professor, Biostatistics
tlumley@u.washington.edu	University of Washington, Seattle

  
  


  


      

    

    

      
      

        


  

        

      Simon Urbanek
    

    

      
      #
    

  


  

      
On Thursday, October 9, 2003, at 06:05  PM, Jan de Leeuw wrote:

        

            

      
      
      
    

        
Since Jan is at it, I'll add my problem:

RAqua + Java doesn't work. What happens is that RAqua crashes with a 
segfault after a while (you don't even have to run any Java code except 
for initialization). Producing any system events in RAqua (clicking, 
moving windows etc. will do the trick) accelerates the process, i.e. it 
happens almost immediately. This is not really a fault of Java, but 
rather due to the RAqua design (imho). The entire solution of RAqua 
seems to me very 'hacked' (just to have something in time for 1.8) and 
I hope we can do much better.
The main problem here is that the event handling is incompatible with 
other applications. If you fire up Java, it needs to poll for system 
events as well. But since RAqua uses its own (unsynchronized) polling, 
the whole event system crashes. It is not a particular code (the crash 
is every time at a different location, mostly in a system thread i.e. 
outside R and Java), but rather a design issue.
I suspect that taking any OS X native application (e.g. Cocoa-based) 
will cause exactly the same problem - Java was just the first I saw to 
trigger this.
Running the same program in the console works fine (no wonder - no 
event polling there ;)).

Presumably most of the problems (except from the 
I'm-using-the-wrong-library-problem) posted by Jan will go away once we 
have the new event loop in R and everyone (incl. tcl/tk and aqua) uses 
it.

Since Jan was listing what doesn't work, I just wanted to let you know 
about it ;). I'm going to fiddle around with the event polling issue 
and see if it can be fixed.

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

  
  


  


      

    

    

      
      

        


  

        

      stefano iacus
    

    

      
      #
    

  


  

      
Thanks to all of you! You have raised several interesting points.

Simon has the right point: the way the event loop is implemented does 
not allow several things (i.e. quartz from the shell, java problems, 
tcltk only through tkStartGUI, etc)
R-core has a commitment to change the event loop structure for R-1.9.0.

With RAqua you don't need to install another copy of R in 
/usr/local/lib, just do a couple of symbolic links

sudo ln -s /Applications/StartR.app/RAqua.app/Contents/ /usr/local/lib/R
sudo ln /Applications/StartR.app/RAqua.app/Contents/MacOS/R 
/usr/local/bin/R

and all should work as well as the former darwin/x11 release (apart the 
tcltk issue).

I had in mind to produce two versions of tcltk package: one for X11 and 
one for aqua (say aquatcltk) but it was to late for doing that in time 
for 1.8.0 and we really want to change the internal event loop so in 
the end I gave up.

We can think of prepearing a X11tcltk package and distribute as a 
special contrib binary package. I'm not sure if it can work with the 
binary of RAqua but if any of you wants to help me, we can distribute 
it (Jan? Simon?). X11 works fine from inside RAqua.

I remind all the people the main assumption beside RAqua: it is for 
people who were used to work with Carbon R and don't know how to build 
an application from sources. We have made big efforts to let R build on 
MacOSX out of the box, so any other unix-macosx user should be able to 
build R without using RAqua.
All of this is a second best, but you know we need not to stop MacOS 
support and I think RAqua is a good compromise.

Also consider that RAqua is a stand-alone application and it simply 
works. I can imagine several macos(x) users that don't know what X11 
is, what a dll is and will be never faced to "/usr" etc stuff because 
the finder doesn't show them!

BTW, we distribute binary prebuilt packages that should work also with 
an R build by users themself so, in my opinion, Jan should avoid to 
recompile all the packages.
The packages binary distributed on cran all have passed CHECK/INSTALL 
step, so they are guaranteed in some sense.
The other packages can be normally built via RAqua from sources by the 
user.

stefano

p.s. I'm actually rebuilding all the packages for RAqua 1.8.0 so until 
tomorrow you'll probably find nothing on CRAN as I have intentionally 
cleaned it. Also the following: the version of RAqua I put on cran 
yesterday wasn't built against readline. I have uploaded a new version, 
so please download the new version if you want to have the nice 
readline capability.

        
On Gioved?, ott 9, 2003, at 19:05 Europe/Rome, Simon Urbanek wrote: