[PD-dev] Re: [PD] Re: [PD-announce] sIgpAck-0.03b

Hans-Christoph Steiner hans at eds.org
Sat Jan 21 20:39:29 CET 2006


On Jan 21, 2006, at 2:01 PM, m.weiss wrote:

> Hans-Christoph Steiner schrieb:
>> On Jan 20, 2006, at 12:40 PM, Frank Barknecht wrote:
>>> Hallo,
>>> Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
>>>
>>>> I'd prefer it if the file names stayed the same, otherwise that will
>>>> break the Pd-extended stuff.  The code in externals/sigpack is  
>>>> setup  in
>>>> the way sigpack was in its previous release, and in a way that's  
>>>> that
>>>> everything else in CVS is.  AFAIK, there are no libs in CVS that  
>>>> have
>>>> prefixes like "sp_" in the filename.
>>>
>>>
>>> If I understand this correctly, the sigpack externals in CVS now
>>> behave differently and have different names than the externals on
>>> Martin's page? I don't like this, it is something that should be
>>> avoided, IMO, unless there is a very good reason, so this should be
>>> sorted out somehow.
>> They should behave exactly the same, since the code is exactly same.   
>>  The prefix to the name is the only difference.
>> Since the sp_ prefix is a recent switch for Martin AFAIK, I hope I  
>> can  convince everyone that its a bad thing with the namespaces, or  
>> at best  unnecessary.  If people want the lib with prefixes, that's  
>> fine, and my  proposed changes will accommodate both ways of working  
>> quite cleanly.    I just hope that Martin will accept them.
>> .hc
>> ______________________________________________________________________ 
>> __ ____
>> "Terrorism is not an enemy.  It cannot be defeated.  It's a tactic.    
>> It's about as sensible to say we declare war on night attacks and   
>> expect we're going to win that war.  We're not going to win the war  
>> on  terrorism."
>>                                     - retired U.S. Army general,   
>> William Odom
> salut
> if both ways working doesnt this make things a little bit confusing?
> you can compile it as lib with or without or as single objects with or
> without
> and why is a prefix bad?
> i ve done the namespace prefix only to avoid nameclashin
> for example the round~ object
> it exists also in iemlib and cyclone
> just wanna use all round objects
> and just want to make developping for me easier
> gruss
> m.weiss

Using CVS helps to make developing easier.  Plus having sIgpAck in  
Pd-extended means that you don't have to make your own releases, saving  
you work.  But in exchange for this labor savings, you'll need to  
change a few minor things about how you work so that it fits in with  
how the CVS repository and Pd-extended is organized.

The lib stuff that I suggested is just for backwards compatibility.   
Since its easy to do and doesn't affect the Pd-extended layout, I have  
no problem having that around.

As for Pd-extended/CVS repository guidelines developed over time on  
this list, here are some (which should be properly documented):

- all lib names and all sections in CVS are lowercase only (name them  
how ever you want in the web-page, etc. but the lib and the directory  
in CVS /externals/ need to be all lowercase (there are only three  
exceptions AFAIK, Gem, miXed, and OSCx, and these are legacy)

- the objects need to compiled in the single-object/single-file format

- the geiger namespace makes object name prefixes like "sp_"  
unnecessary, but if you really want them, that's ok.  But I consider  
them deprecated and ugly.  A better solution would be a more  
descriptive name if you want to differentiate from iemlib's and  
cyclone's [round~], unless they all do similar things.  With the geiger  
namespaces in Pd-extended, you can use all three at the same time even  
if they have the same name.

I pasted this into a wiki page to start documenting this stuff.  Please  
edit, add, etc.

http://puredata.org/docs/developer/CodeGuidelines

.hc

________________________________________________________________________ 
____

                   ¡El pueblo unido jamás será vencido!





More information about the Pd-dev mailing list