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 <[email protected]> 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" <[email protected]
<mailto:[email protected]>> 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"
<[email protected] <mailto:[email protected]>> 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"
<[email protected] <mailto:[email protected]>>
>> 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" <[email protected]
<mailto:[email protected]>> 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, [email protected]
<mailto:[email protected]> 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/>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> [email protected] <mailto:[email protected]> mailing list
>>>>>> UNSUBSCRIBE and account-management ->
>>>>>> http://lists.puredata.info/listinfo/pd-list
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> N �n�r����)em�h�yhiם�w^��
>>>>
>>>> _______________________________________________
>>>> [email protected] <mailto:[email protected]> mailing list
>>>> UNSUBSCRIBE and account-management ->
>>>> http://lists.puredata.info/listinfo/pd-list
>>>>
>>
_______________________________________________
[email protected] <mailto:[email protected]> mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
