You know guys, all I’m saying is perhaps there’s a way to move forward with the spirit of Pd-extended with the practicality of making it easy to use the extended externals with vanilla. In no way was I trying to say what you’re doing or not doing with pd-l2ork is wrong.
This line "I assume l2ork doesn’t rely on one person testing and building across multiple platforms?” is only asking if you’ve experienced what a pain it is to handle that. It takes work and it’s *really* nice not to have to rely on one or two people to manually check things. I wrote that in comradeship assuming you agree that it’s a pain to do. I appreciate the work y’all are doing, but not everyone wants to use pd-l2ork and you yourselves have said you have no interest in trying to fill the role of Pd-extended. -------- Dan Wilcox @danomatika danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> > On Dec 22, 2014, at 7:06 PM, Jonathan Wilkes <[email protected]> wrote: > > One thing I'll add-- Pd-extended already includes within it the ability for > individual libraries to be compiled "a la carte" in the way Dan desires. Any > library adhering to the "libdir" format will have a standard makefile that > can be used to compile the binaries. They'll end up in the same directory > with their help patches, which means in most cases they will create properly > when the user opens the help patch (even if that library hasn't been loaded > yet). > > The idea of scripting dependencies across externals is an interesting one. I > don't think that currently happens with Pd-extended. But a lot of libraries > do employ [pddp/pddplink] in the documentation, so that feature would be > handy in that situation. > > Also-- I think weeding out "duplicate" externals is a bad idea, at least the > way Ivica describes it. Many people have built patches with Pd-extended, > assuming that all the object names available at startup are essentially like > "keywords" in text-based languages. It's unfortunate that [lib1/foo] does > the same exact thing as [lib2/bar]. But if I'm trying to show off Pd by > playing some fancy synthesizer patch which relies on [lib1/foo], it had > better work. I'll always prefer ugly-but-works over > clean-but-let-me-debug-this-patch-while-everyone-sits-there-and-waits. > > Anyway, I think there are ways to prefer certain objects or libs in the > search results, and steer new users to the more reliable and maintained set > of externals. > > -Jonathan > > > On Monday, December 22, 2014 5:48 PM, Ivica Bukvic <[email protected]> wrote: > > > > On Dec 22, 2014 10:23 PM, "Dan Wilcox" <[email protected] > <mailto:[email protected]>> wrote: > > > > > >> On Dec 22, 2014, at 2:55 AM, Jonathan Wilkes <[email protected] > >> <mailto:[email protected]>> wrote: > >> > >> Unless you want an enormous number of patches in the wild to bit-rot, > >> you're going to have a "Install Pd-extended libraries" button. If you > >> have that button, then presumably at least _one_ person is going to need > >> to build and test the whole enchilada, no? > > > > > > I disagree. If it’s easier to build, then it will be easier for a number of > > people to test on their respective OS. I assume l2ork doesn’t rely on one > > person testing and building across multiple platforms? I’ve been in that > > situation already and it sucks. Much nicer to split up the work, better > > still if the makefiles work and we have some scripting to handling > > automation, fetching, etc for developers and volunteer testers. > Actually, you're simply trading one shortcoming for another, and I would > argue you're shortcoming is a lot harder to troubleshoot. If you provide a > monolithic distribution to all of your users, then reproducing their problems > becomes exponentially easier as opposed to encouraging each user to install > select externals which may clash with each other in unusual ways that may not > be apparent otherwise and then trying to backtrace and troubleshoot their > specific set up as opposed to relying on one monolithic release that you can > easily reproduce on your own computer. If we had infinite time on this rock > this may be a feasible option. As for me, particularly considering I am doing > this not because I am getting paid to do it, monolithic approach is the way > to go with the ultimate goal of having all externals in the extra folder and > without any subfolders (in part because duplicates and buggy externals will > have been weeded out). > BTW for clarification purposes, pd-l2ork is tested by a couple of core > developers, including myself almost on a daily basis, plus 12+ members who > have little or no experience with Linux, let alone with PD through the laptop > orchestra, and finally a bunch of kids through various k12 education > initiatives (who also have little or no knowledge of Linux or PD). I feel > that is fairly sufficient for my needs. > Also, to clarify another point that has been brought up several times on this > mailing list, while pd-l2ork does not support Windows or Mac at this time, > this is mainly due to lack of human resources, rather than some kind of > religious mission. There is clearly an intent on supporting those once we > complete port to Qt toolkit. Until then, there is a bootable USB stick that > boots on most computers, and has its own environment, including a persistent > home directory. There are exceptions-- select laptops that stubbornly lock > down their EFI making them not fully compliant with bootable USB stick > format. Examples of this that I observed include select Apple hardware (as > part of their ongoing "we know better than the user" walled garden > initiative) and a few Dell and Alienware machines (in other words, select > companies in close relationships with Microsoft). > > > >> Btw-- are there poisonous spiders lurking in the Pd-extended makefiles? > >> Just reading this thread and seeing alternatives like "let's just port apt > >> to some proprietary OSes" seems odd to me… > > > > > > I agree. I, for one, say let’s make sure the makefiles work well before > > getting into package management (if at all). > > > >> So I guess I'll add my own idea to this mix: how about replacing every > >> single external binary with an abstraction? Then the external libs become > >> portable without having to compile a single thing. Plus any Pd user > >> willing to click the object can potentially fix bugs or make improvements. > >> Sure, you can't do Gem and some of the fancy stuff, but those are > >> details. This would also increase the incentives for doing development to > >> the core which makes abstractions faster. > > > > > > rjlib, etc have done some of this already and I’ve followed when I started > > reimplementing my abstraction library. Honestly, I don’t think this > > community has the resources to tackle an effort like that, regardless of > > the technical issues that would need to be fixed. I think it’s far more > > pragmatic to work on making it easier to split up the maintenance work on > > the existing externals and allow for more people to hep testing, building, > > and using them outside of a monolithic Pd-extended release. Again, this > > approach has worked for other projects like OpenFrameworks, so I think it > > can be applicable to Pd. This way, also, we still allow for the freedom of > > the users to step up and dictate which externals they want to keep using > > without throwing out all the work and useful source code that already > > exists. > > > > -------- > > Dan Wilcox > > @danomatika > > danomatika.com <http://danomatika.com/> > > robotcowboy.com <http://robotcowboy.com/> > > > > > > _______________________________________________ > > [email protected] <mailto:[email protected]> mailing list > > UNSUBSCRIBE and account-management -> > > http://lists.puredata.info/listinfo/pd-list > > <http://lists.puredata.info/listinfo/pd-list> > > > > >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
