Yesterday was productive, as Text::WikiFormat received documentation attention. This is always the last step of my release cycle. Strangely enough, though I enjoy commenting on code (think commentary), I dislike writing documentation, example usage, and all of the things that make developers happy. I even prefer writing tests.
It's a good sanity check, though. Things that are difficult to explain clearly usually need polish. Things I'd rather not explain usually need to be fixed. I tend to add a couple of convenient features and fix annoying buglets during the documentation phase.
I've been doing more work on my Perl bytecode->XML->refactoring/linting/improving->XML->Perl code. Since Schwern asked so nicely ("I don't understand what you claimed to be doing, but are you going to make it available?"), you can download it here. It works like any other backend module. Try perl -MO=ToXML proggie.pl to print an XML file representing (what I can decipher to be) the important parts of the compiled bytecode. If you want to output to a file, use perl -MO=ToXML,-ofilename proggie.pl instead. If you just want to dump a function or functions and print to a file, it's perl -MO=ToXML,-ofilename,func1,func2 proggie.pl.
Bypassing the idea of transformations at this point, I'm left with the task of turning XML back into Perl. There are two possibilities. I could use B::Generate to create an optree, then run it through B::Deparse. The other option is to generate just enough data to send to B::Deparse directly. I much prefer the latter, though I haven't tried the former.
The odds either Simon Cozens or Rafael Garcia-Suarez will take pity on me and reveal the secret information I'm not saving in B::ToXML or the magic of sending data to B::Deparse are minimal.
Since I should be writing two articles aimed at novices, packing up everything I own for a move, or any of several other important things, it's a great distraction.
BTW you can perform some optimizations on the optree, but once turned back into perl code, you've no guarantee that your optimizations will remain. Moreover, a modified optree will not necessarily be turnable into perl code: B::Deparse makes some assumptions on the format of the optree it is given. That's why sometimes bugs are introduced in B::Deparse by modifications in the perl core -- e.g. the recent rcatline optimization, not visible from the Perl language, as it affects only the optree. Be careful then.
Have you heard about Simon's optimizer.pm? You may find it interesting. (It's still alpha, but I think Simon is writing a paper about it.)
And now, a little bit of advertisement: my personal favorite about backend modules that dump the optree is B::Concise. It's really useful to debug internals. Now that I've discovered it, I don't use B::Terse anymore. So give it a try.
Re:XML2perl?
chromatic on 2002-02-21T02:04:03
There's no DTD yet -- I keep having to change things as I learn more. It's on the verge of working, though. I have looked at Simon's pluggable optimizer, but haven't figured out what to do with it. His B::Generate article in last year's TPC proceedings has really come in handy.
Re:XML2perl?
mdupont on 2002-06-20T11:21:47
This is really interesting. I am doing something similar in the introspector.sf.net project. Maybe I can use your XML output as well? please tell me where I can find this code for B::toXML?
Thanks, mikeRe:XML2perl?
chromatic on 2002-06-20T14:40:21
B::ToXML is available from my Perl pages.
