use Perl

• See Also: WWW::Mechanize::Plugin::Display (Score:1)

  by markjugg (792)

  Thanks Andy. A related (but slightly different) tool is WWW::Mechanize::Plugin::Display [cpan.org].
• Default Output Stream (Score:1)

  by Smylers (2592)

  Do you think that will be the canonical use of dump_all?

  If so, would it make more sense for the default output stream to be STDERR rather than STDOUT, to save having to specify it every time?
  • Re: (Score:2)

    by petdance (2468)

    I don't know what the canonical use will be, so I defaulted to STDOUT.

    --
    

    --
    xoa
• I hate to be a spoil sport, but... (Score:1)

  by Alias (5735)

  ... when are you going to get red of whatever test server you are using for the test scripts that keeps failing and causing mech to be an unreliable dependency?
  
  I've started to migrate away from mechanize back to raw lwp in a few applications, simply because mech has become too unreliable.
  
  • Re: (Score:2)

    by petdance (2468)

    I didn't know it was a problem until you mentioned it yesterday. I'm open to alternatives.

    --
    

    --
    xoa
    • Re: (Score:1)

      by mw487 (439)

      In the past I think it failed most of the time on cygwin, due to the forking necessary for the server I believe, and I pretty much went back to LWP in spite of how nice mech seems (although mech can be an install festival).
      
      Maybe the first thing you could do would be test that mech tests still fails on cygwin (untested Mech 1.32, fails 1.3102, untested 1.3101, fail:pass 5:1 1.30, etc.).
      
      And then test the many flavors of http servers that might work. Just run there tests on Cygwin or review their results on t
      • Re: (Score:2)

        by petdance (2468)

        I can't test it on Cygwin. Regardless, my question still stands: What should I run my tests against instead?

        --
        

        --
        xoa
        • Re: (Score:1)

          by mw487 (439)

          I think you could fix the problems with your testing if you used a cross-platform, CPAN-tested local httpd rather than the included LocalServer.pm . Maybe you could pick a CPAN httpd that passes tests on cygwin and ActiveState and Linux etc.
          
          NOT HTTP-Server-Simple, NOT HTTP-Server-Brick, but get twisted with POE-Component-Server-SimpleHTTP, or take what is probably the easy way with Net::HTTPServer notably 1.1.1, a distribution which shows only one fail on CPAN-Testers for about 60 submissions on various v
          • Re: (Score:2)

            by petdance (2468)

            Can you help out on this at all? Also, what's wrong with HTTP::Server::Simple?

            --
            

            --
            xoa
            • Re: (Score:1)

              by mw487 (439)

              I can help out. I already put Net::HTTPServer on my cygwin and ActiveState Perl MSWin32.
              
              For starters, I can pick up a distribution using Net::HTTPServer for the back.t test, passing on your platform, from a url you supply and run the tests on cygwin and ActiveState MSWin32. That would mean you change your test to use Net::HTTPServer over LocalServer.pm.
              
              If you want me to do make the changes, I will need to learn some of your code first, and I may bail, but likely will get to it in time. I like mech, but
              • Re: (Score:2)

                by petdance (2468)

                I'd be glad to have your help. The Mech code lives on Google Code. I'd also really like to be able to get rid of the cut 'n' paste in the t/ directory to support it all.

                What can I do to help you?

                --
                

                --
                xoa
                • Re: (Score:1)

                  by mw487 (439)

                  Did you get my emails to andy@petdance.com? I am mw487@yahoo.com. This is getting into the weeds.
                  
                  In t/local/*.t, change:
                  
                    delete @ENV{ qw( http_proxy HTTP_PROXY ) };
                  
                  to
                  
                  foreach my $proxy (grep {/http_proxy/i} keys %ENV ) {delete $ENV{$proxy}}
                  
                  because believe it or not, Win XP takes my definition of environmental variable 'http_proxy' and kindly gives me 'HTTP_PROXY' and 'HTTP_proxy'. Whereas for 'ftp_proxy' I only seem to get 'FTP_PROXY' as a bonus.
                  
                  That change lets me pass t/local/back.t .
                  • Re: (Score:1)

                    by mw487 (439)

                    Actually, the HTTP_proxy problem seems to be in cygwin perl only, not due to XP, because ActiveStatePerl does not do show the problem. Guess I should file a bug report somewhere...
                    
                    C:/ActiveStatePerl/bin/perl -e 'foreach my $proxy (grep {/_proxy/i} keys %ENV) {print "\$ENV{$proxy} => $ENV{$proxy} \n" ; delete $ENV{$proxy}; } '
                    
                    If I leave my http_proxy and set my environment no_proxy to localhost, I can pass almost every test, except that HTTP:Daemon is a smart ass and uses my machine name instead of local
                  • Re: (Score:1)

                    by Aristotle (5147)

                    No need to write C in Perl:

                    delete @ENV{ grep { /http_proxy/i } keys %ENV };
                  • Re: (Score:2)

                    by petdance (2468)

                    Can you please summarize to http://code.google.com/p/www-mechanize/issues/detail?id=8 [google.com] and carry on commentary there?

                    --
                    

                    --
                    xoa