[ESS] Swankr

[Christophe Rhodes]

Vitalie Spinu <spinuvit at gmail.com> writes:

>> This looks like an error that I fixed yesterday evening -- are you using
>> the most up-to-date git checkout?  Sorry, I should have said that you'd
>> probably need to pull.  (If you are using the most up-to-date checkout,
>> then there's clearly some more debugging to be done)
>>
>
> I am using  http://common-lisp.net/r/users/crhodes/swankr.git to clone
> into, but the last log is from April the  6th.

Oops.  That would be my fault, for forgetting to run git
update-server-info.  I've now done that.

> The git:// link is incorrect
> git://common-lisp.net/crhodes/swankr/swankr.git, it should be
> git://common-lisp.net/users/crhodes/swankr.git
> and it clones as expected.

And this is my fault too!  Impressive detective work.  I have fixed and
reuploaded the documentation.  Thanks.

> I see the prompt and 1+1 works. In case of an error though I am
> getting a backtrace of depth 29 with a lot of stuff coming from swankr
> itself. This renders the backtrace a bit useless.
>
> I can also reproduce the lattice plot directly in the repl, nice. But
> base plots are not working at all:( What are other things to try? You
> said the debugging interface is almost ready. Can I already do some
> visual debugging like jumping through lines of code?

I agree that the backtrace is a bit useless; there are hooks for
filtering out internal frames, but I'm not using them, and I'm simply
giving emacs what R thinks is the current stack frame.  In general, I've
only worked on things that I need -- so for example, the backtrace does
support listing local variables (hit RET on any backtrace line) and
zooming to the source corresponding to the frame (hit 'v' on most
backtrace lines).  Other things that stand a chance of working include
M-. for going to the definition of a function from its use.  Stuff that
doesn't, but could in principle, include a source-code single-stepper, a
data structure inspector, automatic arglist echoing to the minibuffer,
and fancy or fuzzy completion... things that have never been on the
critical path for me.

In terms of base graphics, I'm not sure why with this setup R starts up
with a null graphics device, and why a sensible default one doesn't get
opened when you do some drawing (it looks like a pdf one does instead).  

> Also I am not sure how welcome R is for slime developers. Presumably
> the nature of R will require some specific tailoring in the slime
> itself, which means some sort of cooperation will be required.

Some cooperation would be required, I would agree -- though others are
making a go of maintaining slime or swank in other contexts; there's a
slime-for-vim, a Common Lisp editor MCLIDE, and a swank-for-clojure, all
of which are "friendly forks" in some sense.  And swankr hasn't been
consuming much of my time, either, even while I've been using it as
fully as possible given my other time constraints :-)  But yes, it is
different from ESS, both in how it behaves and how it's made.

Cheers,

Christophe