i seem to recall, that using [makefilename] a lot (i.e. in the range of 1e+08) will flood the symboltable and at best slow down pd, at worst crash it. on the pd list i found a thread about that from 2002 with miller saying: In general, it's a bad idea in Pd to write externs which create indeterminate numbers of symbols at run time. https://lists.puredata.info/pipermail/pd-list/2002-09/007966.html
has this changed somehow since or should it still be avoided? or is there a way to “flush” the symboltable at runtime?
i am asking in the context of pd double, exploring strategies for storing big numbers. so far the most reliable one involves [makefilename %.0f] and fromsymbol as discussed in this thread recently (https://lists.puredata.info/pipermail/pd-list/2020-09/128113.html). but if that creates a problem with symboltable, i´d try other options (e.g. splitting them up into parts).
thanks for confirming or appeasing my fears
hans
On 2020-09-24 10:40, hans w. koch wrote:
has this changed somehow since or should it still be avoided?
nothing changed.
or is there a way to “flush” the symboltable at runtime?
no.
[makefilename] is definitely the wrong tool to solve the problem (although it's probably the one that is available right now, in Pd-vanilla).
on the long run, we should just improve the way numbers are written to disk.
gfadsrm IOhannes
thanks for confirming, johannes!
for now i settled for breaking up the numbers in chunks of 6 digits without using makefilename. but i agree:
on the long run, we should just improve the way numbers are written to disk.
best
hans
Am 24.09.2020 um 13:53 schrieb IOhannes m zmoelnig zmoelnig@iem.at:
On 2020-09-24 10:40, hans w. koch wrote:
has this changed somehow since or should it still be avoided?
nothing changed.
or is there a way to “flush” the symboltable at runtime?
no.
[makefilename] is definitely the wrong tool to solve the problem (although it's probably the one that is available right now, in Pd-vanilla).
on the long run, we should just improve the way numbers are written to disk.
gfadsrm IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list