On 09/25/2014 12:54 PM, Jonathan Wilkes via Pd-list wrote:
Um... have you actually read the source for DesireData?
Just to clarify this-- from m_pd.h desiredata 2010.01.05:
struct _symbol { char *name; /* the const string that represents this symbol */ t_pd *thing; /* pointer to the target of a receive-symbol or to the bindlist of several targets */ struct _symbol *next; /* brochette of all symbols (only for permanent symbols) */ size_t refcount; /* refcount<0 means that the symbol is permanent */ size_t n; /* size of name (support for NUL characters) */ #ifdef PD_PLUSPLUS_FACE bool operator == (const char *s) const {return strcmp(this->name,s)==0;} bool operator != (const char *s) const {return strcmp(this->name,s);} #endif };
Desiredata's t_symbol has extra members that aren't in Pd Vanilla's t_symbol struct. If there is any external out there that uses an array of symbols, then there will be problems due to this binary compatibility.
I have no idea if this is representative of the rest of DesireData or if
it is an outlier. I only know it is a form of binary incompatibility.
Whether it is a significant form is up for discussion, but that requires
a more sophisticated discussion than "Pd-l2ork = binary_incompatible = bad".
-Jonathan
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 ico@vt.edu 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" <hans@at.or.at mailto:hans@at.or.at> 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" <hans@at.or.at <mailto:hans@at.or.at>> 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" <hans@at.or.at <mailto:hans@at.or.at>> >> 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" <danomatika@gmail.com <mailto:danomatika@gmail.com>> 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, pd-list-request@lists.iem.at <mailto:pd-list-request@lists.iem.at> 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 <http://danomatika.com/> >>>>>> robotcowboy.com <http://robotcowboy.com/> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list >>>>>> UNSUBSCRIBE and account-management -> >>>>>> http://lists.puredata.info/listinfo/pd-list >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> N �n�r����)em�h�yhiם�w^�� >>>> >>>> _______________________________________________ >>>> Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list >>>> UNSUBSCRIBE and account-management -> >>>> http://lists.puredata.info/listinfo/pd-list >>>> >>
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list