in reply to Re^2: Windows 7
in thread Windows 7

        My guess is file permissions?

You wouldn't have to "guess" if you displayed the error message from the OS.
Change your code to: 

  open(STDOUT, '>>', 'sbguioutput.txt') or die "Can't open log:$!"; # 
+Note $! added

[download]
FYI -MAD info from http://perldoc.perl.org/perl594delta.html#MAD

MAD, which stands for Misc Attribute Decoration, is a still-in-development work leading to a Perl 5 to Perl 6 converter. To enable it, it's necessary to pass the argument -Dmad to Configure. The obtained perl isn't binary compatible with a regular perl 5.9.4, and has space and speed penalties; moreover not all regression tests still pass with it.

             When in doubt, mumble; when in trouble, delegate; when in charge, ponder. -- James H. Boren

Replies are listed 'Best First'.
Re^4: Windows 7
by taint (Chaplain) on Dec 06, 2013 at 07:35 UTC
    Well done, NetWallah.

    Even tho this wasn't my issue, I really appreciate your clarification.

    +'s to you. :)

    --Chris

    Hey. I'm not completely useless. I can be used as a bad example.
[reply]
Re^4: Windows 7
by raiph (Deacon) on Dec 06, 2013 at 18:23 UTC
    So, it looks like you (PilotinControl) have a perl configured with -Dmad. ("To enable it, it's necessary to pass the argument -Dmad to Configure.".) This is an esoteric option related to source code transformation; you must have enabled it somehow.

    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.

    »ö« . o O ( "the celebrity tell-all of the Perl-6 cult?" )

[reply]

      First thing I did was download the newest version of Activestate Perl to Windows 7 which is a newer version than I have on my current windows XP machine. Then I just copied (bad idea now since windows is more tight with its permissions as I am finding out with using other programs) over the folder from XP to 7. So yes its partially the permissions factor. I will also go through the perl setup process to determine if MAD was configured automatically when installed on Win 7. Thanks for the comments and suggestions.

[reply]
Re^4: Windows 7
by PilotinControl (Pilgrim) on Dec 06, 2013 at 11:45 UTC

    I did confirm this: Windows XP is running Active State Perl 5.10 and Windows 7 is running version 5.18 so I am assuming outside of the Windows Versions along with the different Perl versions has a lot to do with this?

[reply]

In Section Seekers of Perl Wisdom