[PD-dev] pbank in build/src (aka "flatspace")
Hans-Christoph Steiner
hans at eds.org
Thu Feb 26 20:32:04 CET 2009
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
More information about the Pd-dev
mailing list