Hi,
SimpleLists are slow in this situation, basically because the underlying
seqselect is slow, due to this loop:
x - do.call(c, lapply(seq_len(length(ir)), function(i)
window(x,
start = start(ir)[i], width = width(ir)[i])))
Am I missing something or could this
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.
In checking my vcdExtra package, the following NOTE newly appeared
(R-Forge, using R version 3.0.1 Patched (2013-08-20 r63635))
Package in Depends field not imported from: ‘gnm’
These packages needs to imported from for the case when
this namespace is loaded but not attached.
In the
On Aug 22, 2013, at 9:09, Michael Friendly frien...@yorku.ca wrote:
In checking my vcdExtra package, the following NOTE newly appeared (R-Forge,
using R version 3.0.1 Patched (2013-08-20 r63635))
Package in Depends field not imported from: ‘gnm’
These packages needs to imported from for
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 Thu, Aug 22, 2013 at 10:05 AM, R. Michael Weylandt
michael.weyla...@gmail.com michael.weyla...@gmail.com wrote:
On Aug 22, 2013, at 9:09, Michael Friendly frien...@yorku.ca wrote:
In checking my vcdExtra package, the following NOTE newly appeared (R-Forge,
using R version 3.0.1 Patched
On Aug 22, 2013, at 15:33, Henrik Bengtsson h...@biostat.ucsf.edu wrote:
On Thu, Aug 22, 2013 at 10:05 AM, R. Michael Weylandt
michael.weyla...@gmail.com michael.weyla...@gmail.com wrote:
On Aug 22, 2013, at 9:09, Michael Friendly frien...@yorku.ca wrote:
In checking my vcdExtra
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))
30 matches
Mail list logo
