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).
yes and no. the hexloader is a bit less strict when it comes to filename mangling (as certain characters are allowed in filenames but not in c-functionnames); one yould of course use the strictest character set, but i think it adds to readability (in your console (or file-browser, if you insist); not in the patch) to use a larger set of characters if possible. > > 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. ok, so we are have the same idea here. i have no problem with a "Gem external" (or "GF external" or whatever) to depend on another external (Gem, or GF, or whatever), because that's what they are: extensions to a certain external and not extensions to Pd. i think most of the loaders aim to be extensions to Pd rather than extensions of the hexloader. but anyhow, i think we agree. > 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) well yes; but _i_ don't know 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. very simple, let's have an example: let's assume we have a pdlua-class ">~" within a file "0x3e0x7e.lua" the loaders loaded are: odlua, hexloader A. (this is how it is happening now) pd is told to create [>~] which it doesn't know about yet. it calls sys_load_lib(c, ">~") which it turn calls all the loader: 1. it runs sys_do_loadlib, which tries to load the external ">~.l_i386", and fails. 2. it runs pdlua, which tries to load ">~.pdlua" and fails. 3. it runs hexloader, which tries to load "0x3e0x7e.l_i386" and "0x3e0x7e.pd", and fails B: this is how i think it might work. pd is told to create [>~] which it doesn't know about yet. it calls sys_load_lib(c, ">~") which it turn calls all the loader: 1. it runs sys_do_loadlib, which tries to load the external ">~.l_i386", and fails. 2. it runs pdlua, which tries to fin ">~.pdlua" and fails. 3. it runs hexloader, which tries to load "0x3e0x7e.l_i386" and "0x3e0x7e.pd", and fails 4. hexloader now calls sys_load_lib(c, "0x3e0x7e") 4.1. it runs sys_do_loadlib, which tries to load the external "0x3e0x7e.l_i386", and fails. 4.2. it runs pdlua, which tries to load "0x3e0x7e.pdlua" and succeeds. btw, all this slows down loading of abstractions considerably. fgmasdr. IOhannes _______________________________________________ PD-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
