On 11-05-15 11:33 AM, John Chambers wrote:
This is basically a case of a user error that is not being caught:
Sure!
https://stat.ethz.ch/pipermail/r-devel/2009-March/052386.html
On 5/14/11 3:47 PM, Hervé Pagès wrote:
Hi,
I was stumped by this. The two S4 objects below looked exactly the
On Mon, May 16, 2011 at 1:02 AM, Hadley Wickham wrote:
> So what causes allocations when the call stack is empty? Something
> internal? Does the garbage collector trigger allocations (i.e. could
> it be caused by moving data to contiguous memory)?
The garbage collector doesn't move anything, it
This is basically a case of a user error that is not being caught:
On 5/14/11 3:47 PM, Hervé Pagès wrote:
Hi,
I was stumped by this. The two S4 objects below looked exactly the same:
> a1
An object of class "A"
Slot "aa":
integer(0)
> a2
An object of class "A"
Slot "aa":
integer(0)
> str(a
Also, would you mind commenting how RProfmem is misleading?
There are three ways to profile memory use over time in R code. ...
All can be misleading, for different reasons.
---
http://cran.r-project.org/doc/manuals/R-exts.html#Profiling-R-code-for-memory-use
The other two ways describe why they
>> findLineNum doesn't quite do what I want - it works on the text of the
>> srcref, not on the parse tree.
>
> It searches through the parse tree for the smallest source ref that contains
> a given line. So for example,
>
> if(condition) {
> blah
> blah
> blah
> }
>
> is a single statement, an
> The bug is now fixed in R-devel and R-patched.
Thanks!
Hadley
--
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/lis
>> In the subsequence lines I'm assuming the structure is bytes allocated :
>> call.
>
> I think the five numbers come from four memory allocations before
> example() is called. Looking at the code in src/main/memory.c, it
> prints newline only when the call stack is not empty.
Looking into that
