[PD] >, <, &&, || etc

[Hans-Christoph Steiner]

On Apr 8, 2009, at 7:19 AM, IOhannes m zmoelnig wrote:

> Hans-Christoph Steiner wrote:
>> On Apr 6, 2009, at 5:26 AM, IOhannes m zmoelnig wrote:
>>> Hans-Christoph Steiner wrote:
>>>> So a library like 'audiomath' would then have audiomath/ 
>>>> libaudiomath.pd_linux.  Normally, audiomath/libaudiomath.pd_linux  
>>>> would only include shared code, but for this case, it would also  
>>>> include the >~ class, etc.
>>>
>>> i guess you meant to name it either "audiomath/ 
>>> libaudiomath.so" (or .dll or .dylib) or "audiomath/ 
>>> audiomath.pd_linux".
>> Perhaps audiomath/libaudiomath.so makes the most sense so that it  
>> can't be loaded by Pd as an objectclass.  But I am guessing.
>
>
> the question is why you would want to enforce Pd not being able to  
> load this library.
> at the worst this would allow to mix abstractions, single-object- 
> binaries, multi-object-binaries and shared-code dylibs into a single  
> "bundle" (libdir-like directory defining a library)
>
> the only reason i see to create an explicit mechanism to prevent Pd  
> from loadinga file as an object-class is a notorious aversion  
> against multiboject-binaries.
>
> it's ok for me if someone doesn't like these. it's not ok for me  
> declaring war on them.

I have traditionally had an aversion to multiobject-binaries because  
of the pain they caused many people, me included.  It seems that they  
could be fine as long as we have the right mechanisms to be able to  
put the objectclasses in that binary into a fully functioning  
namespace, and be able to address them using namespace prefixes.  From  
the Pd interface point of view, all objectclasses should behave the  
same, regardless of how they are implemented.

The idea for the audiomath/libaudiomath.so chunk is for shared code  
that would be loaded when the library is loaded, whether or not any  
object class has been loaded.  I suppose it might just be simpler to  
make it a .pd_linux.  I just have a feeling that it will cause  
problems down the line, I don't have an example off hand to back up  
that feeling.


>>> i admit that currently all C-code is considered "shared" (that is:  
>>> there is no "list2symbol.pd_linux"), but once you start blurring  
>>> the two worlds it get's blurry anyhow (and "l2s" and "list2symbol"  
>>> share about 100% of their code anyhow)
>> I like having each objectclass as its own file.
>
> i know
>
>> Then only the code that is in use will be loaded into memory.   
>> linking everything together into one zexy.pd_linux means the whole  
>> thing is loaded into memory, no?
>
> obviously.
> but you are surely aware that you cannot avoid people doing this  
> with shared libs (that cannot be loaded directly by Pd) as well.
>
> so again, the only reason to make this explicit is because to throw  
> feeble hurdles on the path of freedom of a developer.
> <trying to turn pathos mode off>

I think the archives have some long discussions about the problems  
with multi-object binaries.  I am not opposed to using them if someone  
wants to do the work to make them behave like abstractions in a libdir  
currently do.  (i.e. [import mylib] then [myobj]; [mylib/myobj],  
etc.)   Then we would have a relatively straightforward solution for  
the problems with >~, etc.

>>> i would also like to have Pd's loading mechanism modified so that  
>>> it _temporarily_ adds Gem/ to the dylib-searchpath, so one could  
>>> ship a library with external dependencies (without having to link  
>>> them statically)
>> I am sure you don't mean to do this on GNU/Linux, right?
>
> yes i want to do this on all platforms.

What lib would you include with Gem on GNU/Linux?  Shouldn't Gem use  
the Debian/Ubuntu/Fedora packages?  Or am I missing something?

>> I take it you mean like including a .dylib in the Gem folder?
>
> but i am not talking about including libGL.so with Gem.
>
> it is really something along the lines of your proposal on  
> "audiomath/libaudiomath.so".
>
>
>> Kind of like what I do with Pd-extended and the Fink dylibs?  That  
>> is not a great system.  I think due to the limitations of the Mac  
>> OS X shared lib loading, it would be painful.  Basically, AFAIK,  
>> a .dylib in Mac OS X must have its path hard-coded in the file.   
>> Otherwise, you have to load it manually with a direct call to dlopen.
>
> but the path can be relative, no?

Not really, IIRC.  It has to be an absolute path, but then there is  
this @executable_path@ variable which is replaced by the path to the  
executable that is loading the lib.  Its all a bit hazy in my brain,  
it would be worth checking the docs and maybe trying a relative path.   
I remember trying a lot of things, then giving up and thinking that Pd  
would have to open audiomath/libaudiomath.so directly using dlopen().

.hc

>> I don't remember the details in Windows, I think that it already  
>> checks "." for .dlls by default.
>
> this is how i remember it as well.
>
>
> fgmasdr
> IOhannes



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

                   ¡El pueblo unido jamás será vencido!