[PD] Updated pd-extended
Jonathan Wilkes
jancsika at yahoo.com
Fri Sep 26 04:22:05 CEST 2014
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 at 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 at.or.at
> <mailto:hans at 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 at.or.at <mailto:hans at 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 at.or.at <mailto:hans at 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 at gmail.com
> <mailto:danomatika at 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 at lists.iem.at
> <mailto:pd-list-request at 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 at lists.iem.at <mailto:Pd-list at 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 at lists.iem.at <mailto:Pd-list at lists.iem.at> mailing list
> >>>> UNSUBSCRIBE and account-management ->
> >>>> http://lists.puredata.info/listinfo/pd-list
> >>>>
> >>
>
>
> _______________________________________________
> Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at> mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140925/ee64e04d/attachment-0001.html>
More information about the Pd-list
mailing list