<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'> > That'd be cool if it correlates. <BR>
> I'll go try p137 again both ways. <BR><BR>It does!<BR>
Standalone p137 and dynamic p137 have very different results.<BR>
<BR>
- Jay<BR><BR>
<BLOCKQUOTE>
<HR id=EC_stopSpelling>
From: jayk123@hotmail.com<BR>To: wagner@elegosoft.com; m3devel@elegosoft.com<BR>Subject: RE: [M3devel] Tinderbox tests on NT386<BR>Date: Sun, 4 May 2008 14:22:57 +0000<BR><BR>
<META content="Microsoft SafeHTML" name=Generator>
<STYLE>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Tahoma;}
</STYLE>
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 -0700<BR>@@ -1,3 +1,418 @@<BR>+************************ ERROR: 282863103 instead of 819734015<BR>+************************ ERROR: 14427647 instead of 819734015<BR>...<BR>lots<BR><BR>You never saw that Olaf?<BR><BR>I should have printed the test names below, it's too hard to read 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 libm3/m3core but current version dynamically links.<BR>That'd be cool if it correlates -- if p137 and the bitmap stuff are the same problem.<BR>I'll go try p137 again both ways.<BR><BR> - Jay<BR>
<BLOCKQUOTE>
<HR id=EC_EC_stopSpelling>
From: jayk123@hotmail.com<BR>To: wagner@elegosoft.com; m3devel@elegosoft.com<BR>Date: Sun, 4 May 2008 14:17:28 +0000<BR>Subject: Re: [M3devel] Tinderbox tests on NT386<BR><BR>
<STYLE>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Tahoma;}
</STYLE>
Here is a QUICK rundown.<BR><BR>p004 I /assume/ this is the same on all platforms<BR> but didn't check<BR><BR>p051 extra print out when building specific to NT386,<BR> fixed, but at great loss of diagnosability IF<BR> there are errors in compiling C code<BR><BR>Specifically, given<BR> cl -nologo -c foo.c bar.c<BR>the compiler prints<BR>foo.c<BR>bar.c<BR><BR>to the same channel as errors (stderr or stdout)<BR>So when running the tests, NT386.common has a hack to throw<BR>out all C compiler output.<BR><BR>p116b floating point issue, probably same on all platforms<BR>p126 ditto<BR>p172 ditto<BR>p186 ditto<BR><BR>p204 compiler bug<BR> I think this also fails on other platforms but obviously<BR> differently; needs investigation<BR><BR>p205 was failing but I put in a fix and then Tony put in a better fix<BR> <BR>p206 I think this fails the same on all platforms, but I <BR> I think it behaves correctly and just update the<BR> std{out,err}.{pgm,build} files; since it is a compilation<BR> failure, it should be an 'e' instead of 'p', not<BR> a big deal I think<BR><BR>p207 probably fall out from longint not being 64 bits<BR> probably should disable just for this platform <BR><BR>r001 This test works in general but is a problem for the<BR> Tinderbox in general. LINUXLIBC6 and NT386 should be<BR> passing, but I think probably it should be turned off.<BR> In particular, the way programs exit when they<BR> fail an assertion and/or have an unhandled exception<BR> varies by platform, in terms of what they actually print.<BR><BR>r002 needs investigation; I think it's an infinite recursion<BR> or just uses a lot of stack, and I THINK I saw it fail<BR> on other platforms <BR><BR>r003 I hadn't looked at this AT ALL but probably the same as r001,<BR> except more interesting?<BR> There is a test that catches an assertion failure, maybe<BR> do that here?<BR> As well, there is the annoying idea of making per-platform <BR> std* files. Hard to maintain.<BR> <BR>r004 ditto -- since there are four of these, and potentially more,<BR> maybe worth coming up with something<BR><BR>Something I considered, but rejected, back when I thought r001<BR>was the only one, is a runtime switch <A href="mailto:M3@consistentAbort">M3@consistentAbort</A> or<BR>somesuch that will just cleanly exit(0) or exit(1) in these cases,<BR>and not print a callstack. I don't want to foul up the<BR>system TOO much for the sake of testing, but testability<BR>is an expected design goal...<BR><BR>Again, this is an issue across platforms.<BR> LINUXLIBC6 seems to print something slightly differently<BR> every time you run these. Test.common has a gross workaround.<BR> The checked in std* files are from FreeBSD.<BR><BR>e020 unknown so far<BR><BR>e026 was a problem on all platforms and should be ok now;<BR> was a compiler bug, I fixed<BR><BR>e029 unknown so far<BR><BR>I think p209 and p210 are the most important currently.<BR>And then maybe e020, e029.<BR><BR>I expect to be "out" all of Sunday.<BR><BR>The Tinderbox SHOULD be OK now.<BR>Sorry...<BR> <BR><BR> - Jay<BR><BR><BR><BR>
<HR id=EC_EC_stopSpelling>
<BR>> Date: Sun, 4 May 2008 15:30:40 +0200<BR>> From: wagner@elegosoft.com<BR>> To: m3devel@elegosoft.com<BR>> Subject: [M3devel] Tinderbox tests on NT386<BR>> <BR>> In case anybody wonders about<BR>> <BR>> http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html<BR>> <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 current<BR>> problems. There have been so many changes that I'm unable to keep<BR>> up with them, and some things seem to be broken.<BR>> <BR>> Except for the problems in m3tests, the rest of the tinderbox<BR>> regression test framework seems to be working now for regular<BR>> regression tests on Windows XP with Cygwin. Some initialization<BR>> scripts are needed for running them, but that was to be expected.<BR>> <BR>> The m3tests reports for the last two days for all target platforms<BR>> in 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.<BR>> <BR>> Olaf<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></BLOCKQUOTE></BLOCKQUOTE></body>
</html>