Skip to content

Script editor for Windows GUI

5 messages · Marsland, John, Simon Urbanek, Uwe Ligges +2 more

Original
Marsland, John
# 
Simon,

This is very interesting and very much in keeping with the direct I woudl
like to take with my own work. We have several Java components that have a
realtime event-driven data stream and would very much like to integrate
these with R using something like the callback mechanism in SJava and then
build GUI components on top of them. We were considering using tck/tk
widgets for the GUI but it would be much better to use Java.

Is you project based upon the SJava package, because we have had lots of
problems with the callback interface?

Would you consider releasing your work in progress under the GPL? We are
keen to avoid re-inventing things and its a long time until we are all at
UseR! - we could at the very least give some user feedback.

On a slightly different tack, I have recently taken a look at Jython - an
implementation of Python in Java that produces byte code that runs on the
JVM. Combined with this there is a project called xoltar which aims to bring
functional programming to Python. This got me thinking that a R parser could
be written in Java for a core set of functionality allowing code and
packages written in "pure-R" to be compiled as byte code and run on the JVM.
Then one could call  the SJava package from Java to execute anything unusual
in R proper.... any thoughts?

PS in terms of a script editor for R ... take a look at the JEdit project
which already supports R and S+ syntax highlighting. There is a plugin
called Sidekick which provides a framework for high-level language-specific
features, such as a structure tree, and code completion... it's all written
in Java so it could be extended to work with R.

Regards,

John
even
********************************************************************** 
This is a commercial communication from Commerzbank AG.\ \ T...{{dropped}}
Simon Urbanek
#
On Feb 26, 2004, at 11:58 AM, Marsland, John wrote:

            

      
      
      
    

        
No, we are not using SJava for obvious reasons. I tried hard to fix it, 
but for some platforms that is impossible w/o complete rewrite, so we 
use our own interface now. The Java GUI approach has the advantage that 
it also circumvents the event loop problems in that context.

            

      
      
      
    

        
I think this is a good idea, especially given the feedback I got since 
the post :P. I'll talk to others in the developer team and maybe we 
could leak a developer preview pre-pre-pre-alpha release in the next 
weeks for those interested.

            

      
      
      
    

        
Good question - due to the amount of packages that use C/Fortran code I 
had the impression that this sounds just too crazy. But I'm really keen 
on getting some feedback on this, because technically, one of the CS 
students here would enjoy doing something like that ...

            

      
      
      
    

        
Does anyone here use JEdit? I had a really quick look at it and it 
looks like a copy of Emacs ... which is a pity, because one could do 
much better with Java ;).
Re auto-completion: auto-completing keywords is ok, but how would one 
include all the functions from all the packages? Especially since this 
is runtime-dependent, because in the editor you don't even know which 
packages are loaded at run-time ...

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

  
  


  


      

    

    

      
      

        


  

        

      Uwe Ligges
    

    

      
      #
    

  


  

      
Simon Urbanek wrote:

        

            

      
      
      
    

        
Simon,

right, building a list of (exported) functions from attached packages 
takes some time (not that dramatic, though).

Just an idea: You can maintain a second list containing information 
whether the first list is up to date by just checking which packages are 
attached, so you won't need to update the first list on each 
"auto-completion event".

Uwe

  
  


  


      

    

    

      
      

        


  

        

      A.J. Rossini
    

    

      
      #
    

  


  

      
Simon Urbanek <Simon.Urbanek@math.uni-augsburg.de> writes:

            

      
      
      
    

        
No one can do better than Emacs.

            

      
      
      
    

        
Sure you do.  How do you think ESS works?

best,
-tony

  
    

      
      
    

  


  


      

    

    
1 day later

    

      
      

        


  

        

      Luke Tierney
    

    

      
      #
    

  


  

      
On Thu, 26 Feb 2004, Simon Urbanek wrote:

        

            

      
      
      
    

        
I think it's doable but a very big task.  Python had a head start
because Python has always been byte compiled to its own set of byte
codes.  This means the semantics evolved in a way that is more
supportive of compilation (things like being able to reliably identify
which variables are local, no lazy evaluation, etc.).  In addition
what seems to constitute the Python C core seems to be smaller than
the R core, the bits in base+nmath, say, by about a factor of 5.
Overall I think it would probably be about an order of magnitude
harder to get R to a state comparable to Jython.  That is before
starting to worry about packages needed to do anything useful.  You
can read about what was involved in creating Jython and do the math
yourself....

Once we get the R byte code compiler fully operational things may
eventually become easier since we may be able to the move some things
now done in C out into R where they are easier to maintain and could
then be automatically handled by an appropriate compiler back end.
Getting to a pure Java or pure .NET/mono setting is still likely to be
a fairly dauting task for a while.

Best,

luke