Re: [Rd] isOpen on closed connections
My solution the original post is to always set 'con <- NULL' after closing a
connection, and then test for NULL. This is how I do to make sure to make
sure that opened connections are closed and as soon as possible.
foo <- function(...) {
con <- file("foo.R", open="r"):
on.exit({
if (!is.null(con)) {
close(con);
con <- NULL;
}
})
# Do some thing that might cause foo() to exit.
bar();
# Do some thing else
cat(con, "foo");
# Close connection as soon as possible
close(con);
con <- NULL;
# Do more things before returning
}
However, is there a reason for not having isOpen() return FALSE after
close() with the logic that a destroy connection is also a non-open one?
So, basically:
isOpen <- function (con, rw = "") {
rw <- pmatch(rw, c("read", "write"), 0)
res <- FALSE
tryCatch({
res <- .Internal(isOpen(con, rw))
}, error = function(ex) {
})
res
}
EXAMPLE:
> con <- file("foo.R")
> print(isOpen(con))
[1] FALSE
> open(con, "w")
> print(isOpen(con))
[1] TRUE
> close(con)
> print(isOpen(con))
[1] FALSE
> open(con, "w")
Error in open.connection(con, "w") : invalid connection
If there is a use case that needs to test if a connection has been
destroyed, it would be more natural to add isDestroyed(), although I cannot
really see where it should be needed.
/Henrik
On Nov 14, 2007 11:18 PM, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
I think the confusion here is over close(): that closes *and destroys* a
connection, so it no longer exists.
isOpen applies to existing connections: you cannot close but not destroy
them at R level, but C code can (and does). You will see it in use in the
utils package.
On Nov 14, 2007 11:18 PM, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
> I think the confusion here is over close(): that closes *and destroys* a
> connection, so it no longer exists.
>
> isOpen applies to existing connections: you cannot close but not destroy
> them at R level, but C code can (and does). You will see it in use in the
> utils package.
>
>
> On Wed, 14 Nov 2007, Seth Falcon wrote:
>
> > "Roger D. Peng" <[EMAIL PROTECTED]> writes:
> >
> >> As far as I can tell, 'isOpen' cannot return FALSE in the case when 'rw
> = ""'.
> >> If the connection has already been closed by 'close' or some other
> function,
> >> then isOpen will produce an error. The problem is that when isOpen
> calls
> >> 'getConnection', the connection cannot be found and 'getConnection'
> produces an
> >> error. The check to see if it is open is never actually done.
> >
> > I see this too with R-devel (r43376) {from Nov 6th}.
> >
> >con = file("example1", "w")
> >isOpen(con)
> >
> >[1] TRUE
> >
> >showConnections()
> >
> > description class mode text isopen can read can write
> >3 "example1" "file" "w" "text" "opened" "no" "yes"
> >
> >close(con)
> >isOpen(con)
> >
> >Error in isOpen(con) : invalid connection
> >
> >## printing also fails
> >con
> >Error in summary.connection(x) : invalid connection
> >
> >> This came up in some code where I'm trying to clean up connections
> after
> >> successfully opening them. The problem is that if I try to close a
> connection
> >> that has already been closed, I get an error (because 'getConnection'
> cannot
> >> find it). But then there's no way for me to find out if a connection
> has
> >> already been closed. Perhaps there's another approach I should be
> taking? The
> >> context is basically,
> >>
> >> con <- file("foo", "w")
> >>
> >> tryCatch({
> >> ## Do stuff that might fail
> >> writeLines(stuff, con)
> >> close(con)
> >>
> >> file.copy("foo", "bar")
> >> }, finally = {
> >> close(con)
> >> })
> >
> > This doesn't address isOpen, but why do you have the call to close
> > inside the tryCatch block? Isn't the idea that finally will always be
> > run and so you can be reasonably sure that close gets called once?
> >
> > If your real world code is more complicated, perhaps you can make use
> > of a work around like:
> >
> > myIsOpen = function(con) tryCatch(isOpen(con), error=function(e) FALSE)
> >
> > You could do similar with myClose and "close" a connection as many
> > times as you'd like :-)
> >
> > + seth
> >
> >
>
> --
> Brian D. Ripley, [EMAIL PROTECTED]
> Professor of Applied Statistics,
> http://www.stats.ox.ac.uk/~ripley/
Re: [Rd] library path in Rd link
On Thu, 15 Nov 2007, Adrian Dusa wrote:
> On Thursday 15 November 2007, Prof Brian Ripley wrote:
>> [...]
>>>
>>> Using as above:
>>> \code{\link{anova}}
>>>
>>> the html help file directs to
>>> file:///home/adi/myRlibrary/stats/html/anova.html
>>
>> I hope it is actually ../../stats/html/anova.html and the browser is
>> interpreting that as a full URL.
>>
>>> instead of
>>> file:///usr/lib/R/library/stats/html/anova.html
>>
>> But at run time help.start() creates links into a subdirectory of
>> tempdir(). As in
>>
>>> help.start()
>
> I got it.
> Perhaps it would be useful to have another startup option, something like:
> options(htmlLinksResolve=TRUE)
>
> that one could use in the .First() function from .Rprofile
You could have a function to run there, essentially (from help.start())
.Script("sh", "help-links.sh",
paste(tempdir(), paste(.libPaths(), collapse = " ")))
and perhaps (it is a lot slower)
utils::make.packages.html()
The problem is that even the first can be slow on a network-mounted file
system with a lot of packages installed, do we don't want to do it by
default.
> I tried using help.start() in .Rprofile, but it throws a (probably obvious)
> error:
> Error: could not find function "help.start"
Duncan has answered that.
> For my personal purposes, all questions have been answered though.
> Thank you very much,
> Adrian
>
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] library path in Rd link
On Thu, 15 Nov 2007, Prof Brian Ripley wrote:
> On Thu, 15 Nov 2007, Adrian Dusa wrote:
>
>> On Thursday 15 November 2007, Prof Brian Ripley wrote:
>>> [...]
Using as above:
\code{\link{anova}}
the html help file directs to
file:///home/adi/myRlibrary/stats/html/anova.html
>>>
>>> I hope it is actually ../../stats/html/anova.html and the browser is
>>> interpreting that as a full URL.
>>>
instead of
file:///usr/lib/R/library/stats/html/anova.html
>>>
>>> But at run time help.start() creates links into a subdirectory of
>>> tempdir(). As in
>>>
help.start()
>>
>> I got it.
>> Perhaps it would be useful to have another startup option, something like:
>> options(htmlLinksResolve=TRUE)
>>
>> that one could use in the .First() function from .Rprofile
>
> You could have a function to run there, essentially (from help.start())
>
> .Script("sh", "help-links.sh",
> paste(tempdir(), paste(.libPaths(), collapse = " ")))
>
> and perhaps (it is a lot slower)
>
> utils::make.packages.html()
It transpires that currently you do need both: although the script is
passed the library locations it does not make use of them, leaving the
linking to make.packages.html. (That used not to be the case.)
> The problem is that even the first can be slow on a network-mounted file
> system with a lot of packages installed, do we don't want to do it by
> default.
So speed is the problem: I am seeing about 4 secs on a system with 1450
packages on the local disc, and 33 secs on a slower system with a
network-mounted FS.
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] faqs
Gabor Grothendieck gmail.com> writes: > inst/NEWS would have the advantage of consistency with R itself > which also has a NEWS file. > ... > > My vote is for inst/ChangeLog. I wote for inst/NEWS, while inst/ChangeLog can also be present to show more details such as svn log. Gregor __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] When to use LazyLoad, LazyData and ZipData?
Prof Brian Ripley wrote: > On Wed, 14 Nov 2007, Bjørn-Helge Mevik wrote: > >> When should one specify LazyLoad, LazyData, and ZipData? > > Preferably always, and I would suggest all should be 'yes' if your > package will work with them. Thank you! After reading this, and the very nice R-news article pointed to by Gabor Grothendieck, I've switched to specifying the directives in my packages. -- Bjørn-Helge Mevik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] library path in Rd link
I think that's right -- it only works on NTFS systems. This page refers to it as an NTFS symbolic link: http://en.wikipedia.org/wiki/NTFS_symbolic_link On Nov 14, 2007 10:00 PM, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > On 14/11/2007 7:44 PM, Gabor Grothendieck wrote: > > On Nov 14, 2007 4:36 PM, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > >> On Unix-alikes, the workaround is to build soft links to all the > >> packages in a standard location; but soft links don't work on Windows > >> (and we don't want to get into the almost-undocumented hard links that > >> exist on some Windows file systems). > > > > Symbolic links are available on Windows Vista: > > Does this work on FAT file systems, e.g. on a USB drive? It used to be > that they only worked on NTFS. > > Duncan Murdoch > > > > > > C:\> mklink /? > > Creates a symbolic link. > > > > MKLINK [[/D] | [/H] | [/J]] Link Target > > > > /D Creates a directory symbolic link. Default is a file > > symbolic link. > > /H Creates a hard link instead of a symbolic link. > > /J Creates a Directory Junction. > > Linkspecifies the new symbolic link name. > > Target specifies the path (relative or absolute) that the new link > > refers to. > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] library path in Rd link
On Thursday 15 November 2007, Prof Brian Ripley wrote:
> [...]
> help.start()
> >>
> >> I got it.
> >> Perhaps it would be useful to have another startup option, something
> >> like: options(htmlLinksResolve=TRUE)
> >>
> >> that one could use in the .First() function from .Rprofile
> >
> > You could have a function to run there, essentially (from help.start())
> >
> > .Script("sh", "help-links.sh",
> > paste(tempdir(), paste(.libPaths(), collapse = " ")))
> >
> > and perhaps (it is a lot slower)
> >
> > utils::make.packages.html()
>
> It transpires that currently you do need both: although the script is
> passed the library locations it does not make use of them, leaving the
> linking to make.packages.html. (That used not to be the case.)
>
> > The problem is that even the first can be slow on a network-mounted file
> > system with a lot of packages installed, do we don't want to do it by
> > default.
>
> So speed is the problem: I am seeing about 4 secs on a system with 1450
> packages on the local disc, and 33 secs on a slower system with
> network-mounted FS.
Completely understandable, it's not going to be automatic. Users who don't
suffer from these restrictions could manually make use of the script.
Thank you very much,
Adrian
--
Adrian Dusa
Romanian Social Data Archive
1, Schitu Magureanu Bd
050025 Bucharest sector 5
Romania
Tel./Fax: +40 21 3126618 \
+40 21 3120210 / int.101
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] isOpen on closed connections
Upon further consideration, I realized there is a philosophical element
here---if a connection is closed and hence does not exist, is it open?
The practical issue for me is that when you do something like
close(con)
the 'con' object is still lying around and is essentially undefined. For
example, if I do
close(con)
con <- "hello"
then it seems logical to me that 'isOpen' would return an error. But it feels
natural to me that a sequence like
close(con)
isOpen(con) ## FALSE?
would not lead to an error. Perhaps my expectations are not reasonable and I'd
appreciate being corrected.
Given Brian's comment, one solution would be to allowing closing but not
destroying connections at the R level (maybe via an option?), but that is a
change in semantics and I'm not sure if this problem really comes up that much.
-roger
Prof Brian Ripley wrote:
> I think the confusion here is over close(): that closes *and destroys* a
> connection, so it no longer exists.
>
> isOpen applies to existing connections: you cannot close but not destroy
> them at R level, but C code can (and does). You will see it in use in
> the utils package.
>
>
> On Wed, 14 Nov 2007, Seth Falcon wrote:
>
>> "Roger D. Peng" <[EMAIL PROTECTED]> writes:
>>
>>> As far as I can tell, 'isOpen' cannot return FALSE in the case when
>>> 'rw = ""'.
>>> If the connection has already been closed by 'close' or some other
>>> function,
>>> then isOpen will produce an error. The problem is that when isOpen
>>> calls
>>> 'getConnection', the connection cannot be found and 'getConnection'
>>> produces an
>>> error. The check to see if it is open is never actually done.
>>
>> I see this too with R-devel (r43376) {from Nov 6th}.
>>
>>con = file("example1", "w")
>>isOpen(con)
>>
>>[1] TRUE
>>
>>showConnections()
>>
>> description class mode text isopen can read can write
>>3 "example1" "file" "w" "text" "opened" "no" "yes"
>>
>>close(con)
>>isOpen(con)
>>
>>Error in isOpen(con) : invalid connection
>>
>>## printing also fails
>>con
>>Error in summary.connection(x) : invalid connection
>>
>>> This came up in some code where I'm trying to clean up connections after
>>> successfully opening them. The problem is that if I try to close a
>>> connection
>>> that has already been closed, I get an error (because 'getConnection'
>>> cannot
>>> find it). But then there's no way for me to find out if a connection
>>> has
>>> already been closed. Perhaps there's another approach I should be
>>> taking? The
>>> context is basically,
>>>
>>> con <- file("foo", "w")
>>>
>>> tryCatch({
>>> ## Do stuff that might fail
>>> writeLines(stuff, con)
>>> close(con)
>>>
>>> file.copy("foo", "bar")
>>> }, finally = {
>>> close(con)
>>> })
>>
>> This doesn't address isOpen, but why do you have the call to close
>> inside the tryCatch block? Isn't the idea that finally will always be
>> run and so you can be reasonably sure that close gets called once?
>>
>> If your real world code is more complicated, perhaps you can make use
>> of a work around like:
>>
>> myIsOpen = function(con) tryCatch(isOpen(con), error=function(e) FALSE)
>>
>> You could do similar with myClose and "close" a connection as many
>> times as you'd like :-)
>>
>> + seth
>>
>>
>
--
Roger D. Peng | http://www.biostat.jhsph.edu/~rpeng/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] slots of type "double"
In-line omments near the end:
On Wed, 14 Nov 2007, Martin Maechler wrote:
still found a bit time for more remarks.
"MM" == Martin Mächler <[EMAIL PROTECTED]>
on Wed, 14 Nov 2007 14:23:12 +0100 (CET) writes:
MM> On Wed, November 14, 2007 09:09, Prof Brian Ripley
MM> wrote:
>> On Tue, 13 Nov 2007, Prof Brian Ripley wrote:
>>
>>> On Tue, 13 Nov 2007, John Chambers wrote:
>>>
What's the proposal here? To eliminate "double" as a
class? No objection
>>>
>>> Eliminate "double" and "single".
>>>
from this corner. As I remember, it was put in early
in the implementation of methods, when I was confused
about what R intended in this area (well, I'm not
totally unconfused even now).
If this is the proposal, we could implement it in
r-devel and see if there are complaints.
>>>
>>> I was going to propose so after running some tests over
>>> CRAN/BioC (which will take a few hours).
>>
>> Which showed up problems in packages Matrix and matlab.
>> Matrix clearly has a different view of these classes:
>>
>> ## "atomic vectors" (-> ?is.atomic ) -- ##
>> --- those that we want to convert from
>> old-style "matrix" setClassUnion("atomicVector", ##
>> numeric = {integer, double} but all 3 should *directly*
>> be atomic members = c("logical", "integer", "double",
>> "numeric", "complex", "raw", "character"))
>>
>> If I remove "double" there, I get an error in an example:
>>
>>> stopifnot(is(scm, "sparseVector"),
>> + identical(cm, as.numeric(scm))) Error in as([EMAIL PROTECTED], mode)
>> : no method or default for coercing "numeric" to "double"
>>
>> and looking at the code suggests that "double" is used as
>> the class name in several places.
yes.
As you mention and I had in the comment above,
I've worked from the premise of something like a class union of
numeric = {integer, double}
-- which corresponds to S3'sis.numeric() which we all know
differs from the semantic of as.numeric()
(It predates S3 classes, being in the Blue Book. And what as.numeric does
in R differs from the Blue Book description, although for a long time the
R help gave the BB version. But S also differs, at least in recent
years.)
and now know why I had done so {empty lines deleted}:
> showClass("numeric")
No Slots, prototype of class "numeric"
Extends: "vector"
Known Subclasses: "double", "integer"
> showClass("double")
No Slots, prototype of class "numeric"
Extends: "vector", "numeric"
> showClass("integer")
No Slots, prototype of class "integer"
Extends: "vector", "numeric"
which you partially also mentioned in your initial posting.
(I posted output from getClass, as showClass is not in the Green Book,
although I actually used showClass first.)
As a 2nd thought I wonder if we should not keep this current
scheme and fix its behavior where needed (the problem the OP had):
The notion of numeric := union(double, integer)
does now appeal to me again;
I don't believe we can get from here to there without massive upheaval.
"numeric" is not a virtual class, and making "double" the basic class and
"numeric" a virtual one would break tons of code (and writeups).
in particular since eliminating "double" in the S4 world will
not eliminate it from other places, and the basic problem of
is.numeric / as.numeric inconsistency is - I think - not
something we'd want to eliminate, just because it would break too
much existing code (and books on S and R).
(I do wonder if any of those books do get to that level of detail, and if
they do what system they describe, given the divergence from the Blue
Book. I checked that the VR ones do not. I tend to agree with the BB
comment that the storage type only matters in external interfaces,
although that perhaps undervalues +/-Inf which may not have been
available back then.)
I may be wrong, but I believe class "double" does not exist in the (strict
sense) S4 world: it was certainly not in S-PLUS 6.2.
With a clean-sheet design we might well do things differently, and I think
it would be possible for Matrix to make use of a class union of "numeric"
and "integer". But the name "numeric" is already taken and we are going
to have to live with three names [*] for the same concept, and setting S3
methods on as.double and S4 ones on as.numeric (because it would be too
painful to change either).
Brian
[*] numeric, double, real. My proposal to remove 'real' met with
objections.
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595__
R-devel@r-project.org mailing list
https://stat.ethz.ch/
Re: [Rd] faqs
On Nov 14, 2007, at 11:55 PM, Gabor Grothendieck wrote: > inst/NEWS would have the advantage of consistency with R itself > which also has a NEWS file. > I vote for NEWS for reasons above plus because that's what I use in my packages already ;). IMHO it should be installed automatically if present, i.e. it shouldn't be necessary to have it in inst/NEWS, just plain NEWS should suffice. Cheers, Simon > > On Nov 14, 2007 10:15 PM, Duncan Murdoch <[EMAIL PROTECTED]> wrote: >> On 14/11/2007 8:53 PM, Gabor Grothendieck wrote: >>> Another possibility is to just place it at the end of the vignette. >>> That is where it is in the proto package: >>> >>> http://cran.r-project.org/doc/vignettes/proto/proto.pdf >>> >>> Package documentation is already quite scattered and adding >>> a faq() command would add just one more thing one has >>> to do. Here are some places one might look already for >>> documentation: >>> >>> package?mypackage >> >> Or just ?mypackage. Writing R Extensions recommends package? >> mypackage, >> with ?mypackage also working if that name isn't taken. However, the >> advice is ignored more than it is followed. >> >>> vignette(...) >>> library(help = mypackage) >>> ?mycommand >>> home page >>> WISHLIST file >>> NEWS file >>> THANKS file >>> svn log >>> >>> I personally would give a much higher priority to a standardized >>> place to find change information. Some packages provide it. >>> Some don't which is very frustrating since you see a new version >>> and have no idea what has changed. If they do document it you >>> often have to download the source just to get at the change >>> information. >> >> Where do you put it? I put it in inst/ChangeLog, which ends up >> installed in the package root as ChangeLog. >> >> Whenever this has come up in the past, there have been several >> proposals, but no consensus. So, to encourage consensus, I've got a >> proposal: >> >> Why don't we vote on a location, with every voter agreeing to >> follow the >> majority? The only condition I'd put on it is that it should be >> something that gets installed, hence somewhere in inst, but I'd be >> happy >> to change the name if ChangeLog doesn't win. >> >> My vote is for inst/ChangeLog. >> >> Duncan Murdoch >> >> >>> >>> >>> >>> On Nov 14, 2007 8:22 PM, roger koenker >>> <[EMAIL PROTECTED]> wrote: An extremely modest proposal: It would be nice if packages could have a FAQ and if faq(package.name) would produce this faq. And if, by default faq() FAQ() would produce the admirable R faq... Apologies in advance if there is already a mechanism like this, but help.search() didn't reveal anything. url:www.econ.uiuc.edu/~rogerRoger Koenker email [EMAIL PROTECTED] Department of Economics vox:217-333-4558University of Illinois fax:217-244-6678Champaign, IL 61820 __ 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 >> >> > > __ > 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] NEWS file (was faqs)
On 11/15/2007 9:57 AM, Simon Urbanek wrote: > On Nov 14, 2007, at 11:55 PM, Gabor Grothendieck wrote: > >> inst/NEWS would have the advantage of consistency with R itself >> which also has a NEWS file. >> > > I vote for NEWS for reasons above plus because that's what I use in my > packages already ;). > IMHO it should be installed automatically if present, i.e. it > shouldn't be necessary to have it in inst/NEWS, just plain NEWS should > suffice. And you're volunteering to make that change? Duncan > > Cheers, > Simon > > >> >> On Nov 14, 2007 10:15 PM, Duncan Murdoch <[EMAIL PROTECTED]> wrote: >>> On 14/11/2007 8:53 PM, Gabor Grothendieck wrote: Another possibility is to just place it at the end of the vignette. That is where it is in the proto package: http://cran.r-project.org/doc/vignettes/proto/proto.pdf Package documentation is already quite scattered and adding a faq() command would add just one more thing one has to do. Here are some places one might look already for documentation: package?mypackage >>> >>> Or just ?mypackage. Writing R Extensions recommends package? >>> mypackage, >>> with ?mypackage also working if that name isn't taken. However, the >>> advice is ignored more than it is followed. >>> vignette(...) library(help = mypackage) ?mycommand home page WISHLIST file NEWS file THANKS file svn log I personally would give a much higher priority to a standardized place to find change information. Some packages provide it. Some don't which is very frustrating since you see a new version and have no idea what has changed. If they do document it you often have to download the source just to get at the change information. >>> >>> Where do you put it? I put it in inst/ChangeLog, which ends up >>> installed in the package root as ChangeLog. >>> >>> Whenever this has come up in the past, there have been several >>> proposals, but no consensus. So, to encourage consensus, I've got a >>> proposal: >>> >>> Why don't we vote on a location, with every voter agreeing to >>> follow the >>> majority? The only condition I'd put on it is that it should be >>> something that gets installed, hence somewhere in inst, but I'd be >>> happy >>> to change the name if ChangeLog doesn't win. >>> >>> My vote is for inst/ChangeLog. >>> >>> Duncan Murdoch >>> >>> On Nov 14, 2007 8:22 PM, roger koenker <[EMAIL PROTECTED]> wrote: > An extremely modest proposal: > > It would be nice if packages could have a FAQ and if > > faq(package.name) > > would produce this faq. And if, by default > > faq() > FAQ() > > would produce the admirable R faq... Apologies in advance > if there is already a mechanism like this, but help.search() > didn't reveal anything. > > url:www.econ.uiuc.edu/~rogerRoger Koenker > email [EMAIL PROTECTED] Department of > Economics > vox:217-333-4558University of > Illinois > fax:217-244-6678Champaign, IL 61820 > > __ > 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 >>> >>> >> >> __ >> 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] faqs
On Nov 15, 2007 9:57 AM, Simon Urbanek <[EMAIL PROTECTED]> wrote: > > On Nov 14, 2007, at 11:55 PM, Gabor Grothendieck wrote: > > > inst/NEWS would have the advantage of consistency with R itself > > which also has a NEWS file. > > > > I vote for NEWS for reasons above plus because that's what I use in my > packages already ;). > IMHO it should be installed automatically if present, i.e. it > shouldn't be necessary to have it in inst/NEWS, just plain NEWS should > suffice. > I agree that that would be desirable. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] isOpen on closed connections
I'd support a change, to having a closed-but-not-invalid status for a
'rw' connection, and to have a usable 'isOpen'. The suggestion of
relying on user-code to always "housekeep" after calling 'close', eg by
setting to NULL, seems a bit risky as a guideline for R as a whole (one
can never tell what convention a different author's code might follow).
And the 'myOpen' solution will work (I'm about to use it myself) but
cumbersome if everyone has to do it. With things as they are, I can
foresee a stream of "why does.../RTFM" emails...
Perhaps the more fundamental issue is whether 'getConnection' should
actually throw an error.
I'm getting bitten by this in R 2.6.1-- I use 'getConnection' in an
'on.exit' statement (where I can't be sure of the state of the
connection), and it's throwing an error instead of returning NULL as it
used to (and as the documentation still states).
--
Mark Bravington
CSIRO Mathematical & Information Sciences
Marine Laboratory
Castray Esplanade
Hobart 7001
TAS
ph (+61) 3 6232 5118
fax (+61) 3 6232 5012
mob (+61) 438 315 623
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Roger D. Peng
> Sent: Thursday, 15 November 2007 11:48 PM
> To: Prof Brian Ripley
> Cc: R-devel mailing list
> Subject: Re: [Rd] isOpen on closed connections
>
> Upon further consideration, I realized there is a
> philosophical element here---if a connection is closed and
> hence does not exist, is it open?
>
> The practical issue for me is that when you do something like
>
> close(con)
>
> the 'con' object is still lying around and is essentially
> undefined. For example, if I do
>
> close(con)
> con <- "hello"
>
> then it seems logical to me that 'isOpen' would return an
> error. But it feels natural to me that a sequence like
>
> close(con)
> isOpen(con) ## FALSE?
>
> would not lead to an error. Perhaps my expectations are not
> reasonable and I'd appreciate being corrected.
>
> Given Brian's comment, one solution would be to allowing
> closing but not destroying connections at the R level (maybe
> via an option?), but that is a change in semantics and I'm
> not sure if this problem really comes up that much.
>
> -roger
>
> Prof Brian Ripley wrote:
> > I think the confusion here is over close(): that closes
> *and destroys*
> > a connection, so it no longer exists.
> >
> > isOpen applies to existing connections: you cannot close but not
> > destroy them at R level, but C code can (and does). You
> will see it
> > in use in the utils package.
> >
> >
> > On Wed, 14 Nov 2007, Seth Falcon wrote:
> >
> >> "Roger D. Peng" <[EMAIL PROTECTED]> writes:
> >>
> >>> As far as I can tell, 'isOpen' cannot return FALSE in the
> case when
> >>> 'rw = ""'.
> >>> If the connection has already been closed by 'close' or
> some other
> >>> function, then isOpen will produce an error. The problem is that
> >>> when isOpen calls 'getConnection', the connection cannot be found
> >>> and 'getConnection'
> >>> produces an
> >>> error. The check to see if it is open is never actually done.
> >>
> >> I see this too with R-devel (r43376) {from Nov 6th}.
> >>
> >>con = file("example1", "w")
> >>isOpen(con)
> >>
> >>[1] TRUE
> >>
> >>showConnections()
> >>
> >> description class mode text isopen can read can write
> >>3 "example1" "file" "w" "text" "opened" "no" "yes"
> >>
> >>close(con)
> >>isOpen(con)
> >>
> >>Error in isOpen(con) : invalid connection
> >>
> >>## printing also fails
> >>con
> >>Error in summary.connection(x) : invalid connection
> >>
> >>> This came up in some code where I'm trying to clean up
> connections
> >>> after successfully opening them. The problem is that if I try to
> >>> close a connection that has already been closed, I get an error
> >>> (because 'getConnection'
> >>> cannot
> >>> find it). But then there's no way for me to find out if a
> >>> connection has already been closed. Perhaps there's another
> >>> approach I should be taking? The context is basically,
> >>>
> >>> con <- file("foo", "w")
> >>>
> >>> tryCatch({
> >>> ## Do stuff that might fail
> >>> writeLines(stuff, con)
> >>> close(con)
> >>>
> >>> file.copy("foo", "bar")
> >>> }, finally = {
> >>> close(con)
> >>> })
> >>
> >> This doesn't address isOpen, but why do you have the call to close
> >> inside the tryCatch block? Isn't the idea that finally
> will always
> >> be run and so you can be reasonably sure that close gets
> called once?
> >>
> >> If your real world code is more complicated, perhaps you
> can make use
> >> of a work around like:
> >>
> >> myIsOpen = function(con) tryCatch(isOpen(con), error=function(e)
> >> FALSE)
> >>
> >> You could do similar with myClose and "close" a connection as many
> >> times as you'd like :-)
> >>
> >> + seth
> >>
> >>
> >
>
> --
> Roger D. Peng | http://www.biostat.jhsph.edu/~rpeng/
>
> __
[Rd] Nested SEXP functions
Hey All,
I was wondering if I could solicit a little advice. I have been
experiencing some quirkiness in my C code through .Call.
Unfortunately, my program is rather large, so I'm trying to create a
brief example. Yet before I do, I thought maybe a conceptual question
would be sufficient.
Basically, I'm writing up a multidimensional Gaussian likelihood (with
spatial covariances and other enhancements). What I'm noticing is
that when I have nested SEXP functions I get inconsistent results.
Here is what I am essentially trying to accomplish when looking at the
Gaussian kernel:
l(beta) = (y-X*beta)^T V^{-1} (y-X*beta)
Now in order to accomplish this, I wrote various linear algebra
subroutines to handle the R objects, we'll call this:
SEXP XtimesY(SEXP X,SEXP Y); // X*Y
SEXP XminusY(SEXP X,SEXP Y); // X-Y
SEXP tX(SEXP X); // X^T
SEXP mycholinv(SEXP V); // Use cholesky decomposition for inverse
Now, what I'm noticing is that if I call each routine individually
such as:
pt1=XtimesY(X,beta); // X*beta
pt2=Xminus(Y,pt1); // Y-X*beta
pt3=tX(pt2); // (Y-X*beta)^T
pt4=mycholinv(V); //V^{-1}
pt5=XtimesY(pt2,pt4); // (Y-X*beta)^T V^{-1}
result=XtimesY(pt5,pt2); //(y-X*beta)^T V^{-1} (y-X*beta)
Then the result is correct. But if instead I want to save some lines
of code, and I use:
result=XtimesY(XtimesY(tX(XminusY(Y,XtimesY(X,beta))),mycholinv(V)),XminusY(Y,XtimesY(X,beta)))
I don't always get the same result. Now my question is, should I
expect weird and ugly things to happen when nesting SEXP functions
such as this? Or is it even highly discouraged in general in C to do
something like this?
If this should work, then I'll need to go through each one of the
functions and try to diagnose where the problem lies. Yet if it
shouldn't work, I'll stick with the first approach I have going now.
Thanks in advance for your input!
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Nested SEXP functions
You assume that when you call any of those functions its arguments are
protected (as it is the case when the function is called from within R).
However, I do not see why they would be if you do not do it explicitly.
Therefore, it is very likely that a result of one function, used in turn
in a call to the other one, is garbage collected on the way and what you
get can be totally wrong. The more R API calls you have within each of
those functions, the more likely it is that the unprotected argument is
garbage collected as the events are triggered within some of those
calls.
One should be very careful about protecting things in .Call interface.
Now here is what I mean in a coding example:
## R CODE #
z1 = .Call("interfaceCFun1", as.numeric(x)) # OK
z2 = .Call("interfaceCFun12", as.numeric(x)) # Can be !OK
SEXP f1(SEXP);
// C code
SEXP interfaceCFun(SEXP x) {
/ /x is protected, so it prints smth and returns new var to R
return f1(x);
}
SEXP interfaceCFun2(SEXP x) {
// for first call to f1 it prints smth of x and returns new var
// to the second call, however in the second call the argument is no
// more x, it is no more protected and can be released by GC, so it is
// no clear what it is going to print there!
return f1(f1(x));
// this would be correct:
SEXP y;
PROTECT(y=f1(x));
// now when we print in the following function we have memory
protected
y = f1(y)
UNPROTECT(1);
return y;
}
SEXP f1(SEXP x) {
Rprintf("\n"); // can possibly trigger garbage collector
Rprintf(REAL(x)[0]);
return allocVector(REALSXP,2);
}
Best,
Oleg
On Thu, 2007-11-15 at 17:10 -0500, [EMAIL PROTECTED] wrote:
> Hey All,
>
> I was wondering if I could solicit a little advice. I have been
> experiencing some quirkiness in my C code through .Call.
> Unfortunately, my program is rather large, so I'm trying to create a
> brief example. Yet before I do, I thought maybe a conceptual question
> would be sufficient.
>
> Basically, I'm writing up a multidimensional Gaussian likelihood (with
> spatial covariances and other enhancements). What I'm noticing is
> that when I have nested SEXP functions I get inconsistent results.
>
> Here is what I am essentially trying to accomplish when looking at the
> Gaussian kernel:
>
> l(beta) = (y-X*beta)^T V^{-1} (y-X*beta)
>
> Now in order to accomplish this, I wrote various linear algebra
> subroutines to handle the R objects, we'll call this:
>
> SEXP XtimesY(SEXP X,SEXP Y); // X*Y
> SEXP XminusY(SEXP X,SEXP Y); // X-Y
> SEXP tX(SEXP X); // X^T
> SEXP mycholinv(SEXP V); // Use cholesky decomposition for inverse
>
> Now, what I'm noticing is that if I call each routine individually
> such as:
>
> pt1=XtimesY(X,beta); // X*beta
> pt2=Xminus(Y,pt1); // Y-X*beta
> pt3=tX(pt2); // (Y-X*beta)^T
> pt4=mycholinv(V); //V^{-1}
> pt5=XtimesY(pt2,pt4); // (Y-X*beta)^T V^{-1}
> result=XtimesY(pt5,pt2); //(y-X*beta)^T V^{-1} (y-X*beta)
>
> Then the result is correct. But if instead I want to save some lines
> of code, and I use:
>
> result=XtimesY(XtimesY(tX(XminusY(Y,XtimesY(X,beta))),mycholinv(V)),XminusY(Y,XtimesY(X,beta)))
>
> I don't always get the same result. Now my question is, should I
> expect weird and ugly things to happen when nesting SEXP functions
> such as this? Or is it even highly discouraged in general in C to do
> something like this?
>
> If this should work, then I'll need to go through each one of the
> functions and try to diagnose where the problem lies. Yet if it
> shouldn't work, I'll stick with the first approach I have going now.
>
> Thanks in advance for your input!
>
> __
> 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] Nested SEXP functions
On Thu, Nov 15, 2007 at 11:53:53PM +, Oleg Sklyar wrote:
> You assume that when you call any of those functions its arguments are
> protected (as it is the case when the function is called from within R).
> However, I do not see why they would be if you do not do it explicitly.
> Therefore, it is very likely that a result of one function, used in turn
> in a call to the other one, is garbage collected on the way and what you
> get can be totally wrong. The more R API calls you have within each of
> those functions, the more likely it is that the unprotected argument is
> garbage collected as the events are triggered within some of those
> calls.
>
> One should be very careful about protecting things in .Call interface.
> Now here is what I mean in a coding example:
Oleg,
Ah Ha!!! I was sure that I protected everything within each one of
the modular functions, so I couldn't understand why my results were
similar to a garbage collection issue. That is, on small examples I
would get the right result, but on large data it would keep failing
with wild numbers.
What you say makes complete sense, and is completely consistent with
the documentation. I appreciate the examples and how they emphasize
your point, and I'm even more grateful that you saved me the effort of
having to write sample code to ask my question.
After reading your advice, I just realized something. Instead of
doing this all within my main program, I could reduce the annoying
steps in my main code by writing the Gaussian kernel as another
modular function. It would essentially accomplish the same goal!
Thanks!
>
> ## R CODE #
> z1 = .Call("interfaceCFun1", as.numeric(x)) # OK
> z2 = .Call("interfaceCFun12", as.numeric(x)) # Can be !OK
>
> SEXP f1(SEXP);
>
> // C code
> SEXP interfaceCFun(SEXP x) {
> / /x is protected, so it prints smth and returns new var to R
> return f1(x);
> }
> SEXP interfaceCFun2(SEXP x) {
> // for first call to f1 it prints smth of x and returns new var
> // to the second call, however in the second call the argument is no
> // more x, it is no more protected and can be released by GC, so it is
> // no clear what it is going to print there!
> return f1(f1(x));
>
> // this would be correct:
> SEXP y;
> PROTECT(y=f1(x));
> // now when we print in the following function we have memory
> protected
> y = f1(y)
> UNPROTECT(1);
> return y;
> }
>
> SEXP f1(SEXP x) {
> Rprintf("\n"); // can possibly trigger garbage collector
> Rprintf(REAL(x)[0]);
> return allocVector(REALSXP,2);
> }
>
> Best,
>
> Oleg
>
>
> On Thu, 2007-11-15 at 17:10 -0500, [EMAIL PROTECTED] wrote:
> > Hey All,
> >
> > I was wondering if I could solicit a little advice. I have been
> > experiencing some quirkiness in my C code through .Call.
> > Unfortunately, my program is rather large, so I'm trying to create a
> > brief example. Yet before I do, I thought maybe a conceptual question
> > would be sufficient.
> >
> > Basically, I'm writing up a multidimensional Gaussian likelihood (with
> > spatial covariances and other enhancements). What I'm noticing is
> > that when I have nested SEXP functions I get inconsistent results.
> >
> > Here is what I am essentially trying to accomplish when looking at the
> > Gaussian kernel:
> >
> > l(beta) = (y-X*beta)^T V^{-1} (y-X*beta)
> >
> > Now in order to accomplish this, I wrote various linear algebra
> > subroutines to handle the R objects, we'll call this:
> >
> > SEXP XtimesY(SEXP X,SEXP Y); // X*Y
> > SEXP XminusY(SEXP X,SEXP Y); // X-Y
> > SEXP tX(SEXP X); // X^T
> > SEXP mycholinv(SEXP V); // Use cholesky decomposition for inverse
> >
> > Now, what I'm noticing is that if I call each routine individually
> > such as:
> >
> > pt1=XtimesY(X,beta); // X*beta
> > pt2=Xminus(Y,pt1); // Y-X*beta
> > pt3=tX(pt2); // (Y-X*beta)^T
> > pt4=mycholinv(V); //V^{-1}
> > pt5=XtimesY(pt2,pt4); // (Y-X*beta)^T V^{-1}
> > result=XtimesY(pt5,pt2); //(y-X*beta)^T V^{-1} (y-X*beta)
> >
> > Then the result is correct. But if instead I want to save some lines
> > of code, and I use:
> >
> > result=XtimesY(XtimesY(tX(XminusY(Y,XtimesY(X,beta))),mycholinv(V)),XminusY(Y,XtimesY(X,beta)))
> >
> > I don't always get the same result. Now my question is, should I
> > expect weird and ugly things to happen when nesting SEXP functions
> > such as this? Or is it even highly discouraged in general in C to do
> > something like this?
> >
> > If this should work, then I'll need to go through each one of the
> > functions and try to diagnose where the problem lies. Yet if it
> > shouldn't work, I'll stick with the first approach I have going now.
> >
> > Thanks in advance for your input!
> >
> > __
> > 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] NEWS file (was faqs)
On Nov 15, 2007, at 10:53 AM, Duncan Murdoch wrote: > On 11/15/2007 9:57 AM, Simon Urbanek wrote: >> On Nov 14, 2007, at 11:55 PM, Gabor Grothendieck wrote: >>> inst/NEWS would have the advantage of consistency with R itself >>> which also has a NEWS file. >>> >> I vote for NEWS for reasons above plus because that's what I use in >> my packages already ;). >> IMHO it should be installed automatically if present, i.e. it >> shouldn't be necessary to have it in inst/NEWS, just plain NEWS >> should suffice. > > And you're volunteering to make that change? > Yup, in R-devel now (43464). However, there are other candidate files as well and we don't do anything with the NEWS file just yet ... any further ideas? Cheers, Simon > >> Cheers, >> Simon >>> >>> On Nov 14, 2007 10:15 PM, Duncan Murdoch <[EMAIL PROTECTED]> >>> wrote: On 14/11/2007 8:53 PM, Gabor Grothendieck wrote: > Another possibility is to just place it at the end of the > vignette. > That is where it is in the proto package: > > http://cran.r-project.org/doc/vignettes/proto/proto.pdf > > Package documentation is already quite scattered and adding > a faq() command would add just one more thing one has > to do. Here are some places one might look already for > documentation: > > package?mypackage Or just ?mypackage. Writing R Extensions recommends package? mypackage, with ?mypackage also working if that name isn't taken. However, the advice is ignored more than it is followed. > vignette(...) > library(help = mypackage) > ?mycommand > home page > WISHLIST file > NEWS file > THANKS file > svn log > > I personally would give a much higher priority to a standardized > place to find change information. Some packages provide it. > Some don't which is very frustrating since you see a new version > and have no idea what has changed. If they do document it you > often have to download the source just to get at the change > information. Where do you put it? I put it in inst/ChangeLog, which ends up installed in the package root as ChangeLog. Whenever this has come up in the past, there have been several proposals, but no consensus. So, to encourage consensus, I've got a proposal: Why don't we vote on a location, with every voter agreeing to follow the majority? The only condition I'd put on it is that it should be something that gets installed, hence somewhere in inst, but I'd be happy to change the name if ChangeLog doesn't win. My vote is for inst/ChangeLog. Duncan Murdoch > > > > On Nov 14, 2007 8:22 PM, roger koenker <[EMAIL PROTECTED] > > wrote: >> An extremely modest proposal: >> >> It would be nice if packages could have a FAQ and if >> >> faq(package.name) >> >> would produce this faq. And if, by default >> >> faq() >> FAQ() >> >> would produce the admirable R faq... Apologies in advance >> if there is already a mechanism like this, but help.search() >> didn't reveal anything. >> >> url:www.econ.uiuc.edu/~rogerRoger Koenker >> email [EMAIL PROTECTED] Department of >> Economics >> vox:217-333-4558University of >> Illinois >> fax:217-244-6678Champaign, IL >> 61820 >> >> __ >> 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 >>> >>> __ >>> 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
