[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 11:01:15 CET 2009

Hans-Christoph Steiner a écrit :
> 
> 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
this mail is only about pd-extended file organization.
i'll be happy to have a svn organization proposition.
or did i misunderstand things?

> 
> 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 certainly miss some discussion here : does miller agree?

  I 
> also want to avoid a difference here.  
cool
>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.

i don't see problem to change pd behaviors from 1 version to an other. but i whish pd and pd-extended to be easily compatible.
so, let's go!

Cyrille

> 
> .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.
> 
> 
> 
> 