note
liz
<I>...It addresses all these problems. Very nice!</I>
<P>
Thank you for your kind words. But I'm afraid there are still some issues involved ;-(
<P>
<I>They alter your source's line numbers...</I>
<P>
I've chosen a very simple, line by line algorithm, that will lend itself for rewriting in C if ever necessary. No lines should be removed or added, so line numbers should always be correct (although pod lines that are not activated, <B>are</B> replaced by empty lines). I'm contemplating emptying out lines that start with "#" also, but I'm afraid the additional check (in Perl) would cost more CPU than adding the whole line to the source again and having the Perl parser get rid of such a line (in C).
<P>
<I>... These Perl "compilers" do not evaluate source filters at runtime...</I>
<P>
Well, add mod_perl to that list. My nice little magic module doesn't do it in mod_perl. ;-( One of the reasons I started this in the first place. ;-(
<P>
Anyway, I have added an API for other modules that would allow them to have an arbitrary piece of code stored in a variable to be processed in the same manner. For instance
<code>
eval $source;
</code>
could become:
<code>
ifdef::process( $source ) if exists &ifdef::process;
eval $source;
</code>
<P>
Now to find out what magic mod_perl is performing when it loads its Perl modules and convince the mod_perl people to add the above extra line... ;-)
<P>
Liz
<P>
<B>Update</B>:<BR>
Actually, I just realized the above could be done smarter:
<code>
=begin MODPERL
ifdef::process( $source );
=cut
eval $source;
</code>
Under mod_perl, the environment variable MODPERL is always defined and not null. If [cpan://ifdef] is active, then the extra processing line becomes active automatically, making sure the $source will also be processed. If [cpan://ifdef] is <B>not</B> loaded, then the pod section will be skipped, directly evalling the source.
323875
323984