[PD-dev] why using vanilla better than extended; was :Re: pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

Wed Feb 25 02:05:47 CET 2009

On Feb 24, 2009, at 11:49 AM, cyrille henry wrote:

>
>
> Hans-Christoph Steiner a écrit :
>> I don't think that Pd-extended is for everyone, that's fine by me.   
>> I  think its good to have many distros of Pd+libs.
> we all agree here.
>> But what I think is  essential is that we have a common library  
>> format so that patches made  in one distro can be compatible in  
>> others.
> yes, it is important.
> but having patch compatible between 2 pd distro require more than  
> just a common lib format.

Yes, but we have to start somewhere.

>> Saying that you tailor  your environment to your patches is not a  
>> solution.   Then your  patches will only work in your custom setups.
> yes. my aim is the opposite.
> starting pd with -noprefs is not really "tailor your environment to  
> your patches"
> but trying to make your patch to work on all environment.
>
>
>> That is why I think we need to discuss the library format and come  
>> up  with a format that works for everyone.  I posted the idea for a  
>> common  library format somewhere in this thread.   This is an idea  
>> that has  been formed from the contributions of a number of people,  
>> and I think  it covers all the concerns that I know of.  Please  
>> take a look and  comment on it, so we can start coding it and lay  
>> this argument to  rest :D
> i miss this discussion.
>
> so, having every file (.pd, .pd_linux .dll .pdlua and *-help.pd) in  
> the same directory is ok for me.
>
> The way you distribute a lib should also be related to the way you  
> develop this lib on the svn.
> so, should the svn be ordered on the same way : every files on the  
> same dir?
> except for sources and everything that need for compiling externals  
> that could go on a src sub-folder?
> and also a sub-folder for the examples (that are not help files)?

here is the proposal in question:

http://lists.puredata.info/pipermail/pd-dev/2009-02/013009.html

If you are happy including any externals in the same folder, then do  
that, you don't need libraries.  For me, I would like to be able to  
easily use externals that have been updated.  Yes, fixing bugs can  
break patches, but that's hardly an argument to stop fixing bugs.  Any  
change in code can break things, shall we just stop changing Pd at  
all?  I think a better solution is to allow a patch to query Pd for  
the version, then include info about which version that patch was made  
with.  Pd-extended has [version] for that purpose.

> about the loading order : is this mandatory to introduce  
> incompatibility between vanilla and extended?
> changing the loading order in pd-extended may break some patch. this  
> is not a major problem for me since we all can adapt old patch to  
> work with a new software version. But to have different order  
> between vanilla and extended is not really nice.

The idea would be to change vanilla, then extended would inherit it.   
I also want to avoid a difference here.  I think changing the loading  
order won't change anything in how Pd-vanilla objects are loaded, it  
might change which objectclass gets loaded in Pd-extended, but that  
can be checked with a script.

It could change how a patch behaves, but in a way that could happen  
switching between distros and installations too.  Things are so messy  
now, I don't think it would be wise to keep it that way.

.hc

