On 10/31/2013 05:20 AM, Victor Stinner wrote:
I did another experiment. I replaced enable/disable/is_enabled with
start/stop/is_tracing, and added enable/disable/is_enabled functions
to disable temporarily tracing.
API:
- clear_traces(): clear traces
- start(): start tracing (the old "enable")
2013/10/31 Victor Stinner :
> If I give access to this flag, it would be possible to disable
> temporarily tracing in the current thread, but tracing would still be
> enabled in other threads. Would it fit your requirement?
It's probably not what you are looking for :-)
As I wrote in the PEP, the
2013/10/29 Victor Stinner :
> 2013/10/29 Kristján Valur Jónsson :
>> I was thinking something similar. It would be useful to be able to "pause"
>> and "resume"
>> if one is doing any analysis work in the live environment. This would
>> reduce the
>> need to have "Filter" objects.
>
> Internally
Jim Jewett writes:
> Later, he wrote:
> > I don't see why disable() would return data.
>
> disable is indeed a bad name for something that returns data.
Note that I never proposed that disable() *return* anything, only that
it *get* the trace. It could store it in some specified object, or
Le 30 oct. 2013 20:58, "Jim Jewett" a écrit :
> hough if you use a dict internally, that might not
> be the case.
Tracemalloc uses a {address: trace} duct internally.
> If you return it as a list instead of a dict, but that list is
> NOT in time-order, that is worth documenting
Ok i will docum
On Wed, Oct 30, 2013 at 6:02 AM, Victor Stinner
wrote:
> 2013/10/30 Jim J. Jewett :
>> Well, unless I missed it... I don't see how to get anything beyond
>> the return value of get_traces, which is a (time-ordered?) list
>> of allocation size with then-current call stack. It doesn't mention
>> an
2013/10/30 Stephen J. Turnbull :
> Just "reset" implies to me that you're ready to start over. Not just
> traced memory blocks but accumulated statistics and any configuration
> (such as Filters) would also be reset. Also tracing would be disabled
> until started explicitly.
If the name is reall
Hi,
2013/10/30 Jim J. Jewett :
> Well, unless I missed it... I don't see how to get anything beyond
> the return value of get_traces, which is a (time-ordered?) list
> of allocation size with then-current call stack. It doesn't mention
> any attribute for indicating that some entries are de-alloc
Victor Stinner writes:
> 2013/10/29 Jim Jewett :
> > reset() function:
> >
> > Clear traces of memory blocks allocated by Python.
> >
> > Does this do anything besides clear? If not, why not just re-use the
> > 'clear' name from dicts?
>
> (I like the reset() name. Charles-F
(Tue Oct 29 12:37:52 CET 2013) Victor Stinner wrote:
> For consistency, you cannot keep traces when tracing is disabled.
> The free() must be enabled to remove allocated memory blocks, or
> next malloc() may get the same address which would raise an assertion
> error (you cannot have two memory
2013/10/29 Jim Jewett :
> reset() function:
>
> Clear traces of memory blocks allocated by Python.
>
> Does this do anything besides clear? If not, why not just re-use the
> 'clear' name from dicts?
(I like the reset() name. Charles-François suggested this name
inspired by OProfile AP
A
>
>
> disable() function:
>
> Stop tracing Python memory allocations and clear traces of
> memory blocks allocated by Python.
>
> I would disable to stop tracing, but I would not expect it to clear out the
> traces it had already captured. If it has to do that, please put
reset() function:
Clear traces of memory blocks allocated by Python.
Does this do anything besides clear? If not, why not just re-use the
'clear' name from dicts?
disable() function:
Stop tracing Python memory allocations and clear traces of
memory blocks alloc
13 matches
Mail list logo
