Dag Sverre Seljebotn wrote:
>I'm repeating myself a bit, but my previous thread of this ended up
>being about something else, and also since then I've been on an
>expedition to the hostile waters of python-dev.
>
>I'm crazy enough to believe that I'm proposing a technical solution to
>allevi
Dag Sverre Seljebotn wrote:
>I'm repeating myself a bit, but my previous thread of this ended up
>being about something else, and also since then I've been on an
>expedition to the hostile waters of python-dev.
>
>I'm crazy enough to believe that I'm proposing a technical solution to
>allevi
I'm repeating myself a bit, but my previous thread of this ended up
being about something else, and also since then I've been on an
expedition to the hostile waters of python-dev.
I'm crazy enough to believe that I'm proposing a technical solution to
alleviate the problems we've faced as a comm
On Thu, May 17, 2012 at 9:52 PM, Nathaniel Smith wrote:
> I'd be tempted to just see if I could get by with massif or another
> "real" heap profiler -- unfortunately the ones I know are C oriented,
> but might still be useful...
I got some very useful information from Fabien's technique, which le
On Thu, May 17, 2012 at 7:50 PM, Stéfan van der Walt wrote:
> On Wed, May 16, 2012 at 12:34 PM, Thouis Jones wrote:
>> I wondered, however, if there were a better way to accomplish the same
>> goal, preferably in pure python.
>
> Fabien recently posted this; not sure if it addresses your use case
On Wed, May 16, 2012 at 12:34 PM, Thouis Jones wrote:
> I wondered, however, if there were a better way to accomplish the same
> goal, preferably in pure python.
Fabien recently posted this; not sure if it addresses your use case:
http://fseoane.net/blog/2012/line-by-line-report-of-memory-usage/
Anthony,
Thanks for looking into this. A few other notes about fromstring() (
and fromfile() ).
Frankly they haven't gotten much love -- they are, as you have seen,
less than optimized, and kind of buggy (actually, not really buggy,
but not robust in the face of malformed input -- and they give r
Le jeudi 17 mai 2012 à 11:16 +0200, Ralf Gommers a écrit :
> On Thu, May 17, 2012 at 10:48 AM, Fabrice Silva wrote:
>
> > Nautilus and file-roller are *** on me...
> > I hope this one is good.
> > Thanks for being patient :)
> >
>
> That was the right tar file. The issue was the one Josef was poi
On Thu, May 17, 2012 at 10:48 AM, Fabrice Silva wrote:
> Nautilus and file-roller are *** on me...
> I hope this one is good.
> Thanks for being patient :)
>
That was the right tar file. The issue was the one Josef was pointing too
(cover-inclusive), which has already been fixed in
https://github
Nautilus and file-roller are *** on me...
I hope this one is good.
Thanks for being patient :)
Best regards
--
Fabrice Silva
mypackage.tar
Description: Unix tar archive
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.or
On Thu, May 17, 2012 at 9:48 AM, Fabrice Silva wrote:
> Le mercredi 16 mai 2012 à 22:58 +0200, Ralf Gommers a écrit :
>
> > Both coverage=True and coverage=False work with your attached package.
> > But it seems you attached an old version, because test_a.py doesn't
> > include the actual test. "o
Le mercredi 16 mai 2012 à 22:58 +0200, Ralf Gommers a écrit :
> Both coverage=True and coverage=False work with your attached package.
> But it seems you attached an old version, because test_a.py doesn't
> include the actual test. "obj = a.b.mycls()" in test_a.py executes
> fine, so it may be a p
12 matches
Mail list logo
