>Paul J. Schinder (schinder@pjstoaster.pg.md.us) writes: >I'm *very* curious. You said yesterday that you're using 5b6? The >straight 5b6 distribution from Gisle Aas's site or from CPAN, or did >you fix it? And you can, say, do an http get with it, or MIME type a >file by extension? If so, this might be a significant clue about the >my bug, and it would be worth knowing tool or application and PPC or >68k. I've only tried a few. MIME::Base64.pm and MIME::QuotedPrint.pm both seem to work satifactorily. There is a set of modules in HTML for translating HTML to PostScript which do not run here without a little modification. The set is: HTML::FormatPS.pm HTML::Formatter.pm HTML::Parse.pm The last will run on its own without complaint, but all three together do not. If all the my's are removed from FormatPS.pm and Formatter.pm the problem is resolved but it seems a bit drastic to do such wholesale hacking. One wonders what the full implications might be? The first crash occurs at line 56 of 'Formatter.pm', which is; return $self->$func($node); If the 'my' at the first line of that subroutine ('sub format'): my ($self, $html) = @_; (line 48), is deleted, there are no further hitches. The scripts are littered with 'my' and littered '$self' and it is difficult to see what is happening. The question is, was it just luck that got the set running with only one 'my' removed? It might be "necessary" but how does one show it is "sufficient"? In passing MacPerl required 3072K of memory allocated to translate the macperl.html document (which is in pod of the MacPerl distribution) and which is only about 18k. Why is so much memory needed? Anyone any ideas on this? Set-up is: MacPerl application 5.0.6; libwww-perl-5b6; 68030/system 7.5.1 Alan