<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>Olaf, You have p137 failing now, which is/was consistent with me.<BR><BR>And still p051 failing for you. I fixed that, but<BR> the fix is half in NT386.common, and half in m3tests. You take that<BR> for each build? The situation there is/was kind of<BR> unfortunate -- all compiler output is quashed, errors and all.<BR>
If we could have per-platform std* files,<BR> this would be one to do that for. You know,<BR> if stdout.pgm.PLATFORM exists, use it, otherwise stdout.pgm.<BR> Problem is whenever the output changes, updating them all.<BR>
<BR>
- Jay<BR><BR><BR>
<HR id=stopSpelling>
<BR>
> Date: Sun, 4 May 2008 16:49:26 +0200<BR>> From: wagner@elegosoft.com<BR>> To: jayk123@hotmail.com<BR>> CC: m3devel@elegosoft.com<BR>> Subject: RE: [M3devel] Tinderbox tests on NT386<BR>> <BR>> Quoting Jay <jayk123@hotmail.com>:<BR>> <BR>> > I'm also seeing lots of failures in p137<BR>> ><BR>> > --- p137 --- bit insert and extract<BR>> > --- ../src/p1/p137/stderr.pgm 2008-05-04 00:10:01.925067200 -0700+++ <BR>> > ../src/p1/p137/NT386/stderr.pgm 2008-05-04 03:59:42.382247900 <BR>> > -0700@@ -1,3 +1,418 @@+************************ ERROR: 282863103 <BR>> > instead of 819734015+************************ ERROR: 14427647 <BR>> > instead of 819734015...<BR>> > lotsYou never saw that Olaf?<BR>> <BR>> p137 was OK on 2008-05-01. Use<BR>> <BR>> http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html<BR>> <BR>> as a reference; I won't overwrite that anymore now.<BR>> Current results of m3tests will be reported to<BR>> <BR>> http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-31.html<BR>> <BR>> soon (sorry for the wrong dates, I'm re-using existing workspaces<BR>> here; it would take too long otherwise).<BR>> <BR>> I'll be out soon, but will have another look later this evening how<BR>> things develop.<BR>> <BR>> Olaf<BR>> <BR>> <BR>> > I should have printed the test names below, it's too hard to read <BR>> > with just numbers..<BR>> > Anyway, just looking busy I guess, no matter, we'll get around to them..<BR>> > (And sorry about the Win32 bitmap stuff, I haven't forgotten...)<BR>> ><BR>> > Hm..maybe related? Older version of m3tests statically links to <BR>> > libm3/m3core but current version dynamically links.<BR>> > That'd be cool if it correlates -- if p137 and the bitmap stuff are <BR>> > the same problem.<BR>> > I'll go try p137 again both ways.<BR>> > - Jay<BR>> ><BR>> ><BR>> > From: jayk123@hotmail.comTo: wagner@elegosoft.com; <BR>> > m3devel@elegosoft.comDate: Sun, 4 May 2008 14:17:28 +0000Subject: <BR>> > Re: [M3devel] Tinderbox tests on NT386<BR>> ><BR>> ><BR>> > Here is a QUICK rundown.p004 I /assume/ this is the same on all <BR>> > platforms but didn't checkp051 extra print out when building <BR>> > specific to NT386, fixed, but at great loss of diagnosability IF <BR>> > there are errors in compiling C codeSpecifically, given cl <BR>> > -nologo -c foo.c bar.cthe compiler printsfoo.cbar.cto the same <BR>> > channel as errors (stderr or stdout)So when running the tests, <BR>> > NT386.common has a hack to throwout all C compiler output.p116b <BR>> > floating point issue, probably same on all platformsp126 dittop172 <BR>> > dittop186 dittop204 compiler bug I think this also fails on other <BR>> > platforms but obviously differently; needs investigationp205 was <BR>> > failing but I put in a fix and then Tony put in a better fix p206 I <BR>> > think this fails the same on all platforms, but I I think it <BR>> > behaves correctly and just update the std{out,err}.{pgm,build} <BR>> > files; since it is a compilation failure, it should be an 'e' <BR>> > instead of 'p', not a big deal I thinkp207 probably fall out <BR>> > from longint not being 64 bits probably should disable just for <BR>> > this platform r001 This test works in general but is a problem for <BR>> > the Tinderbox in general. LINUXLIBC6 and NT386 should be <BR>> > passing, but I think probably it should be turned off. In <BR>> > particular, the way programs exit when they fail an assertion <BR>> > and/or have an unhandled exception varies by platform, in terms <BR>> > of what they actually print.r002 needs investigation; I think it's <BR>> > an infinite recursion or just uses a lot of stack, and I THINK I <BR>> > saw it fail on other platforms r003 I hadn't looked at this AT <BR>> > ALL but probably the same as r001, except more interesting? <BR>> > There is a test that catches an assertion failure, maybe do that <BR>> > here? As well, there is the annoying idea of making <BR>> > per-platform std* files. Hard to maintain. r004 ditto -- since <BR>> > there are four of these, and potentially more, maybe worth <BR>> > coming up with somethingSomething I considered, but rejected, back <BR>> > when I thought r001was the only one, is a runtime switch <BR>> > M3@consistentAbort orsomesuch that will just cleanly exit(0) or <BR>> > exit(1) in these cases,and not print a callstack. I don't want to <BR>> > foul up thesystem TOO much for the sake of testing, but <BR>> > testabilityis an expected design goal...Again, this is an issue <BR>> > across platforms. LINUXLIBC6 seems to print something slightly <BR>> > differently every time you run these. Test.common has a gross <BR>> > workaround. The checked in std* files are from FreeBSD.e020 unknown <BR>> > so fare026 was a problem on all platforms and should be ok now; <BR>> > was a compiler bug, I fixede029 unknown so farI think p209 and p210 <BR>> > are the most important currently.And then maybe e020, e029.I expect <BR>> > to be "out" all of Sunday.The Tinderbox SHOULD be OK now.Sorry... <BR>> > - Jay<BR>> ><BR>> >> Date: Sun, 4 May 2008 15:30:40 +0200> From: wagner@elegosoft.com> <BR>> >> To: m3devel@elegosoft.com> Subject: [M3devel] Tinderbox tests on <BR>> >> NT386> > In case anybody wonders about> > <BR>> >> http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html> > <BR>> >> and following reports, I'm currently trying to run the m3tests on> <BR>> >> NT386 in an older version to get a usable reference for the <BR>> >> current> problems. There have been so many changes that I'm unable <BR>> >> to keep> up with them, and some things seem to be broken.> > Except <BR>> >> for the problems in m3tests, the rest of the tinderbox> regression <BR>> >> test framework seems to be working now for regular> regression <BR>> >> tests on Windows XP with Cygwin. Some initialization> scripts are <BR>> >> needed for running them, but that was to be expected.> > The <BR>> >> m3tests reports for the last two days for all target platforms> in <BR>> >> the tinderbox are not correct (at least, if they show no errors);> <BR>> >> there have been some structural changes and more things need to be> <BR>> >> adapted. Jay Krell is working on it.> > Olaf> -- > Olaf Wagner -- <BR>> >> elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Gebäude 12, <BR>> >> 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 <BR>> >> 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | <BR>> >> Geschäftsführer: Olaf Wagner | Sitz: Berlin> Handelregister: <BR>> >> Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194><BR>> <BR>> <BR>> <BR>> -- <BR>> Olaf Wagner -- elego Software Solutions GmbH<BR>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<BR>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<BR>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin<BR>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<BR>> <BR><BR></body>
</html>