[PD] Updated pd-extended

[Ivica Bukvic]

Based on what metrics?
On Sep 25, 2014 11:05 AM, "Hans-Christoph Steiner" <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>
> 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> 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 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
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> 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 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/af668d0d/attachment.html>