That's good news!
Glad to help.
-tk
On Sun, Sep 11, 2016 at 7:38 AM, Allan
wrote:
> Den 10-09-2016 kl. 14:54 skrev Thomas Keffer:
>
>> OK, so there is clearly a leak in the text rendering algorithm on Centos
>> 7. That narrows things down, but still leaves a
Den 10-09-2016 kl. 14:54 skrev Thomas Keffer:
OK, so there is clearly a leak in the text rendering algorithm on Centos
7. That narrows things down, but still leaves a heck of a lot of territory.
Looking through the Pillow change file
On Saturday, September 10, 2016 at 2:11:31 PM UTC-7, Allan H wrote:
>
> Den 10-09-2016 kl. 23:07 skrev vince:
> > So do I need to do anything to create the memory leak other than leave
> > it running ?
>
> No. At Centos 7 level, that is all it takes.
>
>
ok - no measurable difference in 2:30
On Saturday, September 10, 2016 at 4:27:27 PM UTC-4, vince wrote:
>
> On Saturday, September 10, 2016 at 12:57:17 PM UTC-7, Robert Beer wrote:
>>
>> Did you edit/correct the font paths as mentioned earlier in this thread?
>> You also may need to install a font.
>>
>>
>>
> Not yet. Any
Den 10-09-2016 kl. 02:22 skrev vince:
On Friday, September 9, 2016 at 2:46:32 PM UTC-7, Allan H wrote:
Just to complicate things, have you done the same test on centos6 ?
The differences between centos6+7 might be worth understanding
No, not yet. I'm out of HD space for more VM's :-)
Den 10-09-2016 kl. 00:51 skrev Thomas Keffer:
The problem is not likely to be loading the fonts (which are already
cached), but in their rendering.
Here's a little program that loads the font only once, but renders
"hello world" 2500 times, then shows the result. It prints out the total
memory
On Friday, September 9, 2016 at 2:46:32 PM UTC-7, Allan H wrote:
>
> That made me think, I'd better try testing this from scratch, so I
> installed a new Centos 7 in a VM, and installed weewx 2.7 there.
> As usual, with no changes, there are no leaks; but as soon as I fixed
> the font paths, it
Den 10-09-2016 kl. 00:00 skrev Thomas Keffer:
Hi, Allen
Your conclusions do not surprise me. This is not the first memory leak
we have found in the underlying operating system. Usually we can work
around the leaks by caching... something.
Right now, weewx uses a cache for TrueType fonts. Which
Hi, Allen
Your conclusions do not surprise me. This is not the first memory leak we
have found in the underlying operating system. Usually we can work around
the leaks by caching... something.
Right now, weewx uses a cache for TrueType fonts. Which font is causing the
problems?
-tk
On Fri, Sep
Hi Thomas...
I tried the 2 files - it didn't change anything.
That made me think, I'd better try testing this from scratch, so I
installed a new Centos 7 in a VM, and installed weewx 2.7 there.
As usual, with no changes, there are no leaks; but as soon as I fixed
the font paths, it leaks just
The only thing that changed in the plotting functions between V2.7 and V3.5
is that the plot labels now uniformly use Unicode. Before it was a mishmash.
The two commits of weeplot that introduced this were done on 20 Feb 2016.
You could use the last commit
If you can find a reproducible problem in the standard skin, that would get
my attention. :-)
-tk
On Fri, Aug 19, 2016 at 3:48 PM, Allan
wrote:
> Den 20-08-2016 kl. 00:37 skrev Thomas Keffer:
>
>> Hello, Allan
>>
>> Do you get a memory leak if you use the
Oh, a couple other things:
When did you upgrade to V3.0?
The interface to search list extensions changed between 2.7 and 3.0. Did
whoever publishes Byteweather use search list extensions? Did their code
change? Did they use any additional low-level routines in their extension?
I don't mean to
Hello, Allan
Do you get a memory leak if you use the standard skin?
-tk
On Fri, Aug 19, 2016 at 3:28 PM, Allan
wrote:
> Hi Thomas...
>
> Den 19-08-2016 kl. 03:19 skrev Thomas Keffer:
>
>> Python itself is garbage collected, so it doesn't "leak" memory. Weewx
>>
Hi Thomas...
Den 19-08-2016 kl. 03:19 skrev Thomas Keffer:
Python itself is garbage collected, so it doesn't "leak" memory. Weewx
is also pretty careful about avoiding circular references, which can
slow down the GC process, leading to something that looks like an
erratic slow leak.
So, when
Python itself is garbage collected, so it doesn't "leak" memory. Weewx is
also pretty careful about avoiding circular references, which can slow down
the GC process, leading to something that looks like an erratic slow leak.
So, when memory use grows without bounds, the problem is usually in some
Den 07-07-2016 kl. 17:57 skrev Allan:
Den 07-07-2016 kl. 01:54 skrev Thomas Keffer:
Which Python graphics library are you using? PIL or Pillow?
PIL has a known problem where it does not return font handles. There's a
workaround for this in weewx (since V2.6), but it's possible ByteWeather
17 matches
Mail list logo