On Feb 26, 2009, at 11:22 AM, João Pais wrote: >> Basically, organization of the libs could not really be any /worse/ >> than it is now (e.g. I'm constantly checking ggee, hcs, moonlib and >> zexy to find various OS and filesystem externals I need), so I'm >> basically proposing the same thing you are, but approached as >> follows: >> * Lazy consensus on a directory structure (I think we were already >> making very nice progress on that in the "Proposals for object >> categories" thread before it went off track : ) ) > > I can start organising the info in a wiki page later in the day. I > guess this is point where we all agreed, we should try to move in > the direction of a structured pd-ext?
I see what you mean now, so like a "standard lib" or JDK for Pd. Sounds like a good idea. I think it makes sense to start organizing this stuff now, but I am guessing it will have to be finalized at the PdCon in Sao Paulo. This kind of thing is vastly easier to do it person than via email. I am sure was can also do audio/video chat and even streaming and IRC for this meeting to include people that are not there. There is already a wiki page with some info that you can build upon: http://puredata.info/dev/PdLibraries .hc >> * Creation of a branch of SVN with the directory structure in place >> * Everyone works together to shuffle the many libs into the new >> structure >> * We each claim a domain we'd like to maintain >> * And then, finally, the maintainer (with help from consenting >> developers where necessary) begin to rewrite the objects in that >> category to have a consistent interface. > > is the consistent interface really necessary? there was already some > discussion about the layout for the pddp project (am I right?), > maybe elements from there could be taken? > or maybe it's enough to provide a general template with guidelines > to be followed, in case the developer wants the objects to become > part of pd-ext? f.e., I have a consistent approach to the > documentation of my abstractions - of course I can use another > graphical template, but that might open lots of unecessary > discussions: "why these colors", "why this layout", "why so many > graphics and not only text", ..... > > But I think that in general it should be stressed that objects > should be stable and properly documented. > > >> And of course this does not need to be a mandate - if a developer >> would rather keep all his/her stuff together, that's fine. And, >> there >> will always be exceptions like rtc-lib or sigpack that shouldn't >> really be split up. > > shouldn't they really? depends on what you're talking about - rtc, > vasp, etc. are very cohese libs, that anyway don't go much outside > their domains - their developers even made that separation clear, by > putting other externals available elsewhere. they could easily go > to /control/rtc or /control/array/vasp or etc. But for not so tight > lib-packages, is it that bad to separate objects, as long as they're > all available on path? > > >> But, on the other side, I'm assuming there are many developers that >> would be more than happy to move their code into common categories - >> at the very least including myself, João and Cyrille, and only >> haven't >> done so because the structure did not exist. And personally I'd be >> just as willing to adapt the interfaces of my abstractions to a >> category-defined standard, but once again, none exists now to adapt >> to. > > I have no problem in structuring my abstractions (I can't code), but > my "lib" is probably one of the most simple ones. ---------------------------------------------------------------------------- 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
