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!
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
