Hallo,
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Mon, 23 Feb 2009, Phil Stone wrote:
Oh! Very good. I didn't realize that an identical symbol would get
re-used. For completeness' sake, I will make a new [ps-stopwatch] that
does not leak (and is plain vanilla, to boot).
On Tue, 24 Feb 2009, Frank Barknecht wrote:
Is there a difference between symbols and immutable strings like Lua
or Java have them?
Immutable strings are deallocatable.
If this happened to pd symbols that they became deallocatable, then
externs couldn't keep a t_symbol pointer unless they
Mathieu Bouchard wrote:
On Mon, 23 Feb 2009, Roman Haefeli wrote:
for instance, when using OSC, probably every message is a new symbol.
so i guess, it cannot be avoided, even if text processing is done
outside of pd, unless a string type is introduced (is that correct?).
Every OSC target
Phil Stone wrote:
Mathieu Bouchard wrote:
On Mon, 23 Feb 2009, Roman Haefeli wrote:
for instance, when using OSC, probably every message is a new symbol.
so i guess, it cannot be avoided, even if text processing is done
outside of pd, unless a string type is introduced (is that
Hallo,
Phil Stone hat gesagt: // Phil Stone wrote:
Attached is [maketime], a lovely little timer/stopwatch. I've long
since lost track of who made it, so I'm sorry can't give you
well-deserved credit here. At any rate, it creates *at least* one
symbol per second (probably more, I'm not
Frank Barknecht wrote:
Hallo,
Phil Stone hat gesagt: // Phil Stone wrote:
Attached is [maketime], a lovely little timer/stopwatch. I've long
since lost track of who made it, so I'm sorry can't give you
well-deserved credit here. At any rate, it creates *at least* one
symbol per second
On Mon, 23 Feb 2009, Phil Stone wrote:
Just to see the magnitude of the issue, I made a little test patch
(attached) called [symbol_pig]. It just creates symbols, very fast. A
very rough measurement based on watching resident memory increasing in
bash's top command indicates that (on OS X
Hallo,
Phil Stone hat gesagt: // Phil Stone wrote:
Frank Barknecht wrote:
A fix for this maketime would be to reuse the symbols :00 ... :59
for minutes and hours by using two [cnv] objects for these. Then you
would be able to let the clock run for decades before you get into
trouble with the
Frank Barknecht wrote:
Hallo,
Phil Stone hat gesagt: // Phil Stone wrote:
Frank Barknecht wrote:
A fix for this maketime would be to reuse the symbols :00 ... :59
for minutes and hours by using two [cnv] objects for these. Then you
would be able to let the clock run for decades
On Mon, 2009-02-23 at 13:55 -0800, Phil Stone wrote:
Frank Barknecht wrote:
Hallo,
Phil Stone hat gesagt: // Phil Stone wrote:
Frank Barknecht wrote:
A fix for this maketime would be to reuse the symbols :00 ... :59
for minutes and hours by using two [cnv] objects for
On Mon, 2009-02-23 at 22:42 +0100, Frank Barknecht wrote:
Personally I'd do heavy text processing in something like pdlua. Pd
feels awkward when processing text.
but even if you do not heavy text processing, there are ways to pollute
the symbol table heavily. it is sufficient to only
On Mon, 23 Feb 2009, Frank Barknecht wrote:
Phil Stone hat gesagt: // Phil Stone wrote:
bash's top command indicates that (on OS X 10.4), a megabyte is used up
for approximately every 32,000 symbols.
So you can generate 128 million different symbols with a 4 GB RAM
machine. :)
Not quite.
On Mon, 23 Feb 2009, Phil Stone wrote:
Oh! Very good. I didn't realize that an identical symbol would get
re-used. For completeness' sake, I will make a new [ps-stopwatch] that
does not leak (and is plain vanilla, to boot).
Yes, it's re-used, which sort of goes with the fact that it
On Mon, 23 Feb 2009, Roman Haefeli wrote:
for instance, when using OSC, probably every message is a new symbol. so
i guess, it cannot be avoided, even if text processing is done outside
of pd, unless a string type is introduced (is that correct?).
Every OSC target is a symbol, just like every
Hi everybody,
Ever since I first started programming with Pd, I have had a vague
anxiety about symbols, or to be more exact, symbol table growth. Now,
I've never run into a problem in real life, but the worry is still
there, nagging at me, ever since I read on a Pd-list thread that each
On Sun, 22 Feb 2009, Phil Stone wrote:
A) Is it true that [maketime] would continually grow the symbol table?
yes.
B) Is it possible to tell how full the symbol table is? How much memory
is allocated to it in the first place?
It never gets full. It just becomes bigger and bigger, as long
16 matches
Mail list logo
