[PD] Updated pd-extended

[Ivica Bukvic]

...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> 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>
> 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/eee37f57/attachment.html>