Re: [Rd] Hook for running a function before evaluation

From: Byron Ellis <byron.ellis_at_gmail.com>
Date: Fri, 06 Jul 2007 17:16:17 -0700

Running from the Terminal, it acts as a simple shim for people who would prefer to use the Terminal or a terminal-like interface such as ESS. It provides a pretty basic graphics device implementation with a full event loop (without requiring CarbonEL or other workarounds) in that mode. That graphics device is also technically capable (though it doesn't actually write the file at the moment) of writing to a variety of bitmap formats as well as Quicktime movies without having to involve X11. You can also route PDF, though the built-in PDF device will likely give you smaller files.

It's under heavy development (see http://statcomp.blogspot.com) at the moment so some things don't work often because there is an aqua-specific thing that needs to happen (viewing help for example) that we don't actually want to reroute away from the terminal (suspect functions usually contain if(Platform$GUI...) at the top). I'll get those all sorted out sooner rather than later.

However, the real power and, I hope, primary use, isn't from the Terminal---although you can do some cute things like copy objects between any instance (they call themselves "R Execution Server 1," "R Execution Server 2" and so on or take a name you provide via environment variables). Each of the instances, unless told otherwise, is actually vending itself as a Distributed Object that can be attached from another process.

The first client is obviously a standard R GUI (again, see the site above for a screenshot) that can run more than one instance of R at a time much the same way you'd just run from multiple xterms or what have you. It'll feel like a single GUI and have all of the current GUI's features w.r.t. script editing and so on. You'll just have more than one Console (this was actually Stefano's idea. I just wanted to see if it would work. :-) ).

It's a pretty similar model to Simon's JGR stuff in spirit at least, though IIRC that is all still be running in the same process whereas Distributed Objects do not necessarily even need to be on the same machine. So, maybe a cross between Rserve and JGR then. :-)

So far I'm actually quite surprised how quickly its come together.

On 7/6/07, Philippe Grosjean <phgrosjean_at_sciviews.org> wrote:
> Hi Byron,
>
> Excellent! I am also on OS X (together with Win XP and Quantian using
> Parallels desktop ;-)
>
> So far, so good, I have the latest RExecServer running in a terminal.
> So, what can I do with it?
> Best,
>
> Philippe
>
> ..............................................<}))><........
> ) ) ) ) )
> ( ( ( ( ( Prof. Philippe Grosjean
> ) ) ) ) )
> ( ( ( ( ( Numerical Ecology of Aquatic Systems
> ) ) ) ) ) Mons-Hainaut University, Belgium
> ( ( ( ( (
> ..............................................................
>
> Byron Ellis wrote:
> > Hi Philippe,
> >
> > This is exactly the approach being taken in RExecServer (which is in
> > turn possibly connected to front ends via distributed objects). It's
> > an OS X app so the model is
> >
> > my_ReadConsole(...) {
> > didFinishEvaluationForInterpreter(...);
> > internalReadConsole(...); (usually start the run loop and wait for an
> > appropriate event)
> > willBeginEvaluationForInterpreter(...);
> > }
> >
> > technically there should also be shouldBeginEvaluationforInterpreter()
> > to let us bail out of evaluation and head back to the reader loop.
> >
> > http://repo.or.cz/w/RExecServer.git
> >
> > On 7/6/07, Philippe Grosjean <phgrosjean_at_sciviews.org> wrote:
> >> Hello,
> >> I like much addTaskCallback() and friends. However, there are situations
> >> were we would like to have a function run BEFORE, not after every
> >> top-level tasks. I think specifically to reset options(width = ) to
> >> accommodate to the current width of the console, using something like:
> >>
> >> options(width = system("tput cols"))
> >>
> >> I am sure there are many other situations where this could be useful.
> >> Combining tasks run before and after evaluation, one could design a
> >> system to (remotely) indicate when a given R kernel is
> >> starting/evaluating/ending evaluation of some code (with Rpad in mind,
> >> for instance).
> >>
> >> How difficult would it be to implement such Tasks run before top-level
> >> ones?
> >>
> >> Best,
> >>
> >> Philippe
> >> --
> >> ..............................................<}))><........
> >> ) ) ) ) )
> >> ( ( ( ( ( Prof. Philippe Grosjean
> >> ) ) ) ) )
> >> ( ( ( ( ( Numerical Ecology of Aquatic Systems
> >> ) ) ) ) ) Mons-Hainaut University, Belgium
> >> ( ( ( ( (
> >> ..............................................................
> >>
> >> ______________________________________________
> >> R-devel_at_r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
> >
> >
>

-- 
Byron Ellis (byron.ellis_at_gmail.com)
"Oook" -- The Librarian

______________________________________________
R-devel_at_r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Received on Sat 07 Jul 2007 - 00:19:15 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Sat 07 Jul 2007 - 04:35:45 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel. Please read the posting guide before posting to the list.