Perhaps you were interested in P6 years ago and installed or configured something related to that? Or perhaps you've installed some automated refactoring thing?
Then again, I don't know how that could/would carry over from your XP setup to your Win 7 setup.
Given that MAD normally creates a bunch of overhead (making perl run more slowly and use more memory) and typically doesn't provide any benefit, you should figure out how to switch it off. As a bonus, that should fix your problem too.
If you decide to leave MAD on, then I think you need to figure out in to which directory perl writes the file specified in PERL_XMLDUMP. Does the perl process you're running have permission to write to that directory? Windows 7 tightened up permissions considerably compared to XP.
Hth.
Not that it's relevant to the OP, but for completeness sake, from #perl6 log, Aug 22, 2013:
17:14 TimToady well, I'm not necessarily recommending the MAD approach these days,
since it turned out to be rather fragile
While Larry has previously suggested it was best to leave the MAD code and configure option in perl5 core for the time being, I think that suggestion is now somewhat stale. In the above log Larry (quite sensibly imo) suggests one day leveraging FROGG's v5 for translation. Such a translator would not use MAD. Also, fglock started a perlito based translator a couple months back -- and it won't use MAD either. Finally, in August (and the above IRC log) Util talked about creating a translator (Blue_Tiger) that could theoretically use MAD -- but he said he thought PPI was good enough.
In reply to Re^4: Windows 7
by raiph
in thread Windows 7
by PilotinControl
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |