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 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 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 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
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 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 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@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 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