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 _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
