[PD-dev] overriding "internals"

Hans-Christoph Steiner hans at eds.org
Sat Nov 10 18:50:23 CET 2007


On Nov 10, 2007, at 11:25 AM, IOhannes m zmoelnig wrote:

> Hans-Christoph Steiner wrote:
>> On Nov 10, 2007, at 3:55 AM, IOhannes m zmoelnig wrote:
>>>
>>> cyclone does something like this (it overrides already registered  
>>> externals, which - at this point - are not different from internals)
>>>
>>> it is basically looking whether the class-name is already  
>>> registered, and if so, overwrites the class-pointers.
>>>
>>> however, for this to work, you need first need to call a function  
>>> in your overriding new library.
>>> therefore you will probably need something like a  
>>> "library" (instead of single, same-named externals)
>> I'd rather not use a special mechanism, especially if it is not  
>> already widely used.
>
> well you asked, i gave you an answer.
> but then i probably have not read your original email as careful as  
> i have should.

No problem, I am just discussing how I think it should be done.

>>>> I was thinking of just breaking out the classes into their own  
>>>> files,  then compiling things as a libdir.  This is pretty easy  
>>>> for most of  the objects, but I haven't gotten into the DSP  
>>>> classes yet, and I  expect things will be more complicated  
>>>> there.  And [list] too.
>>>
>>> funnily enough i have always been opposed when requesting that  
>>> the [list] objects get _proper_ names.
>> Why?  For example, [list append] will happily append a symbol to a  
>> float, so the "list" part doesn't seem so accurate.  Why not just  
>> [append]?
>
> probably because of [append] already exists?

Ok, but you can use a different word.  Why do these things need a  
special syntax of a meta object and then another selector?

Also consider [trim].  If [list trim] will trim "symbol" from a  
symbol message, then it's not doing anything with lists.

>> The libtkwidget.so would be included in the libdir to make it a  
>> simple package.
>
> so how do you convince the ldopen to look for the libtkwidget.so in  
> your libdir instead of whatever is configured in /etc/ld.so.conf?
>
> i guess, adding your libdir path to /etc/ld.so.conf disqualifies it  
> as "a simple package".
>
> i would really be interested in a solution for this.

Thomas had this working with flext, I don't know the details, it's  
possible.  At the very least, you can have a mechanism like Pd does,  
opening it's own .so libs (aka .pd_darwin, .pd_linux, etc) without  
touching ld.conf.

.hc

------------------------------------------------------------------------ 
----

News is what people want to keep hidden and everything else is  
publicity.          - Bill Moyers






More information about the Pd-dev mailing list