[ESS] Displaying plots in Emacs
|@wrence@m|ch@e| @end|ng |rom gene@com
Tue May 19 17:04:28 CEST 2015
On Tue, May 19, 2015 at 7:22 AM, Vitalie Spinu <spinuvit using gmail.com> wrote:
> >>> Michael Lawrence on Mon, 18 May 2015 21:30:37 -0700 wrote:
> > The issue is how we actually transfer the SVG data to Emacs. I could
> > doing something with sockets, but that sounds redundant with nREPL.
> Yes, that's exactly the idea. Transfer either SVG or raw png data
> through sockets or other transfer channels. Good thing about nREPL is
> that the transfer layer is by construction separated. You can add
> whatever weirdo transfer protocols latter and everything else will work
> out of the box. My plan is to have TCP sockets first and Web Sockets a
> bit later.
> > How far along is nREPL?
> Conceptually it's pretty far. I have a pretty clear picture of what has
> to be done. But it's a fairly complex issue with many running
> pieces. Here are the main ones.
> - The R-nREPL is pretty basic now. It uses R's builtin connection
> system that is limited to only one client per server's
> session. That's unacceptable from a tool which calls itself "network
> My plan is to base it on libuv , but that means writing a separate
> binding package.
What about the httpuv R package?
> - Emacs nrepl-client.el  is tightly bound with CIDER/clojure
> ecosystem. I have already done some work on cleaning and splitting it
> up, but more should still be done.
> - Emacs support for image manipulation sucks. Simply displaying images
> in repl window is not what I would be satisfied with. I have now
> almost finished image-transform and image-display . Image-display
> is a replacement for image-mode that works well with potentially very
> long chains of images and abstracts from the physical representation
> of those images. You can have images as files, archives, email
> attachment or piped through nREPL. The exact physical representation
> doesn't matter, the UI is the same for all cases.
> - nREPL is by construction asynchronous and R's inability to do basic
> concurrency is a huge handicap. So additional tooling must be build
> which is not needed for Clojure.
> My workaround idea is to have one R master server and one R slave
> fork for each new client instance, The master will take care of
> routing client requests to slave forks and will also be responsible
> for tooling requests which are different from eval requests
> (completions, help etc). That would allow a pretty good amount of
> non-blocking communication and should be more than enough for most
What about just making an Emacs client for Rserve?
>  https://github.com/libuv/libuv
>  https://github.com/clojure-emacs/cider/blob/master/nrepl-client.el
>  https://github.com/vspinu/image-display
[[alternative HTML version deleted]]
More information about the ESS-help