...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
>>>>
>>
_______________________________________________