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

[IOhannes m zmoelnig]

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

>  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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20090408/59f7484c/attachment.bin>