On May 24, 2009, at 10:18 AM, Romain Francois wrote:
Robert Gentleman wrote:
Hi,
I stripped the cc's as I believe that all read this list.
Romain Francois wrote:
[moving this to r-devel]
Robert Gentleman wrote:
Hi,
Romain Francois wrote:
Duncan Murdoch wrote:
On 5/22/2009 10:59 AM, Michael wrote:
Really I think if there is a Visual Studio strength debugger,
our
collective time spent in developing R code will be greatly
reduced.
If someone who knows how to write a debugger plugin for Eclipse
wants
to help, we could have that fairly easily. All the
infrastructure is
there; it's the UI part that's missing.
Duncan Murdoch
[I've copied Mark Bravington and Robert Gentleman to the list as
they
are likely to have views here, and I am not sure they monitor R-
help]
Hello,
Making a front-end to debugging was one of the proposed google
summer of
code for this year [1], it was not retained eventually, but I am
still
motivated.
Pretty much all infrastructure is there, and some work has been
done
__very recently__ in R's debugging internals (ability to step
up). As I
see it, the ability to call some sort of hook each time the
debugger
waits for input would make it much easier for someone to write
I have still not come to an understanding of what this is
supposed to
do? When
you have the browser prompt you can call any function or code you
want
to. There
is no need for something special to allow you to do that.
Sure. What I have in mind is something that gets __automatically__
called, similar to the task callback but happening right before
the user
is given the browser prompt.
I am trying to understand the scenario you have in mind. Is it that
the user is
running R directly and your debugger is essentially a helper
function that gets
updated etc as R runs?
yes. there are now several ui toolkits that could be use to give
some sort of graphical representation of what is being debugged.
I agree with you that and IDE should command R and not the other way
around, but I am not (yet) here talking about a fully featured IDE,
but simply a debugger.
I need to read more about embedding R (as in section 8 of WRE). I
know you can supply your own implementation of the REPL, but I am
not sure this includes the one that goes on once trapped into the
browser.
Yes - it would be quite useless otherwise ;) there are many examples
of GUIs that use it (including the built-in ones [Windows, MAc, ..] or
external ones e.g JGR).
Cheers,
S
For example littler ships its own REPL, but this does not seem to
fool/deal with browser:
$ r -e "print(1:10); browser(); print(1:5) "
[1] 1 2 3 4 5 6 7 8 9 10
Called from: NULL
c
[1] 1 2 3 4 5
Not sure this is an omission of Jeffrey and Dirk or something else.
If so, then I don't think that works very well and given the
constraints we
have with R I don't think it will be able to solve many of the
problems that an
IDE should. The hook you want will give you some functionality,
but no where
near enough.
In the long run, I do agree. In the short run, I'd prefer taking the
bus to the airport rather than walk.
Let me suggest instead that the IDE should be running the show. It
should
initialize an instance of R, but it controls all communication and
hence
controls what is rendered on the client side. If that is what you
mean by
embedding R, then yes that is what is needed. There is no way that
I can see to
support most of the things that IDE type debuggers support without
the IDE
controlling the communication with R.
And if I am wrong about what your debugger will look like please
let me know.
best wishes
Robert
front-ends. A recent post of mine (patch included) [2] on R-devel
suggested a custom prompt for browser which would do the trick,
but I
now think that a hook would be more appropriate. Without something
similar to that, there is no way that I know of for making a
front-end,
unless maybe if you embed R ... (please let me know how I am
wrong)
I think you are wrong. I can't see why it is needed. The external
debugger has
lots of options for handling debugging. It can rewrite code (see
examples in
trace for how John Chambers has done this to support tracing at a
location),
which is AFAIK a pretty standard approach to writing debuggers.
It can
figure
out where the break point is (made a bit easier by allowing it to
put
in pieces
of text in the call to browser). These are things the internal
debugger can't do.
Thanks. I'll have another look into that.
There is also the debug package [3,4] which does __not__ work
with R
internals but rather works with instrumenting tricks at the R
level.
debug provides a tcl/tk front-end. It is my understanding that
it does
not work using R internals (do_browser, ...) because it was not
possible
at the time, and I believe this is still not possible today, but
I might
be wrong. I'd prefer to be wrong actually.
I don't understand this statement. It has always been possible to
work with
the internal version - but one can also take the approach of
rewriting
code.
There are some difficulties supporting all the operations that one
would like by
rewriting code and I think a combination of external controls and
the
internal
debugger will get most of the functionality that anyone wants.
There are somethings that are hard and once I have a more complete
list I will
be adding this to the appropriate manual. I will also be
documenting
the changes
that I have been making, but that project is in flux and won't be
done
until the
end of August, so people who want to look at it are welcome (it
is in
R-devel),
but it is in development and could change pretty much without
notice.
Romain noted that we now support stepping out from one place to
another
function. We also have a debugonce flag that lets you get close to
step in, but
step in is very hard in R.
I am mostly interested in writing tools in R that can be used by
anyone that
wants to write an external debugger and am not that interested in
any
particular
external debugger. I would be happy to listen to feature requests
or
issues that
arise - but the discussion should probably be on R-devel mailing
list.
best wishes
Robert
Romain
[1] : http://www.r-project.org/soc09/ideas.html#p5
[2] : https://stat.ethz.ch/pipermail/r-devel/2009-April/
053128.html
[3] : http://cran.r-project.org/web/packages/debug/index.html
[4] : http://cran.r-project.org/doc/Rnews/Rnews_2003-3.pdf
--
Romain Francois
Independent R Consultant
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