>
>
> cyrille
>
>> .hc
>> On Feb 23, 2009, at 6:16 PM, cyrille henry wrote:
>>>
>>> João Pais a écrit :
>>>>>> -for stability : i don't wish to use code that i don't fully   
>>>>>> trust, and  i don't have time to personally test everything  
>>>>>> deeply.
>>>>> Yes, there is definitely some crappy code included in Pd-  
>>>>> extended.   That's why I think we should stop including  
>>>>> anything  but the most stable  libraries, and instead make it  
>>>>> very easy for  people to make and install  libraries.  But one  
>>>>> nice thing about  using libdirs is that, if you don't  use the  
>>>>> crappy code, it is  just a blob taking up disk space.  It is  
>>>>> not  loaded at all,  therefore it won't affect your stability.
>>>> here here. even if the code gets loaded into memory, as long as   
>>>> there are  no nameclashing you shouldn't even notice it (except   
>>>> you're running an  installation on a low-end computer and each  
>>>> byte  counts, ...)
>>> loading a patch when you have lot's of lib loaded should be slower.
>>> but why using pd-extended if you don't need all the lib?
>>>
>>>>>> -for simplicity : i think it's more simple to use a limited  
>>>>>> set  of  object, than choosing from about 2000 of them.
>>>>> I agree simplicity is good, and there is a lot of redundancy in   
>>>>> Pd- extended.  The redundancy is mostly for backwards   
>>>>> compatibility.  Then  the other problem is that one person's   
>>>>> simple set of objects don't work  for someone else.  For  
>>>>> example,  I don't think you ever use creb but for  others,  
>>>>> that's  indispensible.
>>>> and I also think that the redundancy comes also from the fact  
>>>> that  there  is no object list for pd-ext. no one has the time to  
>>>> search  2xxx objects,  so they just program their own.
>>> it's not very hard to look on the svn for a specific object name   
>>> before writing the same object wih the same name.
>>>
>>>
>>>>>> -for compatibility : i need to have my patch running on lot's  
>>>>>> of   different computer, using different version of pd,  
>>>>>> different OS.  since  pd-extended is not yet the standard pd  
>>>>>> distribution for  anyone, i have  to use the minimal set of  
>>>>>> external. i.e : almost  none. (see RJDJ by  example)
>>>>> If you don't use externals at all, then this is true.  If you  
>>>>> do,  then  Pd-extended is the most compatible way to use  
>>>>> externals.
>>>> is pd-ext not the standard version for many reasons more than it   
>>>> isn't  maintained by MP, and because it isn't as actual as pd-van?
>>> i just mean pd-extended is not used by anyone.
>>>> I don't know  about the compatibility issue - you say this  
>>>> because  some systems have low  resources (like rjdj), or because  
>>>> pd-ext  isn't stable in some systems? the  1st makes sense,  
>>>> naturally (also  if you get a 10year old computer for an   
>>>> installation, etc.)
>>> everybody use a different set of external. so when you share a   
>>> patch, you can have problem if someone does not load the lib  
>>> you're  using.
>>> look at how many problem send on the pd list is solve via  
>>> changing  pd lib loading preferences.
>>>
>>>>>> -for conservation : in 50 years, it will certainly be easier  
>>>>>> to  use a  pd patch than a pd-extended patch. at least, it will  
>>>>>> not  be harder.  This was true for the last few years since pd   
>>>>>> extended was not mature  until recently.
>>>>> If you use no externals at all, or you always include every   
>>>>> external/ abstraction you use within the project, then this  
>>>>> could  be true.  AFAIK,  this is how Miller bundles his code in  
>>>>> PDRP.
>>>>>
>>>>> If you use externals at all, then I disagree here quite  
>>>>> strongly.   There  is no standard way to install or setup  
>>>>> externals with Pd- vanilla.  That  means in 50 years, people  
>>>>> will have no idea how  you set up your  Pd-vanilla + externals.   
>>>>> Pd-extended will still  be just a package with  everything in  
>>>>> the right place.
>>>> I think so as well, the builds are a solid package (if the code   
>>>> inside  works, like it does in many of the libs). anyway, this   
>>>> discussion (and  subsequent actions, if they happen) would be a   
>>>> good step to make pd-ext  even more mature. I would think that a   
>>>> small "tester group" to test  objects, or to alert developers  
>>>> for  good testing + documentation + use of  proper formats (for   
>>>> documentation + pdpedia or whatever) would be a good  thing. I   
>>>> would be up to give some time for it (can't give much more than    
>>>> that, anyway).
>>>>>> -for new feature : pd-extended is 1 or 2 version late, and new   
>>>>>> pd  feature are usually really nice. by example i deeply use  
>>>>>> the  new pd~  object for a project i'm working on. i don't  
>>>>>> really know  when pd- extended will be in version 0.42.
>>>>> With new features come new bugs, unfortunately, like the  
>>>>> editing  helper  and the pow~/override issue.  The latter could  
>>>>> cause big  problems.  But  mostly the reason why there is a  
>>>>> delay is because  there is only so much  I can do.
>>>> are there any users that could help HC with the task of putting  
>>>> pd- van and  pd-ext at the same level? I guess that the most  
>>>> mature  result would be  that MP's code would go directly to pd- 
>>>> ext after  being tested/released.
>>>>>> -to prevent incompatibility : pd extended does not use   
>>>>>> transparent  object and this does break some of my old patch   
>>>>>> (when using a canvas  and symbol to create some visual  
>>>>>> feedback).  moreover, it's visually  ugly.
>>>> what do you mean visually ugly? the fonts, or something that  
>>>> can't  be  adjusted?
>>> i just don't like the not transparent object.
>>>
>>> cyrille
>>>
>>>> _______________________________________________
>>>> Pd-dev mailing list
>>>> Pd-dev at iem.at
>>>> http://lists.puredata.info/listinfo/pd-dev
>> ----------------------------------------------------------------------------
>> "[W]e have invented the technology to eliminate scarcity, but we  
>> are  deliberately throwing it away to benefit those who profit  
>> from  scarcity."        -John Gilmore
>> _______________________________________________
>> Pd-dev mailing list
>> Pd-dev at iem.at
>> http://lists.puredata.info/listinfo/pd-dev

----------------------------------------------------------------------------

"[T]he greatest purveyor of violence in the world today [is] my own  
government." - Martin Luther King, Jr.