I am working on a project involving data analysis, and I am using Lisp
as I would Mathematica -- in an interactive fashion, often for one-off
computations. Part of it involves making graphs/plots. One thing I
would like to do is to be able to do someting
(plot-data '(1 2 3 4 5))
and then have a graph appear in slime.
Lets suppose plot-data creates a temp file and saves the image to it,
or returns a class which has the bitmap in it. What would it take to
convince SLIME to display the image inline?
Basically, I am looking to make SLIME do something like this:
http://www.texmacs.org/tmweb/home/screenshots.en.html (4th screenshot).
Should I work on making SLIME work w/ Texmacs or can I just use normal
emacs? Any further pointers?
Thanks,
Alex
··········@gmail.com writes:
> I am working on a project involving data analysis, and I am using Lisp
> as I would Mathematica -- in an interactive fashion, often for one-off
> computations. Part of it involves making graphs/plots. One thing I
> would like to do is to be able to do someting
>
> (plot-data '(1 2 3 4 5))
>
> and then have a graph appear in slime.
>
> Lets suppose plot-data creates a temp file and saves the image to it,
> or returns a class which has the bitmap in it. What would it take to
> convince SLIME to display the image inline?
>
> Basically, I am looking to make SLIME do something like this:
> http://www.texmacs.org/tmweb/home/screenshots.en.html (4th screenshot).
> Should I work on making SLIME work w/ Texmacs or can I just use normal
> emacs? Any further pointers?
You can establish bi-directionnal communication between emacs and the
inferior lisp process thru slime and swank with the following:
;;; In emacs, we can execute Common Lisp expressions:
;; (require 'slime)
;; (slime)
(setf slime-enable-evaluate-in-emacs t)
(defun eval-in-cl (cl-expression-string process-result-values)
(slime-eval-with-transcript
`(swank:eval-and-grab-output ,cl-expression-string)
(lexical-let ((here (current-buffer))
(process-result-values process-result-values))
(lambda (result-values)
(set-buffer here)
(funcall process-result-values result-values)))))
;; (eval-in-cl "(values 1 * (ext:! 20) (package-name *package*))"
;; (lambda (values)
;; (dolist (v values)
;; (insert (format "%s\n" v)))))
;; Returns:
;;
;; nil
;;
;; then later inserts:
;;
;; 1
;; (42 (EMACS-UNREADABLE |buffer| |*scratch*|))
;; 2432902008176640000
;; "COMMON-LISP-USER"
;;; In Common Lisp, we can execute emacs lisp expressions:
(defparameter *emacs-readtable* (copy-readtable))
(setf (readtable-case *emacs-readtable*) :preserve)
(set-syntax-from-char #\> #\) *emacs-readtable*)
(set-dispatch-macro-character
#\# #\<
(lambda (stream subchar dispchar)
`(emacs-unreadable ,@(read-delimited-list #\> stream t)))
*emacs-readtable*)
;; Probably more readtable patching would be in order.
;;
;; We could define CLOS proxies for emacs objects for a more seamless
;; integration. swank::eval-in-emacs process the CL form to make it
;; "emacs" (eg. downcase symbols, etc). It could convert CLOS proxies
;; to emacs lisp forms returning the corresponding emacs object.
(defun eval-in-emacs (form &optional nowait)
(let ((result (SWANK::EVAL-IN-EMACS `(format "%S" ,form) nowait))
(*readtable* *emacs-readtable*))
(with-input-from-string (in result)
(let ((result (read in nil in)))
result))))
(eval-in-emacs `(progn
(switch-to-buffer (buffer-named "*scratch*"))
(goto-char (point-max))
(insert ,(format nil "~%Hello~%"))
(list 42 (current-buffer))))
;; Switch to the *scratch* buffer,
;; goto the last position, and
;; inserts \nHello\n
;; then returns:
;; (42 (EMACS-UNREADABLE |buffer| |*scratch*|))
Emacs can handle pictures inside a buffer. So you can generate the
pictures in Common Lisp, then send them back to emacs, and have them
inserted in the buffer.
--
__Pascal Bourguignon__
Alex,
I haven't hacked on this, but I know that AUCTeX mode[1] for emacs does
something similar with its "previews" where figures and tables are
rendered by *TeX and then included in the buffer.
If you look through the code of AUCTeX you could probably implement the
needed things in the slime REPL buffer.
Chris
[1]: http://www.gnu.org/software/auctex/preview-latex.html
··········@gmail.com wrote:
> I am working on a project involving data analysis, and I am using Lisp
> as I would Mathematica -- in an interactive fashion, often for one-off
> computations. Part of it involves making graphs/plots. One thing I
> would like to do is to be able to do someting
>
> (plot-data '(1 2 3 4 5))
>
> and then have a graph appear in slime.
>
> Lets suppose plot-data creates a temp file and saves the image to it,
> or returns a class which has the bitmap in it. What would it take to
> convince SLIME to display the image inline?
>
> Basically, I am looking to make SLIME do something like this:
> http://www.texmacs.org/tmweb/home/screenshots.en.html (4th screenshot).
> Should I work on making SLIME work w/ Texmacs or can I just use normal
> emacs? Any further pointers?
>
> Thanks,
> Alex
··········@gmail.com writes:
> I am working on a project involving data analysis, and I am using Lisp
> as I would Mathematica -- in an interactive fashion, often for one-off
> computations. Part of it involves making graphs/plots. One thing I
> would like to do is to be able to do someting
>
> (plot-data '(1 2 3 4 5))
>
Just a "further pointer". Maybe you should consider to take a look at
clim (mcclim is a free implementation).
After reading about the main concepts, and looking at some example
(town-example is enlightening) it is not difficult to build a simple
REPL interactor (look at Listener application) where you can mix (or
put them in two separate window areas) graphics and text, present and
get as input clos objects in both ways and inspect them
easily. Furthermore mcclim handle postscript so you can save all the
stuff you plot/write in ps.
I also use cl to compute and plot and i found mcclim good for this
kind of UI :-)
The subject line is something I have been wondering about: can the Lisp
process talked to by Emacs pop-up, say, an LTk window? Well, of course,
dumb question. So what stops Slime (or a Slime-killer) from being
GUI-based? Or shalt we have no Gods before the Emacs text-only interface
model? I imagine one problem is that Emacs users probably expand windows
to fill the whole desktop, but what is that second huge flatpanel for?
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton <·········@gmail.com> writes:
> So what stops Slime (or a Slime-killer) from being GUI-based?
Nothing technical, other than the preferences of the slime authors.
-russ
Russell McManus wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>
>>So what stops Slime (or a Slime-killer) from being GUI-based?
>
>
> Nothing technical, other than the preferences of the slime authors.
Tempting project, then. That and some work on Hemlock. Do I recall Mr.
Burdick was expending some energies in that direction?
ken
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon