Re: [Rd] RFC: allow packages to advertise vignettes on Windows

[Duncan Murdoch]

On 15/05/2007 6:59 PM, Seth Falcon wrote:
> Simon Urbanek <[EMAIL PROTECTED]> writes:
> 
>> On May 15, 2007, at 1:57 PM, Prof Brian Ripley wrote:
>>
>>> On Mon, 14 May 2007, Seth Falcon wrote:
>>>
 Duncan Murdoch <[EMAIL PROTECTED]> writes:
> I'm interested in making vignettes more visible.  Putting them on
> the
> menu is not the only way, but since you're offering to do the
> work, I
> think it's a good idea :-).
 Excellent :-)

> A few questions:
>
>  - Should packages need to take any action to register their
> vignettes, or should this happen automatically for anything that the
> vignette() function would recognize as a vignette?
>>> I do think this should be optional, and preferably an option that
>>> people have to opt in for.
> 
> Just to make sure we are on the same page: you are advocating for an
> option that would be used by package developers to opt-in for their
> vignette to be registered.
> 
>>> Some sort of vignette browser that packages can register with would
>>> in my view be better, and that could have a single menu entry.
>>> Menus can easily get swamped.
>>>
>> I agree entirely.
>>
>> What puzzles me: why do we need yet another way to register
>> vignettes? What is wrong with vignette()?
> 
> Vignettes are a great form of documentation for new users.  These
> users are more likely to be most comfortable in the GUI environment
> and providing access to the vignettes via the GUI(s) seems like it
> adds a lot of value.
> 
> I don't disagree with the assessment that a menu list isn't the worlds
> best vignette browser interface.  But this approach has been
> reasonably successful for the Bioconductor project to make things
> easier for our Windows users.  Perhaps most importantly, we have code
> that would require little modification to allow package authors to
> register vignettes in a Vignettes menu on Windows.  I think this would
> be an improvement over what is available now.
> 
> It would be great if this discussion generates interest in a more
> robust solution; my offer of help may be limited to polishing what
> we've been using in BioC.

I think it's clear that the different GUIs should expose the information 
in different ways.  The OSX Gui shows the list of all vignettes in a 
very nice multi-column display, including descriptions, but as far as I 
can see it will always show all vignettes, not just those in attached 
packages, and it doesn't allow the user to drill down through the 
package list to the list of vignettes in just one package (other than by 
scrolling through the whole list of vignettes, which are sorted 
alphabetically by vignette name within package name).  If a user has all 
of CRAN installed, your design would be easier to use, but I wouldn't 
suggest that OSX should adopt it:  they should just steal the good parts 
of it.

I'd like to have a multi-column selection list in the Windows GUI, but I 
don't think we should wait for me or someone else to program that before 
including this improvement.  It will be easy to change the look of the 
list later if we want to do that.

Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] optim non-bug

[Prof Brian Ripley]

On Tue, 15 May 2007, Prof Brian Ripley wrote:


There quite a lot of these: optimize, uniroot, nlm for example.

I don't think the problem is large enough to merit another argument.
It is tempting to move '...' up the argument list so that partial matching 
will not occur.  I am not sure how far you can go: ?optim has positional 
matching for 'method', and ?optimize has abbreviations for lower and upper.


In R you rarely need to pass additional arguments in programming as lexical 
scoping can be used to capture them.


I'll do some experimenting.


Overnight runs show that if we do this maximally, only a very few packages 
are affected


optim: SoPhy has 'meth', copula has 'hess', MeasurementError.cor (BioC)
  has unnamed 'method'
uniroot: distrDoc has 'low', 'up' in a vignette
optimize: qtlDesign, sde, waveslim have 'max'
nlm: none
integrate: none

Doubtless there are scripts that will be affected (but with an error and a 
clearcut error message), but unless I hear cogent reasons otherwise

it seems that the balance is well in favour of making the change.

(I have more than once been tempted to knock up a version of R that does 
not allow partial matching of arguments to see what breaks, but a few are 
entrenched like 'length.out' and 'along.with' in seq.default and 'all' in 
ls.  Seems someone is fond of 'env' in get/exists/assign.)






On Tue, 15 May 2007, Bill Dunlap wrote:


On Tue, 15 May 2007, Prof Brian Ripley wrote:


This is not a bug, but as documented on the help page:

  ...: Further arguments to be passed to 'fn' and 'gr'. Beware of
   partial matching to earlier arguments.

You have partial matching to 'upper'.


We have this problem in optim(), integrate(),
and probably other functions.  These functions
have a lot of arguments before the ..., using
up a lot of partial matching space.  Would you consider
adding another argument to the tail end of
their argument lists that would include the
auxillary arguments?

E.g.,
  optim <- function(par, fn, gr = NULL,
  method = c("Nelder-Mead", "BFGS", "CG", "L-BFGS-B", "SANN"),
  lower = -Inf, upper = Inf,
  control = list(), hessian = FALSE,
  ..., aux.args = list(...))
If the user did not supply aux.args this would
act like the old version.  If the user did supply
aux.args then the function could check that no
unrecognized arguments were given to optim.

optim might require 2 such arguments,
   aux.args.fn = list(...),  aux.args.gr=aux.args.fn
(The forces you to know that the objective function
is called 'fn', not integrate's 'f' or apply's 'FUN'.)
I don't know what the best name for such an argument
would be.  If we added it, it would nice to make it
the same in R and Splus.


On Mon, 14 May 2007, [EMAIL PROTECTED] wrote:

'optim' does not accept arguments called 'u'. Here is an example:


R> fun<-function(x,u) (x-u)^2
R> optim(7,fn=fun,u=9)

Fehler in fn(par, ...) : Argument "u" fehlt (ohne Standardwert)
Zusätzlich: Warning message:
bounds can only be used with method L-BFGS-B in: optim(7, fn = fun, u = 
9)




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."







--
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] RFC: allow packages to advertise vignettes on Windows

[Simon Urbanek]

Seth,

we already *have* vignette registration in place [vignette()] and we  
already *have* support in the GUIs (I'm talking e.g. about the Mac  
GUI here which uses vignette() to build a vignettes browser).

What you propose circumvents all the mechanisms already in place and  
adds replicates the same functionality. I'll repeat my question: what  
is wrong with the current approach? Why do you want to add a parallel  
approach?

Cheers,
Simon

On May 15, 2007, at 6:59 PM, Seth Falcon wrote:

> Simon Urbanek <[EMAIL PROTECTED]> writes:
>
>> On May 15, 2007, at 1:57 PM, Prof Brian Ripley wrote:
>>
>>> On Mon, 14 May 2007, Seth Falcon wrote:
>>>
 Duncan Murdoch <[EMAIL PROTECTED]> writes:
> I'm interested in making vignettes more visible.  Putting them on
> the
> menu is not the only way, but since you're offering to do the
> work, I
> think it's a good idea :-).

 Excellent :-)

> A few questions:
>
>  - Should packages need to take any action to register their
> vignettes, or should this happen automatically for anything  
> that the
> vignette() function would recognize as a vignette?
>>>
>>> I do think this should be optional, and preferably an option that
>>> people have to opt in for.
>
> Just to make sure we are on the same page: you are advocating for an
> option that would be used by package developers to opt-in for their
> vignette to be registered.
>
>>> Some sort of vignette browser that packages can register with would
>>> in my view be better, and that could have a single menu entry.
>>> Menus can easily get swamped.
>>>
>>
>> I agree entirely.
>>
>> What puzzles me: why do we need yet another way to register
>> vignettes? What is wrong with vignette()?
>
> Vignettes are a great form of documentation for new users.  These
> users are more likely to be most comfortable in the GUI environment
> and providing access to the vignettes via the GUI(s) seems like it
> adds a lot of value.
>
> I don't disagree with the assessment that a menu list isn't the worlds
> best vignette browser interface.  But this approach has been
> reasonably successful for the Bioconductor project to make things
> easier for our Windows users.  Perhaps most importantly, we have code
> that would require little modification to allow package authors to
> register vignettes in a Vignettes menu on Windows.  I think this would
> be an improvement over what is available now.
>
> It would be great if this discussion generates interest in a more
> robust solution; my offer of help may be limited to polishing what
> we've been using in BioC.
>
> Cheers,
>
> + seth
>
> -- 
> Seth Falcon | Computational Biology | Fred Hutchinson Cancer  
> Research Center
> http://bioconductor.org
>
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] RFC: allow packages to advertise vignettes on Windows

[Simon Urbanek]

On May 16, 2007, at 7:38 AM, Duncan Murdoch wrote:

> On 15/05/2007 6:59 PM, Seth Falcon wrote:
>> Simon Urbanek <[EMAIL PROTECTED]> writes:
>>> On May 15, 2007, at 1:57 PM, Prof Brian Ripley wrote:
>>>
 On Mon, 14 May 2007, Seth Falcon wrote:

> Duncan Murdoch <[EMAIL PROTECTED]> writes:
>> I'm interested in making vignettes more visible.  Putting them on
>> the
>> menu is not the only way, but since you're offering to do the
>> work, I
>> think it's a good idea :-).
> Excellent :-)
>
>> A few questions:
>>
>>  - Should packages need to take any action to register their
>> vignettes, or should this happen automatically for anything  
>> that the
>> vignette() function would recognize as a vignette?
 I do think this should be optional, and preferably an option that
 people have to opt in for.
>> Just to make sure we are on the same page: you are advocating for an
>> option that would be used by package developers to opt-in for their
>> vignette to be registered.
 Some sort of vignette browser that packages can register with would
 in my view be better, and that could have a single menu entry.
 Menus can easily get swamped.

>>> I agree entirely.
>>>
>>> What puzzles me: why do we need yet another way to register
>>> vignettes? What is wrong with vignette()?
>> Vignettes are a great form of documentation for new users.  These
>> users are more likely to be most comfortable in the GUI environment
>> and providing access to the vignettes via the GUI(s) seems like it
>> adds a lot of value.
>> I don't disagree with the assessment that a menu list isn't the  
>> worlds
>> best vignette browser interface.  But this approach has been
>> reasonably successful for the Bioconductor project to make things
>> easier for our Windows users.  Perhaps most importantly, we have code
>> that would require little modification to allow package authors to
>> register vignettes in a Vignettes menu on Windows.  I think this  
>> would
>> be an improvement over what is available now.
>> It would be great if this discussion generates interest in a more
>> robust solution; my offer of help may be limited to polishing what
>> we've been using in BioC.
>
> I think it's clear that the different GUIs should expose the  
> information in different ways.  The OSX Gui shows the list of all  
> vignettes in a very nice multi-column display, including  
> descriptions, but as far as I can see it will always show all  
> vignettes, not just those in attached packages

That is a good idea and a trivial change - I'll add it.


> , and it doesn't allow the user to drill down through the package  
> list to the list of vignettes in just one package

.. just start typing the name of the package in the search field ..

Alternative approach would be some hierarchical view, but I'm not  
very fond of it, especially because it doesn't interact well with  
dynamic searches.


> (other than by scrolling through the whole list of vignettes, which  
> are sorted alphabetically by vignette name within package name).   
> If a user has all of CRAN installed, your design would be easier to  
> use, but I wouldn't suggest that OSX should adopt it:  they should  
> just steal the good parts of it.
>
> I'd like to have a multi-column selection list in the Windows GUI,  
> but I don't think we should wait for me or someone else to program  
> that before including this improvement.  It will be easy to change  
> the look of the list later if we want to do that.
>

Indeed, and I guess you see why I don't like Seth's proposed approach  
- it is forcing a particular limited UI instead of conceptually  
providing information necessary to build a good UI.

Cheers,
Simon

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] RFC: allow packages to advertise vignettes on Windows

[Seth Falcon]

Simon Urbanek <[EMAIL PROTECTED]> writes:

> Seth,
>
> we already *have* vignette registration in place [vignette()] and we
> already *have* support in the GUIs (I'm talking e.g. about the Mac
> GUI here which uses vignette() to build a vignettes browser).

Yes, fine.  I agree that vignette() provides most of
what is needed in terms of the implementationn details and could
replace most of the code that I posted, but it doesn't
mean there is nothing to do.

> What you propose circumvents all the mechanisms already in place and
> adds replicates the same functionality. I'll repeat my question: what
> is wrong with the current approach? Why do you want to add a parallel
> approach?

What is wrong with the current approach is that, at least on Windows,
vignettes are not as easily accessible they should be.  vignette() is
fine as an implementation detail for GUI developers.  It is a bit
silly for beginning users who will have a much better chance of
getting to such introductory documentation if it is part of the GUI.
Gaah, I feel like a broken record.

What we have had with the code in Biobase is a menu of vignettes for
_attached_ packages.  Given the total number of packages that could be
installed and given the fact that running code in a vignette requires
said package to be attached, I think this makes a lot of sense [And I
think this would improve the usability of the OS X vignette browser
because the list is long, the vignettes for an individual package are
not sensibly ordered, etc].  A menu is not perfect, but limiting to
attached packages makes it a useful solution until more robust
browsers etc get to the top of someones TODO list.  But YMMV and what
I've proposed does not require your OS X GUI to change _anything_.

So, as a small step, I'm trying to get vignettes for attached packages
to be easily accessible via the Windows GUI.  I don't care all that
much about the particulars -- and am certainly not attached to the
code that I posted.

What the vignette() function does not provide for is a hook such that
a GUI can add the vignette info for attached packages.  Comments from
others in this thread suggest that there is a desire that this be an
opt-in feature for package authors [I don't really understand this
desire as it seems to me it should be a feature/decision of the GUI]
and again vignette() doesn't help.

+ seth

-- 
Seth Falcon | Computational Biology | Fred Hutchinson Cancer Research Center
http://bioconductor.org

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] RFC: allow packages to advertise vignettes on Windows

[Simon Urbanek]

On May 16, 2007, at 11:36 AM, Seth Falcon wrote:

> Simon Urbanek <[EMAIL PROTECTED]> writes:
>
>> Seth,
>>
>> we already *have* vignette registration in place [vignette()] and we
>> already *have* support in the GUIs (I'm talking e.g. about the Mac
>> GUI here which uses vignette() to build a vignettes browser).
>
> Yes, fine.  I agree that vignette() provides most of
> what is needed in terms of the implementationn details and could
> replace most of the code that I posted, but it doesn't
> mean there is nothing to do.
>
>> What you propose circumvents all the mechanisms already in place and
>> adds replicates the same functionality. I'll repeat my question: what
>> is wrong with the current approach? Why do you want to add a parallel
>> approach?
>
> What is wrong with the current approach is that, at least on Windows,
> vignettes are not as easily accessible they should be.

Ok, fine, but this is specific to the Windows GUI - it needs to be  
updated to take advantage of vignette, I' fine whit that.


>   vignette() is fine as an implementation detail for GUI  
> developers.  It is a bit silly for beginning users who will have a  
> much better chance of getting to such introductory documentation if  
> it is part of the GUI.

Definitely, so yes, fix the GUI ;). My point is that you were  
proposing vignette registration methods instead of saying 'fix the  
GUI' ;). There's nothing wrong with that if the methods need fixing,  
of course.


> What we have had with the code in Biobase is a menu of vignettes for
> _attached_ packages.

Yes, I know, I did acknowledge that it is a good idea and it's really  
easy in fact.


> [...]  A menu is not perfect, but limiting to attached packages  
> makes it a useful solution until more robust browsers etc get to  
> the top of someones TODO list.  But YMMV and what I've proposed  
> does not require your OS X GUI to change _anything_.
>
> So, as a small step, I'm trying to get vignettes for attached  
> packages to be easily accessible via the Windows GUI.  I don't care  
> all that much about the particulars -- and am certainly not  
> attached to the code that I posted.
>

But why not take the vignette() approach instead? I know, still the  
same question, I'm just trying to find you what's missing ...

> What the vignette() function does not provide for is a hook such  
> that a GUI can add the vignette info for attached packages.

Um .. I'm not quite sure I understand - all you have to do is
v=vignette(); v$results[v$results[,1] %in% search(),]
or am I missing something?

There is one thing that could be addressed I suppose - we don't have  
any hooks for GUIs in the sense that R cannot tell the GUI that  
something changed (e.g. a new package was installed). Right now each  
GUI uses system's facilities (or asynchronous checks) to learn about  
such events. This could be unified (as well as other aspects like  
e.g.  the menu access).

Cheers,
Simon

>   Comments from others in this thread suggest that there is a  
> desire that this be an opt-in feature for package authors [I don't  
> really understand this desire as it seems to me it should be a  
> feature/decision of the GUI] and again vignette() doesn't help.
>



> + seth
>
> -- 
> Seth Falcon | Computational Biology | Fred Hutchinson Cancer  
> Research Center
> http://bioconductor.org
>
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] RFC: allow packages to advertise vignettes on Windows

[Duncan Murdoch]

On 5/16/2007 11:58 AM, Simon Urbanek wrote:

> Um .. I'm not quite sure I understand - all you have to do is
> v=vignette(); v$results[v$results[,1] %in% search(),]
> or am I missing something?

In the interest of avoiding duplication and speeding up the calculation, 
I'd put this into the vignette() function (e.g. add an attached=FALSE 
argument).  I suspect on a system with several hundred installed 
packages vignette(attached=TRUE) could be quite a bit faster than 
searching all packages and subsetting afterwards.

> There is one thing that could be addressed I suppose - we don't have  
> any hooks for GUIs in the sense that R cannot tell the GUI that  
> something changed (e.g. a new package was installed). Right now each  
> GUI uses system's facilities (or asynchronous checks) to learn about  
> such events. This could be unified (as well as other aspects like  
> e.g.  the menu access).

Both of these things would be really nice, but I wouldn't hold off on 
Seth's suggestion to wait for them.

Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] 'attach workspace' on R console File menu

[Christos Hatzis]

Quite often I save misc functions and data objects as .RData files that I
can use in other sessions.  Although I could 'Load Workspace" these files,
most of the times I prefer attaching them.  It would be really convenient to
have a menu item under the File menu on the Windows R Console to allow
attaching workspaces, e.g.
 

Attach Workspace...
Load Workspace...
Save Workspace...
 
 
Is this something that could make the wish list for future R Console
features?

Thanks.
-Christos

Christos Hatzis, Ph.D.
Nuvera Biosciences, Inc.
400 West Cummings Park
Suite 5350
Woburn, MA 01801
Tel: 781-938-3830
www.nuverabio.com 

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] RFC: allow packages to advertise vignettes on Windows

[Martin Maechler]

> "Duncan" == Duncan Murdoch <[EMAIL PROTECTED]>
> on Wed, 16 May 2007 12:51:35 -0400 writes:

Duncan> On 5/16/2007 11:58 AM, Simon Urbanek wrote:
>> Um .. I'm not quite sure I understand - all you have to do is
>> v=vignette(); v$results[v$results[,1] %in% search(),]
>> or am I missing something?

Duncan> In the interest of avoiding duplication and speeding up the 
calculation, 
Duncan> I'd put this into the vignette() function (e.g. add an 
attached=FALSE 
Duncan> argument).  I suspect on a system with several hundred installed 
Duncan> packages vignette(attached=TRUE) could be quite a bit faster than 
Duncan> searching all packages and subsetting afterwards.

Indeed, a good idea.
For me, with quite a bit in .libPath() but on a quite fast hi-memory machine,

> system.time(v <- vignette())

   user  system elapsed 
  7.349   6.257 145.329 

i.e. elapsed time of 2.5 minutes {with > 1100 installed packages}

>> There is one thing that could be addressed I suppose - we don't have  
>> any hooks for GUIs in the sense that R cannot tell the GUI that  
>> something changed (e.g. a new package was installed). Right now each  
>> GUI uses system's facilities (or asynchronous checks) to learn about  
>> such events. This could be unified (as well as other aspects like  
>> e.g.  the menu access).

Duncan> Both of these things would be really nice, but I
Duncan> wouldn't hold off on Seth's suggestion to wait for
Duncan> them.

I agree.  I also agree with Simon that it makes sense trying to
provide as much as possible GUI-independently (and in way that is
as easily as possible "GUI-pluggable").

Martin

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] 'attach workspace' on R console File menu

[Henrique Dallazuanna]

Hi,

You can make and load the source in the Rprofile:

look
?winMenuAdd



-- 
Henrique Dallazuanna
Curitiba-Paraná-Brasil
25° 25' 40" S 49° 16' 22"
O

On 16/05/07, Christos Hatzis <[EMAIL PROTECTED]> wrote:
>
> Quite often I save misc functions and data objects as .RData files that I
> can use in other sessions.  Although I could 'Load Workspace" these files,
> most of the times I prefer attaching them.  It would be really convenient
> to
> have a menu item under the File menu on the Windows R Console to allow
> attaching workspaces, e.g.
>
> 
> Attach Workspace...
> Load Workspace...
> Save Workspace...
> 
>
> Is this something that could make the wish list for future R Console
> features?
>
> Thanks.
> -Christos
>
> Christos Hatzis, Ph.D.
> Nuvera Biosciences, Inc.
> 400 West Cummings Park
> Suite 5350
> Woburn, MA 01801
> Tel: 781-938-3830
> www.nuverabio.com 
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] 'attach workspace' on R console File menu

[Gabor Grothendieck]

On 5/16/07, Christos Hatzis <[EMAIL PROTECTED]> wrote:
> Quite often I save misc functions and data objects as .RData files that I
> can use in other sessions.  Although I could 'Load Workspace" these files,
> most of the times I prefer attaching them.  It would be really convenient to
> have a menu item under the File menu on the Windows R Console to allow
> attaching workspaces, e.g.
>
> 
> Attach Workspace...
> Load Workspace...
> Save Workspace...
> 
>
> Is this something that could make the wish list for future R Console
> features?

It is possible for you to set it up yourself in your profile for R under
Windows. See ?winMenuAdd

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] 'attach workspace' on R console File menu

[Christos Hatzis]

Thanks, Gabor.
This does not add a new item to the existing File menu, instead it creates a
new user menu where the new item can be added.  Although not ideal, it is an
acceptable workaround.

Thanks.
-Christos 

> -Original Message-
> From: Gabor Grothendieck [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, May 16, 2007 1:34 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Rd] 'attach workspace' on R console File menu
> 
> On 5/16/07, Christos Hatzis <[EMAIL PROTECTED]> wrote:
> > Quite often I save misc functions and data objects as .RData files 
> > that I can use in other sessions.  Although I could 'Load 
> Workspace" 
> > these files, most of the times I prefer attaching them.  It 
> would be 
> > really convenient to have a menu item under the File menu on the 
> > Windows R Console to allow attaching workspaces, e.g.
> >
> > 
> > Attach Workspace...
> > Load Workspace...
> > Save Workspace...
> > 
> >
> > Is this something that could make the wish list for future 
> R Console 
> > features?
> 
> It is possible for you to set it up yourself in your profile 
> for R under Windows. See ?winMenuAdd
> 
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] attach/detach asymmetry

