Re: [Rd] Re-attaching a package environment drops the attributes
Note that attach() has a return value, so you don't need to use
as.environment() on the name.
Do note more carefully that the attribute you added to env _has_ 'been
dropped', so there is nothing special about package environments here.
You seem to believe that you can (re-)attach an actual environment.
However (as the help page says), attach() makes a new environment and
copies the bindings into that environment so the result of attach() is a
different environment which does not inherit any attributes from the
argument to attach(). Nor would it be desirable to do so, for the
attached environment can be altered independently of the argument to
attach().
If you name enviroments to look like packages when they are not you are
likely to break quite a lot of things, and yes, that would be expected.
On Mon, 17 Sep 2007, Henrik Bengtsson wrote:
> Hi.
>
> contrary to other environments, the attributes of a *package*
> environment are dropped (from the new environment) when attach():ing
> it to the search() path. This might or might not be surprising, but
> have some side effects if rearranging/attaching package environments.
>
> # Example - Regular environments
> env <- new.env()
> attr(env, "foo") <- "bar"
> print(env)
> ##
> ## attr(,"foo")
> ## [1] "bar"
> attach(env, pos=2, name="foo", warn.conflicts=FALSE)
> env2 <- as.environment("foo")
> print(env2)
> ##
> ## attr(,"name")
> ## [1] "foo"
And no "foo" attribute.
>
> # Example - Package environments
> env <- as.environment("package:utils")
> attr(env, "foo") <- "bar"
> print(env)
> ##
> ## attr(,"name")
> ## [1] "package:utils"
> ## attr(,"path")
> ## [1] "C:/PROGRA~1/R/R-2.6.0alpha/library/utils"
> ## attr(,"foo")
> ## [1] "bar"
> attach(env, pos=2, name="package:utils2", warn.conflicts=FALSE)
> env2 <- as.environment("package:utils2")
> print(env2)
> ##
> ## attr(,"name")
> ## [1] "package:utils2"
>
> This becomes a problem, because the 'path' attribute is dropped causing:
>
> packageDescription("utils2")
> ## Error in if (pkgpath == "") { : argument is of length zero
> sessionInfo()
> ## Error in if (pkgpath == "") { : argument is of length zero
>
> Again, this might or might not expected.
>
> Finally:
>
>> sessionInfo()
> R version 2.6.0 alpha (2007-09-14 r42843)
> i386-pc-mingw32
>
> locale:
> LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
> States.1252;LC_MONETARY=English_United
> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> Cheers
>
> Henrik
>
> __
> R-devel@r-project.org 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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#9915) *.Rd file: space after topic in "\alias{topic }"
Spaces are indeed significant in \alias, and the treatment of leading and
trailing spaces seems undocumented. (Four CRAN package authors have made
assumptions here.)
As far as I can see this comes up in 3 places:
1) Writing AnIndex strips leading but not trailing spaces.
2) get_multi used to create @aliases strips both.
3) Looking up aliases in \link happens at both compile and (for [C]HTML)
run times, and it seems never strips spaces.
I think it would have been better to leave spaces alone, but I propose to
consistently strip leading and trailing spaces in aliases and not links,
and to document that.
On Mon, 17 Sep 2007, [EMAIL PROTECTED] wrote:
> On Mon, 17 Sep 2007 [EMAIL PROTECTED] wrote:
>
>> Full_Name: Bill Dunlap
>> Version: R version 2.6.0 Under development (unstable) (2007-07-26 r42329)
>> OS: Linux
>> Submission from: (NULL) (24.16.101.199)
>>
>> If a *.Rd file has an \alias{topic } with a space
>> between 'topic' and the closing '}' then the space
>> is copied to the help/AnIndex file and help(topic)
>> fails to find the help file.
>>
>> E.g., if the help file starts with
>>\name{test1}
>>\alias{test1 }
>>\alias{test2}
>>\alias{test3 }
>>\alias{test4}
>> then help(test1) and help(test4) work, but not
>> help(test1) or help(test3).
>>
>> A possible fix is
>> --- share/perl/R/Rdlists.pm (revision 42846)
>> +++ share/perl/R/Rdlists.pm (working copy)
>> @@ -329,7 +329,7 @@
>> $main::title2file{$rdtitle} = $manfilebase;
>> }
>>
>> - while($text =~ s/\\alias\{\s*(.*)\s*\}//){
>> + while($text =~ s/\\alias\{\s*([^\s]*)\s*\}//){
>> $alias = $1;
>> $alias =~ s/\\%/%/g;
>> if ($internal){
>
> It looks like internal spaces are used in \alias entries,
> e.g.,
> ./R.utils/man/Non-documented_objects.Rd:\alias{Non-documented objects}
> ./SparseM/man/character-null-class.Rd:\alias{character or NULL-class}
> I think the trailing spaces are intended to be ignored,
> so a better fix would be
>
> --- Rdlists.pm (revision 42846)
> +++ Rdlists.pm (working copy)
> @@ -332,6 +332,7 @@
>while($text =~ s/\\alias\{\s*(.*)\s*\}//){
>$alias = $1;
>$alias =~ s/\\%/%/g;
> + $alias =~ s/\s*$//;
>if ($internal){
>$internal{$alias} = 1;
>}
>
>
>
>
> Bill Dunlap
> Insightful Corporation
> bill at insightful dot com
> 360-428-8146
>
> "All statements in this message represent the opinions of the author and do
> not necessarily reflect Insightful Corporation policy or position."
>
> __
> R-devel@r-project.org 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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re-attaching a package environment drops the attributes
On 9/18/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
> Note that attach() has a return value, so you don't need to use
> as.environment() on the name.
>
> Do note more carefully that the attribute you added to env _has_ 'been
> dropped', so there is nothing special about package environments here.
I am sorry about that - mixing up the "foo" outputs. Yes, it applies
to all environments.
(I have to stop working in the middle of the night or at least send
emails at that time).
/Henrik
>
> You seem to believe that you can (re-)attach an actual environment.
> However (as the help page says), attach() makes a new environment and
> copies the bindings into that environment so the result of attach() is a
> different environment which does not inherit any attributes from the
> argument to attach(). Nor would it be desirable to do so, for the
> attached environment can be altered independently of the argument to
> attach().
>
> If you name enviroments to look like packages when they are not you are
> likely to break quite a lot of things, and yes, that would be expected.
>
> On Mon, 17 Sep 2007, Henrik Bengtsson wrote:
>
> > Hi.
> >
> > contrary to other environments, the attributes of a *package*
> > environment are dropped (from the new environment) when attach():ing
> > it to the search() path. This might or might not be surprising, but
> > have some side effects if rearranging/attaching package environments.
> >
> > # Example - Regular environments
> > env <- new.env()
> > attr(env, "foo") <- "bar"
> > print(env)
> > ##
> > ## attr(,"foo")
> > ## [1] "bar"
> > attach(env, pos=2, name="foo", warn.conflicts=FALSE)
> > env2 <- as.environment("foo")
> > print(env2)
> > ##
> > ## attr(,"name")
> > ## [1] "foo"
>
> And no "foo" attribute.
>
> >
> > # Example - Package environments
> > env <- as.environment("package:utils")
> > attr(env, "foo") <- "bar"
> > print(env)
> > ##
> > ## attr(,"name")
> > ## [1] "package:utils"
> > ## attr(,"path")
> > ## [1] "C:/PROGRA~1/R/R-2.6.0alpha/library/utils"
> > ## attr(,"foo")
> > ## [1] "bar"
> > attach(env, pos=2, name="package:utils2", warn.conflicts=FALSE)
> > env2 <- as.environment("package:utils2")
> > print(env2)
> > ##
> > ## attr(,"name")
> > ## [1] "package:utils2"
> >
> > This becomes a problem, because the 'path' attribute is dropped causing:
> >
> > packageDescription("utils2")
> > ## Error in if (pkgpath == "") { : argument is of length zero
> > sessionInfo()
> > ## Error in if (pkgpath == "") { : argument is of length zero
> >
> > Again, this might or might not expected.
> >
> > Finally:
> >
> >> sessionInfo()
> > R version 2.6.0 alpha (2007-09-14 r42843)
> > i386-pc-mingw32
> >
> > locale:
> > LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
> > States.1252;LC_MONETARY=English_United
> > States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
> >
> > attached base packages:
> > [1] stats graphics grDevices utils datasets methods base
> >
> > Cheers
> >
> > Henrik
> >
> > __
> > R-devel@r-project.org 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
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Welcome to the "R-devel" mailing list
2007/9/19, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > > Welcome to the R-devel@r-project.org mailing list! > > To post to this list, send your email to: > > r-devel@r-project.org > > General information about the mailing list is at: > > https://stat.ethz.ch/mailman/listinfo/r-devel > > If you ever want to unsubscribe or change your options (eg, switch to > or from digest mode, change your password, etc.), visit your > subscription page at: > > https://stat.ethz.ch/mailman/options/r-devel/chxmahappy%40gmail.com > > You can also make such adjustments via email by sending a message to: > > [EMAIL PROTECTED] > > with the word `help' in the subject or body (don't include the > quotes), and you will get back a message with instructions. > > You must know your password to change your options (including changing > the password, itself) or to unsubscribe. It is: > > 800724 > > Normally, Mailman will remind you of your r-project.org mailing list > passwords once every month, although you can disable this if you > prefer. This reminder will also include instructions on how to > unsubscribe or change your account options. There is also a button on > your options page that will email your current password to you. > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
