[PD-dev] [PD] hex loader

[IOhannes m zmoelnig]

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