Based on what metrics? On Sep 25, 2014 11:05 AM, "Hans-Christoph Steiner" <[email protected]> wrote:
> > For libraries, there is binary compatibility between pd vanilla, extended, > desiredata, and vibrez. desiredata made much larger changes to the > GUI-side > than pd-l2ork. > > .hc > > Ivica Bukvic wrote: > > Why is this such a problem? I did not break source compatibility (well, > > some of it will happen for gui objects as a result of porting gui to qt) > > and for every extended release you recompile new binaries anyhow and so > > does pd-l2ork, except that pd-l2ork goes even one step further offering a > > monolithic release. Besides, pd is not java and there is no binary > > compatibility across different platforms (except maybe libpd realized in > > java, but that is not what we are talking about here). Under such > > circumstances, I see binary compatibility strictly as a means of > > maintaining status quo. As a final thought, consider that a lot of good > > work (as you called it, and I thank you for your kind words) would not > have > > been possible without breaking binary compatibility which, given the > > aforesaid circumstances, is a non-issue to begin with. > > > > Best, > > > > Ico > > On Sep 25, 2014 10:54 AM, "Hans-Christoph Steiner" <[email protected]> > wrote: > > > >> > >> You've done a lot of good work in pd-l2ork, but you also broke binary > >> compatibility of libraries for no good reason. You could have > implemented > >> that feature in a way that preserved binary compatibility of libraries. > >> You > >> still can, and you should. > >> > >> .hc > >> > >> Ivica Bukvic wrote: > >>> Well, I guess you can call me a "developer," whatever that means--I > don't > >>> care that much about titles. Yet, I would argue that as far as low > level > >>> stuff is concerned in recent years pd-l2ork has certainly pushed the > >>> envelope in terms of core development. Even the feature that has earned > >> me > >>> the title in quotations delves so deep into the core that currently it > >>> cannot be implemented in either vanilla or extended without significant > >>> changes even though it retains full backwards compatibility. I would > also > >>> argue it is essential and offers a slew of features that are > unavailable > >> in > >>> any other implementation of presets. > >>> > >>> Pd-l2ork's greatest deterrent is exclusivity to Linux, which was > >> initially > >>> a conscious decision to allow for faster development while addressing > the > >>> lack of manpower. But that is about to change once we complete port to > Qt > >>> library. We already transitioned to Tkpath quite a while ago which > >> allowed > >>> us to use a full SVG-based canvas, so I have no doubt we will be able > to > >> do > >>> this again. Once this is done, we won't have to circumnavigate > exceptions > >>> Tk library requires in order to be compliant with different platforms > >> and I > >>> would argue in turn that will result in faster development. So, if you > >> are > >>> really interested in pushing the development of non-vanilla pd I think > >> you > >>> should heed some of Jonathan's advice and look for ways how community > can > >>> work together in combining the "best of" and engaging developers and > >>> "developers" alike who have shown dedication to the cause. But before > >> that > >>> can be accomplished, the community should consider agreeing on design > >>> choices. For instance, pd-l2ork came into existence because it focuses > on > >>> more nimble development at the expense of potential loss of backwards > >>> compatibility (even though after 4 years of development the only > >>> incompatibility we infatuated is correcting buggy positioning of iemgui > >>> objects, which is cosmetic in nature) because a good chunk of that > >>> compatibility stems from buggy implementations that stuck around long > >>> enough that they became a part of the standard (e.g. iemgui's buggy > >>> positioning of objects that are arbitrarily offset from their x and y > >>> positions, as reported by the pd script), which is unfortunate. > >>> > >>> Best, > >>> > >>> Ico > >>> On Sep 23, 2014 9:21 AM, "Dan Wilcox" <[email protected]> wrote: > >>> > >>>> I disagree. Your example lists what? 2 more developers? I'm talking > >> about > >>>> "developers" as in people working the C code, build scripts, tcl/tk > etc > >> aka > >>>> people who could, theoretically, help push out a new Pd-extended > >> release. > >>>> True, we have plenty of people working on externals, but this is a > >> problem > >>>> for someone who can go deeper. > >>>> > >>>> I still maintain that the number of low level developers to overall > >> users > >>>> (non-developers) is relatively low. > >>>> > >>>> On Sep 23, 2014, at 6:00 AM, [email protected] wrote: > >>>> > >>>> However, your description of the user/developer ratio doesn't ring > true > >> to > >>>> me. There's actually a surplus of developers and development > energy-- I > >>>> count two implementations of presets in the last year or two (in > >> Pd-l2ork > >>>> and the Chocolate et Coffee lib) which are in addition to however many > >>>> already exist on svn and the Pd forum. > >>>> > >>>> > >>>> -------- > >>>> Dan Wilcox > >>>> @danomatika > >>>> danomatika.com > >>>> robotcowboy.com > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> [email protected] mailing list > >>>> UNSUBSCRIBE and account-management -> > >>>> http://lists.puredata.info/listinfo/pd-list > >>>> > >>>> > >>>> > >>>> > >>>> N �n�r����)em�h�yhiם�w^�� > >> > >> _______________________________________________ > >> [email protected] mailing list > >> UNSUBSCRIBE and account-management -> > >> http://lists.puredata.info/listinfo/pd-list > >> >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
