On Mar 31, 2006, at 10:42 AM, carmen wrote:
So the question is, if we're going ahead to create this kind of standard libs for PD, what should they be written in?
C
If we want a lot of functionality fast then python seems like the best solution
anyone can already use Python, Tcl Scheme, Guile, Ruby etc..
it would be great to have bindings to all the POSIX stuff like fopen () etc , instead of semi-featured inconsistent frontends to a few pieces here and there like the [sprintf] external in cyclone or the [popen] external or bits of fopen() in soundfiler..maybe it can be generated with SWIG.. since stuff like python just hooks into the same things, i dont see why PD cant do it without a middleman..although maybe string/raw-bytes types and some better object-reference mechanisms would help? .. i have no idea how much work it would be (has anyone on this list implemented a standard library in a scripting language?)
Yes indeed, Pd definitely needs standard libs. I agree, they should be written in C, but they can also be written in Pd whenever possible. I don't necessarily think that POSIX is the best interface for Pd, but I have no problem if someone wants to make a POSIX lib. I think that would be a nice thing to have in addition to a more Pd- ish set of libs to do strings/symbols, files, etc.
Right now, I am just writing some objects as I think of them, but my plan is to start designing libraries that are coherently organized with consistent interfaces and naming schemes. I think these new libraries should ignore backwards compatibility, because we have backwards compatibility if we just leave the existing code in place as libdirs.
.hc
________________________________________________________________________ ____
If you are not part of the solution, you are part of the problem. - Eldridge Cleaver