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 >>>>> [email protected] >>>>> 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 >>> [email protected] >>> 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. > > > > _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
