[Rd] Exiting R and package detachment?
Hi,
is there away to assure that a package is detached when R quits? I know
about .Last(), but that requires the user to setup that function. What
I am looking for is a way for the package to do this itself, without
asking the user to edit "their" .Last(). From ?setHook I know that:
"...when an R is finished, packages are not detached and namespaces
are not unloaded, so the corresponding hooks will not be run."
I am going to use this to load settings from file when a package loads
and automatically save (by optionally prompting the user) them back to
file when the package is no longer available (==detached/unloaded/R
quits). I am currently loading the settings in .First.lib() and have
code in .Last.lib() to save them.
Are there other ways to assure functions to be called when R quits? The
best I can think of now is to "hack" .Last() by doing something like
if (!exists(".LastOriginal", mode="function")) {
.LastOriginal <<- get(".Last", envir=.GlobalEnv);
.Last <<- function(..., envir=parent.frame()) {
for (fun in getHook(".Last")) {
if (is.character(fun))
fun <- get(fun, mode="function")
try(fun());
}
eval(.LastOriginal(...), envir=envir);
} # .Last()
}
Then in package :
.First.lib <- function(libname, pkgname) {
# Detach package when R finishes.
setHook(".Last", function(...) {
pos <- match(paste("package:", pkgname, sep=""), search());
if (!is.na(pos))
detach(pos=pos);
})
}
However, this will be broken if user redefines .Last(). What about
defining a hook "onSessionExit" to be called before (after?) .Last() is
called. In analogue to on.exit() one could then define
onSessionExit <- function(fcn, ...) {
setHook("onSessionExit", fcn, ...);
}
Just curious, the above quote makes me wonder what is the rational for
the behavior? Was it made on purpose or is it simply just easier for R
to finish without detaching/unloading packages first? In what
situations to you have "clean-up" code for a package that is only called
when detach("package:") is used? One situation I can imaging is
when a bundle of packages are loaded and when you detach the package
that all other packages requires, the other packages are also detached
for conveniency.
Best wishes
Henrik
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] [QuickML] Error: hello
You are not a member of the mailing list: <[EMAIL PROTECTED]> Did you send a mail with a different address from the address registered in the mailing list? Please check your 'From:' address. -- Info: http://QuickML.com/ - Original Message - Subject: hello To: [EMAIL PROTECTED] From: [EMAIL PROTECTED] Date: Fri, 10 Jun 2005 18:45:26 -0700 ALERT!!! This e-mail contained one or more infected files. The following attachments were infected and have been repaired: No attachments are in this category. The following infected attachments were deleted: 1. test.scr: [EMAIL PROTECTED] The following infected attachments were blocked because of Mail Policy violations: No attachments are in this category. You may wish to contact the sender to notify them about their infected file(s). Thank you Original message text follows The original message was included as an attachment. file attachment: test.scr The file attached to this email was removed because it is infected with the [EMAIL PROTECTED] virus. __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Exiting R and package detachment?
Note that you can terminate R via q() without running .Last, and indeed
how R is terminated is up to the front-end in use. So the answer to
> is there away to assure that a package is detached when R quits?
is `No'.
On Fri, 10 Jun 2005, Henrik Bengtsson wrote:
> Hi,
>
> is there away to assure that a package is detached when R quits? I know
> about .Last(), but that requires the user to setup that function. What
> I am looking for is a way for the package to do this itself, without
> asking the user to edit "their" .Last(). From ?setHook I know that:
>
> "...when an R is finished, packages are not detached and namespaces
> are not unloaded, so the corresponding hooks will not be run."
>
> I am going to use this to load settings from file when a package loads
> and automatically save (by optionally prompting the user) them back to
> file when the package is no longer available (==detached/unloaded/R
> quits). I am currently loading the settings in .First.lib() and have
> code in .Last.lib() to save them.
>
> Are there other ways to assure functions to be called when R quits? The
> best I can think of now is to "hack" .Last() by doing something like
>
> if (!exists(".LastOriginal", mode="function")) {
> .LastOriginal <<- get(".Last", envir=.GlobalEnv);
>
> .Last <<- function(..., envir=parent.frame()) {
> for (fun in getHook(".Last")) {
> if (is.character(fun))
> fun <- get(fun, mode="function")
> try(fun());
> }
> eval(.LastOriginal(...), envir=envir);
> } # .Last()
> }
>
> Then in package :
> .First.lib <- function(libname, pkgname) {
> # Detach package when R finishes.
> setHook(".Last", function(...) {
> pos <- match(paste("package:", pkgname, sep=""), search());
> if (!is.na(pos))
> detach(pos=pos);
> })
> }
>
> However, this will be broken if user redefines .Last(). What about
> defining a hook "onSessionExit" to be called before (after?) .Last() is
> called. In analogue to on.exit() one could then define
>
> onSessionExit <- function(fcn, ...) {
> setHook("onSessionExit", fcn, ...);
> }
>
>
> Just curious, the above quote makes me wonder what is the rational for
> the behavior? Was it made on purpose or is it simply just easier for R
> to finish without detaching/unloading packages first? In what
> situations to you have "clean-up" code for a package that is only called
> when detach("package:") is used? One situation I can imaging is
> when a bundle of packages are loaded and when you detach the package
> that all other packages requires, the other packages are also detached
> for conveniency.
>
> Best wishes
>
> Henrik
>
> __
> [EMAIL PROTECTED] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
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
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggestion: help()
Kurt Hornik wrote: >>Duncan Murdoch writes: > > >On Tue, 7 Jun 2005, Duncan Murdoch wrote: > >[...] > > > >>My proposal (modified following the suggestions I've heard so far) is as >>follows: >> >> - to check that a couple of help topic aliases exist (.package >>and ) >> - to recommend that .package contain general information about >>the package, and that be an alias for it, if it isn't used for >>some other purpose. >> - to write promptPackage() to help create an initial version of >>.package.Rd. It can get some information from the DESCRIPTION >>file; perhaps it could go looking for a vignette, or the INDEX, or >> - to modify the other help system tools to make use of this (e.g. the >>package: heading on a page would become a link to the .package >>alias, etc.) > > >>I've now committed some of this to R-devel, and I invite comments. I've >>abandoned the idea of the check, which seems too controversial. I've >>done the second and third items, but not the 4th. > > >>I wrote about a dozen of these files this afternoon as I was refining >>promptPackage. It is very quick to generate a basic man page using >>promptPackage with an option saying you want a final version. Manually >>editing this file, running it through checks, etc. took me around 10-20 >>minutes per package. > > >>I only did the base packages, and they probably have less in their >>overview than most contributors would want, so someone starting from >>nothing would probably take longer --- but many packages already have >>the text written somewhere, and they just need to add an alias to an Rd >>file, or perhaps reformat an INDEX file. > > > Duncan, > > I am not sure why you went ahead on this. It seemed to me that most of the discussion focussed on one point (forcing extra work on people); this seems to be the only way to get discussion on any other aspect of the proposal. > My understanding was that > there was considerable opposition to introducing a convention for > package documentation intermediate between providing package meta data > in the DESCRIPTION file and providing vignettes, given in particular > that we already have such an additional mechanism (INDEX files) for > historic reasons. The reason I went ahead was that I think this implementation is an improvement on INDEX files, though it is backwards compatible. In several of the overviews I wrote I refer to the automatically generated INDEX file. In cases where the INDEX was manually edited I recommend putting the content into the overview topic instead (but do not force this). I did it for the boot package (and I'll send the work to Brian if he's interested in incorporating it, since boot isn't a base package, and he's the maintainer); it wasn't that hard, but I think it was an improvement, in that the function names can be links to the function man pages, not just names to be copied and pasted. In at least one case (the stats4 package) I think the INDEX file is almost completely useless, so I wrote the overview completely from scratch. I'm not sure I got it right, comments or corrections to the content would of course be welcome too. However, I'd really like to hear a clear explanation of why you think the current system is superior. So far all that I've heard are messages like "this forces too much work on package writers", "we did this three years ago, why do it again?" I've explained why I think this solution is better, and I've modified it to allow it to be anywhere from "zero cost" (ignore it) to "very low cost" (use the automatically generated overview), on up as far as a package writer wants to take it. > I also object particularly to the naming convention. Rd documentation > objects are identified by their NAME (as indicated in their \name meta > data), not the name of the file used for their serialization into Rd > format. IF we want to have such a mechanism, then at least let it work > on a topic-style alias of the form PACKAGE-package, which would be > consistent with what we do for S4 classes and methods. The problem with that style is that it doesn't parse to a name, so it needs quotes to work with the help system. For example, ?boot-PACKAGE doesn't do what you'd guess at all. (It gives help on "-"). Remember, my main aim is to simplify the answer to the question "how do I get help on foo?" So far nobody has written out a complete answer to that question; I invite you to try to do so. I'd have to see how it works with all the tools, but in principle I'd have no objection to putting "-" in the name, as long as there was guaranteed to be a simple pattern to generate an alias that wouldn't need quoting. Would you object to that? Why? Unfortunately our help system doesn't handle duplicate aliases, so I can't always use the package name as an alias (which is what I'd really like to do). However, changes to
Re: [Rd] Exiting R and package detachment?
Prof Brian Ripley wrote:
> Note that you can terminate R via q() without running .Last, and indeed
> how R is terminated is up to the front-end in use. So the answer to
>
>> is there away to assure that a package is detached when R quits?
>
>
> is `No'.
Thank you for this. After rereading the ?Last, I wonder, is it
.Internal(quit(...)) that calls .Last() or is it some other lower-level
mechanism that does this? In other words, is it only when
quit(runLast=TRUE) is called that .Last() is called?
/Henrik
PS. I know the answer is in the source code, but I'm behind a 56k modem
without having the source code on my laptop. DS.
> On Fri, 10 Jun 2005, Henrik Bengtsson wrote:
>
>> Hi,
>>
>> is there away to assure that a package is detached when R quits? I know
>> about .Last(), but that requires the user to setup that function. What
>> I am looking for is a way for the package to do this itself, without
>> asking the user to edit "their" .Last(). From ?setHook I know that:
>>
>> "...when an R is finished, packages are not detached and namespaces
>> are not unloaded, so the corresponding hooks will not be run."
>>
>> I am going to use this to load settings from file when a package loads
>> and automatically save (by optionally prompting the user) them back to
>> file when the package is no longer available (==detached/unloaded/R
>> quits). I am currently loading the settings in .First.lib() and have
>> code in .Last.lib() to save them.
>>
>> Are there other ways to assure functions to be called when R quits? The
>> best I can think of now is to "hack" .Last() by doing something like
>>
>> if (!exists(".LastOriginal", mode="function")) {
>> .LastOriginal <<- get(".Last", envir=.GlobalEnv);
>>
>> .Last <<- function(..., envir=parent.frame()) {
>> for (fun in getHook(".Last")) {
>> if (is.character(fun))
>> fun <- get(fun, mode="function")
>> try(fun());
>> }
>> eval(.LastOriginal(...), envir=envir);
>> } # .Last()
>> }
>>
>> Then in package :
>> .First.lib <- function(libname, pkgname) {
>> # Detach package when R finishes.
>> setHook(".Last", function(...) {
>> pos <- match(paste("package:", pkgname, sep=""), search());
>> if (!is.na(pos))
>> detach(pos=pos);
>> })
>> }
>>
>> However, this will be broken if user redefines .Last(). What about
>> defining a hook "onSessionExit" to be called before (after?) .Last() is
>> called. In analogue to on.exit() one could then define
>>
>> onSessionExit <- function(fcn, ...) {
>> setHook("onSessionExit", fcn, ...);
>> }
>>
>>
>> Just curious, the above quote makes me wonder what is the rational for
>> the behavior? Was it made on purpose or is it simply just easier for R
>> to finish without detaching/unloading packages first? In what
>> situations to you have "clean-up" code for a package that is only called
>> when detach("package:") is used? One situation I can imaging is
>> when a bundle of packages are loaded and when you detach the package
>> that all other packages requires, the other packages are also detached
>> for conveniency.
>>
>> Best wishes
>>
>> Henrik
>>
>> __
>> [EMAIL PROTECTED] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggestion: help()
On 6/10/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > Kurt Hornik wrote: > >>Duncan Murdoch writes: > > > > > >On Tue, 7 Jun 2005, Duncan Murdoch wrote: > > > >[...] > > > > > > > >>My proposal (modified following the suggestions I've heard so far) is as > >>follows: > >> > >> - to check that a couple of help topic aliases exist (.package > >>and ) > >> - to recommend that .package contain general information about > >>the package, and that be an alias for it, if it isn't used for > >>some other purpose. > >> - to write promptPackage() to help create an initial version of > >>.package.Rd. It can get some information from the DESCRIPTION > >>file; perhaps it could go looking for a vignette, or the INDEX, or > >> - to modify the other help system tools to make use of this (e.g. the > >>package: heading on a page would become a link to the .package > >>alias, etc.) > > > > > >>I've now committed some of this to R-devel, and I invite comments. I've > >>abandoned the idea of the check, which seems too controversial. I've > >>done the second and third items, but not the 4th. > > > > > >>I wrote about a dozen of these files this afternoon as I was refining > >>promptPackage. It is very quick to generate a basic man page using > >>promptPackage with an option saying you want a final version. Manually > >>editing this file, running it through checks, etc. took me around 10-20 > >>minutes per package. > > > > > >>I only did the base packages, and they probably have less in their > >>overview than most contributors would want, so someone starting from > >>nothing would probably take longer --- but many packages already have > >>the text written somewhere, and they just need to add an alias to an Rd > >>file, or perhaps reformat an INDEX file. > > > > > > Duncan, > > > > I am not sure why you went ahead on this. > > It seemed to me that most of the discussion focussed on one point > (forcing extra work on people); this seems to be the only way to get > discussion on any other aspect of the proposal. > > > My understanding was that > > there was considerable opposition to introducing a convention for > > package documentation intermediate between providing package meta data > > in the DESCRIPTION file and providing vignettes, given in particular > > that we already have such an additional mechanism (INDEX files) for > > historic reasons. > > The reason I went ahead was that I think this implementation is an > improvement on INDEX files, though it is backwards compatible. In > several of the overviews I wrote I refer to the automatically generated > INDEX file. In cases where the INDEX was manually edited I recommend > putting the content into the overview topic instead (but do not force > this). I did it for the boot package (and I'll send the work to Brian if > he's interested in incorporating it, since boot isn't a base package, > and he's the maintainer); it wasn't that hard, but I think it was an > improvement, in that the function names can be links to the function man > pages, not just names to be copied and pasted. > > In at least one case (the stats4 package) I think the INDEX file is > almost completely useless, so I wrote the overview completely from > scratch. I'm not sure I got it right, comments or corrections to the > content would of course be welcome too. > > However, I'd really like to hear a clear explanation of why you think > the current system is superior. So far all that I've heard are messages > like "this forces too much work on package writers", "we did this three > years ago, why do it again?" I've explained why I think this solution > is better, and I've modified it to allow it to be anywhere from "zero > cost" (ignore it) to "very low cost" (use the automatically generated > overview), on up as far as a package writer wants to take it. > > > I also object particularly to the naming convention. Rd documentation > > objects are identified by their NAME (as indicated in their \name meta > > data), not the name of the file used for their serialization into Rd > > format. IF we want to have such a mechanism, then at least let it work > > on a topic-style alias of the form PACKAGE-package, which would be > > consistent with what we do for S4 classes and methods. > > The problem with that style is that it doesn't parse to a name, so it > needs quotes to work with the help system. For example, > > ?boot-PACKAGE It would be invoked like this: package?boot with the effect of giving help on boot-package. By the way, note that this already works in R since foo?bar works generally to give help on bar-foo thus the main issue is just whether packages actually make use of it, whether R CMD CHECK regards it as mandatory or not and support tools such as promptPackage and links. The best situation would be that if one did: ?mypkg that it would find all occurrences of whatever?mypkg
[Rd] R 2.1.1 slated for June 20
The next version of R will be released (barring force majeure) on June 20th, with beta versions available starting Monday. Please do check them on your system *before* the release this time... Apologies for the late announcement, but my department moved this week and I needed to be sure that my set-up survived the move. -pd -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggestion: help()
On 6/10/2005 8:00 AM, Gabor Grothendieck wrote: > On 6/10/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: >> Kurt Hornik wrote: >> >>Duncan Murdoch writes: >> > >> > >> >On Tue, 7 Jun 2005, Duncan Murdoch wrote: >> > >> >[...] >> > >> > >> > >> >>My proposal (modified following the suggestions I've heard so far) is >> >>as >> >>follows: >> >> >> >> - to check that a couple of help topic aliases exist (.package >> >>and ) >> >> - to recommend that .package contain general information about >> >>the package, and that be an alias for it, if it isn't used for >> >>some other purpose. >> >> - to write promptPackage() to help create an initial version of >> >>.package.Rd. It can get some information from the DESCRIPTION >> >>file; perhaps it could go looking for a vignette, or the INDEX, or >> >> - to modify the other help system tools to make use of this (e.g. the >> >>package: heading on a page would become a link to the >> >>.package >> >>alias, etc.) >> > >> > >> >>I've now committed some of this to R-devel, and I invite comments. I've >> >>abandoned the idea of the check, which seems too controversial. I've >> >>done the second and third items, but not the 4th. >> > >> > >> >>I wrote about a dozen of these files this afternoon as I was refining >> >>promptPackage. It is very quick to generate a basic man page using >> >>promptPackage with an option saying you want a final version. Manually >> >>editing this file, running it through checks, etc. took me around 10-20 >> >>minutes per package. >> > >> > >> >>I only did the base packages, and they probably have less in their >> >>overview than most contributors would want, so someone starting from >> >>nothing would probably take longer --- but many packages already have >> >>the text written somewhere, and they just need to add an alias to an Rd >> >>file, or perhaps reformat an INDEX file. >> > >> > >> > Duncan, >> > >> > I am not sure why you went ahead on this. >> >> It seemed to me that most of the discussion focussed on one point >> (forcing extra work on people); this seems to be the only way to get >> discussion on any other aspect of the proposal. >> >> > My understanding was that >> > there was considerable opposition to introducing a convention for >> > package documentation intermediate between providing package meta data >> > in the DESCRIPTION file and providing vignettes, given in particular >> > that we already have such an additional mechanism (INDEX files) for >> > historic reasons. >> >> The reason I went ahead was that I think this implementation is an >> improvement on INDEX files, though it is backwards compatible. In >> several of the overviews I wrote I refer to the automatically generated >> INDEX file. In cases where the INDEX was manually edited I recommend >> putting the content into the overview topic instead (but do not force >> this). I did it for the boot package (and I'll send the work to Brian if >> he's interested in incorporating it, since boot isn't a base package, >> and he's the maintainer); it wasn't that hard, but I think it was an >> improvement, in that the function names can be links to the function man >> pages, not just names to be copied and pasted. >> >> In at least one case (the stats4 package) I think the INDEX file is >> almost completely useless, so I wrote the overview completely from >> scratch. I'm not sure I got it right, comments or corrections to the >> content would of course be welcome too. >> >> However, I'd really like to hear a clear explanation of why you think >> the current system is superior. So far all that I've heard are messages >> like "this forces too much work on package writers", "we did this three >> years ago, why do it again?" I've explained why I think this solution >> is better, and I've modified it to allow it to be anywhere from "zero >> cost" (ignore it) to "very low cost" (use the automatically generated >> overview), on up as far as a package writer wants to take it. >> >> > I also object particularly to the naming convention. Rd documentation >> > objects are identified by their NAME (as indicated in their \name meta >> > data), not the name of the file used for their serialization into Rd >> > format. IF we want to have such a mechanism, then at least let it work >> > on a topic-style alias of the form PACKAGE-package, which would be >> > consistent with what we do for S4 classes and methods. >> >> The problem with that style is that it doesn't parse to a name, so it >> needs quotes to work with the help system. For example, >> >> ?boot-PACKAGE > > It would be invoked like this: > >package?boot > > with the effect of giving help on boot-package. Okay, I get it. That's a good change. I'll put it in unless I hear objections very soon. (I'm going to be away from tomorrow through Thursday, so I might appear to be ignoring objections if I don't see them
Re: [Rd] Exiting R and package detachment?
On Fri, 10 Jun 2005, Henrik Bengtsson wrote:
> Prof Brian Ripley wrote:
>> Note that you can terminate R via q() without running .Last, and indeed how
>> R is terminated is up to the front-end in use. So the answer to
>>
>>> is there away to assure that a package is detached when R quits?
>>
>>
>> is `No'.
>
> Thank you for this. After rereading the ?Last, I wonder, is it
> .Internal(quit(...)) that calls .Last() or is it some other lower-level
> mechanism that does this? In other words, is it only when quit(runLast=TRUE)
> is called that .Last() is called?
It is done by the front-end's termination code, e.g. RStd_CleanUp on
terminal-based Unix.
>
> /Henrik
>
> PS. I know the answer is in the source code, but I'm behind a 56k modem
> without having the source code on my laptop. DS.
Look at Writing R Extensions, which does explain all this.
>> On Fri, 10 Jun 2005, Henrik Bengtsson wrote:
>>
>>> Hi,
>>>
>>> is there away to assure that a package is detached when R quits? I know
>>> about .Last(), but that requires the user to setup that function. What
>>> I am looking for is a way for the package to do this itself, without
>>> asking the user to edit "their" .Last(). From ?setHook I know that:
>>>
>>> "...when an R is finished, packages are not detached and namespaces
>>> are not unloaded, so the corresponding hooks will not be run."
>>>
>>> I am going to use this to load settings from file when a package loads
>>> and automatically save (by optionally prompting the user) them back to
>>> file when the package is no longer available (==detached/unloaded/R
>>> quits). I am currently loading the settings in .First.lib() and have
>>> code in .Last.lib() to save them.
>>>
>>> Are there other ways to assure functions to be called when R quits? The
>>> best I can think of now is to "hack" .Last() by doing something like
>>>
>>> if (!exists(".LastOriginal", mode="function")) {
>>> .LastOriginal <<- get(".Last", envir=.GlobalEnv);
>>>
>>> .Last <<- function(..., envir=parent.frame()) {
>>> for (fun in getHook(".Last")) {
>>> if (is.character(fun))
>>> fun <- get(fun, mode="function")
>>> try(fun());
>>> }
>>> eval(.LastOriginal(...), envir=envir);
>>> } # .Last()
>>> }
>>>
>>> Then in package :
>>> .First.lib <- function(libname, pkgname) {
>>> # Detach package when R finishes.
>>> setHook(".Last", function(...) {
>>> pos <- match(paste("package:", pkgname, sep=""), search());
>>> if (!is.na(pos))
>>> detach(pos=pos);
>>> })
>>> }
>>>
>>> However, this will be broken if user redefines .Last(). What about
>>> defining a hook "onSessionExit" to be called before (after?) .Last() is
>>> called. In analogue to on.exit() one could then define
>>>
>>> onSessionExit <- function(fcn, ...) {
>>> setHook("onSessionExit", fcn, ...);
>>> }
>>>
>>>
>>> Just curious, the above quote makes me wonder what is the rational for
>>> the behavior? Was it made on purpose or is it simply just easier for R
>>> to finish without detaching/unloading packages first? In what
>>> situations to you have "clean-up" code for a package that is only called
>>> when detach("package:") is used? One situation I can imaging is
>>> when a bundle of packages are loaded and when you detach the package
>>> that all other packages requires, the other packages are also detached
>>> for conveniency.
>>>
>>> Best wishes
>>>
>>> Henrik
>>>
>>> __
>>> [EMAIL PROTECTED] mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>>
>>
>
>
--
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
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.1.1 slated for June 20
On Fri, 10 Jun 2005, Peter Dalgaard wrote: > The next version of R will be released (barring force majeure) on June > 20th, with beta versions available starting Monday. > > Please do check them on your system *before* the release this time... Some things which it would be particularly helpful to have tested: - FreeBSD. We believe we have a workaround and it has been tested by Rainer Hurling, but tests of the actual beta tarball would be helpful. - AIX. I am unclear if R currrently builds on AIX. - Solaris 10. I believe that various people have now succeeded, but it would be good to have positive feedback, especially if anyone has the latest Sun compilers (Forte 9?). - Korean. We have recently had contributed Korean translations of the messages, Windows menus and installer. It looks like Korean to me, but that's as far as it goes. So please test on Windows and on Unix-alikes, the latter in both UTF-8 and EUC-KR if possible. - Bleeding-edge OSes, e.g. anyone running Fedora Core 4 test 3? (These often show up problems with bugs in the pre-release versions of components such as X11 and compilers.) - Windows: R for Windows can now be installed in a wide range of Western European languages, some Eastern European ones, (Simplified) Chinese, Japanese and Korean. Please test these. If you know Catalan, Czech, Dutch, Hungarian, Norwegian, Polish, (European) Portuguese or Slovenian please consider submitting translations for the following phrases which will otherwise appear in English: en.regentries=Registry entries: en.associate=Associate R with .RData files en.dcom=Register R path for use by the (D)COM server en.user=User installation en.compact=Minimal user installation en.full=Full installation en.CJK=Chinese/Japanese/Korean installation en.custom=Custom installation -- 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 __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R.app (PR#7926)
Full_Name: Christian Meisenbichler
Version: 2.1.0a
OS: 10.3.9
Submission from: (NULL) (143.50.77.182)
problem with terminal
R terminal in aqua interface exits with
2005-06-10 16:51:03.826 R[1464] *** -[NSCFType characterAtIndex:]: selector not
recognized
2005-06-10 16:51:03.827 R[1464] *** NSTimer discarding exception
'NSInvalidArgumentException' (reason '*** -[NSCFType characterAtIndex:]:
selector not recognized') that raised during firing of timer with target 3cab80
and selector 'kickstart:'
Reproduceable:
mistype "demo()" like "demo()(" short after promt shows up after launching
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R.app editor (PR#7927)
Full_Name: Christian Meisenbichler Version: 2.1.0a OS: 10.3.9 Submission from: (NULL) (143.50.77.182) the editor alows pasting formatted text, schould be plain text shouldn't it __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R.app editor (PR#7928)
Full_Name: Christian Meisenbichler Version: 2.1.0a OS: 10.3.9 Submission from: (NULL) (143.50.77.182) device pdf() produces empty files and device postscript() produces incompleete graphs __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R.app (PR#7926)
On Jun 10, 2005, at 11:03 AM, [EMAIL PROTECTED] wrote:
> R terminal in aqua interface exits with
>
> 2005-06-10 16:51:03.826 R[1464] *** -[NSCFType characterAtIndex:]:
> selector not
> recognized
> 2005-06-10 16:51:03.827 R[1464] *** NSTimer discarding exception
> 'NSInvalidArgumentException' (reason '*** -[NSCFType
> characterAtIndex:]:
> selector not recognized') that raised during firing of timer with
> target 3cab80
> and selector 'kickstart:'
>
> Reproduceable:
>
> mistype "demo()" like "demo()(" short after promt shows up after
> launching
This is highly likely to be a problem reported before, reproducible
only on slow machines and has been fixed in R.app build 1564. Please
use the most recent build and tell us whether you can still reproduce
the problem.
Thanks,
Simon
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R.app editor (PR#7928)
You didn't use appropriate subject, didn't provide a reproducible example, didn't read the documentation and the problems you describe are most probably just user errors. (Hint: ever heard of dev.off()?) Please stop spamming the bug report system, and read the posting guide! Thanks, Simon On Jun 10, 2005, at 11:10 AM, [EMAIL PROTECTED] wrote: > Full_Name: Christian Meisenbichler > Version: 2.1.0a > OS: 10.3.9 > Submission from: (NULL) (143.50.77.182) > > > device pdf() produces empty files > > and device postscript() produces incompleete graphs __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R.app editor (PR#7928)
What has this to do with your subject line? You've sent three messages already with that uninformative subject. Please do read the FAQ and the posting guide and provide a full reproducible example as they ask. My guess is that this is user error, the user having failed to call dev.off() to complete the files. In the absence of any indication that dev.off() was called, I am closing this report. On Fri, 10 Jun 2005 [EMAIL PROTECTED] wrote: > Full_Name: Christian Meisenbichler > Version: 2.1.0a > OS: 10.3.9 Is that Windows 10.3.9 or Solaris 10.3.9? > Submission from: (NULL) (143.50.77.182) > > device pdf() produces empty files > > and device postscript() produces incompleete graphs -- 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 __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] attach and object masking
The library() function prints an information message when objects are masked on the search path by (or from) a newly attached package. The attach() function, however, doesn't. Is there a good reason for this? I have adapted the machinery for checking conflicts used in the library () function to attach(). If there are no objections, I will check this into R-devel. I have seen new users get into terrible trouble with attach, e.g. 1) attaching the same database multiple times, or 2) Masking a vector in an attached data frame with a transformed version in the global environment and *then* re-running a script that transforms the transformed variable. For example, run this snippet twice and you might get a surprise. foo <- data.frame(x=1:10) attach(foo) x <- x/2 A warning would certainly help. Incidentally, (1) occurs in the example for the beavers data set. I didn't find any other problems. __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] attach and object masking
On Fri, 10 Jun 2005, Martyn Plummer wrote: > The library() function prints an information message when objects are > masked on the search path by (or from) a newly attached package. The > attach() function, however, doesn't. Is there a good reason for this? > I have adapted the machinery for checking conflicts used in the library > () function to attach(). If there are no objections, I will check this > into R-devel. > > I have seen new users get into terrible trouble with attach, e.g. > 1) attaching the same database multiple times, or > 2) Masking a vector in an attached data frame with a transformed version > in the global environment and *then* re-running a script that transforms > the transformed variable. For example, run this snippet twice and you > might get a surprise. > > foo <- data.frame(x=1:10) > attach(foo) > x <- x/2 > > A warning would certainly help. > > Incidentally, (1) occurs in the example for the beavers data set. I > didn't find any other problems. Not so: it attaches different dfs with the same column names. I think that is quite common and normally intentional. (Not cleaning up is not good practice though, and that example can be improved a lot.) __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] source bug ? (PR#7929)
hello bug fixers i think this bug is probably mentioned before but i couldn't find the answer to it on google. i have to build R from the source files ( on a mac os x system ) because i need the python R interface too work. for this too happen r needs to be configured in the following way ./configure --enable-R-shlib when i do this on the newest package i get already some problems but these can be handled by the inactivation of the following: --with-readline=no --with-x=no now i go on with building R with sudo make: the following errors are mentioned: make[4]: *** [libRlapack.dylib] Error 1 make[3]: *** [R] Error 2 make[2]: *** [R] Error 1 make[1]: *** [R] Error 1 make: *** [R] Error 1 it seems that it fails on the following code: gcc -dynamiclib -L/sw/lib -L/usr/local/lib -install_name /Library/Frameworks/R.framework/Versions/2.0.1/Resources/lib/libRlapack.dylib -o libRlapack.dylib dlamc.lo dlapack0.lo dlapack1.lo dlapack2.lo dlapack3.lo cmplx.lo cmplxblas.lo -L/sw/lib -L/usr/local/lib -L/usr/local/lib/gcc/powerpc-apple-darwin6.8/3.4.2 -L/usr/local/lib/gcc/powerpc-apple-darwin6.8/3.4.2/../../.. -lfrtbegin -lg2c -lSystem ld: common symbols not allowed with MH_DYLIB output format with the -multi_module option /usr/local/lib/libg2c.a(err.o) definition of common _f__cblank (size 4) /usr/local/lib/libg2c.a(fmt.o) definition of common _f__cnt (size 40) /usr/local/lib/libg2c.a(fmt.o) definition of common f(char, *) (size 4) /usr/local/lib/libg2c.a(err.o) definition of common f(char, long *, short __restrict) (/usr/bin/libtool: internal link edit command failed together with a teacher of me i tried too resolve the problem by making some changes in the configure file unfortunate we couldnt resolve it our selves. if you have any idea how to fix this problem, can you send it to me thanks in advance richard mendes ps: building R from the binaries works just fine ( only not in combination with rpy ) __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] source bug ? (PR#7929)
On Fri, 10 Jun 2005 [EMAIL PROTECTED] wrote: > hello bug fixers > > i think this bug is probably mentioned before but i couldn't find the > answer to it on google. > i have to build R from the source files ( on a mac os x system ) > because i need the python R interface too work. for this too happen r > needs to be configured in the following way > > ./configure --enable-R-shlib > The R for Mac OS X FAQ tells you how to configure. You do need the --with-blas='-framework vecLib' --with-lapack flags that it lists. -thomas __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggestion: help()
On 6/10/2005 8:17 AM, Duncan Murdoch wrote: > On 6/10/2005 8:00 AM, Gabor Grothendieck wrote: >> It would be invoked like this: >> >>package?boot >> >> with the effect of giving help on boot-package. > > Okay, I get it. That's a good change. I'll put it in unless I hear > objections very soon. (I'm going to be away from tomorrow through > Thursday, so I might appear to be ignoring objections if I don't see > them in time.) I've committed this change now. Package overviews are in -package now (in R-devel). As Gabor said, this is already supported by the help system, so there's nothing to stop someone from creating such an alias in their package before that version is released in the fall. Duncan __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Wishlist: axis( ) could take vector of colors (PR#7930)
Hi,
This is not a bug, but a simple enhancement suggestion: that axis( ) also
allow option "col" to take a vector of colors equal to the length of
"labels". Currently it allows it, in the sense that there is no error
message, but the function will use just the first element of the vector.
Example
> plot(1:5,exp(1:5),axes=F,type="o")
> axis(1,col=c(rep("red",2),rep("blue",3)))
gives all red axis notation.
Thanks,
Elizabeth Purdom
(Windows XP, R 2.1.0)
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Wishlist: strwidth allow for rotation of text (PR#7931)
Hi,
This is not a bug, but an enhancement suggestion. "strwidth" only gives the
width of the text according to the x-axis user coordinates, and similarly
for "strheight". Even if the par setting "srt" is changed to rotate the
text, the resulting width (resp. height) is in terms of the non-rotated
text. Currently, if I want to know how much space to leave for vertical
text in the user coordinates, I manually invert the user coordinates, and
then change them back.
Even if arbitrary "srt" is too much, just having the option for 90 degree
rotation would be helpful. If it were implemented for arbitrary srt, then I
personally think it's x-axis and y-axis dimensions are of interest, and not
the actual length of the rotated text.
I'm using R 2.1.0, Windows XP
Thanks,
Elizabeth Purdom
Example:
plot(1:100,seq(2,5,length=100), type="n")
par("usr")
# [1] -2.96 103.96 1.88 5.12
strwidth("hello","user")
# [1] 7.613353
par(srt=90) #rotate 90 degrees
strwidth("hello","user") #still gives same width of text
# [1] 7.613353
par(usr=par("usr")[c(3,4,1,2)])
strwidth("hello","user")
# [1] 0.2307077
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
