[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