On Feb 25, 2009, at 5:01 AM, cyrille henry wrote: > > > 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?
That thread is about the design of a common library format and search path order. .hc > > >> 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. ---------------------------------------------------------------------------- You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
