Hm, I can't seem to find any proposals on the list. If someone can find them for me (and if there are indeed details there) I'll see if they will work.
-Jonathan On Wednesday, October 1, 2014 10:51 AM, Hans-Christoph Steiner <[email protected]> wrote: There were at least two proposals back when the change was made. They're in the archives. I certainly don't remember the details at this point. .hc Jonathan Wilkes wrote: > Um... have you actually read the source for DesireData? > > If someone wants to write me up a nice, concise, friendly non-sarcastic spec > about how to change Pd-l2ork's code so that it can be binary compatible with > the same features it currently has, I'll be happy to try implementing it. > > -Jonathan > > > On Thursday, September 25, 2014 12:04 PM, Ivica Bukvic <[email protected]> wrote: > > > > ...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 >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
