Looks like the dumping codec just is very bad at resolving things. Whatever it can't resolve, it dumps recursively. I see it dumps recursively not only PiXPull but also Locale.Charset.Encoder, Locale.Charset.Decoder and Stdio.Stream. I'll see if I can improve it, but it'll only happen in 7.5 in that case.

/ Martin Stjernholm, Roxen IS

Previous text:

2003-05-28 12:41: Subject: dumping modules

---

I tried running dumpmodule.pike on some of my .pmod's, with the result:

-rw-r--r-- 1 rjb rjb 55029 May 21 11:23 PiXPull.pmod -rw-r--r-- 1 rjb rjb 82157 May 28 11:43 PiXPull.pmod.o -rw-r--r-- 1 rjb rjb 18221 May 21 11:23 PiXTree.pmod -rw-r--r-- 1 rjb rjb 102525 May 28 11:43 PiXTree.pmod.o

Note the funny sizes: the module with much less code gets a significantly larger bytecode dump.

Taking a closer look, I concluded that the bytecode for PiXPull.pmod was for some reason getting pulled into PiXTree.pmod.o. Indeed, running `strings' on PiXTree.pmod.o, I found all the string literals used in PiXPull.pmod.

In fact, PiXTree.pmod contains the statement `import .PiXPull;', but it's not clear to me whether this should have the above effect. NB modifying PiXTree.pmod to reference .PiXPull.Parser etc. explicitly (instead of using the import) has little effect on the dump.

(This is with Pike v7.4 release 21)

/ rjb