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