Tim Peters wrote:
> Center for Alcohol & Drug Treatment
Besides Jamie Zawinski's definition, Google also told me it stands
for
Computer Aided Drafting Technology
where "to draft" turns out to have two different meanings :-)
Regards,
Martin
__
Fredrik Lundh wrote:
> is this some intrinsic property of profilers? if the existing tool has
> problems, why not improve the tool itself? do we really need CADT-
> based development in the standard library?
It is, IMO, intrinsic to parts of the library that aren't used much.
If bugs are in the
[EMAIL PROTECTED] wrote:
> The local python community here in Sydney indicated that python.org is
> only upset when groups port the source to 'obscure' systems and *don't*
> submit patches... It is possible that I was misinformed.
I never heard such concerns. I personally wouldn't notice if somebo
Neal Norwitz wrote:
> I still think the total references at the end of a test run are high,
> 342291. I don't have anything to base this number on. Some strategic
> interning should help this number go down a bit. I suppose I
> shouldn't worry much since these references don't seem to become
> a
Tim Peters <[EMAIL PROTECTED]> wrote:
> We should note that hotshot didn't intend to reduce total time
> overhead. What it's aiming at here is to be less disruptive (than
> profile.py) to the code being profiled _while_ that code is running.
A statistical profiler (e.g.
http://wingolog.org/archi
On Sunday 20 November 2005 21:02, Tim Peters wrote:
> Since I didn't know what that meant, Google helpfully told me:
>
> Center for Alcohol & Drug Treatment
On Sunday 20 November 2005 22:04, Steve Holden wrote:
> I suspect you may already know that Fredrik referred to
>
> Cascade
Neal Norwitz wrote:
[...]
> To give you an example, I ran the entire regression suite through
> Valgrind after configuring --without-pymalloc. I only found 3
> additional problems in new code. There was also one problem in older
> code (Python/modsupport.c).
>
> The big benefit of running with
On Sun, Nov 20, 2005 at 11:33:42PM +0100, Fredrik Lundh wrote:
> do we really need CADT-based development in the standard library?
I didn't recognize the acronym, but Google told me CADT = "Cascade of
Attention-Deficit Teenagers"; see http://www.jwz.org/doc/cadt.html
for a rant.
--amk
__
Tim Peters wrote:
> [Martin v. Löwis]
>
>>>I'm really concerned that the same fate will happen to any new
>>>profiling library: anybody but the original author will hate it,
>>>write his own, and then suggest to replace the existing one.
>
>
> [Fredrik Lundh]
>
>>is this some intrinsic property
[Martin v. Löwis]
>> I'm really concerned that the same fate will happen to any new
>> profiling library: anybody but the original author will hate it,
>> write his own, and then suggest to replace the existing one.
[Fredrik Lundh]
> is this some intrinsic property of profilers? if the existing t
[Armin Rigo]
...
> ...
> 'hotshot', new from 2.2, is quite faster (reportedly, only 30% added
> overhead). The log file is then loaded and turned into an instance of
> the same 'pstats.Stats'. This loading takes ages. The reason is that
> the log file only records events, and loading is done by
Fredrik> (on the other hand, I'm not sure we need a profiler as part of
Fredrik> the standard library either, but that's me...)
Painful though hotshot can be at times, I occasionally find it extremely
useful to zoom in on trouble spots. I haven't used profile in awhile and
haven't tried
I would really like it if someone could run Purify (or another memory
tool) on Windows. Purify on any another (unix) platform would be
nice, but I doubt it will show much more. By using different tools,
problems not found by one tool may be found by the other. Plus there
is windows specific code
On 11/20/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> Can somebody please give a quick explanation how valgrind can give
> *any* reasonable leak analysis when obmalloc is used? In the current
> implementation, obmalloc never ever calls free(3), so all pool memory
> should appear to have lea
Martin v. Löwis wrote:
> The same could be said about hotshot, which was originally contributed
> by Fred Drake, and hacked by Tim Peters, yourself, and others. Yet, now
> people want to remove it again.
>
> I'm really concerned that the same fate will happen to any new
> profiling library: anybod
Michael Hudson wrote:
>>As stated, it certainly is a bad idea.
>
>
> This is a bit extreme...
Yes, my apologies :-(
>>To make it a good idea, there should also be some commitment to
>>maintain this library for a number of years. So who would be
>>maintaining it, and what are their plans for doi
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Armin Rigo wrote:
>> If anyone feels like this is a bad idea, please speak up.
>
> As stated, it certainly is a bad idea.
This is a bit extreme...
> To make it a good idea, there should also be some commitment to
> maintain this library for a numbe
Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Thomas Lee wrote:
>
>> Even if it meant we had just one function call - one, safe function call
>> that deallocated all the memory allocated within a function - that we
>> had to put before each and every return, that's better than what we
>> have.
>
> all
[EMAIL PROTECTED] wrote:
> I've taken a glance at the patch. There are probably a few things to quarrel
> over--for instance, it looks like a site.py change will cause python to print
> a blank line when it's started, and the removal of a '#define HAVE_FORK 1' in
> posixmodule.c---but this still
On Sat, Nov 19, 2005 at 11:06:16PM +0100, "Martin v. Löwis" wrote:
> [EMAIL PROTECTED] wrote:
> > I would appreciate feedback concerning these patches before the next
> > "PythonD" (for DOS/DJGPP) is released.
>
> PEP 11 says that DOS is not supported anymore since Python 2.0. So
> I am -1 on rein
Neal Norwitz wrote:
> There are still 2 memory leaks while running the regression tests.
> They show up when running test_fork1 and test_pty. There may be more,
> valgrind crashed on me the last run which was also before I fixed some
> of the reference leaks. It would be great if people could lo
21 matches
Mail list logo