On Wed, Nov 9, 2011 at 2:38 PM, Juan Declet-Barreto
wrote:
> I am using Cygwin build of Python2.6. This Cygwin install has both a Cygwin
> gcc (versions 3.4.4 and 4.5.3) and mingw32 (3.4.4), as listed in lib/gcc/.
>
> I also tried the mingw32 shell separately, but I get the same results even
>
Am 09.11.2011 20:38, schrieb Juan Declet-Barreto:
> I am using Cygwin build of Python2.6. This Cygwin install has both a Cygwin
> gcc (versions 3.4.4 and 4.5.3) and mingw32 (3.4.4), as listed in lib/gcc/.
>
> I also tried the mingw32 shell separately, but I get the same results even
> when I p
z@python.org
[mailto:python-list-bounces+juan.declet-barreto=mesaaz@python.org] On
Behalf Of Christian Heimes
Sent: Wednesday, November 09, 2011 12:21 PM
To: python-list@python.org
Subject: Re: guppy
Am 09.11.2011 20:08, schrieb Juan Declet-Barreto:
> I am trying to build guppy on Pytho
On Wed, Nov 9, 2011 at 2:08 PM, Juan Declet-Barreto
wrote:
>
> I am trying to build guppy on Python 2.5, but am getting an "initializer
> element is not constant" error from gcc. I have found very little on this
> issue in the fora when looking for the general cause of the error; there is
> eve
Am 09.11.2011 20:08, schrieb Juan Declet-Barreto:
> I am trying to build guppy on Python 2.5, but am getting an "initializer
> element is not constant" error from gcc. I have found very little on this
> issue in the fora when looking for the general cause of the error; there is
> even less that
Chris Withers wrote:
Sverker Nilsson wrote:
The __repr__ I use don't have the enclosing <>, granted, maybe I missed
this or it wasn't in the docs in 2005 or I didn't think it was important
(still don't) but was that really what the complain was about?
No, it was about the fact that when I do
Sverker Nilsson wrote:
If you just use heap(), and only want total memory not relative to a
reference point, you can just use hpy() directly. So rather than:
CASE 1:
h=hpy()
h.heap().dump(...)
#other code, the data internal to h is still around
h.heap().dump(...)
you'd do:
CASE 2:
hpy().heap
On Wed, 2009-09-09 at 13:47 +0100, Chris Withers wrote:
> Sverker Nilsson wrote:
> > As the enclosing class or frame is deallocated, so is its attribute h
> > itself.
>
> Right, but as long as the h hangs around, it hangs on to all the memory
> it's used to build its stats, right? This caused me
Sverker Nilsson wrote:
But I don't think I would want to risk breaking someone's code just for
this when we could just add a new method.
I don't think anyone will be relying on StopIteration being raised.
If you're worried, do the next release as a 0.10.0 release and explain
the backwards inco
On Mon, 2009-09-07 at 16:53 +0100, Chris Withers wrote:
> Sverker Nilsson wrote:
> > I hope the new loadall method as I wrote about before will resolve this.
> >
> > def loadall(self,f):
> > ''' Generates all objects from an open file f or a file named f'''
> > if isinstance(f,basestring):
Sverker Nilsson wrote:
I hope the new loadall method as I wrote about before will resolve this.
def loadall(self,f):
''' Generates all objects from an open file f or a file named f'''
if isinstance(f,basestring):
f=open(f)
while True:
yield self.load(f)
It would be
On Fri, 2009-09-04 at 15:25 +0200, Sverker Nilsson wrote:
>
> However, I am aware of the extra initial overhead to do h=hpy(). I
> discussed this in my thesis. "Section 4.7.8 Why not importing Use
> directly?" page 36,
>
> http://guppy-pe.sourceforge.net/heapy-thesis.pdf
Actually it is describ
On Thu, 2009-09-03 at 10:05 +0100, Chris Withers wrote:
> Raymond Hettinger wrote:
> > In the first case, you would write:
> >sets.extend(h.load(f))
>
> yes, what I had was:
>
> for s in iter(h.load(f)): sets.append(s)
>
> ...which I mistakenly thought was working, but in in fact boils down
Raymond Hettinger wrote:
In the first case, you would write:
sets.extend(h.load(f))
yes, what I had was:
for s in iter(h.load(f)): sets.append(s)
...which I mistakenly thought was working, but in in fact boils down to
Raymond's code.
The problem is that each item that h.load(f) returns
> I dont know guppy,
> but if h.load(f) raises StopIteration upon eof, as seems implied by your
> proposal, then something like the following would work.
>
> sets.extend(h.load(f) for _ in xrange(1e9))
Sounds like hpy has a weird API. Either it should be an
iterator supporting __iter__() and nex
Sverker Nilsson wrote:
Sverker Nilsson wrote:
It reads one Stat object at a time and wants to report something
when there is no more to be read from the file.
Hmm, am I right in thinking the above can more nicely be written as:
>>> from guppy import hpy
>>> h = hpy()
>>> f = open(r'your.hp
A question arose on guppy-pe-list about how to iterate over objects
returned one by one by a method (load) called repeatedly. I defined a
generator to do this (loadall), but this seems unwieldy in general. Is
there a common idiom here that can usefully be encapsulated in a general
method?
On Mon,
17 matches
Mail list logo
