[PD] hex loader
Hans-Christoph Steiner
hans at eds.org
Thu Nov 29 05:44:39 CET 2007
By the way, I just read thru the whole hexloader README. Looks like
nice work, I think you covered every possibility that I could think
of :)
.hc
On Nov 28, 2007, at 10:05 PM, Mathieu Bouchard wrote:
> On Wed, 28 Nov 2007, IOhannes m zmoelnig wrote:
>
>> i don't like matju's suggestion to provide an API,
>
> Ideally, hexloader should be merged into the core and the API would
> be a single function shared by the loader and the parts of the
> internals that do the same thing as the hexloader does (the symbol
> mangler).
>
> I'm not really advocating that an external exposes an API otherwise
> than as pd objects and methods... but then, this is also what Gem
> need to do if some externals are not linked directly into Gem... so
> it must not be that ugly. GridFlow will also have to do it
> eventually. I just think that doing it for one function is a waste.
>
> Anyway, because virtually the same code is already in the core, it
> makes sense to have that shared function in the core, so the issue
> of linking to an external should be moot.
>
>> as this would require to have hexloader be loaded before all other
>> externals that rely on that API.
>
> Not if the linker knows about it. (The problem is how to tell the
> linker about it)
>
>> what might be a better solution is to tell Pd to try to load a
>> different class instead (kind of recursively calling the loading
>> stuff).
>
> I don't understand.
>
> _ _ __ ___ _____ ________ _____________ _____________________ ...
> | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
------------------------------------------------------------------------
----
"It is convenient to imagine a power beyond us because that means we
don't have to examine our own lives.", from "The Idols of
Environmentalism", by Curtis White
More information about the Pd-list
mailing list