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

[Hans-Christoph Steiner]

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 latter is btw, similar to what zexy and/or Gem suggest  
> "upstream" (that is: from my side; not to be confused with any  
> packagers' versions):: zexy/zexy.pd_linux holds shared code (e.g.  
> [>~]) and signle-file-object live side-by-side to it, e.g. rad2deg.pd;
>
> 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.  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?

> having said all that, i think it is a good idea: i would like to be  
> able (e.g. in Pd-extended) to "load" Gem (without modifying the  
> path!) and it should find Gem/Gem.pd_linux and add Gem/ to it's  
> search paths (for abstractions and single-file externals)
> 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?

I take it you mean like including a .dylib in the Gem folder?  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.  I don't remember  
the details in Windows, I think that it already checks "." for .dlls  
by default.

.hc


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

I spent 33 years and four months in active military service and during  
that period I spent most of my time as a high class muscle man for Big  
Business, for Wall Street and the bankers.      - General Smedley Butler