[M3devel] Tinderbox tests on NT386

Sun May 4 16:25:26 CEST 2008

 > That'd be cool if it correlates. 
 > I'll go try p137 again both ways.  It does!
Standalone p137 and dynamic p137 have very different results.

 - Jay

From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comSubject: RE: [M3devel] Tinderbox tests on NT386Date: Sun, 4 May 2008 14:22:57 +0000

I'm also seeing lots of failures in p137 --- p137 --- bit insert and extract--- ../src/p1/p137/stderr.pgm 2008-05-04 00:10:01.925067200 -0700+++ ../src/p1/p137/NT386/stderr.pgm 2008-05-04 03:59:42.382247900 -0700@@ -1,3 +1,418 @@+************************ ERROR: 282863103 instead of 819734015+************************ ERROR: 14427647 instead of 819734015...lotsYou never saw that Olaf?I should have printed the test names below, it's too hard to read with just numbers..Anyway, just looking busy I guess, no matter, we'll get around to them..(And sorry about the Win32 bitmap stuff, I haven't forgotten...) Hm..maybe related? Older version of m3tests statically links to libm3/m3core but current version dynamically links.That'd be cool if it correlates -- if p137 and the bitmap stuff are the same problem.I'll go try p137 again both ways. - Jay

From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Sun, 4 May 2008 14:17:28 +0000Subject: Re: [M3devel] Tinderbox tests on NT386

Here is a QUICK rundown.p004 I /assume/ this is the same on all platforms     but didn't checkp051 extra print out when building specific to NT386,     fixed, but at great loss of diagnosability IF     there are errors in compiling C codeSpecifically, given  cl -nologo -c foo.c bar.cthe compiler printsfoo.cbar.cto the same channel as errors (stderr or stdout)So when running the tests, NT386.common has a hack to throwout all C compiler output.p116b floating point issue, probably same on all platformsp126 dittop172 dittop186 dittop204 compiler bug I think this also fails on other platforms but obviously differently; needs investigationp205 was failing but I put in a fix and then Tony put in a better fix p206 I think this fails the same on all platforms, but I      I think it behaves correctly and just update the     std{out,err}.{pgm,build} files; since it is a compilation     failure, it should be an 'e' instead of 'p', not     a big deal I thinkp207 probably fall out from longint not being 64 bits     probably should disable just for this platform r001 This test works in general but is a problem for the     Tinderbox in general. LINUXLIBC6 and NT386 should be     passing, but I think probably it should be turned off.     In particular, the way programs exit when they     fail an assertion and/or have an unhandled exception     varies by platform, in terms of what they actually print.r002 needs investigation; I think it's an infinite recursion     or just uses a lot of stack, and I THINK I saw it fail     on other platforms r003 I hadn't looked at this AT ALL but probably the same as r001,     except more interesting?     There is a test that catches an assertion failure, maybe     do that here?     As well, there is the annoying idea of making per-platform      std* files. Hard to maintain. r004 ditto -- since there are four of these, and potentially more,     maybe worth coming up with somethingSomething I considered, but rejected, back when I thought r001was the only one, is a runtime switch M3 at consistentAbort orsomesuch that will just cleanly exit(0) or exit(1) in these cases,and not print a callstack. I don't want to foul up thesystem TOO much for the sake of testing, but testabilityis an expected design goal...Again, this is an issue across platforms. LINUXLIBC6 seems to print something slightly differently every time you run these. Test.common has a gross workaround. The checked in std* files are from FreeBSD.e020 unknown so fare026 was a problem on all platforms and should be ok now;     was a compiler bug, I fixede029 unknown so farI think p209 and p210 are the most important currently.And then maybe e020, e029.I expect to be "out" all of Sunday.The Tinderbox SHOULD be OK now.Sorry...  - Jay

> Date: Sun, 4 May 2008 15:30:40 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] Tinderbox tests on NT386> > In case anybody wonders about> > http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html> > and following reports, I'm currently trying to run the m3tests on> NT386 in an older version to get a usable reference for the current> problems. There have been so many changes that I'm unable to keep> up with them, and some things seem to be broken.> > Except for the problems in m3tests, the rest of the tinderbox> regression test framework seems to be working now for regular> regression tests on Windows XP with Cygwin. Some initialization> scripts are needed for running them, but that was to be expected.> > The m3tests reports for the last two days for all target platforms> in the tinderbox are not correct (at least, if they show no errors);> there have been some structural changes and more things need to be> adapted. Jay Krell is working on it.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080504/4968feaf/attachment-0002.html>