Re: W3C validator
Op een mooie lentedag (Monday 08 May 2006 20:01),schreef Gabor Szabo: > I checked it again, one can download the source code of their service > from here http://validator.w3.org/source/ > and it is even packaged in some of the linux distros. > > (It is of course slightly outdated on Debian) > > Someone might want to write a wrapper around it > or maybe use WebService::Validator::HTML::W3C with a > local URL instead of the real W3C service. WWW::ChackSite::Validator can be told to use another URL for it's validating. My local setup uses a local installation of the W3 validator. checksite -p mysite http://localhost --by_uri 'http://localhost:81/check?uri=%s' Good luck, Abe -- Either I need more coffee... or the "self-resume" code is somewhat unlikely to be run, unless our script is called baron_munchausen.pl. -- Jarkko Hietaniemi on p5p @ 2002-01-21
Re: Smoke [5.9.4] 27938 FAIL(X) linux 2.6.15-20-386 [debian] (i686/1 cpu)
Op een mooie winterdag (Monday 24 April 2006 00:21),schreef Abe Timmerman: > Op een mooie winterdag (Sunday 23 April 2006 17:30),schreef Steve Peters: I am so sorry, I got you mixed up with the other Steve (Hay that is) and didn't look at the report. So I assumed it was windows. Please disregard my nonsense; you are quite right. > > [EMAIL PROTECTED] wrote: > > > Automated smoke report for 5.9.4 patch 27938 > > > kirk: Intel(R) Celeron(R) CPU 2.00GHz (GenuineIntel 1994MHz) (i686/1 > > > cpu) onlinux - 2.6.15-20-386 [debian] > > > using cc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5) > > > smoketime 17 hours 54 minutes (average 1 hour 7 minutes) > > > > > > Summary: FAIL(X) > > [snip] > > > > [perlio] -DDEBUGGING -Duseithreads -Duselongdouble > > > Inconsistent test results (between TEST and harness): > > > ../ext/threads/t/free.t.FAILED--expected test 15, > > > saw test 16 > > > > What's happening above is that TEST cannot handle seeing tests come in > > out of order, while harness can. I'm scanning Test::Harness::TAP a bit, > > but it seems to be unspecified whether this is OK or not. Should TEST > > care if the tests are reported out of order? > > Windows makefiles don't have a "test_harness:" target and the > test/test-notty/ _test targets all use harness, so no need to blame TEST. > > I will raise the question once again "Why don't we use TEST on mswin32?". > > (I should probably change that message for mswin32 while Test::Smoke is > using harness for both runs) Good luck, Abe -- Nick> > Over to you, Jarkko ??? Jarkko> Urque. Hmm... I can't seem to find a patch in there anywhere. -- Nicholas Clark on p5p @ 2005-01-23
Re: Smoke [5.9.4] 27938 FAIL(X) linux 2.6.15-20-386 [debian] (i686/1 cpu)
Op een mooie winterdag (Sunday 23 April 2006 17:30),schreef Steve Peters: > [EMAIL PROTECTED] wrote: > > Automated smoke report for 5.9.4 patch 27938 > > kirk: Intel(R) Celeron(R) CPU 2.00GHz (GenuineIntel 1994MHz) (i686/1 cpu) > > onlinux - 2.6.15-20-386 [debian] > > using cc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5) > > smoketime 17 hours 54 minutes (average 1 hour 7 minutes) > > > > Summary: FAIL(X) [snip] > > [perlio] -DDEBUGGING -Duseithreads -Duselongdouble > > Inconsistent test results (between TEST and harness): > > ../ext/threads/t/free.t.FAILED--expected test 15, saw > > test 16 > > What's happening above is that TEST cannot handle seeing tests come in > out of order, while harness can. I'm scanning Test::Harness::TAP a bit, > but it seems to be unspecified whether this is OK or not. Should TEST > care if the tests are reported out of order? Windows makefiles don't have a "test_harness:" target and the test/test-notty/ _test targets all use harness, so no need to blame TEST. I will raise the question once again "Why don't we use TEST on mswin32?". (I should probably change that message for mswin32 while Test::Smoke is using harness for both runs) Good luck, Abe -- I admit that there was too much waving the chicken and too little looking at the chicken's genome in that change. -- Jarkko Hietaniemi on p5p @ 2003-08-11
Re: Test::Smoke reports archive ?
Op een zonnige zomerdag (Monday 02 August 2004 01:25), schreef Jim Cromie: > for various reasons, it would be nice to have a newsgroup, > ex this one (perl.test, but sending failed), or perhaps > [EMAIL PROTECTED], that gets full-reports for smoke-tests when > something breaks. http://www.nntp.perl.org/group/perl.daily-build.reports (aka [EMAIL PROTECTED]) We discuss the Test::Smoke software on daily-build (aka [EMAIL PROTECTED]) ... > This would save smokers from the hassle of rerunning tests to > supply a would-be fixer with the full info, as the report would already > be 'out there'. Are you suggesting we should change the smoke-reports? Any input is always welcome. Please discuss on the smokers list (most p5-porters also read it). Good luck, Abe -- Well, dereferencing that (as CvGV() would do) leads nowhere. Or, as the Ten Commandments for C Programmers quoth, "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end." -- Jarkko Hietaniemi on p5p @ 2002-05-14
Re: PERL_UNICODE and smokes
Op een druilerige winterdag (Wednesday 10 March 2004 12:00), schreef Rafael
Garcia-Suarez:
> Abe Timmerman wrote in perl.daily-build :
> >> The recent smoke failures noticed by Merijn are reproducible with
> >> the environment variables
> >> PERL_UNICODE=""
> >> LC_ALL=fr_FR.utf8 (or another utf8 locale)
> >> perlrun states clearly that PERL_UNICODE being unset is not equivalent
> >> to PERL_UNICODE="", but to PERL_UNICODE="0". I don't know how
> >> Test::Smoke sets those variables up,
> >
> > From Test::Smoke::Smoker::make_test()
> >
> > local( $ENV{PERLIO}, $ENV{LC_ALL}, $ENV{PERL_UNICODE} ) =
> > ( "", defined $ENV{LC_ALL} ? $ENV{LC_ALL} : "", "" );
>
> I was merely suggesting something like
> local( $ENV{PERLIO}, $ENV{LC_ALL}, $ENV{PERL_UNICODE} ) =
> ( "", defined $ENV{LC_ALL} ? $ENV{LC_ALL} : "",
> $ENV{LC_ALL} ? "" : undef,
> );
> because if I understand the setup correctly nothing is ever smoked
> without PERL_UNICODE="". And the default mode of operation for most
> people is with PERL_UNICODE unset.
$ENV{PERL_UNICODE} is explicitly deleted in the cases where the env is not
UTF8 (locale) and so is $ENV{LC_ALL} (unless force_c_locale was set))
$perlio can be one of 'stdio', 'perlio' or 'locale'
if ( $perlio ne 'locale' ) {
$ENV{PERLIO} = $perlio;
$self->{is_win32} and $ENV{PERLIO} .= " :crlf";
$ENV{LC_ALL} = 'C' if $self->{force_c_locale};
$ENV{LC_ALL} or delete $ENV{LC_ALL};
delete $ENV{PERL_UNICODE};
> Makes sense ?
If I understand you correctly, so much, that it already is this way...
Does the answer to "How do I investigate failures?" in the Test::Smoke FAQ
help?
Good luck,
Abe
--
Schwern> Anything else you'd like? Side order of fries? Clean your stables?
Schwern> Get you an apple? Part the Red Sea?
I guess I otherwise would sense some sarcasm in your voice but
unfortunately my sarcasm-o-meter burned out years ago from prolonged
exposure to myself.
-- Jarkko Hietaniemi on p5p @ 2002-02-03
Re: Testing complex web site
Op een druilerige winterdag (Monday 19 January 2004 19:10), schreef Gabor Szabo: > If this is OT, please point me to some better place to find an answer. > > I am looking for a way to functional and load test a web site. > > On the functional level: > Basic things can be achieved by WWW::Mechanize but I don't know yet how > to deal with Javascript in the response page. I'm working on Win32::IE::Mechanize which uses InternetExplorer.Application via Win32::OLE. It should be able to handle JavaScript. Downside is, it isn't completely compatible with WWW::Mechanize (and you'll need a windows box with IE6) If you're interested in that, I can send you a pre-alpha version, although I haven't got the time to work on it right now... Good luck, Abe -- Either I need more coffee... or the "self-resume" code is somewhat unlikely to be run, unless our script is called baron_munchausen.pl. -- Jarkko Hietaniemi on p5p @ 2002-01-21
Re: testing File::Finder
Op een winterige herfstdag (Thursday 18 December 2003 22:44), schreef Randal L. Schwartz: > > "Michael" == Michael G Schwern <[EMAIL PROTECTED]> writes: > > Michael> If you're not planning on your tests modifying the test tree at > all, Michael> you can probably just get away with having t/tree/... as a > bunch of Michael> normal files and directorys in the tarball. Don't ship a > seperate Michael> tar file, that introduces unnecessary dependencies. > > oh. duh. Yeah, that makes great sense. I can add local symlinks > and hardlinks. Oh yeah, that's just great! Exclude all them poor Win32 users! Please stick to the advice Schwern gave and ship with a true directory tree (or a script that creates one) for your testing! > I'll compute ownership out-of-band and compare it > to the test result though... I wouldn't want someone extracting > this as joebloe to fail because the uid wasn't root. :) what's 'root' ;-) Good luck, Abe -- "Jarkko Hietaniemi" is actually the code name for a whole team of Finnish super-programmers, capable of working continuously 25 hours a day without tripping each other up, and running solely only on intravenous caffeine. -- Nicholas Clark on p5p @ 2002-03-04
Re: Scrutinizing CPAN distributions (was Testing for valid path names...)
Op een zonnige zomerdag (Monday 18 August 2003 21:48), schreef Thomas Klausner: > Hi! > > Just yesterday I was thinking of something like validator.cpan.org > (parallel to validator.w3.org): > > Upload a dist and let it be checked by a future version of Module::CPANTS. > > You should get back a report and/or a "kwalitee" rating. If the kwalitee is > too low, improve your distribution (where improve means: code the module so > that it gets a high kwalitee). The hard part of this validation service is > definitly deciding how to calculate kwalitee. Perhaps the way Web Content Accessebility Guidelines is setup, is a better way to get this off to a start. I like the way Bobby (http://bobby.cast.org) checks and reports your (non)use of the guidelines. IMO it is better to have guidelines than laws carved in stone. There are already a lot of good guidelines discussed in the thread and most of them can be checked for or an indication can be given to module authors as to how to follow the guideline. Good luck, Abe -- Rafael> Actually you're thinking aloud, here ? Yes? No? Maybe? -- Jarkko Hietaniemi on p5p @ 2003-02-17
Re: Testers & PASS
Op een zonnige zomerdag (Sunday 03 August 2003 10:42), schreef Leon Brocard: > Leon Brocard sent the following bits through the ether: > > Secondly, who do I need to convince to add the "make test" results for > > PASSes too? ;-) > > So, does anyone actually have an opinion on this? If you are talking about "make test" in a rather standard module (that uses Test::Harness) the information is already there: All tests successful. Files=23, Tests=435, 12 wallclock secs ( 3.95 cusr + 1.28 csys = 5.23 CPU) or even: All tests successful, 1 test skipped. Files=24, Tests=440, 18 wallclock secs ( 5.38 cusr + 1.85 csys = 7.23 CPU) Did I misunderstand? Good luck, Abe -- I'm not convinced. By setting up mock-ups you are not testing the real thing: you are testing mock-ups. It's really emptying shotguns at decoys and concluding that yup, we are eating duck tonight. -- Jarkko Hietaniemi on p5p @ 2001-10-20
Re: Test-Smoke questions
Op een zonnige zomerdag (Friday 27 June 2003 20:26), schreef John Peacock:
> Abe Timmerman wrote:
> > T::S::S::Hardlink uses *all* of the source directory, so if you are using
> > a working copy (under version control) the MANIFEST check will report all
> > .svn stuff in the report. I'd use rsync on local directories (resulting
> > in something like):
> >
> > rsync -a --delete --exclude '.svn' working_dir/. .
> >
> > This can be configured from 'configsmoke.pl' (Just make sure that the
> > rsync source ends with a slash [or slash-dot].)
>
> That's a better way to go then. However, I just tried it and
> configsmoke.pl doesn't quote the rsync options properly, so the --exclude
> option is ignored (and the .svn files copied anyway). I'll try and fix
> that and send you a patch.
It would be nice to be able to have quoted arguments, although I cannot see
any reason for it to go wrong...
Okay, now I see, you have just found an error in F (patch
below) I'll try and put a new release on CPAN this weekend.
Please change 'opt' to 'opts' in smokecurrent_config
Here's the patch to prevent that from happening again:
Index: configsmoke.pl
===
--- configsmoke.pl (revision 186)
+++ configsmoke.pl (working copy)
@@ -208,7 +208,7 @@
alt => [ ],
dft => whereis( 'rsync' ),
},
-opt => {
+opts => {
msg => 'Which arguments should be used for rsync?',
alt => [ ],
dft => '-az --delete',
@@ -644,7 +644,7 @@
$arg = 'rsync';
$config{ $arg } = prompt( $arg );
-$arg = 'opt';
+$arg = 'opts';
$config{ $arg } = prompt( $arg );
last SYNCER;
Good luck,
Abe
--
We might as well document that in future sort() in scalar context *may*
make flying pigs in pink tutus spring forth from one's nostrils, too :-)
For 5.8.0 I'm happy just to document the current behaviour.
-- Jarkko Hietaniemi on p5p @ 2002-06-12
Re: Test-Smoke questions
Op een zonnige zomerdag (Friday 27 June 2003 17:19), schreef John Peacock: > Now that I have a subversion repository of the APC (All Perl Changes) on a > machine that is largely unloaded, I can set up a smoke process nightly. In > order to do that, I have a couple of questions: > > 1) When running `perl Makefile.pl` it asks me where to install the code; > I'm guessing that this is so it doesn't live in the ordinary Perl lib tree. Yup. > As long as that directory is in the path for the user running the smokes, > that is fine, right? There is a "use lib catdir( $FindBin::Bin, 'lib' );" for all the scripts and the startup script (smokecurrent.sh) adds the directory to the path. > 2) Since I already will have a fully synced subversion repository, I don't > need most of the functionality of Test::Smoke::Syncer. Has anyone already > started work on Test::Smoke::Syncer::Subversion yet, or am I free to play > with it? Sounds like a good idea, if I find some spare time I'll give that a shot, but patches are also welcome :) > I am guessing that I will use T::S::S::Hardlink with a source of > a Subversion working copy. T::S::S::Hardlink uses *all* of the source directory, so if you are using a working copy (under version control) the MANIFEST check will report all .svn stuff in the report. I'd use rsync on local directories (resulting in something like): rsync -a --delete --exclude '.svn' working_dir/. . This can be configured from 'configsmoke.pl' (Just make sure that the rsync source ends with a slash [or slash-dot].) > 3) Once I am smoking bleadperl, I'll add the 5.8.x smoke as well (using > `svn switch` on my hdir and T::S::S::Hardlink again. Comments??? you can always edit the resulting smoke58x.sh shellscript after 'configsmoke.pl' to add the 'svn switch' before 'smokeperl.pl' is started. The problem with a single source-dir could be if your 5.9.0 smoke overlaps your 5.8.x smoke. Good luck, Abe -- "Crashes Perl (or Used To)" is not a really useful classifying criterion, it's about as useful as "the number of characters in the test is divisible by 73". -- Jarkko Hietaniemi on p5p @ 2001-10-30
