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
