[Rd] Hook for running a function before evaluation

[Byron Ellis]

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