[PD-dev] extending the .pd format

Mathieu Bouchard matju at sympatico.ca
Wed Apr 14 05:12:06 CEST 2004


On Thu, 1 Apr 2004, guenter geiger wrote:

> I understand your reasoning, but pd is not a text processing language
> either.

And then what? It's not a video processing language either, and it's not
an opengl processing language either, and guess what, people use it like
that. Can't it handle text processing properly now?...

> Anyhow, probably there is a solution to the problem by introducing
> a garbage collection for the symbol table, or destroying unused symbols
> explicitly.

Which garbage collection algorithm do you recommend? BTW we prolly can't
just scan through atoms because t_symbol*'s may be taken away from their
origin.

Destroying unused symbols explicitly allows the user to crash Pd if the
unused symbols aren't really unused.

> If you look at the users list, the standard pd user doesn't want to
> make a distinction between symbol "hello" and string "hello". I think
> this should be hidden.

I wonder whether it's even possible to hide this and keep any kind of
backwards compatibility at once...

Btw, to add to the difficulty of backwards compatibility, the symbols are
not data-abstracted, so externals just access the ->s_name, AND as well,
externals may check for T_SYMBOL when they are trying to differentiate
between floats and symbols, so even though atom_getsymbol on a string
could intern the string and return that, it would get thrown as unknown
type T_STRING before reaching that point. I don't quite know what to do.

I think the solution looks pretty much like introducing strings with
explicit casting to symbol... except that this sort of implies
doublequotes will be used to denote symbols, and strings would have to use
another character.

________________________________________________________________
Mathieu Bouchard                       http://artengine.ca/matju





More information about the Pd-dev mailing list