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
On Nov 29, 2007, at 3:51 AM, IOhannes m zmoelnig wrote:
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:
- 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:
- 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.
I see, so if hexloader fails in the first pass, it then proceeds to try each of the possible variations on the name by feeding it back thru Pd's loader list. That sounds like a workable solution.
btw, all this slows down loading of abstractions considerably.
This is going to be inevitable if we are going to support a bunch of loaders. I could imagine having hexloader, libdir, lua, python, haskell, tcl, and java loaders all running. I think that testing for the existence of files is usually really fast, so I can't imagine it would slow things down that much. If it is a big concern, it could be profiled without too much difficulty.
Not to distract from this topic, but perhaps all of the file loading stuff should be done in a separate thread? It's already non- deterministic since it's dealing with the OS's file handling. There could be a low-priority thread that matches all of the classnames to the right files, reads those files into memory, then when everything is ready, hands all that over to the pd process to load.
I don't really know how complicated it would be, it has the potential of being a major pain, but I just thought I'd throw the idea out there.
.hc
------------------------------------------------------------------------ ----
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
-
Hans-Christoph Steiner -
IOhannes m zmoelnig