folks,

Ive worked up this patch, and would like to get feedback.

1. is it useful ?
2. are there any glaring or subtle problems ?
3. do you like/dislike the XS to perl callback ?

I recognize this can be done in C, but calling back into perl
is easier, and more flexible.

its my 1st XS ever, so please be gentle.
And I'll take opportunity to thank Marcus Holland-Moritz
for his huge help in making this pass its tests on his 91 perls.

And I should say that it needs 5.8.6 to actually work. (uses new new B::Concise features)


In particular, t/glob.t (which dumps the stash, but runs no tests -yet ) raises a few questions:

# dl_load_flags.SCALAR => 12
# dl_load_flags.GLOB => 566
# EXPORT_TAGS.SCALAR => 12
# EXPORT_TAGS.HASH => 117
# EXPORT_TAGS.GLOB => 413
# total_size.SCALAR => 12
err: coderef B::CV=SCALAR(0x8a03b18) has no START
# total_size CODE: is probably XS code
err: coderef B::CV=SCALAR(0x8a044b4) has no START
# total_size GLOB: is probably XS code

1. do the sizes look sensible
I think so, but I hav *no* experience with these things.

2. why do both {CODE} and {GLOB} thingies in the stash-val
result in calls to Devel::Size::_sizeCV  (my new func)
I would expect former, but not latter.

3. It appears that the 'err: coderef $foo has no START'
is result of calling _sizeCV on an XS function.
Does that sound right ?  Are there any other causes ?
if Yes, no, then Ill send a patch to blead.

4. any point in computing size of binary functions ?
I could imagine doing it with `nm -S` but this is horribly unportable.
It also opens a whole nuther can of worms, since each function
is likely to call lots of others.

thanks in advance,
Jim Cromie

Attachment: patch.dsize.60_06.bz2
Description: BZip2 compressed data



Reply via email to