...As strange as it may sound I must admit I've missed our broken conversations/banter. Welcome back, Hans!
Alas, this time I will have to bow out--so many things to do, so little time. Hope you'll understand. Best, Ico On Sep 25, 2014 11:08 AM, "Hans-Christoph Steiner" <[email protected]> wrote: > > You can take an external compiled for the same OS/arch and it loads and > works > on all of them. > > .hc > > Ivica Bukvic wrote: > > 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