[Barry Rowlingson]

Is there a good reason why arguments to 'attach' and 'detach' differ so 
much? Yes, I know this is the documented behaviour, it just seems to 
violate the principle of least surprise.

Examples:

  file = "foo.RData"
  df = data.frame(x=1:10,y=1:10)

  attach(file) # attaches the RData file 'foo.RData'
  attach(df) # attaches the object df

  Not surprising in an OO system that a function operating on different 
things does different things. However:

  detach(df)  - works as expected

  detach(file)
gives:
  Error in detach(file) : invalid name

  That's surprise number 1.

  Oh well, lets type the filename out:

  detach("foo.RData")
gives:
  Error in detach("foo.RData") :
  invalid name

  Surprise number 2.

  Check the search() list, and you see that R has stuck 'file:' on the 
start of your file path. So try that:

  detach("file:foo.RData")

  and that works nicely. No surprise there, except perhaps that nothing 
surprising happened.

  So, maybe you can attach() with a 'file:' prefix?

  attach("file:foo.RData")
gives:
  Error in attach("file:foo.RData") :
 file 'file:foo.RData' not found

  - in this case it took it literally as a file name. Surprise number 3.

This is all documented behaviour (actually, I cant find any 
documentation on the 'file:' prefixing), but am I the only person who 
finds it inelegant? Or even downright ugly that the help page for 
detach() gives this example code for attaching and detaching by name?

attach_and_detach <- function(db, pos=2)
  {
 name <- deparse(substitute(db))
 attach(db, pos=pos, name=name)
 print(search()[pos])
 eval(substitute(detach(n), list(n=name)))
  }

  - and that doesn't work for attached data files because of the 'file:' 
prefix.

  I think this could be solved by changing detach(foo) to do something 
different if foo is a character string, and adding the 'file:' prefix 
internally. Or maybe they need rewriting as proper methods?

  Perhaps I'm just being over-sensitive about a matter of aesthetics...

Barry

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] 'attach workspace' on R console File menu

[Gabor Grothendieck]

I think it would be possible but its a bit of work.  Note that this
deletes the original File menu and adds a new File menu at the end.

   winMenuAdd("File")
   winMenuDel("File")

By deleting all the original menus and replacing them in this way and
then tediously replacing the items on each menu I think you could do it.
I haven't tried it myself to check whether it really is possible to add
all the menu items.

On 5/16/07, Christos Hatzis <[EMAIL PROTECTED]> wrote:
> Thanks, Gabor.
> This does not add a new item to the existing File menu, instead it creates a
> new user menu where the new item can be added.  Although not ideal, it is an
> acceptable workaround.
>
> Thanks.
> -Christos
>
> > -Original Message-
> > From: Gabor Grothendieck [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, May 16, 2007 1:34 PM
> > To: [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: [Rd] 'attach workspace' on R console File menu
> >
> > On 5/16/07, Christos Hatzis <[EMAIL PROTECTED]> wrote:
> > > Quite often I save misc functions and data objects as .RData files
> > > that I can use in other sessions.  Although I could 'Load
> > Workspace"
> > > these files, most of the times I prefer attaching them.  It
> > would be
> > > really convenient to have a menu item under the File menu on the
> > > Windows R Console to allow attaching workspaces, e.g.
> > >
> > > 
> > > Attach Workspace...
> > > Load Workspace...
> > > Save Workspace...
> > > 
> > >
> > > Is this something that could make the wish list for future
> > R Console
> > > features?
> >
> > It is possible for you to set it up yourself in your profile
> > for R under Windows. See ?winMenuAdd
> >
> >
>
>
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] citation question

[Ben Bolker]

  I want to put the correct information into the "author" field
of the DESCRIPTION file for my bbmle package, which is a modified
and extended version of the mle code in the stats4 package.

  If I put only myself as author I feel like I'm ignoring the
contribution of R-Core (and I think Peter Dalgaard in particular)
in writing the original code.  If I add "R Development Core
Team" to the author list I feel I am suggesting that they
might be responsible for my changes.  Neither seems entirely
appropriate.

  Suggestions?

  Ben Bolker

PS this is my current DESCRIPTION file:

Package: bbmle
Title: Maximum likelihood estimation
Version: 0.7
Date: 2007/05/16
Author: Ben Bolker
Maintainer: Ben Bolker <[EMAIL PROTECTED]>
Depends: R (>= 2.0.0), methods, stats, graphics
Description: Methods and functions for fitting maximum likelihood models
in R. This package modifies and extends the mle classes in the stats4
library, written by the R Development Core Team.
License: GPL




signature.asc
Description: OpenPGP digital signature
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] citation question

