On Thu, 1 Apr 2004, Mathieu Bouchard wrote:
.. so this means no changes, right ? Surely a possible extension.
It means some changes, because currently, Pd can load a patch in which "#X connect" has 5 or more arguments, BUT it does NOT save back the extra arguments.
Yes, thats true. I meant in terms of compatibility. But of course, the problem is that editting a patch with more connect arguments in the standard pd version would remove all of the additional information.
I think you would only have to change the parser, and the converter from pd internal types to text representation. This should not introduce changes in too many places.
Cool, I'll try this eventually, though I'm not completely sure how I'll implement nested lists -- or how I'll avoid implementing them...
I skipped the nested lists part. Do not have any idea myself, probably its better to avoid them for now until we have a better picture.
Considering that the language itself should be kept as simple as possible (everyone is happy that we do not have integer and float types anymore), I think, at least for the user, there should not be a distinction between symbols and strings. Where would we want to have strings ?
G�nter, a symboltable is not meant to be used as a textprocessing playground.
I understand your reasoning, but pd is not a text processing language either. Anyhow, probably there is a solution to the problem by introducing a garbage collection for the symbol table, or destroying unused symbols explicitly.
The way it's used in Pd right now, it's a big gaping glorified developer-approved memory leak. I guess it matters less nowadays, because with average textprocessing needs, even a gallery installation can stay up for weeks and months on a commonplace 512M RAM memory card, and I'm not even talking of swap partitions and swap files. Then the next barrier is the 2560M limit of virtual memory per process... under 32-bit Linux anyway... and I guess buying a 64-bit K8 -- with 16 billion gigs of virtual address space per process -- is easier than fixing a big gaping glorified developer-approved memory leak... :-}
I mean I can hear John McCarthy scream in disgust and abomination... (he invented the symbol type back in 1958...)
If there is too much resistance, I guess I'll continue developing them string features in terms of grids, but currently it's not possible to put a grid inside a list, so you can't do a list of strings of variable lengths, so it sort of sucks too. I guess they could be \0-padded ... I wonder how Jitter's string handling handles this case... if it does at all...
I don't really know if I am resisting, it all depends on the implementation of strings, and how they should be handled from the users point of view. 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.
Guenter