I am happy to announce Guppy-PE 0.1.10
Guppy-PE is a library and programming environment for Python,
currently providing in particular the Heapy subsystem, which supports
object and heap memory sizing, profiling and debugging. It also
includes a prototypical specification language, the Guppy
results even
> when I pass the "-c mingw32" option.
>
> The error is reproduced below:
> ...
It works for me. guppy 0.1.9
gcc 4.5.3
Python 2.6.5
cygwin 1.7.9
[I have no idea if it works as intended. I don't use guppy.]
--
http://mail.python.org/mailman/listinfo/python-list
tSet_Type;". It's not a
file local static but an extern declaration. Are you sure that you are
using a recent version of GCC 4.x? I had some issues with GCC 3.x in the
past. Cygwin has GCC 3.x as default gcc.
For Python 2.6 you can use the free VS 2008 Express version. I've
compiled guppy for 32bit Python 2.7 a couple of days ago w/o any issue
--
http://mail.python.org/mailman/listinfo/python-list
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
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 i
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 is specific to a guppy build on Python 2
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
its stats, right? This caused me problems in my most
> recent use of guppy...
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
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 problems in my most
recent use of guppy...
themselves, but I am talking about mor
but at least it
should be improved by not sharing the hpy() structures.)
Even in the absence of multiple threads, you might have an outer
invocation of hpy() that is used for global analysis, with its specific
options, setref()'s etc, and inner invocations that make some local
analysis perhaps
attributes of a class instance of some sort then?
the other objects you created. Also, it allows for several parallel
invocations of Heapy.
When is that helpful?
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 importin
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/heap
f=open(f)
while True:
yield self.load(f)
Should we call it loadall? It is a generator so it doesn't really load
all immedietally, just lazily. Maybe call it iload? Or redefine load,
but that might break existing code so would not be good.
> It's all really rather confus
turns *is* actually an
iterable, so either of the above just ends up the contents of each set
being extended onto `sets` rather than the sets themselved.
It's all really rather confusing, apologies if there's interspersed rant
in here:
>>> from guppy import hpy
>>>
> 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
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 = h
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
I am happy to announce Guppy-PE 0.1.9
Guppy-PE is a library and programming environment for Python,
currently providing in particular the Heapy subsystem, which supports
object and heap memory sizing, profiling and debugging. It also
includes a prototypical specification language, the Guppy
I am happy to announce Guppy-PE 0.1.8
Guppy-PE is a library and programming environment for Python,
currently providing in particular the Heapy subsystem, which supports
object and heap memory sizing, profiling and debugging. It also
includes a prototypical specification language, the Guppy
I would like to announce Guppy-PE 0.1.5
Guppy-PE is a library and programming environment for Python,
currently providing in particular the Heapy subsystem, which supports
object and heap memory sizing, profiling and debugging. It also
includes a prototypical specification language, the Guppy
> "Claudio Grondi" <[EMAIL PROTECTED]> wrote:
I don't know if it applies here, but in this context the extern keyword
> comes to my mind.
[snip extracts from Microsoft docs]
Perhaps. But I suspect it isn't that simple since ...
I'd think even if I don't use the extern keyword
,j); /* Makes sure the optimizer doesnt remove the
> previous code */
> return 0;
> }
>
> with
>
> gcc -O3 -Wall main.c
>
> gives me:
>
> main.c: In function `main':
> main.c:4: warning: `p' might be used uninitialized in this function
>
> (An
ove the
previous code */
return 0;
}
with
gcc -O3 -Wall main.c
gives me:
main.c: In function `main':
main.c:4: warning: `p' might be used uninitialized in this function
(And I get a Segmentation fault from running the executable.)
The -Wall flag enables, umm, as it is saying 'a
> I have made a new version now, 0.1.1 .
> It compiles cleanly with gcc -pedantic .
but the problem with sets.c remains:
C:\VisualC++NET2003\Vc7\bin\cl.exe /c /nologo /Ox /MD /W3 /G7 /GX
/DNDEBUG -IE:\Python24\include -IE:\Python24\PC /Tcsrc/sets/sets.c
/Fobuild\temp.win32-2.4\Re
lease\src/sets/s
I added most of the
time but I may have missed some. I have no easy way to test with
MSWindows currently and it will probably take a while before I get
around to do it.
The new version is on the home page:
http://guppy-pe.sourceforge.net
Regards,
Sverker
--
http://mail.python.org/mailman/listinfo/python-list
On 29 Nov 2005 11:53:31 -0800 in comp.lang.python, "Sverker Nilsson"
<[EMAIL PROTECTED]> wrote:
[...]
>One of the problems, seems to be string constants in the C source that
>contain newlines. I am using GCC on Linux so, I missed this with the
I'm not sure what you mean by this. Something like
"Sverker Nilsson" <[EMAIL PROTECTED]> schrieb im Newsbeitrag
news:[EMAIL PROTECTED]
> I have been informed that Guppy-PE (http://guppy-pe.sourceforge.net)
> has failed to compile its extension modules with a Microsoft .NET 2003
> compiler under Windows 2000.
>
>
I have been informed that Guppy-PE (http://guppy-pe.sourceforge.net)
has failed to compile its extension modules with a Microsoft .NET 2003
compiler under Windows 2000.
[To the person who informed me about this in an email per 27 Nov:
Thanks for your message.
I couldn't reply t
30 matches
Mail list logo
