On Wed, May 14, 2014 at 12:29 AM, Duncan Murdoch
murdoch.dun...@gmail.com wrote:
On 13/05/2014 12:14 PM, Knut Krueger wrote:
Is there another new solution for this issue?
especially I would like to use:
utils:::.win32consoleCompletion
the use of this is suggested in the completion.r file of
Am 14.05.2014 08:56, schrieb Deepayan Sarkar:
On Wed, May 14, 2014 at 12:29 AM, Duncan Murdoch
murdoch.dun...@gmail.com wrote:
I think you are misunderstanding the comments in that file. It's an
internal set of tests for the package, so test some typical completion
attempts is a description of
Is there another new solution for this issue?
especially I would like to use:
utils:::.win32consoleCompletion
the use of this is suggested in the completion.r file of utils:
## test some typical completion attempts
library(utils)
testLine - function(line, cursor = nchar(line))
{
On Tue, May 13, 2014 at 9:14 AM, Knut Krueger r...@knut-krueger.de wrote:
Is there another new solution for this issue?
especially I would like to use:
utils:::.win32consoleCompletion
the use of this is suggested in the completion.r file of utils:
Besides forking the function (i.e.
On 13/05/2014 12:14 PM, Knut Krueger wrote:
Is there another new solution for this issue?
especially I would like to use:
utils:::.win32consoleCompletion
the use of this is suggested in the completion.r file of utils:
## test some typical completion attempts
library(utils)
testLine -
Yihui,
On Sun, Aug 25, 2013 at 7:53 PM, Yihui Xie x...@yihui.name wrote:
I know it is really bad, but the so-called good approach can be more
expensive than that snip
It is more expensive for you, yes. On the other hand, I'm pretty sure if
everyone were running around circumventing whatever
Hi,
related to this important discussion I have several questions:
What can I do to explicitly state that I want to use a certain,
*non-exported* generic function? The function I am currently talking of
is predict.smooth.spline from package stats. As I want to make shure
that *this* function
On 26/08/2013 8:51 AM, Benjamin Hofner wrote:
Hi,
related to this important discussion I have several questions:
What can I do to explicitly state that I want to use a certain,
*non-exported* generic function? The function I am currently talking of
is predict.smooth.spline from package stats.
Dear Duncan,
thank you for the quick reply.
Am 26.08.2013 16:47, schrieb Duncan Murdoch:
On 26/08/2013 8:51 AM, Benjamin Hofner wrote:
Hi,
related to this important discussion I have several questions:
What can I do to explicitly state that I want to use a certain,
*non-exported* generic
I would say that you should certainly state it in the man page, and have
something in the DESCRIPTION file as well. It might be something like
Author: Duncan Murdoch, with code from others (see the man pages)
However, I just looked at rgl (a package I maintain), and I see we didn't do
It seems that several people in this thread assumes that it is easy or even
possible to convince an author of a package to export a given function.
This is clearly not always true, partly because as an author you gain
additional work by doing this. The downsides to using ::: is really about
the
This is a good solution. Do I need to specify the original License etc? And
what about a helper function such as stats:::n.knots? This will not appear
in the manual of my package. Is it sufficient in this case to document the
authorship in the source (and perhaps a README as you suggested)?
On Mon, Aug 26, 2013 at 1:06 PM, Trevor Davis trevor.l.da...@gmail.com wrote:
This is a good solution. Do I need to specify the original License etc? And
what about a helper function such as stats:::n.knots? This will not appear
in the manual of my package. Is it sufficient in this case to
On 26/08/2013 1:57 PM, Kasper Daniel Hansen wrote:
It seems that several people in this thread assumes that it is easy or
even possible to convince an author of a package to export a given
function. This is clearly not always true, partly because as an
author you gain additional work by doing
On 26/08/2013 11:20 AM, Benjamin Hofner wrote:
Dear Duncan,
thank you for the quick reply.
Am 26.08.2013 16:47, schrieb Duncan Murdoch:
On 26/08/2013 8:51 AM, Benjamin Hofner wrote:
Hi,
related to this important discussion I have several questions:
What can I do to explicitly state that
Am 26.08.2013 17:38, schrieb Hadley Wickham:
I would say that you should certainly state it in the man page, and have
something in the DESCRIPTION file as well. It might be something like
Author: Duncan Murdoch, with code from others (see the man pages)
However, I just looked at rgl (a
Dear Duncan,
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-bounces@r-
project.org] On Behalf Of Duncan Murdoch
Sent: Monday, August 26, 2013 2:24 PM
To: Benjamin Hofner
Cc: r-devel@r-project.org
Subject: Re: [Rd] legitimate use of :::
On 26/08/2013 11:20
On Sat, Aug 24, 2013 at 9:46 AM, Kasper Daniel Hansen
kasperdanielhan...@gmail.com wrote:
On Thu, Aug 22, 2013 at 8:27 PM, Peter Meilstrup Using ::: on a package you
don't control can be more dangerous. For a
package author to choose to export a function to the public interface
represents at
On 13-08-22 11:54 PM, Yihui Xie wrote:
Maybe it is not a good idea for R CMD check to check ::: at all, and a
warning in R-exts and ?':::' may well be enough. On the other hand, it
is just so easy to get around :::, because everybody can see its
source code:
It's a really bad idea to write
On 13-08-24 12:46 PM, Kasper Daniel Hansen wrote:
On Thu, Aug 22, 2013 at 8:27 PM, Peter Meilstrup Using ::: on a package you
don't control can be more dangerous. For a
package author to choose to export a function to the public interface
represents at least some assurance that that interface
I know it is really bad, but the so-called good approach can be more
expensive than that, primarily because a package with a NOTE in R CMD
check is likely to be rejected by CRAN, or authors have to justify the
NOTE in the email.
For this particular case, I can imagine at least one case which can
On Thu, Aug 22, 2013 at 8:27 PM, Peter Meilstrup Using ::: on a package you
don't control can be more dangerous. For a
package author to choose to export a function to the public interface
represents at least some assurance that that interface will be stable or
slow-moving. But there are no
To avoid the NOTEs (which often triggers a 'pls fix' upon submission to
CRAN), I simply copied/pasted these functions to my package, but this
seems wasteful.
An issue is how one acknowledges the author of the cut and pasted code.
Assume that for one reason or another the original function
On 22.08.2013 07:45, Yihui Xie wrote:
Hi,
So now R CMD check starts to warn against :::, but I believe sometimes
it is legitimate to use it when developing R packages. For example, I
have some utils functions that are not exported but I want to share
them across the packages that I maintain.
On 8/22/2013 7:45 AM, Uwe Ligges wrote:
On 22.08.2013 07:45, Yihui Xie wrote:
Hi,
So now R CMD check starts to warn against :::, but I believe sometimes
it is legitimate to use it when developing R packages. For example, I
have some utils functions that are not exported but I want to share
On Aug 22, 2013, at 20:57 , Michael Friendly wrote:
Cases in point: in heplots, I had used stats:::Pillai, stats:::Wilks,
stats:::Roy and stats:::LH for calculation in one of my functions.
That particular case has been on what remains of my conscience for some time
--
Peter Dalgaard,
Dear Michael and Uwe,
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-bounces@r-
project.org] On Behalf Of Michael Friendly
Sent: Thursday, August 22, 2013 2:57 PM
To: Uwe Ligges
Cc: R-devel
Subject: Re: [Rd] legitimate use of :::
On 8/22/2013 7:45 AM, Uwe
To avoid the NOTEs (which often triggers a 'pls fix' upon submission to
CRAN), I simply copied/pasted these functions to my package, but this seems
wasteful.
Wasteful of disk space, but disk space is cheap. It's less wasteful of
your time, if the referenced code breaks in an unexpected time.
r63654 has fixed this particular issue, and R-devel will no longer
warn against the use of ::: on packages of the same maintainer.
Regards,
Yihui
--
Yihui Xie xieyi...@gmail.com
Web: http://yihui.name
Department of Statistics, Iowa State University
102 Snedecor Hall, Ames, IA
On Thu, Aug 22,
On Thu, Aug 22, 2013 at 2:03 PM, Hadley Wickham h.wick...@gmail.com wrote:
To avoid the NOTEs (which often triggers a 'pls fix' upon submission to
CRAN), I simply copied/pasted these functions to my package, but this seems
wasteful.
Wasteful of disk space, but disk space is cheap. It's less
On Thu, Aug 22, 2013 at 2:03 PM, Hadley Wickham h.wick...@gmail.com wrote:
To avoid the NOTEs (which often triggers a 'pls fix' upon submission to
CRAN), I simply copied/pasted these functions to my package, but this
seems
wasteful.
Wasteful of disk space, but disk space is cheap. It's less
Wasteful of disk space, but disk space is cheap. It's less wasteful of
your time, if the referenced code breaks in an unexpected time. Your
time is much more valuable than disk space.
On the other hand, it's quite dangerous software design. What if the
original author finds a bug and
Dear Peter,
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-bounces@r-
project.org] On Behalf Of peter dalgaard
Sent: Thursday, August 22, 2013 4:45 PM
To: Michael Friendly
Cc: R-devel; Uwe Ligges
Subject: Re: [Rd] legitimate use of :::
On Aug 22, 2013
Another point to consider is that copying someone else's code forces you to
become a maintainer of the copied code. If there are any bug
fixes/enhancements/what-have-you in the original you won't get those updates.
So now you own the copied code and need to consider the cost of the codebase
On Thu, Aug 22, 2013 at 4:52 PM, Brian Rowe r...@muxspace.com wrote:
Another point to consider is that copying someone else's code forces you to
become a maintainer of the copied code. If there are any bug
fixes/enhancements/what-have-you in the original you won't get those updates.
So now
If ::: is disallowed then its likely that package developers will need
to export more functions to satisfy the consumers of those otherwise
hidden functions but if more functions are exported then there
will be a greater likelihood of conflicts among packages.
The problem seems to be that there
You raise an interesting point that I've mulled over a bit: namespace
collisions. How many of these issues would go away if there were a better
mechanism for managing namespaces? eg in other languages you can control which
objects/modules you wish to import from a library. Under this regime I
On 23.08.2013 00:36, Brian Lee Yung Rowe wrote:
You raise an interesting point that I've mulled over a bit: namespace
collisions. How many of these issues would go away if there were a better
mechanism for managing namespaces? eg in other languages you can control which
objects/modules you
On Thu, Aug 22, 2013 at 6:41 PM, Uwe Ligges
lig...@statistik.tu-dortmund.de wrote:
On 23.08.2013 00:36, Brian Lee Yung Rowe wrote:
You raise an interesting point that I've mulled over a bit: namespace
collisions. How many of these issues would go away if there were a better
mechanism for
My understanding is that lookup happens in the imports before moving on to
the search path, so if I understand you correctly I don't think that is an
issue. If A also *exported* f, that would be a problem...
From writing R extensions (talking about functions in a package finding
variables, sec
It would be nice if the functionality of importFrom() and import() were
available to user level code, rather than just to people building packages
for distribution. One most often encounters namespace conflicts at the user
level, when loading two packages that have no logical connection other than
On Thu, Aug 22, 2013 at 7:57 PM, Gabriel Becker gmbec...@ucdavis.edu wrote:
My understanding is that lookup happens in the imports before moving on to
the search path, so if I understand you correctly I don't think that is an
issue. If A also *exported* f, that would be a problem...
A can
(missed the list the first time)
Perhaps an importHiddenFrom directive should be added to the namespace
vocabulary which can import a non-exported function. The non-exported
functions clearly exist somewhere, as package code can use them, so it
would not be impossible to allow that (though I'm
This is what I was getting at as well. It would be great to have a call like
require(package, c('funtion.1','function.2'))
or similar that gives users granular control over what gets imported in the
shell. I would be drunk with joy if the same mechanism could be used to
automatically populate
Peter Meilstrup: (05:01PM on Thu, Aug 22)
One most often encounters namespace conflicts at the user level, when
loading two packages that have no logical connection other than both
bearing on your problem of the moment.
Unless I'm mistaken, you can reassign the hidden functions, ie
fna -
Dear Gray,
On Thu, 22 Aug 2013 19:41:58 -0500
Gray g...@clhn.co wrote:
Peter Meilstrup: (05:01PM on Thu, Aug 22)
One most often encounters namespace conflicts at the user level, when
loading two packages that have no logical connection other than both
bearing on your problem of the moment.
Hey guys,
Because I was curious and had nothing else that I should have been doing
(that second part is a lie), I looked into the namespace code.
I have a working patch that implements importHiddenFrom. It doesn't
currently check whether you then export that symbol (which should not be
allowed)
Maybe it is not a good idea for R CMD check to check ::: at all, and a
warning in R-exts and ?':::' may well be enough. On the other hand, it
is just so easy to get around :::, because everybody can see its
source code:
`:::`
function (pkg, name)
{
pkg - as.character(substitute(pkg))
Hi,
So now R CMD check starts to warn against :::, but I believe sometimes
it is legitimate to use it when developing R packages. For example, I
have some utils functions that are not exported but I want to share
them across the packages that I maintain. I do not need to coordinate
with other
49 matches
Mail list logo
