On Fri, 15 Dec 2006, padawan12 wrote:
I tie myself in knots trying string-like operations sometimes :), so I know its a can of worms, but what are the fundamental limitations surrounding symbol.
The fundamental limitation is that there are enough pd developers who believe that "pd is not meant for string processing", that you can be sure that it can't happen in the MAIN branch. There's also the belief that "all pd-like systems that had elaborate typesystems, have failed" which I haven't heard from many people, but one is enough, if that one is the leader.
Did I hear a rumour that better string handling is chalked in for Pd soon?
Huh??
What would be the best way to introduce the concept of strings to Pd in a consistent and robust way.
what I could find in archives is the bottom of http://lists.puredata.info/pipermail/pd-dev/2005-12/005460.html but that is just an allusion to the actual plan. I can also see one year earlier http://lists.puredata.info/pipermail/pd-list/2004-11/024330.html but I suspect that I wrote more mails about the topic between those two. You may also look at more mails in that "non-leaky symbols" thread.
I have all the plan in my head, it's just that I don't want to re-explain it. The next and last thorough explanation that I'll make, I'll make it to GCC, it'll understand and there will be no need to arguë. Where the shit will hit the fan is when I'll have to introduce a "next-generation Pd API" and a migration plan, because too many externals just assume that if something isn't a float, then it must be a symbol, and then t_atom is rarely handled properly enough for anything related to reference-counting (missing constructors and destructors).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada