View previous topic :: View next topic |
Author |
Message |
dhasenan
Joined: 03 Feb 2005 Posts: 73 Location: New York
|
Posted: Wed May 28, 2008 7:51 pm Post subject: Thousands of modules; manageable imports |
|
|
Hi --
I'm starting to integrate minid into my nascent MUD. I'm going to have about one file per entity: a kopesh gets one file, a rapier another, a breastplate in a third, et cetera.
Some of these modules will need a lot of imports. Mainly with something like an NPC, which can have a large number of items and spells and skills. This means I'll have to write a lot of import statements, and they'll quite possibly get pretty long.
My first thought was to glob all the files for a particular area together. It's possible for one area to reference another, though, for which I can use the import statement. But since my modules would then be huge, there's a high probability of importing the same module multiple times. I'm pretty sure that the current minid2 compiler dislikes it if module A imports module B multiple times. Would you accept a patch that allows multiple imports?
Or do you have any other suggestions on dealing with large numbers of imports? |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
dhasenan
Joined: 03 Feb 2005 Posts: 73 Location: New York
|
Posted: Wed May 28, 2008 9:42 pm Post subject: |
|
|
Also, since I'll need to do some preprocessing, most likely, on these modules, I'll need to alter MDContext to allow lower level access somehow. I'd like something like this:
bool haveModule(dchar[] name);
void loadModule(dchar[] name, dchar[] source, MDState s = null);
The implementation of importModule would then essentially just check haveModule and, if that returns false, read the appropriate file and call loadModule.
I could use MDContext.initializeModule instead, if I can access MDContext.mMainThread and a number of other things, but that's cumbersome and would force me to duplicate large portions of existing methods. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
dhasenan
Joined: 03 Feb 2005 Posts: 73 Location: New York
|
Posted: Thu May 29, 2008 7:05 am Post subject: |
|
|
I'm not sure how imports are resolved in MiniD. It looks like the compiler doesn't handle that, and that they are resolved at runtime. Where is this handled?
Also, now I see the module minid.minid, which has support for compiling modules from strings. But where do I get an MDState to use with that? I can get an MDContext, but its default MDState is private. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
dhasenan
Joined: 03 Feb 2005 Posts: 73 Location: New York
|
Posted: Thu May 29, 2008 7:14 am Post subject: |
|
|
Okay, I got the MDState with MDContext.mainThread. And I found the import code around minid.d:6550, and around 3400.
There's no way for me to add a custom import resolver, though. This means either I hack up MiniD, or I manage intermodule dependencies manually, or I try to load each, ignore failures, and retry until every one succeeds:
Code: |
while (toLoad.length)
{
foreach (module; toLoad)
{
try { load(module); toLoad.remove(module); } catch {}
}
}
|
I'll submit a patch for custom resolvers at some point. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
dhasenan
Joined: 03 Feb 2005 Posts: 73 Location: New York
|
Posted: Thu May 29, 2008 7:27 am Post subject: |
|
|
Now I'm seeing support for custom module loaders with MDContext.setModuleLoader. This is used with WrapModule. One of the parameters is an MDNamespace. This is a bit ugly, though, since the obvious solution for resolving a module is to compile it, and all the compilation methods return an MDNamespace rather than taking one as a parameter. Any suggestions? |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
JarrettBillingsley
Joined: 20 Jun 2006 Posts: 457 Location: Pennsylvania!
|
Posted: Thu May 29, 2008 9:11 am Post subject: |
|
|
Having multiple imports of the same module in one module is not an error, the compiler won't complain about it. Because, as you've discovered, import resolution happens at runtime.
As for custom module loaders -- you're right, there does seem to be a bit of a disconnect between the protocol for custom module loaders and the compilation methods. I'll have to look into that more. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|