Hi,
SETUP:
Consider three packages PkgA, PkgB and PkgC.
PkgA defines a generic function foo() and exports it;
export(foo)
PkgB imports PkgA::foo() and re-exports it;
importFrom(PkgA, foo)
export(foo)
PkgC imports everything from PkgA and PkgB:
imports(PkgA, PkgB)
PROBLEM:
Loading or attach
On Thu, Aug 29, 2013 at 6:21 AM, Ben Bolker wrote:
> On 13-08-28 05:43 PM, Gabriel Becker wrote:
> > Ben,
> >
> > It works for me ...
> >> x = rpois(100, 5) + 1
> >> y = rnorm(100, x)
> >> d = data.frame(x,y)
> >> m <- lm(y~log(x),d)
> >> update(m,data=model.frame(m))
> >
> > Call:
> > lm(formula
Whoops, yes. As Brian reminded me, it was probably double alignment, not
pointers, that was the issue on the old Suns.
-pd
On Aug 29, 2013, at 21:11 , peter dalgaard wrote:
>
> On Aug 29, 2013, at 20:37 , Hadley Wickham wrote:
>
>>> Not to be picky, but that is not the point. The alignment is
Dear Henrik,
Thank you for your extensive reply, using:
Sweave("QAReport.Rnw")
tools::texi2pdf("QAReport.tex", clean = TRUE)
did solve my problem.
Nevertheless, I do not understand why function buildVignettes() was
modified in a way that it can no longer be used to create vignettes for
testi
On 29/08/2013 20:26, Hadley Wickham wrote:
Do pointers always have to be aligned?
Depends on the architecture, e.g., Sparc doesn't allow non-aligned pointers at
all (results in a segfault), SV x86_64 ABI specifies pointers to be aligned at
8 bytes, but the x86_64 CPUs will allow misaligned po
You only need ::: from outside the package.
Hadley
On Thu, Aug 29, 2013 at 2:37 PM, Jonathan Greenberg wrote:
> Ah, sorry -- I thought if I try to call a "hidden" function that has
> not be exported (and, I thought, if it is exported, it needs to be
> documented?), I have to call it via ::: ?
>
>
Ah, sorry -- I thought if I try to call a "hidden" function that has
not be exported (and, I thought, if it is exported, it needs to be
documented?), I have to call it via ::: ?
--j
On Thu, Aug 29, 2013 at 2:33 PM, Hadley Wickham wrote:
> You only need ::: if you're calling it from another packa
You only need ::: if you're calling it from another package (and see
the lengthly recent discussion on that issue). The key distinction is
whether the function is exported or not: You must document any
function that you export. You don't have to document any function you
don't export.
Hadley
On
On Aug 29, 2013, at 3:26 PM, Hadley Wickham wrote:
>>> Do pointers always have to be aligned?
>>
>> Depends on the architecture, e.g., Sparc doesn't allow non-aligned pointers
>> at all (results in a segfault), SV x86_64 ABI specifies pointers to be
>> aligned at 8 bytes, but the x86_64 CPUs wi
>> Do pointers always have to be aligned?
>
> Depends on the architecture, e.g., Sparc doesn't allow non-aligned pointers
> at all (results in a segfault), SV x86_64 ABI specifies pointers to be
> aligned at 8 bytes, but the x86_64 CPUs will allow misaligned pointers with a
> performance penalty
I had a similar question awhile ago. Basically, my understanding is
if it is a function, it needs to be documented UNLESS you are calling
it via :::
--j
On Thu, Aug 29, 2013 at 1:11 PM, Sana Wajid wrote:
> Thank you all, I appreciate your responses. Just a quick follow up
> question: couple of
On Aug 29, 2013, at 20:37 , Hadley Wickham wrote:
>> Not to be picky, but that is not the point. The alignment is due to the
>> attrib pointer which is at offset 8 despite the fact that there is only a
>> 4-byte element in front of it. Maybe for better illustration, this is the
>> layout on 64
On Aug 29, 2013, at 2:37 PM, Hadley Wickham wrote:
>> Not to be picky, but that is not the point. The alignment is due to the
>> attrib pointer which is at offset 8 despite the fact that there is only a
>> 4-byte element in front of it. Maybe for better illustration, this is the
>> layout on 6
> Not to be picky, but that is not the point. The alignment is due to the
> attrib pointer which is at offset 8 despite the fact that there is only a
> 4-byte element in front of it. Maybe for better illustration, this is the
> layout on 64-bit machines:
Ok, thanks for the clarification.
>
> *
On Aug 29, 2013, at 12:08 PM, Hadley Wickham wrote:
>> You have not: the start of the vector area also needs to be aligned (since
>> it might hold doubles or CHARSXPs).
>
> Thanks, that was the key point I was missing. (Also mentioned to me off list
> by Luke Tierney).
>
Not to be picky, but t
Thank you all, I appreciate your responses. Just a quick follow up
question: couple of my functions are "background" or "behind the scenes"
functions. Do these have to be documented in the manual as well?
On Wed, Aug 28, 2013 at 5:19 PM, Geoff Jentry wrote:
> On Wed, 28 Aug 2013, Ben Bolker wrot
> You have not: the start of the vector area also needs to be aligned (since
> it might hold doubles or CHARSXPs).
Thanks, that was the key point I was missing. (Also mentioned to me
off list by Luke Tierney).
> See memory.c, which says, inter alia
>
> /* All vector objects must be a multiple of
On 29/08/2013 14:39, Hadley Wickham wrote:
Hi all,
Why is the object size of an empty vector 40 bytes? (At least in 64-bit R.)
object.size(integer(0))
# 40 bytes
Reading R internals, it looks like it should be:
* 4 bytes: sxpinfo header (= 32 bits)
* 8 bytes: pointer to attributes
* 8 bytes:
On Aug 29, 2013, at 9:39 AM, Hadley Wickham wrote:
> Hi all,
>
> Why is the object size of an empty vector 40 bytes? (At least in 64-bit R.)
>
> object.size(integer(0))
> # 40 bytes
>
> Reading R internals, it looks like it should be:
>
> * 4 bytes: sxpinfo header (= 32 bits)
> * 8 bytes: poi
Hi all,
Why is the object size of an empty vector 40 bytes? (At least in 64-bit R.)
object.size(integer(0))
# 40 bytes
Reading R internals, it looks like it should be:
* 4 bytes: sxpinfo header (= 32 bits)
* 8 bytes: pointer to attributes
* 8 bytes: pointer to next node
* 8 bytes: pointer to pr
On 13-08-28 05:43 PM, Gabriel Becker wrote:
> Ben,
>
> It works for me ...
>> x = rpois(100, 5) + 1
>> y = rnorm(100, x)
>> d = data.frame(x,y)
>> m <- lm(y~log(x),d)
>> update(m,data=model.frame(m))
>
> Call:
> lm(formula = y ~ log(x), data = model.frame(m))
>
> Coefficients:
> (Intercept)
Dear Uwe and Martin,
Thank you for your reply and workaround.
Best regards,
Christian
On 8/29/13 2:56 PM, Martin Maechler wrote:
Uwe Ligges
on Thu, 29 Aug 2013 14:47:21 +0200 writes:
> Thanks, we know, this is work in progress. Uwe Ligges
and mirrors still work, e.g.,
http://c
> Uwe Ligges
> on Thu, 29 Aug 2013 14:47:21 +0200 writes:
> Thanks, we know, this is work in progress. Uwe Ligges
and mirrors still work, e.g.,
http://cran.CH.r-project.org/web/packages/
---
Martin
> On 29.08.2013 14:08, cstrato wrote:
>> Dear all,
>>
Thanks, we know, this is work in progress.
Uwe Ligges
On 29.08.2013 14:08, cstrato wrote:
Dear all,
On the CRAN website http://cran.r-project.org/ it is currently not
possible to get to the packages. Clicking on "Packages" or on
"Contributed extension packages" results in Error 404: Object
Dear all,
On the CRAN website http://cran.r-project.org/ it is currently not
possible to get to the packages. Clicking on "Packages" or on
"Contributed extension packages" results in Error 404: Object not
found!, see: http://cran.r-project.org/web/packages/
Best regards,
Christian
_._._._._.
On 13-08-28 9:00 PM, Kasper Daniel Hansen wrote:
On Wed, Aug 28, 2013 at 3:22 PM, Duncan Murdoch
mailto:murdoch.dun...@gmail.com>> wrote:
On 28/08/2013 3:06 PM, Kasper Daniel Hansen wrote:
My point of view is that if you have a core package where you
need access
t
Dear Uwe,
Thanks for your reply. Then I will keep the original name.
Best,
Comaths
Uwe Ligges-3 wrote
> On 27.08.2013 18:38, comaths wrote:
>> Hello Folks,
>>
>> I have an R package published on CRAN and I want to rename it for the
>> next
>> version, something like from "rName" to "rNAME". I
27 matches
Mail list logo
