Re: Smoke [5.8.7] 25589 FAIL(m) MSWin32 WinXP/.Net SP2 (x86/2 cpu)
On Fri, Sep 23, 2005 at 09:14:09PM +0100, Nicholas Clark wrote:
And between last time and this one I didn't think that there were any
dangerous changes. Given that, and the lack of any helpful log on this
smoke report, I'm stuck as to what I messed up that needs fixing.
I think I failed to spot a change that I needed to integrate. Hopefully
25592 fixes it. I think that Steve Hay's 5.8.7 smoker only works weekdays,
so if someone else is able to test build maint on Windows I'd be most
grateful.
Nicholas Clark
Change 25592 by [EMAIL PROTECTED] on 2005/09/24 09:56:14
Integrate:
[ 25110]
no code before declarations!
Affected files ...
... //depot/maint-5.8/perl/doio.c#52 integrate
Differences ...
//depot/maint-5.8/perl/doio.c#52 (text)
@@ -1461,9 +1461,10 @@
Perl_croak(aTHX_ exec? I'm not *that* kind of operating system);
#else
if (sp mark) {
+ char **a;
+ const char *tmps = Nullch;
Newx(PL_Argv, sp - mark + 1, char*);
- char **a = PL_Argv;
- const char *tmps = Nullch;
+ a = PL_Argv;
while (++mark = sp) {
if (*mark)
[EMAIL PROTECTED] [perl]$
kill mv-if-diff?
The distribution contains a shell script mv-if-diff, which does what it says. The Makefile uses it to avoid touching the timestamps on automatically generated files, if they've not actually changed. For example, lib/Config.pm I notice that on my local checkout of maint, when I do a clean rebuild, lib/unicore/mktables is being run 7 times. I also observe that sometimes when I edit files and rebuild, later files needlessly get rebuilt, probably because make thinks something is out of date, something that never gets updated, probably because it's not being touched, due to mv-if-diff, and there are non-file targets in the dependency tree. Parallel makes are also broken. I wonder if all this is related. Should we just get rid of mv-if-diff, and let make be the sole arbiter of what needs updating? And trust that if make wants to rebuild something, it should. I think that doing this would make our rebuilds cleaner, and make it easier to work out the correct set of dependencies such that we can make parallel makes work. Nicholas Clark
Re: kill mv-if-diff?
On 9/24/05, Nicholas Clark [EMAIL PROTECTED] wrote: I also observe that sometimes when I edit files and rebuild, later files needlessly get rebuilt, probably because make thinks something is out of date, something that never gets updated, probably because it's not being I don't get your reasoning here... touched, due to mv-if-diff, and there are non-file targets in the dependency tree. Anyway, I've never looked at this that much, but if someone can figure out solutions to things getting run too many times, good :) (that could be added in perltodo as well)
Re: kill mv-if-diff?
On Sat, Sep 24, 2005 at 06:44:57PM +0200, Rafael Garcia-Suarez wrote: On 9/24/05, Nicholas Clark [EMAIL PROTECTED] wrote: I also observe that sometimes when I edit files and rebuild, later files needlessly get rebuilt, probably because make thinks something is out of date, something that never gets updated, probably because it's not being I don't get your reasoning here... Sorry, yes, I failed to explain properly. IIRC the following happens: I edit (say) sv.c I run make make reasons that a lot of things are out of date. Specifically, 1: all the Unicode tables are out of date with respect to lib/Config.pm 2: because that in turn is out of date w.r.t. miniperl 3: because that is out of date w.r.t. sv.o 4: because that is out of date w.r.t. sv.c So the make reruns the build steps for 4,3,2,1 Only mv-if-diff kicks in, and lib/Config.pm isn't changed (make never checks if a step actually changes the timestamp on a file) So if I re-run make, make sees that lib/Config.pm is *still* out of date w.r.t. miniperl, so (correctly) figures that steps 2 and 1 need re-running. I stop the insanity with touch lib/Config.pm; make and make re-runs the Unicode tables generation one last time, and then all is happy. Hence why I think that mv-if-diff is counterproductive. Nicholas Clark
Re: kill mv-if-diff?
On 9/24/05, Nicholas Clark [EMAIL PROTECTED] wrote: IIRC the following happens: I edit (say) sv.c I run make make reasons that a lot of things are out of date. Specifically, 1: all the Unicode tables are out of date with respect to lib/Config.pm 2: because that in turn is out of date w.r.t. miniperl ah yes. 3: because that is out of date w.r.t. sv.o 4: because that is out of date w.r.t. sv.c So the make reruns the build steps for 4,3,2,1 Only mv-if-diff kicks in, and lib/Config.pm isn't changed Ok. Given that nothing prevents people from running make perl directly if they don't want to rebuild tables, maybe we can simplify mv-if-diff out.
Smoke [5.8.7] 25595 FAIL(m) MSWin32 WinXP/.Net SP2 (x86/2 cpu)
Automated smoke report for 5.8.7 patch 25595 Mugwump.uk.radan.com: Intel(R) Pentium(R) 4 CPU 3.40GHz(~3391 MHz) (x86/2 cpu) onMSWin32 - WinXP/.Net SP2 using ? unknown cc version smoketime 17 minutes 23 seconds (average 52.150 seconds) Summary: FAIL(m) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep 25595 Configuration (common) -DINST_TOP=$(INST_DRV)\Smoke\doesntexist --- - m m m m -Dusemymalloc m m -Duselargefiles m m -Duselargefiles -Dusemymalloc m m -Duseithreads -Uuseimpsys m m -Duseithreads -Uuseimpsys -Dusemymalloc m m -Duseithreads -Uuseimpsys -Duselargefiles m m -Duseithreads -Uuseimpsys -Duselargefiles -Dusemymalloc m m -Duseithreads m m -Duseithreads -Duselargefiles | +- -DDEBUGGING +--- no debugging Locally applied patches: MAINT24637 -- Report by Test::Smoke v1.19_72 build 895 running on perl v5.9.3 (Reporter v0.026 / Smoker v0.026) Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: kill mv-if-diff?
On Sat, Sep 24, 2005 at 04:31:45PM +0100, Nicholas Clark wrote: The distribution contains a shell script mv-if-diff, which does what it says. The Makefile uses it to avoid touching the timestamps on automatically generated files, if they've not actually changed. For example, lib/Config.pm I notice that on my local checkout of maint, when I do a clean rebuild, lib/unicore/mktables is being run 7 times. I also observe that sometimes when I edit files and rebuild, later files needlessly get rebuilt, probably because make thinks something is out of date, something that never gets updated, probably because it's not being touched, due to mv-if-diff, and there are non-file targets in the dependency tree. Parallel makes are also broken. I wonder if all this is related. Should we just get rid of mv-if-diff, and let make be the sole arbiter of what needs updating? And trust that if make wants to rebuild something, it should. I think that doing this would make our rebuilds cleaner, and make it easier to work out the correct set of dependencies such that we can make parallel makes work. I had fixed one bug with parallel make that was somewhat effected by mv-if-diff, but the biggest issue was just having correct dependencies in the Makefile. My thoughts are that mv-if-diff is just a symptom of a different problem in the Makefile where more targets and dependencies are needed. Steve Peters [EMAIL PROTECTED]
Re: kill mv-if-diff?
Nicholas Clark [EMAIL PROTECTED] writes: The distribution contains a shell script mv-if-diff, which does what it says. The Makefile uses it to avoid touching the timestamps on automatically generated files, if they've not actually changed. For example, lib/Config.pm I notice that on my local checkout of maint, when I do a clean rebuild, lib/unicore/mktables is being run 7 times. I also observe that sometimes when I edit files and rebuild, later files needlessly get rebuilt, probably because make thinks something is out of date, something that never gets updated, probably because it's not being touched, due to mv-if-diff, and there are non-file targets in the dependency tree. Parallel makes are also broken. I wonder if all this is related. It sounds like the problem isn't the existence of mv-if-diff, but rather a lack of capabilities in it. Shouldn't it touch the files that it doesn't need to replace? Then it would touch lib/Config.pm and all the right things would happen. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: kill mv-if-diff?
On 9/24/05, Nicholas Clark [EMAIL PROTECTED] wrote: The distribution contains a shell script mv-if-diff, which does what it says. The Makefile uses it to avoid touching the timestamps on automatically generated files, if they've not actually changed. For example, lib/Config.pm I notice that on my local checkout of maint, when I do a clean rebuild, lib/unicore/mktables is being run 7 times. I think this is the same problem that lead to patches 24004, 24056 (and sortof 24320). (Just in case you've forgotten.) Yves -- perl -Mre=debug -e /just|another|perl|hacker/
Smoke [5.8.7] 25592 FAIL(XF) openbsd 3.7 (i386/1 cpu)
Automated smoke report for 5.8.7 patch 25592 mccoy.peters.homeunix.org: Intel Pentium III (GenuineIntel 686-class, 512KB L2 cache) (i386/1 cpu) onopenbsd - 3.7 using cc version 3.3.5 (propolice) smoketime 10 hours 33 minutes (average 1 hour 3 minutes) Summary: FAIL(XF) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep 25592 Configuration (common) none --- - O - O - -Uuseperlio O O O O O O O O -Duse64bitint O O O X -Duseithreads O F O O -Duseithreads -Duse64bitint | | | +- PERLIO = perlio -DDEBUGGING | | +--- PERLIO = stdio -DDEBUGGING | +- PERLIO = perlio +--- PERLIO = stdio Failures: [perlio] -DDEBUGGING -Duseithreads Inconsistent test results (between TEST and harness): ../lib/ExtUtils/t/Constant.tFAILED at test 103 [perlio] -Duseithreads -Duse64bitint ../lib/ExtUtils/t/Constant.tFAILED 229-272 -- Report by Test::Smoke v1.19#716 running on perl 5.8.6 (Reporter v0.016 / Smoker v0.015)
Re: Smoke [5.8.7] 25589 FAIL(m) MSWin32 WinXP/.Net SP2 (x86/2 cpu)
On Sat, Sep 24, 2005 at 12:45:35PM +0100, Nicholas Clark wrote: On Fri, Sep 23, 2005 at 09:14:09PM +0100, Nicholas Clark wrote: And between last time and this one I didn't think that there were any dangerous changes. Given that, and the lack of any helpful log on this smoke report, I'm stuck as to what I messed up that needs fixing. I think I failed to spot a change that I needed to integrate. Hopefully 25592 fixes it. I think that Steve Hay's 5.8.7 smoker only works weekdays, so if someone else is able to test build maint on Windows I'd be most grateful. I pulled down a perl-5.8.x at 25596, and it built just fine on Win32. There does seem to be a bit of a problem with the Win32 Makefile, though. Several files are getting getting compiled twice. What happens is all the files that do not dependin on the Win32 config.h are built. conofig.h is created and the rest of the core files are built. Then, config.h is recreated forcing a recompile of all the files that depend on config.h. Steve Peters [EMAIL PROTECTED]
Re: kill mv-if-diff?
On Sep 24, 2005, at 2:22 PM, Russ Allbery wrote: Nicholas Clark [EMAIL PROTECTED] writes: The distribution contains a shell script mv-if-diff, which does what it says. The Makefile uses it to avoid touching the timestamps on automatically generated files, if they've not actually changed. For example, lib/Config.pm I notice that on my local checkout of maint, when I do a clean rebuild, lib/unicore/mktables is being run 7 times. I also observe that sometimes when I edit files and rebuild, later files needlessly get rebuilt, probably because make thinks something is out of date, something that never gets updated, probably because it's not being touched, due to mv-if-diff, and there are non-file targets in the dependency tree. Parallel makes are also broken. I wonder if all this is related. It sounds like the problem isn't the existence of mv-if-diff, but rather a lack of capabilities in it. Shouldn't it touch the files that it doesn't need to replace? Then it would touch lib/Config.pm and all the right things would happen. The root cause is attempting to manage two pieces of information (the date a file was changed, and the date it was confirmed up-to-date) with one storage slot. Recognizing that a file may be current even though it hasn't changed since its prerequisites have is an optimization, which in traditional make usage is ignored -- being current is equated with having been modified, so there's only one date to store. If I were designing a Mac-specific implementation I might use the file backup date (which is stored with other file metadata) as an up-to-date stamp, but unless I'm mistaken a portable solution would require an external data store. Or you can just drop the broken optimization and always touch up-to-date files, which is fully portable and guaranteed to work. :-) Josh
Re: lib/test/simple/t/create.t help with VMS issue needed.
Michael G Schwern wrote: On Sat, Aug 13, 2005 at 10:33:45PM -0400, John E. Malmberg wrote: Test 7 is failing because normally on VMS, unless you specify otherwise, you get exclusive access to the file, so the second open is failing. The logical name DECC$FILE_SHARING defined as ENABLE will change VMS behavior to that of UNIX which will allow test 7 to pass. I can probably come up with some code to have the script on VMS make sure that that value is set and to clear it on exit. Test 8 is more of a problem. The issue is that the buffers for the other stream written by the new_tb-output(some_file) have not made it to disk, so they can not yet be read by the new input stream to pass the test. There does not seem to be a method of explicitly closing or flushing the output stream being written to by Test::Builder. I was about to commit the test fix for this and then I realized that Test::Builder unbuffers its newly created output filehandles. Everything should be written to disk immediately. If not then there's a bug either in Test::Builder's autoflush logic or in Perl. Could you have another look at this? Test::Builder _new_fh() and _autoflush() will be of some interest. _autoflush is setting $| which should cause a flush. The only call to fsync() that I can find that gets compiled in on the VMS build is in vms/vms.c routine Perl_my_flush() which has a macro alias of my_flush(), and a macro alias Fflush(). Setting a breakpoint on vms/Perl_my_flush() on the debugger shows that it is not called, and this is the only way that the I/O will be written to disk. Putting a break on pp_hot/Perl_pp_print() shows that it recognizes that the $| variable was set, and it calls PerlIO_flush. PerlIO_flush looks up a function in a table and ends up calling PerlIOBuf_flush(). PerlIOBuf_flush() writes the internal buffer to the C library internal buffer. It then calls PerlIO_flush again and this time the function lookup is to a routine that does nothing by design. Nothing ever called an fsync() call, so nothing is guaranteed to get to the disk. It seems to work ok flushing I/O to the terminal. A scan of the source code shows that my_flush or Perl_my_flush is only referenced in VMS.C Fflush is only referenced in ext/IO/io.c, and an alias of PerlSIO_fflush. It appears that that PerlSIO_fflush() is called by PerlIOStdio_flush() only. So it appears the problem is that nothing is calling fsync(), but I am not sure what needs to be changed to fix this. I also do not know if this affects anything other than VMS. -John [EMAIL PROTECTED] Personal Opinion Only
Re: lib/test/simple/t/create.t help with VMS issue needed.
Michael G Schwern wrote: On Sat, Aug 13, 2005 at 10:33:45PM -0400, John E. Malmberg wrote: Test 7 is failing because normally on VMS, unless you specify otherwise, you get exclusive access to the file, so the second open is failing. The logical name DECC$FILE_SHARING defined as ENABLE will change VMS behavior to that of UNIX which will allow test 7 to pass. I can probably come up with some code to have the script on VMS make sure that that value is set and to clear it on exit. Test 8 is more of a problem. The issue is that the buffers for the other stream written by the new_tb-output(some_file) have not made it to disk, so they can not yet be read by the new input stream to pass the test. There does not seem to be a method of explicitly closing or flushing the output stream being written to by Test::Builder. I was about to commit the test fix for this and then I realized that Test::Builder unbuffers its newly created output filehandles. Everything should be written to disk immediately. If not then there's a bug either in Test::Builder's autoflush logic or in Perl. Could you have another look at this? Test::Builder _new_fh() and _autoflush() will be of some interest. Sure, I can take a look. I also discovered while doing research on how to add the methods to set/get the current VMS C Library behavior that VMS was not configuring d_fsync, and with out a fsync() call, C I/O is not flushed down to the disk. fsync() is being called in VMS.C in one place, but I do not have time to look for a while. -John [EMAIL PROTECTED] Personal Opinion Only
[ANNOUNCE] Test::Simple/More/Builder 0.61
http://www.pobox.com/~schwern/src/Test-Simple-0.61.tar.gz or http://svn.schwern.org/CPAN/Test-Simple/trunk or a CPAN mirror near you. A small raft of small fixes have happened between 0.60 and 0.61 as well as a few new features. New Features: * Test::Builder::Module has been added to help test module authors. It implements the oft requested import() method to parse plan information on the use line just as Test::More does. If you base your testing module on Test::Builder::Module it will no longer need to rely on Test::More to set the plan. * Added the oft requested BAIL_OUT() function to Test::More. * Added a no_diag() method to Test::Builder. * The standard failure diagnostics now include the name of the test for easier recognition when run through Test::Harness. * cmp_ok(), like() and unlike() will now warn if given uninitialized values. * cmp_ok() will now throw warnings if the given comparison warrents it. For example, cmp_ok(2, '==', 'foo') will warn about 'foo' not being numeric. * Test will now report *both* the number of tests failed and if the wrong number of tests was run. Previously if both occured it would only report the latter. * For the purposes of calculating the exit code, missing or extra tests are not considered failures. Should there be no failures but the wrong number of tests the exit code will be 254. Deprecations: * The no_diag option to Test::More has been deprecated. Use Test::More-builder-no_diag(1) instead. * Test::Builder-BAILOUT is now BAIL_OUT to match all the other naming conventions. BAILOUT has been deprecated. Bug fixes: * A large number of bugs related to overloaded objects have been fixed. See the change log below for details. 0.61 Fri Sep 23 23:26:05 PDT 2005 - create.t was trying to read from a file before it had been closed (and thus the changes may not have yet been written). * is_deeply() would call stringification methods on non-object strings which happened to be the name of a string overloaded class. [rt.cpan.org 14675] 0.60_02 Tue Aug 9 00:27:41 PDT 2005 * Added Test::Builder::Module. - Changed Test::More and Test::Simple to use Test::Builder::Module - Minor Win32 testing nit in fail-more.t * Added no_diag() method to Test::Builder and changed Test::More's no_diag internals to use that. [rt.cpan.org 8655] * Deprecated no_diag() as an option to use Test::More. Call the Test::Builder method instead. 0.60_01 Sun Jul 3 18:11:58 PDT 2005 - Moved the docs around a little to better group all the testing functions together. [rt.cpan.org 8388] * Added a BAIL_OUT() function to Test::More [rt.cpan.org 8381] - Changed Test::Builder-BAILOUT to BAIL_OUT to match other method's naming conventions. BAILOUT remains but is deprecated. * Changed the standard failure diagnostics to include the test name. [rt.cpan.org 12490] - is_deeply() was broken for overloaded objects in the top level in 0.59_01. [rt.cpan.org 13506] - String overloaded objects without an 'eq' or '==' method are now handled in cmp_ok() and is(). - cmp_ok() will now treat overloaded objects as numbers if the comparison operator is numeric. [rt.cpan.org 13156] - cmp_ok(), like() and unlike will now throw uninit warnings if their arguments are undefined. [rt.cpan.org 13155] - cmp_ok() will now throw warnings as if the comparison were run normally, for example cmp_ok(2, '==', 'foo') will warn about 'foo' not being numeric. Previously all warnings in the comparison were supressed. [rt.cpan.org 13155] - Tests will now report *both* the number of tests failed and if the wrong number of tests were run. Previously if tests failed and the wrong number were run it would only report the latter. [rt.cpan.org 13494] - Missing or extra tests are not considered failures for the purposes of calculating the exit code. Should there be no failures but the wrong number of tests the exit code will be 254. - Avoiding an unbalanced sort in eq_set() [bugs.perl.org 36354] - Documenting that eq_set() doesn't deal well with refs. - Clarified how is_deeply() compares a bit. * Once again working on 5.4.5. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Insulting our readers is part of our business model. http://somethingpositive.net/sp07122005.shtml
