[PD-dev] Re: Restructuring of CVS/externals

[Hans-Christoph Steiner]

On Feb 2, 2006, at 6:55 AM, IOhannes m zmoelnig wrote:

> hi.
>
> Hans-Christoph Steiner wrote:
>> I've been thinking about this a lot recently, especially with all of   
>> the Pd-extended stuff I have been doing.  Here's what I am currently   
>> thinking would be the best approach:
>> - new code like moocow gets added in the old-style developer  
>> directory.
>
> i don't think that this is the _best_ approach (especially as the  
> prominent first item of your list), but i agree that it might be the  
> most practical.
>
>> - new libraries get defined, like math, net, buffer, mapping, io, etc.
>> - lead maintainers get chosen for each library (it could be more than  
>>  one person)
>
> sounds ok, though - just for the archives - these libraries should be  
> structured themselves into sub-libraries (via subdirs), which could be  
> maintained by other people than the parent lib.

This idea should probably be tested first to see what kind of problems  
might arise from names like [math/fft/rifft~].  But a Java-style  
multi-level namespace would probably also make sense for Pd too.

Namespaces were recently implemented in SmallTalk, so this would  
probably be a good example to look into. Its similar to Pd in that we  
are adding a namespace to an established language.  There are a number  
of papers on the topic.

> as for designing the categories i think it would be best to stick to  
> existing layouts; probably the one from java (and not the one from  
> perl)

Java is a well defined example of a namespace, but I am not a fan of  
its C-ishness sometimes.  But yes, definitely not perl.

>> - the maintainers then design the library, including which objects   
>> should be included, make a naming scheme, arguments, messages, etc.
>> For example, for a math lib, I think that all conversion objects  
>> should  have a "2" in the name (cart2pol, f2m, etc. instead of  
>> carttopol, ftom,
>
> (while this is just to illustrate the idea, i wonder why you think  
> this (i mean "2" vs "to") is such a good idea....but nevermind

a) one standard is needed
b) I think having a "2" is much clearer to read

ftom  (f-tom a strange atom?)	vs. 	f2m (f-to-i, freq2midi would be  
better)
atoi  (a-toy)   				vs. 	a2i (a-to-i, ascii2int would be better)
mtof  (m-tof)					vs. 	m2f (m-to-f, midi2freq would be better)


>> - then all additions, etc. go thru these maintainers.   What level of  
>>  control is up to the maintainer.  For me, its very important that a   
>> library have a very coherent set of standards.  Other maintainers  
>> might  have different ideas (though I would encourage them to try to  
>> make  things as consistent as possible).
>
> i think the main task of the maintainer should be maintainance and not  
> development. as a first step it will be mere collecting/revisioning of  
> existing objects, then adapting them to a "layout" and finally to  
> write the missing parts. (which might be fairly obvious)

Ok, call it a library designer then, if you don't like the word  
maintainer for that.  But I do not think we should take objects as they  
are just because they work.  The interface needs to be standardized, so  
object names will change, inlets, outlets, arguments, etc.   Certain  
functionality will change too.  We of course should use the vast body  
of existing code, but we should not sacrifice anything to backwards  
compatibility.  These are brand new libraries.  They should be thought  
of as a whole, not merely a bag of assembled tricks.  The only  
libraries will be there for backwards compatibility.

>> - old developer libraries will be kept for backwards compatibility
>
> i don't think that the stdlib-project's goal should be to totally  
> eliminate people's libraries - it should not even cover everything  
> that is now in the externals/-folder
> i see it as a way to have access to objects for "everyday" usage - not  
> for highly sepcialized things.

The namespace allows people to do whatever they want in that regard.  
What I am saying is that we should think of Pd as a platform like Java.  
  And this platform comes with a vast set of standard libs.  People are  
always free to add their own namespaces, classes, etc.  But the  
standard distro should be clearly organized.  There is no java.misc,  
for example, (tho java.util is kind of misc-like).

>>> are a plenty of externals that would simultaneously belong to two
>>> catagories, like pix_pix2sig~ (not an individual external) which is   
>>> both
>
> btw, i don't think that Gem should be part of the stdlib project.
> and even if it would, than i would like to have every "real" Gem  
> object in "graphics:Gem"
>
> while having things like [pix_video] and [pdp_qt] in the same package  
> (as in: sub-package of the stdlib) "graphics:pixel:input" makes some  
> functional sense, it will only confuse people into trying to connect  
> [pix_video] to [pdp_xv].

The video stuff will probably stay as it is for a long time.  Plus  
Miller is working on making video work with ~ classes.  Let's start  
with the easy problems, like math and io, and not worry about video and  
other thorny issues for now.

> of course, this does not mean that both things don't belong into the  
> same "category" (from a help-browser point of view), so they should be  
> tagged with metadata appropriately.

yes.

>
>>>
>>> Symlinks possible from an external in one CVS directory?
>
> on w32?
>
> you could have symlinks in the cvsroot (this is: server side of cvs),  
> but in the sandbox (client side of the cvs) they will appear separate.
> (but if you checkin the changes of one symlink, the other one will  
> magically get the changes on next update)

Symlinks are possible with Cygwin, but not MinGW or straight Win32.  So  
unless someone wants to do some serious work getting Pd running on  
Cygwin, then we should probably not use symlinks for cross-platform  
stuff.


> anyhow, i (think i) agree with hans that there is some need for a  
> stdlib for pd and that this is _not_ the same as the (also necessary)  
> pddp (even though it superficially seems to be so, as they share some  
> keywords)

yes.

.hc

________________________________________________________________________ 
____

            "The arc of history bends towards justice."
                                            - Dr. Martin Luther King, Jr.