John,
What would be nice is not necessarily trivial.
Consider an example. After running a line of code with an assignment statement,
did you know the last value has been saved in .Last.value as in this snippet of
code:
> x <- 12
> .Last.value
[1] 12
> y <- .Last.value**2
> y
[1] 144
> .Last.value
[1] 144
Now how many novices would know to use this, say in a complicated calculation
where another statement uses the results from before?
So, what if R saved an unevaluated line of code as .Last_text_evaluated or
something. For all I know, something like that may exist and perhaps might be
shown by something like ls(all.names=TRUE) or something.
Novices likely will not know about, nor many experts. It might not even be set
if an error happens. Even if available, no current mechanism exists to show it
after each line.
oThere are ways to save your history and restore it and so on, and running R
interactively may allow something as simple as using up-arrows to see the last
statements. RSTUDIO allows you to see all recent commands in a window.
So, if a program STOPS, you should be able to at least see the preceding line
of code.
But what do you suggest should be the last command in something like a multiple
embedded loop? Is it the code for many lines, or just the one being run? How do
you deal with commands spread over multiple lines?
-----Original Message-----
From: Sorkin, John <jsor...@som.umaryland.edu>
Sent: Sunday, January 19, 2025 3:47 PM
To: avi.e.gr...@gmail.com; 'Ivo Welch' <ivo.we...@gmail.com>;
luke-tier...@uiowa.edu
Cc: r-help@r-project.org
Subject: Re: [R] [External] Re: Parser For Line Number Tracing
Avi,
Yes, R (really S) was not designed for novice users but rather for experts. For
better or worse it has evolved into a programming language used by tyros, and
experts. Debugging tools should be easy to use, generally known, and helpful
for tyro and expert. It would certainly help if R reported the line number, or
the code, that generated the error.
John
John David Sorkin M.D., Ph.D.
Professor of Medicine, University of Maryland School of Medicine;
Associate Director for Biostatistics and Informatics, Baltimore VA Medical
Center Geriatrics Research, Education, and Clinical Center;
PI Biostatistics and Informatics Core, University of Maryland School of
Medicine Claude D. Pepper Older Americans Independence Center;
Senior Statistician University of Maryland Center for Vascular Research;
Division of Gerontology and Paliative Care,
10 North Greene Street
GRECC (BT/18/GR)
Baltimore, MD 21201-1524
Cell phone 443-418-5382
________________________________________
From: R-help <r-help-boun...@r-project.org> on behalf of avi.e.gr...@gmail.com
<avi.e.gr...@gmail.com>
Sent: Sunday, January 19, 2025 3:31 PM
To: 'Ivo Welch'; luke-tier...@uiowa.edu
Cc: r-help@r-project.org
Subject: Re: [R] [External] Re: Parser For Line Number Tracing
Arguably, R was not designed or evolved for truly novice users, nor really was
Python or just about all computer languages. As they evolved and became in many
ways more powerful, they tended to get ever less user friendly in the way you
are asking for and gotten so bloated that many features are not familiar even
to expert users.
Compiled languages can have ways to keep track of what LINE of code is being
worked on. You can sometimes compile them with a flag that preserves
information needed or to have it run with less overhead.
Interpreted languages that can be typed in as you go along are a challenge in
that a concept like line number may not be trivial to use. Do you remember what
was the 325th line you typed in? R does not normally display line numbers in a
prompt.
As noted, there is plenty of debug info, not to mention what you can examine
while running inside a debugger, that can be helpful.
Another consideration to consider is that you can run snippets of R code in
cells as in a Markdown document, Notebook, Quarto or Jupyter notebook along
with pieces of text around it. RSTUDIO supports some of these and there are
likely other variants out there.
Since each cell can contain a limited set of code, down to as little as one
instruction, and you can run segments one after another, or all at once to a
point, and there can be text with info between cells, you might find where
things go wrong and localize them in many cases. Of course, if a cell contains
a loop that breaks after N iterations, not so much.
It is a problem now that so many people do not study a programming language for
itself, but only want to do the minimum needed to use it as a one-time tool for
solving something else they are studying. These days, you can ask a pseudo-AI
to write you a snippet of code that may work and learn next to nothing you can
use to do more.
-----Original Message-----
From: R-help <r-help-boun...@r-project.org> On Behalf Of Ivo Welch
Sent: Sunday, January 19, 2025 12:01 PM
To: luke-tier...@uiowa.edu
Cc: r-help@r-project.org
Subject: Re: [R] [External] Re: Parser For Line Number Tracing
understood.
but, please, consider not people like me but unwary beginners and
students of R. I have used R now for decades, and even I am baffled
by it. Couldn't you make R code easier to debug not only for people
like me (who can indeed tweak their environments) but also for novice
users?
On Sun, Jan 19, 2025 at 8:46 AM <luke-tier...@uiowa.edu> wrote:
>
> On Sun, 19 Jan 2025, Ivo Welch wrote:
>
> > Hi Duncan — Wonderful. Thank you. Bug or no bug, I think it would be
> > a huge improvement for user-friendliness if R printed the last line by
> > default *every time* a script dies. Most computer languages do so.
> >
> > Should I file it as a request for improvement to the R code
> > development team? Maybe R can be improved at a very low cost to the
> > development team and a very high benefit to newbies.
>
> No. There are already many ways to influence the way the default error
> handler prints information about errors, mstly via options(). In
> particular you may want to look at entries in ?options for
>
> show.error.locations
> showErrorCalls
> showWarningCalls
>
> and adjust your options settings accordingly.
>
> Best,
>
> luke
>
> >
> > Regards,
> >
> > /ivo
> >
> > On Sun, Jan 19, 2025 at 2:39 AM Duncan Murdoch <murdoch.dun...@gmail.com>
> > wrote:
> >>
> >> On 2025-01-18 8:27 p.m., Ivo Welch wrote:
> >>> I am afraid my errors are worse! (so are my postings. I should have
> >>> given an example.)
> >>>
> >>> ```
> >>> x <- 1
> >>> y <- 2
> >>> nofunction("something stupid I am doing!")
> >>> z <- 4
> >>> ```
> >>>
> >>> and
> >>>
> >>> ```
> >>>> source("where-is-my-water.R")
> >>> Error in nofunction("something stupid I am doing!") :
> >>> could not find function "nofunction"
> >>> ```
> >>>
> >>> and no traceback is available.
> >>
> >> Okay, I see. In that case traceback() doesn't report the line, but it
> >> still is known internally. You can see it using the following function:
> >>
> >> showKnownLocations <- function() {
> >> calls <- sys.calls()
> >> srcrefs <- sapply(calls, function(v) if (!is.null(srcref <- attr(v,
> >>
> >> "srcref"))) {
> >> srcfile <- attr(srcref, "srcfile")
> >> paste0(basename(srcfile$filename), "#", srcref[1L])
> >> } else ".")
> >> cat("Current call stack locations:\n")
> >> cat(srcrefs, sep = " ")
> >> cat("\n")
> >> }
> >>
> >> I haven't done much testing on this, but I think it can be called
> >> explicitly from any location if you want to know how you got there, or
> >> you can set it as the error handler using
> >>
> >> options(error = showKnownLocations)
> >>
> >> For example, try this script:
> >>
> >> options(error = showKnownLocations)
> >> f <- function() showKnownLocations()
> >> x <- 1
> >> f()
> >> y <- 2
> >> nofunction("something stupid I am doing!")
> >> z <- 4
> >>
> >> I see this output from source("test.R"):
> >>
> >> > source("test.R")
> >> Current call stack locations:
> >> . . . . test.R#4 test.R#2
> >> Error in nofunction("something stupid I am doing!") :
> >> could not find function "nofunction"
> >> Current call stack locations:
> >> . . . . test.R#6
> >>
> >> The first report is from the explicit call in f() on line 2 that was
> >> invoked on line 4, and the second report happens during error handling.
> >>
> >> I supppose the fact that traceback() isn't showing you the line 6
> >> location could be considered a bug.
> >>
> >> Duncan Murdoch
> >>
> >>
> >
> > ______________________________________________
> > R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> > https://stat.ethz.ch/mailman/listinfo/r-help
> > PLEASE do read the posting guide
> > https://www.r-project.org/posting-guide.html
> > and provide commented, minimal, self-contained, reproducible code.
> >
>
> --
> Luke Tierney
> Ralph E. Wareham Professor of Mathematical Sciences
> University of Iowa Phone: 319-335-3386
> Department of Statistics and Fax: 319-335-3017
> Actuarial Science
> 241 Schaeffer Hall email: luke-tier...@uiowa.edu
> Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu/
______________________________________________
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide https://www.r-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
______________________________________________
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide https://www.r-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
______________________________________________
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide https://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
