[Rd] source, sys.source and error line numbers
Hi,
is there a way to retrieve the line number of where en error occurred when
sourcing a file in a tryCatch statement? Is it stored somewhere accessible?
It is not found in the error object.
Consider the following code/output and note the difference in the traceback
between source (has line number) and sys.source (has no line number).
Thank you,
Renaud
# code
codefile <- tempfile()
write("# some comment
# some good lines
a <- 1
# a bad line
stop('an error')
# another good line
b <- 2
", file=codefile)
# with source() the line number is displayed
source(codefile)
traceback()
tryCatch(source(codefile), error= function(e){ str(e) })
# with sys.source() the line number is _not_ displayed
e <- new.env()
sys.source(codefile, e)
traceback()
sessionInfo()
#
# output
#
> codefile <- tempfile()
> write("# some comment
+ # some good lines
+ a <- 1
+ # a bad line
+ stop('an error')
+ # another good line
+ b <- 2
+ ", file=codefile)
> # with source() the line number is displayed
> source(codefile)
Error in eval(expr, envir, enclos) : an error
> traceback()
5: stop("an error") at file46641af8754#5
4: eval(expr, envir, enclos)
3: eval(ei, envir)
2: withVisible(eval(ei, envir))
1: source(codefile)
> tryCatch(source(codefile), error= function(e){ str(e) })
List of 2
$ message: chr "an error"
$ call : language eval(expr, envir, enclos)
- attr(*, "class")= chr [1:3] "simpleError" "error" "condition"
>
> # with sys.source() the line number is _not_ displayed
> e <- new.env()
> sys.source(codefile, e)
Error in eval(expr, envir, enclos) : an error
> traceback()
4: stop("an error")
3: eval(expr, envir, enclos)
2: eval(i, envir)
1: sys.source(codefile, e)
>
> sessionInfo()
R version 2.15.3 (2013-03-01)
Platform: i686-pc-linux-gnu (32-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=C LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] preparing for R 3.0.0
I am preparing my package for the release of R 3.0.0 and thinking about the suggestion (from Duncan Murdoch) to maintain two versions of the package temporarily. Since my package contains knitr-compiled vignettes, I need to restrict it to 3.0.0 going forward. I'd like to submit a final version for 2.x that will not be updated but compiles the vignettes in the old manner; and a version for 3.x. My thought is that they will have the same version number, with the only difference being how the vignette is compiled and the DESCRIPTION files. Is it possible that they have the same version number; or, should I send two updates simultaneously with successive version numbers, flagging one as restricted to R >3.0.0? Thanks, Richard __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Windows R-3.0.0 and Tcl/tkrplot issue
Greetings R Developers,
I've been testing the alpha release of R-3.0.0 and I noticed that the plotting
functionality in package tkrplot was not working correctly.
Further diagnosis found the issue to be related to the command '.Tcl("image
create Rplot plotname")' from package "tkrplot".
The following example is taken from here:
http://tkrplot.sourcearchive.com/documentation/0.0.14/tcltkimg_8c_source.html
> library(tkrplot)
> library(tcltk)
> my.tkdev <- function() win.metafile(width=4,height=4)
> my.tkdev()
> plot(1:20)
> .Tcl("image create Rplot fred")
Error in structure(.External(.C_dotTcl, ...), class = "tclObj") :
[tcl] can't get device image.
This example works fine in R-2.15.3. I've emailed the package maintainer Luke
Tierney but unfortunately he doesn't have the ability to build and test
packages on windows.
Can anyone elucidate what tcltk changes have been made in moving to R-3.0.0?
Details of installation are as follows:
> version
platform i386-w64-mingw32
arch i386
os mingw32
system i386, mingw32
status alpha
major 3
minor 0.0
year 2013
month 03
day16
svn rev62282
language R
version.string R version 3.0.0 alpha (2013-03-16 r62282)
nickname Unsuffered Consequences
>
Thanks,
Wayne
Wayne Jones
Statistics & Chemometrics
Shell Global Solutions (UK)
Shell Technology Centre Thornton
P.O. Box 1, Chester CH1 3SH, United Kingdom
Tel: +44 (0) 151 373 5977 Mobile: +44 (0) 7896 536026
Email: wayne.w.jo...@shell.com
Intranet: Statistics and Chemometrics - Shell
Wiki
Internet: Shell Global
Solutions
Shell Global Solutions (UK) is a division of Shell Research Limited which has
its Registered Office at Shell Centre, London SE1 7NA and is registered in
England & Wales with No.539964.
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Windows R-3.0.0 and Tcl/tkrplot issue
This has been fixed already, as far as I know,
Uwe
On 18.03.2013 12:10, wayne.w.jo...@shell.com wrote:
Greetings R Developers,
I've been testing the alpha release of R-3.0.0 and I noticed that the plotting
functionality in package tkrplot was not working correctly.
Further diagnosis found the issue to be related to the command '.Tcl("image create Rplot
plotname")' from package "tkrplot".
The following example is taken from here:
http://tkrplot.sourcearchive.com/documentation/0.0.14/tcltkimg_8c_source.html
library(tkrplot)
library(tcltk)
my.tkdev <- function() win.metafile(width=4,height=4)
my.tkdev()
plot(1:20)
.Tcl("image create Rplot fred")
Error in structure(.External(.C_dotTcl, ...), class = "tclObj") :
[tcl] can't get device image.
This example works fine in R-2.15.3. I've emailed the package maintainer Luke
Tierney but unfortunately he doesn't have the ability to build and test
packages on windows.
Can anyone elucidate what tcltk changes have been made in moving to R-3.0.0?
Details of installation are as follows:
version
platform i386-w64-mingw32
arch i386
os mingw32
system i386, mingw32
status alpha
major 3
minor 0.0
year 2013
month 03
day16
svn rev62282
language R
version.string R version 3.0.0 alpha (2013-03-16 r62282)
nickname Unsuffered Consequences
Thanks,
Wayne
Wayne Jones
Statistics & Chemometrics
Shell Global Solutions (UK)
Shell Technology Centre Thornton
P.O. Box 1, Chester CH1 3SH, United Kingdom
Tel: +44 (0) 151 373 5977 Mobile: +44 (0) 7896 536026
Email: wayne.w.jo...@shell.com
Intranet: Statistics and Chemometrics - Shell
Wiki
Internet: Shell Global
Solutions
Shell Global Solutions (UK) is a division of Shell Research Limited which has its
Registered Office at Shell Centre, London SE1 7NA and is registered in England
& Wales with No.539964.
[[alternative HTML version deleted]]
__
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
Re: [Rd] preparing for R 3.0.0
On 19.03.2013 15:41, Richard D. Morey wrote: I am preparing my package for the release of R 3.0.0 and thinking about the suggestion (from Duncan Murdoch) to maintain two versions of the package temporarily. Since my package contains knitr-compiled vignettes, I need to restrict it to 3.0.0 going forward. I'd like to submit a final version for 2.x that will not be updated but compiles the vignettes in the old manner; and a version for 3.x. My thought is that they will have the same version number, with the only difference being how the vignette is compiled and the DESCRIPTION files. Is it possible that they have the same version number; or, should I send two updates simultaneously with successive version numbers, flagging one as restricted to R >3.0.0? The one for R >= 3.0.0 should have a larger version number and goes into a separate part of the repository (and moved to the main part once R-3.0.0 is released), the other one should have a dependency on R < 3.0.0. Best, Uwe Ligges Thanks, Richard __ 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
Re: [Rd] removing union class
> "RG" == Renaud Gaujoux
> on Sun, 17 Mar 2013 10:38:44 +0200 writes:
RG> Late report is better than never isn't it? :)
>> > Well,... you forgot to show the error (and the
>> traceback) :
>>
RG> Apologies, I usually include them (and sessionInfo ...).
>>
>> > Note that this problem is somewhat dependent on the use
>> of the > infamous "matrix" class {not properly defined as
>> a class in S3, > as it may or may not have dimnames, and
>> then tried to be made S4 > compatible "as well as
>> possible" in the methods package, see
>>
RG> Ok. What I want to do is to define a class in my
RG> namespace that gather some matrix-like classes so that I
RG> can define a set of common functions for them.
RG> Initially I want matrix and ExpressionSet objects, and
RG> possibly add array objects later. Union classes seem to
RG> be exactly the way to go, but maybe there is an
RG> alternative?
There's really *no* problem with class unions.
They work fine and nicely... we also use them in the Matrix
package (part of the R distro).
The problem you've reported is only a propblem of removeClass().
Martin
>>
>> > Of course, I could not have thought of a realistic
>> situation > where this was a problem, but then you
>> exemplify one :
>>
>> >> Hadley, this is problematic for devtools, because
>> load_all tries to cleanup >> S4 classes when an error
>> occurs when loading a development package and >> crashes
>> with no hint on the original error.
>>
>>
RG> I guess a quick fix for devtools, would be to wrap the
RG> cleanup procedure into a try or tryCatch (Hadley?).
RG> Thanks, Renaud
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] the case of building R snapshot without svn nor network connection.
> Simon Urbanek > on Sat, 16 Mar 2013 10:39:42 -0400 writes: > On Mar 16, 2013, at 10:13 AM, Hin-Tak Leung wrote: >> Network access is *not* a given, nor is the privilege of >> installing arbitrary "uncertified" and "non-essential" >> tools - whatever the meaning of "uncertified" and >> "non-essential" are, those being defined, as is "design >> goal", etc, by some small committee. >> >> It is a very common scenario, e.g. banks & telecom, some >> part of public/government service and health care. This >> does not seem to sink in without repeating. >> > Network access is not needed to build R - apparently that > fact did not seem to sink in, either. This entire thread > is based on false assumptions and as such the only place > for it is /dev/null Indeed! Hin-Tak, do you really think that we, R core, would cripple ourselves in such a way ?? I bet that almost all of us build R (from svn) without internet connection many times a year. But we do follow the build presciptions (*) which you have taken enormous lengths *not* to go along with. Martin --- (*) builddir != srcdir >> --- On Sat, 16/3/13, Hin-Tak Leung >> wrote: >> >>> I'll quantify the first part - R is perhaps the only >>> public software project hosted on a subversion >>> repository for which the result of 'svn export ...' does >>> not build. Not only that it does not build, but make it >>> a feature that it does not build. >>> >>> Very few other projects actively try to go in that >>> direction. >>> >>> --- On Fri, 15/3/13, Hin-Tak Leung >>> wrote: >>> The decision to actively discourage non-subsersion usage of snapshot build is already made (r62183). So I am just here to register a differing opinion. - it is not about subversion vs >>> other-version-control-tools. There are two parts of R's dev build process which >>> requires an active network connection - tools/rsync-recommended >>> and capturing `svn info` into R's headers. The former can >>> be overridden with "./configure --with-recommended-packages=no". A few changes had been >>> made in the last 6 months to make the latter mandatory. It >>> used to be optional. --- there are genuine needs for testing snapshots in a non-networked minimalist environment - e.g. banks or >>> telecom industries - where one wants a "standardised host" >>> build, and often it means an "outdated host"; or in a virtual machine environment - which are non-networked for >>> security reasons, and also do not have tools beyond necessary >>> for compiling and building. This is quite a common >>> scenario. --- AFAIK, 6 months ago, a snapshot copied to an non-networked host will build with "./configure --with-recommended-packages=no". Of course copying >>> those recommended package tar balls across would be nicer. >>> This is sadly no longer the case. - dependent on `svn info` and sitting on top of a svn checkout possibly also affects cross-compiling. But >>> then, it is not clear whether it is still possible to >>> cross-compile R, since quite a few changes have been made to remove >>> the capability of cross-compiling R for windows on unix >>> hosts in the last few years. - testing dev snapshots is about trying things and >>> fixing bugs before release. Making it difficult for non-core >>> people to "try", seem to go against that ethos. If that's the >>> case, maybe the repository could be closed off to anonymous >>> check outs altogether, just to make it clear that testing snapshots before releases or even close to release, is >>> not welcomed. Just a thought. - although the official repository of the "main" linux kernel branch is git-based, there are mercurial >>> mirrors; AFAIK the digital video broadcasting hardware support >>> of the linux kernel is officially in mercurial repositories, >>> but have git mirrors; likewise much of Xorg's is in >>> mercurial but have git mirrors. I haven't heard of any much >>> bigger public projects than R where some actively discourage others. - To be honest r62183 itself is probably a good reason >>> to move away from server-side repositories to distributed repositories (hg/git/arch/bzr). Local enhancements - >>> i.e. an in-house fork - some of which are never going upstream, >>> such as a local revert of r62183 (or a
Re: [Rd] numerics from a factor
> Ulrike Grömping
> on Sat, 16 Mar 2013 13:04:07 +0100 writes:
> Hi Terry, you can use type.convert instead of as.numeric
> for numbers with decimals:
> type.convert(levels(factor(1:6/2)), dec=unlist(options("OutDec")))
> Best, Ulrike
a late and minor remark: If you use the above, a slightly more expressive
preferred way is
type.convert(levels(factor(1:6/2)), dec = getOption("OutDec"))
Martin
> Am 16.03.2013 12:00, schrieb r-devel-requ...@r-project.org:
[...]
>> A problem has been pointed out by a French user of the survival package
and I'm looking
>> for a pointer.
>>
>> > options(OutDec= ",")
>> > fit <- survfit(Surv(1:6 /2) ~ 1)
>> > fit$time
>> [1] NA 1 NA 2 NA 3
>>
>> A year or two ago some test cases that broke survfit were presented to
me. The heart of
>> the problem was numbers that were almost identical, where table(x) and
unique(x) gave
>> different counts of distinct values.
>> The solution was to use "ftime <- factor(time)" at the top of the code,
and do all the
>> calulations using the integer levels of the factor as the unique time
points. At the very
>> end the numeric component "time" of the result is created using
>> as.numeric(levels(ftime)). It's this last line that breaks.
>>
>> I could set the OutDec option within survfit and reset when I leave
using on.exit. Any
>> other simple solutions? Any other ways I could get caught by this issue?
>>
>> Terry Therneau
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] numerics from a factor
Thanks Martin. I had already changed the second argument to getOption.
By the way, per an off list comment from Brian R the bug I was addressing won't affect
anyone using R as shipped; the default decimal separator is "." whatever the region. It
only bit those who set the OutDec option themselves.
Terry T.
On 03/19/2013 11:30 AM, Martin Maechler wrote:
> Hi Terry, you can use type.convert instead of as.numeric
> for numbers with decimals:
> type.convert(levels(factor(1:6/2)), dec=unlist(options("OutDec")))
> Best, Ulrike
a late and minor remark: If you use the above, a slightly more expressive
preferred way is
type.convert(levels(factor(1:6/2)), dec = getOption("OutDec"))
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] the case of building R snapshot without svn nor network connection.
--- On Sat, 16/3/13, Hin-Tak Leung wrote: > Network access is *not* a given, nor > is the privilege of installing arbitrary "uncertified" and > "non-essential" tools - whatever the meaning of > "uncertified" and "non-essential" are, those being defined, > as is "design goal", etc, by some small committee. > > It is a very common scenario, e.g. banks & telecom, some > part of public/government service and health care. This does > not seem to sink in without repeating. Oh, and some might call using a tool beyond its initial purpose and context an enhancement, rather than 'misuse'. Quite a lot of words, like 'certified', 'essential', have no meaning outside the small group of people who use and misuse them, as is 'misuse'. > --- On Sat, 16/3/13, Hin-Tak Leung > wrote: > > > I'll quantify the first part - R is > > perhaps the only public software project hosted on a > > subversion repository for which the result of 'svn > export > > ...' does not build. Not only that it does not build, > but > > make it a feature that it does not build. > > > > Very few other projects actively try to go in that > > direction. > > > > --- On Fri, 15/3/13, Hin-Tak Leung > > wrote: > > > > > The decision to actively discourage > > > non-subsersion usage of snapshot build is already > made > > > (r62183). So I am just here to register a > differing > > > opinion. > > > > > > - it is not about subversion vs > > other-version-control-tools. > > > There are two parts of R's dev build process > which > > requires > > > an active network connection - > tools/rsync-recommended > > and > > > capturing `svn info` into R's headers. The former > can > > be > > > overridden with "./configure > > > --with-recommended-packages=no". A few changes had > been > > made > > > in the last 6 months to make the latter mandatory. > It > > used > > > to be optional. > > > > > > --- there are genuine needs for testing snapshots > in a > > > non-networked minimalist environment - e.g. banks > or > > telecom > > > industries - where one wants a "standardised > host" > > build, > > > and often it means an "outdated host"; or in a > virtual > > > machine environment - which are non-networked for > > security > > > reasons, and also do not have tools beyond > necessary > > for > > > compiling and building. This is quite a common > > scenario. > > > > > > --- AFAIK, 6 months ago, a snapshot copied to an > > > non-networked host will build with "./configure > > > --with-recommended-packages=no". Of course > copying > > those > > > recommended package tar balls across would be > nicer. > > This is > > > sadly no longer the case. > > > > > > - dependent on `svn info` and sitting on top of a > svn > > > checkout possibly also affects cross-compiling. > But > > then, it > > > is not clear whether it is still possible to > > cross-compile > > > R, since quite a few changes have been made to > remove > > the > > > capability of cross-compiling R for windows on > unix > > hosts in > > > the last few years. > > > > > > - testing dev snapshots is about trying things > and > > fixing > > > bugs before release. Making it difficult for > non-core > > people > > > to "try", seem to go against that ethos. If that's > the > > case, > > > maybe the repository could be closed off to > anonymous > > check > > > outs altogether, just to make it clear that > testing > > > snapshots before releases or even close to > release, is > > not > > > welcomed. Just a thought. > > > > > > - although the official repository of the "main" > linux > > > kernel branch is git-based, there are mercurial > > mirrors; > > > AFAIK the digital video broadcasting hardware > support > > of the > > > linux kernel is officially in mercurial > repositories, > > but > > > have git mirrors; likewise much of Xorg's is in > > mercurial > > > but have git mirrors. I haven't heard of any much > > bigger > > > public projects than R where some actively > discourage > > > others. > > > > > > - To be honest r62183 itself is probably a good > reason > > to > > > move away from server-side repositories to > distributed > > > repositories (hg/git/arch/bzr). Local enhancements > - > > i.e. an > > > in-house fork - some of which are never going > upstream, > > such > > > as a local revert of r62183 (or a local revert of > any > > other > > > upstream commits) is one reason why some have > > distributed > > > repositories. > > > > > > Lastly, a minor grip. The current head of the HK > > government > > > is probably sometimes called "HK Leung", just as > some > > might > > > call a certain old lady "UK Windsor" and a > certain > > black > > > person "US Obama". > > > > > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] removing union class
All good then.
Thanks.
Renaud
2013/3/19 Martin Maechler
> > "RG" == Renaud Gaujoux
> > on Sun, 17 Mar 2013 10:38:44 +0200 writes:
>
> RG> Late report is better than never isn't it? :)
> >> > Well,... you forgot to show the error (and the
> >> traceback) :
> >>
>
> RG> Apologies, I usually include them (and sessionInfo ...).
>
>
> >>
> >> > Note that this problem is somewhat dependent on the use
> >> of the > infamous "matrix" class {not properly defined as
> >> a class in S3, > as it may or may not have dimnames, and
> >> then tried to be made S4 > compatible "as well as
> >> possible" in the methods package, see
> >>
>
> RG> Ok. What I want to do is to define a class in my
> RG> namespace that gather some matrix-like classes so that I
> RG> can define a set of common functions for them.
> RG> Initially I want matrix and ExpressionSet objects, and
> RG> possibly add array objects later. Union classes seem to
> RG> be exactly the way to go, but maybe there is an
> RG> alternative?
>
> There's really *no* problem with class unions.
> They work fine and nicely... we also use them in the Matrix
> package (part of the R distro).
>
> The problem you've reported is only a propblem of removeClass().
>
> Martin
>
>
>
> >>
> >> > Of course, I could not have thought of a realistic
> >> situation > where this was a problem, but then you
> >> exemplify one :
> >>
> >> >> Hadley, this is problematic for devtools, because
> >> load_all tries to cleanup >> S4 classes when an error
> >> occurs when loading a development package and >> crashes
> >> with no hint on the original error.
> >>
> >>
> RG> I guess a quick fix for devtools, would be to wrap the
> RG> cleanup procedure into a try or tryCatch (Hadley?).
>
>
> RG> Thanks, Renaud
>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
