On Feb 17, 2009, at 2:37 AM, Roman Haefeli wrote: > On Tue, 2009-02-17 at 00:36 -0500, Matt Barber wrote: >>> Getting rid of cyclone's pow~ would break all of the patches that >>> rely >>> on cyclone's pow~, and would also make it harder to import Max/MSP >>> patches. Removing it is not a solution. >> >> >> Okay. But I don't see why something that is a rather obvious breach >> of style should be allowed to bully the rest of the application. I >> have never used Max/MSP, but it seems like its (and cyclone's) [pow~] >> is really something more like an [exp~] with a changeable base. >> >> In my view -- this is an open-source program which is more or less >> guaranteed to evolve. If your patch breaks with a new version, use >> an >> older version, or find and fix the problems in the patch. To me it >> is >> a problem to avoid improvements to the language to maintain backward >> compatibility at all costs, and much better to throw warnings -- >> "Warning: your patch might be broken: look for all instances of pow~. >> Thank you." =o) >> >> The best solution in any of these circumstances is the least worst >> solution. As far as I can tell the least worst solution is the one >> with the most patch-level control for the libraries. As a user I >> would rather do the research to see which externals I needed than to >> be forced into accepting one or the other, ESPECIALLY if vanilla >> classes are overwritten -- this seems the most egregious to me. >> Pd+libs and Pd-extended should support vanilla patching, since many >> users insist upon vanilla only -- worrying about cyclone and allowing >> vanilla to break seems to me to be putting the cart before the horse >> with regard to backward compatibility. Pd is not Max/MSP. Should >> you >> really have to import vanilla? >> >> Thanks, > > > yo.. i very much agree with you. isn't it the wrong approach to use so > many tricks and kludges just to keep backwards compatibility? isn't > that > just a too expensive goal? > > i mean, there have been so many discussions about how to load > libraries, > extend namespaces and such and then there is much not working yet, > respectively there are still a lot of incompatibilies between > pd-extended and pd vanilla, is it wise to introduce _now_ such a > feature? for me it is clearly another step away from a more consistent > pd world. and i am a bit confused to see, that this is done > deliberately. > > roman
I don't know of any incompatibilities between Pd-vanilla and Pd- extended in this regard. The incompability here is between the old cyclone pow~ which has been around for a long time, and Pd-vanilla 0.42's pow~. In the bigger sense, the library incompatibilities between Pd-extended and some builds of Pd-vanilla come from the different library formats. If you build Pd-vanilla with the same library format at Pd-extended, then it'll all be compatible. There isn't a standard way to include libraries in Pd-vanilla, so there are bound to be incompatibilities between different installations. Try it yourself: http://autobuild.puredata.info/auto-build/latest/Pd-0.42.4-vanilla+libs-debian-stable-i386.deb .hc ---------------------------------------------------------------------------- Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