[Gabor Grothendieck]

This is how one package handled it:

> packageDescription("RSVGTipsDevice")$Author
[1] "Tony Plate <[EMAIL PROTECTED]>, based on RSVGDevice by T
Jake\nLuciani <[EMAIL PROTECTED]>"


On 5/16/07, Ben Bolker <[EMAIL PROTECTED]> wrote:
>
>  I want to put the correct information into the "author" field
> of the DESCRIPTION file for my bbmle package, which is a modified
> and extended version of the mle code in the stats4 package.
>
>  If I put only myself as author I feel like I'm ignoring the
> contribution of R-Core (and I think Peter Dalgaard in particular)
> in writing the original code.  If I add "R Development Core
> Team" to the author list I feel I am suggesting that they
> might be responsible for my changes.  Neither seems entirely
> appropriate.
>
>  Suggestions?
>
>  Ben Bolker
>
> PS this is my current DESCRIPTION file:
>
> Package: bbmle
> Title: Maximum likelihood estimation
> Version: 0.7
> Date: 2007/05/16
> Author: Ben Bolker
> Maintainer: Ben Bolker <[EMAIL PROTECTED]>
> Depends: R (>= 2.0.0), methods, stats, graphics
> Description: Methods and functions for fitting maximum likelihood models
> in R. This package modifies and extends the mle classes in the stats4
> library, written by the R Development Core Team.
> License: GPL
>
>
>
> __
> 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] 'attach workspace' on R console File menu

[Christos Hatzis]

Yes, I found that out as well.  
Rebuilding the File menu is probably too much of a hassle and will introduce
dependencies that would be difficult to maintain.  I hope that the core team
would consider this request.

Thanks.
-Christos  

> -Original Message-
> From: Gabor Grothendieck [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, May 16, 2007 2:55 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Rd] 'attach workspace' on R console File menu
> 
> I think it would be possible but its a bit of work.  Note 
> that this deletes the original File menu and adds a new File 
> menu at the end.
> 
>winMenuAdd("File")
>winMenuDel("File")
> 
> By deleting all the original menus and replacing them in this 
> way and then tediously replacing the items on each menu I 
> think you could do it.
> I haven't tried it myself to check whether it really is 
> possible to add all the menu items.
> 
> On 5/16/07, Christos Hatzis <[EMAIL PROTECTED]> wrote:
> > Thanks, Gabor.
> > This does not add a new item to the existing File menu, instead it 
> > creates a new user menu where the new item can be added.  
> Although not 
> > ideal, it is an acceptable workaround.
> >
> > Thanks.
> > -Christos
> >
> > > -Original Message-
> > > From: Gabor Grothendieck [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, May 16, 2007 1:34 PM
> > > To: [EMAIL PROTECTED]
> > > Cc: [EMAIL PROTECTED]
> > > Subject: Re: [Rd] 'attach workspace' on R console File menu
> > >
> > > On 5/16/07, Christos Hatzis <[EMAIL PROTECTED]> wrote:
> > > > Quite often I save misc functions and data objects as 
> .RData files 
> > > > that I can use in other sessions.  Although I could 'Load
> > > Workspace"
> > > > these files, most of the times I prefer attaching them.  It
> > > would be
> > > > really convenient to have a menu item under the File 
> menu on the 
> > > > Windows R Console to allow attaching workspaces, e.g.
> > > >
> > > > 
> > > > Attach Workspace...
> > > > Load Workspace...
> > > > Save Workspace...
> > > > 
> > > >
> > > > Is this something that could make the wish list for future
> > > R Console
> > > > features?
> > >
> > > It is possible for you to set it up yourself in your 
> profile for R 
> > > under Windows. See ?winMenuAdd
> > >
> > >
> >
> >
> >
> 
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] citation question

[Martin Maechler]

> "Ben" == Ben Bolker <[EMAIL PROTECTED]>
> on Wed, 16 May 2007 15:01:31 -0400 writes:

Ben>   I want to put the correct information into the
Ben> "author" field of the DESCRIPTION file for my bbmle
Ben> package, which is a modified and extended version of
Ben> the mle code in the stats4 package.

Ben>   If I put only myself as author I feel like I'm
Ben> ignoring the contribution of R-Core (and I think Peter
Ben> Dalgaard in particular) in writing the original code.
Ben> If I add "R Development Core Team" to the author list I
Ben> feel I am suggesting that they might be responsible for
Ben> my changes.  Neither seems entirely appropriate.

Ben>   Suggestions?

I think Gabor's is fine.
{maybe don't give the e-mail address of the R core team; we
 already get e-mails we should not}.

Ben>   Ben Bolker

Ben> PS this is my current DESCRIPTION file:

Ben> Package: bbmle
Ben> Title: Maximum likelihood estimation
Ben> Version: 0.7
Ben> Date: 2007/05/16
Ben> Author: Ben Bolker
Ben> Maintainer: Ben Bolker <[EMAIL PROTECTED]>
Ben> Depends: R (>= 2.0.0), methods, stats, graphics
Ben> Description: Methods and functions for fitting maximum likelihood 
models
Ben> in R. This package modifies and extends the mle classes in the stats4
Ben> library, written by the R Development Core Team.
 ^^^
  please! How can I ever get old and wise
  in quietness when even you ... ;-)
  --> fortune("library.*Maechler")
Regards,
Martin

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Bug#424696: R CMD INSTALL -l does not create path (PR#9691)

[edd]

Soeren,

On 16 May 2007 at 23:00, Soeren Sonnenburg wrote:
| Package: r-base-core
| Version: 2.5.1~20070513-1[ aka R-patched as of 20070513 ]
| Severity: important
| 
| R CMD INSTALL -l /path/to/lib 
| 
| no longer creates /path/to/lib but assumes it does already exist. This
| is a change in behaviour as it has worked with R 2.4.X 

Let me pass that on to R Bugs then as it is in no way related to any Debian
changes.  

Thanks, Dirk

 
| looking at /usr/lib/R/bin/INSTALL, the problem seems to be in the block 
starting at line 298:
| 
| 
| 
| lib=`tilde_expand "${lib}"`
| if test -z "${lib}"; then
|   lib=`echo "cat('\n~~~', .libPaths()[1], '\n', sep = '')" | \
| R_DEFAULT_PACKAGES=NULL "${R_EXE}" --no-save --slave | \
| grep '^~~~' | sed 's/.*~~~//'`
|   message "Installing to library '$lib'"
| else
|   lib0=${lib}
|   cd ${lib}<-- PROBLEM directory must not exist (call 
MKDIR_P before ?)
|   lib=`${GETWD}`
|   cd ${startdir}
| fi
| 
| 
| -- System Information:
| Debian Release: lenny/sid
|   APT prefers stable
|   APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable'), (1, 
'experimental')
| Architecture: i386 (i686)
| 
| Kernel: Linux 2.6.21.1-sonne (SMP w/2 CPU cores; PREEMPT)
| Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
| Shell: /bin/sh linked to /bin/dash
| 
| Versions of packages r-base-core depends on:
| ii  atlas3-base [libblas.so.3 3.6.0-20.6 Automatically Tuned Linear 
Algebra
| ii  atlas3-sse2 [libblas.so.3 3.6.0-20.6 Automatically Tuned Linear 
Algebra
| ii  libbz2-1.01.0.3-6high-quality block-sorting file 
co
| ii  libc6 2.5-7  GNU C Library: Shared libraries
| ii  libgfortran1  4.1.2-7Runtime library for GNU Fortran 
ap
| ii  libice6   1:1.0.3-2  X11 Inter-Client Exchange library
| ii  libjpeg62 6b-13  The Independent JPEG Group's 
JPEG 
| ii  libpaper-utils1.1.21 Library for handling paper 
charact
| ii  libpcre3  6.7-1  Perl 5 Compatible Regular 
Expressi
| ii  libpng12-01.2.15~beta5-1 PNG library - runtime
| ii  libreadline5  5.2-2  GNU readline and history 
libraries
| ii  libsm62:1.0.3-1  X11 Session Management library
| ii  libx11-6  2:1.0.3-7  X11 client-side library
| ii  libxt61:1.0.5-2  X11 toolkit intrinsics library
| ii  perl  5.8.8-7Larry Wall's Practical 
Extraction 
| ii  refblas3 [libblas.so.3]   1.2-8  Basic Linear Algebra Subroutines 
3
| ii  tcl8.48.4.12-1.1 Tcl (the Tool Command Language) 
v8
| ii  tk8.4 8.4.12-1   Tk toolkit for Tcl and X11, v8.4 
-
| ii  unzip 5.52-9 De-archiver for .zip files
| ii  zip   2.32-1 Archiver for .zip files
| ii  zlib1g1:1.2.3-14 compression library - runtime
| 
| Versions of packages r-base-core recommends:
| ii  r-base-dev  2.5.1~20070513-1 GNU R installation of auxiliary 
GN
| ii  r-recommended   2.5.1~20070513-1 GNU R collection of recommended 
pa
| 
| -- no debconf information
| 

-- 
Hell, there are no rules here - we're trying to accomplish something. 
  -- Thomas A. Edison

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel