Skip to content

[R-gui] Feedback about SciViews?

11 messages · Martin Maechler, Duncan Murdoch, Philippe GROSJEAN +3 more

Original
Philippe GROSJEAN
# 
Hello,

This message is little off-topic in R-help. Sorry for that, but not all
interested people are wired yet to r-sig-gui
(http://www.stat.math.ethz.ch/mailman/listinfo/r-sig-gui). Thanks for your
comprehension.

A preview version of SciViews (a Graphical User Interface for R under
Windows, http://www.sciviews.org) was released a few weeks ago. Since then,
the Web site recorded several thousands of downloads. I would really
appreciate your feedback:
- What you like,
- What you don't like,
- Wich features you would like to get in the next release.

I got already some comments. I will post a summary in a while in r-sig-gui.

Best,

Philippe Grosjean

P.S.: we are working now mainly on features like a complete object explorer
and "libraries" (that is, graphical menus in the form of graph galleries,
electronic reference cards, assistants,...).

...........]<(({?<...............<?}))><...............................
 ) ) ) ) )
( ( ( ( (       Dr. Philippe Grosjean
 ) ) ) ) )
( ( ( ( (       LOV, UMR 7093
 ) ) ) ) )      Station Zoologique
( ( ( ( (       Observatoire Oc?anologique
 ) ) ) ) )      BP 28
( ( ( ( (       06234 Villefranche sur mer cedex
 ) ) ) ) )      France
( ( ( ( (
 ) ) ) ) )      tel: +33.4.93.76.38.18, fax: +33.4.93.76.38.34
( ( ( ( (
 ) ) ) ) )      e-mail: phgrosjean@sciviews.org
( ( ( ( (       SciViews project coordinator (http://www.sciviews.org)
 ) ) ) ) )
.......................................................................
Martin Maechler
# 
PhGr> Hello, This message is little off-topic in
    PhGr> R-help. Sorry for that, but not all interested people
    PhGr> are wired yet to r-sig-gui
    PhGr> (http://www.stat.math.ethz.ch/mailman/listinfo/r-sig-gui). Thanks
    PhGr> for your comprehension.

    PhGr> A preview version of SciViews 
    PhGr> (a Graphical User Interface for R under Windows,
					    =============

    PhGr> http://www.sciviews.org)  was released a few weeks ago.

R for Windows already comes with a (simple) GUI.
Many of the R developers would rather think mostly about GUI
efforts that are platform INDEPENDENT, such as the standard Tcl/Tk
package (try "library(tcltk)" and the demos from "demo(package =
"tcltk")" in R), and the RGtk (http://www.omegahat.org/RGtk/) one.

For that reason, in the Bioconductor project (http://www.bioconductor.org),
the  "tkWidgets" package has been developed (built on top of R's
standard "tcltk" package -- which from 1.7.0 on does not need
extra efforts for installation on Windows).

Excuse that this sounds a bit negative, but platform independence
is one of the strengths of R.

Martin Maechler <maechler@stat.math.ethz.ch>	http://stat.ethz.ch/~maechler/
Seminar fuer Statistik, ETH-Zentrum  LEO C16	Leonhardstr. 27
ETH (Federal Inst. Technology)	8092 Zurich	SWITZERLAND
phone: x-41-1-632-3408		fax: ...-1228			<><
Duncan Murdoch
#
On Tue, 29 Apr 2003 11:31:44 +0200, you wrote:

            

      
      
      
    

        
That's true, but as the Windows maintainer, I would *love* to have an
alternative to Rgui.  The Graphapp package that underlies it is not
easy to work with.

I think the best long term strategy is to have a clean division
between the user interface aspects of R (which are necessarily
platform dependent) and the underlying computing engine (which should
be platform independent).  It should be as easy to experiment with the
user interface as it is to experiment with other aspects of
statistical computing.  TCL/TK is one way to realize this, but should
not be the only one.

Duncan Murdoch

  
  


  


      

    

    

      
      

        


  

        

      Philippe GROSJEAN
    

    

      
      #
    

  


  

          

      
      
      
    

        
PhGr> Hello, This message is little off-topic in
    PhGr> R-help. Sorry for that, but not all interested people
    PhGr> are wired yet to r-sig-gui
    PhGr> (http://www.stat.math.ethz.ch/mailman/listinfo/r-sig-gui). Thanks
    PhGr> for your comprehension.

    PhGr> A preview version of SciViews
    PhGr> (a Graphical User Interface for R under Windows,
					    =============

    PhGr> http://www.sciviews.org)  was released a few weeks ago.

Martin Maechler answered:

            

      
      
      
    

        
No problem, I am aware of this. I place platform independence high in the
wish list. However, do not condamn SciViews just because it does not match
this constraint, or because it does not use tools provided by the R Core
Team. Believe me, if I would be able to develop SciViews today with RAD
tools using platform independent toolkits, I would do so! Remember that the
current implementation is rather a prototype for testing various concepts. I
believe that early testing of concepts is very important in order to design
an efficient GUI for R (according to various discussions, there is still
much work to do for prototyping good GUIs in statistics / data analysis).

Tcl/Tk and library(tcltk) is nice and I will use it as much as possible in
SciViews... for what it is currently capable within R: dialog boxes. For
several reasons, it is not yet capable of handling all the features proposed
in SciViews. However, there are a few complete GUIs written in Tcl/Tk around
there, and I am pretty much confident that Peter Dalgaard will enhance the
tcltk library to a level that will allow replicating SciViews with it.
Active development of more sophisticated widgets thanks to bioconductor
people and others also contribute to this feeling.

RGtk and co currently suffers from two big problem: (1) it is not the
fastest, and (2) it is not yet Windows-compatible (according to some
discussions in r-sig-gui, Windows users are currently the priority target
for a R GUI). Yet, I look with much interest towards projects like Poor
Man's GUI of John Verzani, and I encourage it. Also, Gtk is much more OO
than Tcl/Tk, and this is a strong advantage for large projects.

ObveRsive is platform independent, and it explores various technical
solutions to be it. SciViews is not, but it is dedicated to explores various
GUI concepts. Do you see now the complementarity and interest of SciViews in
this context?

Thank you for your feedback.
Best,

Philippe

...........]<(({?<...............<?}))><...............................
 ) ) ) ) )
( ( ( ( (       Dr. Philippe Grosjean
 ) ) ) ) )
( ( ( ( (       LOV, UMR 7093
 ) ) ) ) )      Station Zoologique
( ( ( ( (       Observatoire Oceanologique
 ) ) ) ) )      BP 28
( ( ( ( (       06234 Villefranche sur mer cedex
 ) ) ) ) )      France
( ( ( ( (
 ) ) ) ) )      tel: +33.4.93.76.38.18, fax: +33.4.93.76.38.34
( ( ( ( (
 ) ) ) ) )      e-mail: phgrosjean@sciviews.org
( ( ( ( (       SciViews project coordinator (http://www.sciviews.org)
 ) ) ) ) )
.......................................................................

  
  


  


      

    

    

      
      

        


  

        

      Duncan Temple Lang
    

    

      
      #
    

  


  

      
Philippe Grosjean wrote:

            

      
      
      
    

        
Hi Philippe.

 Can you tell us how you came to these conclusions? I haven't done any
performance measurements on RGtk or tcltk, but I would be startled if
there was any discernible difference in their response times for
callbacks. If there is some other way in which it is slow I'd be very
happy to look into it. We haven't experienced any problems with it in
using it in Berkeley for teaching (www.statdocs.org).  And we can use
S functions as callbacks in GGobi for identifying points, brushing
regions, etc.

One issue might be the integration of the event loop and that is
something quite different from RGtk itself.  If the speed is being
measured from John Verzani's pmg, you may want to identify whether
this lack of speed is in the loading of the package, the running of
the GUI, or the method dispatch in the OOP mechanism.

The core gtk library and hence RGtk is windows-compatible and indeed
there is a binary on the Omegahat web site for RGtk.  What are not
necessarily windows compatible are the additional libraries such as
gtkhtml, etc. that use Gnome.  Since some of these widgets are not
available for Tk, the platform-dependency is a different issue.

 So if you have any examples where RGtk is slow, I'd be
grateful if you could point me at them so I can find out if
it can be fixed.

 Thanks,
   D.

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Philippe GROSJEAN
    

    

      
      #
    

  


  

      
Duncan Temple Lang wrote:

        

            

      
      
      
    

        
Hmmm, looks like I should include a link to StatDocs in
http://www.r-project.org/GUI! By the way, most links in this site refer to
pages I cannot download. Is this site under construction, or reorganization?

            

      
      
      
    

        
I apologize. My conclusions were drawn from PMG use, which was my last
experience with RGtk and related packages. Indeed yes, I also use GGobi and
I am pretty happy with its speed and also with its compatibility with
Windows.

            

      
      
      
    

        
... but yet! It is one of the reasons why I was unable to develop SciViews
with Tk.

            

      
      
      
    

        
Best,

Philippe

  
  


  


      

    

    

      
      

        


  

        

      Byron Ellis
    

    

      
      #
    

  


  

      
On Tuesday, April 29, 2003, at 07:13  AM, Duncan Murdoch wrote:

        

            

      
      
      
    

        
Precisely. I would actually say that R is -not- platform independent in 
that it expects a certain type of GUI--- a shell process living on 
STDIN and STDOUT that talks to an out-of-process Window Server of some 
sort. Most of the work done in the Windows GUI is spent faking that 
environment to make R think its still running on a X Server somewhere 
and similar work was done for the Mac/Carbon port (obviously, Darwin R 
can happily use Apple's X server). REventLoop takes some steps as does 
the work on embedding, but its still safer to run the "GUI" stuff 
out-of-process and even then not foolproof.

If you want true platform independence you really have to consider 
independence in terms of style of interaction as well as operating 
system. Some people really dig on ESS, some like to click things. 
Personally, I like my plots inline with my code. All should be able to 
first-class GUI citizens if they so desire.

            

      
      
      
    

        

      
      
    

        
Byron Ellis (bellis@hsph.harvard.edu)
"Oook" - The Librarian

  
  


  


      

    

    

      
      

        


  

        

      Zed Shaw
    

    

      
      #
    

  


  

      
Martin,

I hate to rain on your parade, but being someone who has had to 
struggle with R for the last three years, I have to disagree with you 
here.  I know you really like R, and I'm sure it is possible to produce 
an interface with it, but "possible" is completely different from 
"reasonable" when it comes to development.  Statements like your's are 
basically what caused people like myself to look outside R for their 
development needs.  Rather than saying, "Hey, what are we doing wrong?" 
  You wold rather ignore the problem and say, "Idiots.  They should use 
R for development."

I think that maybe you should listen to what people have to say about 
their experience trying to write these GUIs.  Maybe if you started to 
hear things like what Philippe and myself continue to complain about, 
and started to fix them, then you might find that even your own 
development projects improve.  Basically, start listening to your users 
more and don't assume that you can impose your way of doing things on 
other people.  A classic example is how the R code insists on checking 
to see it is connected to a pty, and if not it aborts on any errors.  
Or that R uses jumps to maintain the event loop, but doesn't provide a 
convenient way to override this behavior.  Simple things like this 
cause others tons of headaches, but are so simple to fix.

I won't go into specific complaints about R as a large scale 
development language as I don't think anyone working on R is interested 
in hearing them (that's called "industrial autism" BTW).  All I can say 
is, if you want people to use R to write their programs, maybe you 
should make R behave more like every other scripting language on the 
planet.  Take a look at how Python, Perl, Lua, Ruby, Tcl, Java, and 
others do things.  Try to find out from people what features of these 
languages they like and then try to emulate those features.  I think if 
you just adopted a few really simple features from these languages, 
you'd improve R tremendously.

Anyway, enjoy your day.

Zed A. Shaw
http://www.zedshaw.com/

        
On Tuesday, April 29, 2003, at 02:31 AM, Martin Maechler wrote:

        

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Byron Ellis
    

    

      
      #
    

  


  

      
I'm probably setting myself up for a nice long flame session, but here 
we go:

        
On Tuesday, April 29, 2003, at 09:10  PM, Zed Shaw wrote:

        

            

      
      
      
    

        
Well the pty thing I'll give you---irritating as hell---but as for R's 
exception handling and its ease of repair, your statements somewhat 
disingenuous. R's exception handling mechanism is simply How It is Done 
in C. Go look at the Python source code sometime, what do you find? 
That's right. setjmp()/longjmp() for exception handling. Just like R. 
Just like Objective-C and AFAIK Perl as well.

This is, of course, the point where the C++ people jump in and proudly 
point to their exception handling and boldly claim that THEY don't have 
these problems. On Windows using VC++ they're right---exception 
handling is actually provided by the OS kernel rather than being a 
userspace thing (the so-called Structured Exception Handling services) 
and VC++ takes advantage of those capabilities. G++ used to use 
setjmp()/longjmp() to implement exceptions (offering no advantage other 
than C++ vs Macros) but my understanding is they now use something else 
far more complex. My understanding is also that it is far buggier so 
advantage: push.

All that said, it would be nice if TRY { } CATCH { } was available 
(throw is already available in the form of error(), though it is less 
formal than most exception mechanisms). BUT, I disagree completely with 
your assertion that it is a "simple fix." To survive an exception there 
is a great deal of work that needs to get done, especially in the 
memory manager, to ensure the environment is in a defined state---to 
let people willy-nilly override exception handling is just going to 
cause massive headaches as would the conditional header file required 
to harmonize R's exception handling with the myriad of other exception 
handlers would also induce much pain (setjmp()/longjmp() is standard, 
but what actually goes on the heap isn't). Having a context argument (a 
la Java) might help to some degree but that would involve changing 
literally every single R function as well as every function in every R 
package. The change itself probably wouldn't be complex, but it is by 
no means a trivial task.

            

      
      
      
    

        
More likely, they've heard them before, squinted, scratched their heads 
and asked "so, tell me again why you want to implement Tetris in R?" R 
_isn't_ a scripting language. It shares many features with scripting 
languages, high level constructions, automatic memory management, etc 
but its a data analysis language. More importantly, an interactive data 
analysis language (which is where the pty weirdness comes from). It's 
purpose (near as I've been able to fathom) is to make the manipulation 
of real data as much like pushing symbols around on a piece of paper in 
Inference 101 as possible. In this regard it is fundamentally different 
in philosophy from the languages you name below.

Does that mean we should ignore the other languages? Hell no. There's 
some good implementation ideas there---if the extensible SEXP idea ever 
gets off the ground I hope it looks something like Python's new object 
implementation. Its pretty clean and a joy to work with. There's also 
some good object lessons there--Perl's "What Was I Smoking" XS for 
instance. Most of the stuff is pretty sophisticated though, not simple 
features at all.

In fact, I'm not sure what simple features you have in mind? I suppose 
the first thing to come to mind is the memory manager, its what I 
thought of when I started messing around with R's underbelly---it 
becomes especially problematic when datasets get large (something I 
work with, "unable to allocate vector of size xxxx" is a familiar face 
these days). The first thought is "hey, Look at Python! Reference 
Counting! Yes." Well, no. R objects are like strings and tuples in 
Python--semantically (and literally) immutable objects so the reference 
counting scheme doesn't really help since you always have to make a 
copy anyways (this is mark-and-sweep right? I'm too lazy to walk across 
the room and look it up). Ideally we'd want (well, I'd want) a 
copy-on-write scheme, but it seems those are difficult to implement and 
probably even harder to shoehorn into an existing system. There are 
other things: R in Databases for instance. This seems like a good idea 
(I still like it), but how to do it? First we have to find and 
implement an entirely new class of algorithms. Most of your standard 
algorithms assume uniform access to all observations and covariates 
(via matrix multiplication or whatever), which is definitely not true 
of a database where your access to data is anything but uniform. So, 
this necessitates the development of some set of online algorithms, 
which may or may not exist for an arbitrary algorithm. Next there's the 
question of Security. Java has a lot to say about this, and it would be 
nice if we could do similar things in R as the DB server process is 
almost definitely running as a user who is not the one accessing the 
server. And so on, but I digress as these aren't really simple features 
from languages and all of the languages you've mentioned (except maybe 
Tcl) aren't terribly well suited for that sort of duty either.

            

      
      
      
    

        

      
      
    

        
Byron Ellis (bellis@hsph.harvard.edu)
"Oook" - The Librarian

  
  


  


      

    

    

      
      

        


  

        

      Zed Shaw
    

    

      
      #
    

  


  

      
Hi Byron,

With regard to your comments on exception handling, I say I have to 
agree, but I'm not quite sure where you got that I was critiquing R's 
exception handling.  It's no better or worse than others, although I 
agree that try/catch would be nice.  Actually, I'm using try() to get 
around my real complaint:  jump_now handling.

Read the "Handling Errors" section of:

http://developer.r-project.org/embedded.html

For details on what is wrong.  Now, they recommend that you actually 
create a function that overrides the jump_now found in the libR.so 
file.  The problem with that is when you are on other platforms (like, 
Mac OSX) the libR.so jump_now overrides the one you write.  If they 
created a global variable like "R_JumpNowFunc" which you could set to 
your own jump_now handler, then the problem would go away.

I went into fits for about a week trying just about everything I could 
to get my version of jump_now to work.  Eventually I just backed out of 
it and now wrap everything in a try({}) call to keep R from crashing.  
This is what I mean when I complain about how jumps are used to 
maintain the event loop.

Just a quick clarification, otherwise I pretty much agree with what you 
say.  The main things I'd like added to R are too long to mention, and 
I doubt anyone who could make the changes would care.

Zed A. Shaw
http://www.zedshaw.com/

        
On Tuesday, April 29, 2003, at 07:32 PM, Byron Ellis wrote:

        

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Duncan Temple Lang
    

    

      
      #
    

  


  

      
The embedded.html file on developer.r-project.org has a date of August
2000 and it is an RFC rather than part of the R-extensions manual.  It
is out of date and I need to put something into the R extensions
manual to give the "best" approach for handling R errors at the C
level. Ironically, I was chatting with David James on Monday about
this and noted that it wasn't in the extensions manual.

R_jump_now was a left over because of the way the header files did not
export low-level data structures needed for error handling in C.
Luke and I have provided the R_tryEval() routine which one can use
to evaluate an R expression and guarantee returning to that point
in the C code whether there was an error or not.

While it would be better if it was documented in a manual, it
currently isn't. However, many packages illustrate its use.  For
example, almost all of the inter-system interface packages in
Omegahat.  Since there are relatively few people working with
embedding R, documenting them hasn't been impertaive. I find it works
better to have people ask questions about how to do things or why they
are they way they are and then build a FAQ and then documentation from
that rather than just accepting they are this way.
 

Luke, Robert, and I discussed S-level exceptions many years ago and
they are still very much on the todo list. (I raise the issue probably
once every 2 or 3 weeks.)  Regular/exiting exceptions as in Java, C++, ...
are relatively straight forward (especially _now_ that we a more formal
class system (S4).)  Robert and Luke have plans for calling exceptions.


 D.

        
Zed Shaw wrote: