
<html>

<head>

<style>

.hmmessage P

{

margin:0px;

padding:0px

}

body.hmmessage

{

FONT-SIZE: 10pt;

FONT-FAMILY:Tahoma

}

</style>

</head>

<body class='hmmessage'>The bogus commands are actually a "simulation" of what the code is doing, I think.<BR>

It isn't so dumb as to run little rm commands here it and there. It deletes files without running anything and prints stuff that if run will approximate what it did. It is indeed worthwhile I think, though it isn't "-commands" per se.<BR>

That's my vague understanding not having read the code closely.<BR>

The "strange" thing is to see "rm" commands on NT386.<BR>

 <BR>

Planning for success is arguably wrong.<BR>

There will be errors. They need to be debugged.<BR>

You can't always rerun the scenario.<BR>

 <BR>

I think a log file with a little more information is a reasonable compromise.<BR>

 <BR>

Even that is gray. For example, the log file should not contain the output of -trace.<BR>

That's just too low level, too voluminous, and fails too rarely to be interesting.<BR>

 <BR>

Echoing command lines always into a log seems good on the assumption that command lines are expensive, so the i/o to put them in a log should be ok. This isn't entirely true, what with stuff like mkdir and rm.<BR>

On the assumption that command lines are running "big" things that "often" fail.<BR>

Again this is mixed. Most systems that show command lines still hide many.<BR>

ie: invocations of gcc are often shown, but invocations of cc1 and as not so much.<BR>

 <BR>

Personally I debug a lot of stuff and I err in favor of debuggability, be it live or post-mortem.<BR>

Debugging is hard enough, I don't like the obvious easy powers taken away from me.<BR>

I know logging and printf is incredibly crude vs. stepping through code in a debugger, but I also had it be fantastically successful and fast too many times to discount. Esp. in data-intensive code where the same code runs successfully many times before the problem occurs.<BR>

 <BR>

I will grant that in my Modula-3 use, debugging has mostly been easy enough, the repro cases available enough, that optimizing for post-mortem debugging of one and only one instance of a problem is probably overkill.<BR>

But still, a log file seems reasonable..<BR>

(The debugging has actually been not easy, quite difficult at times, the NT386GNU X windows problem, the double aligment, the stat overflow...but the repro cases and ability to peel the onion in run after run after run has been good; like cm3cg -y for example..and the logging we are talking about only helps in the easiest of cases...)<BR>

 <BR>

 - Jay<BR><BR><BR><BR><BR>

<BLOCKQUOTE>

<HR id=EC_stopSpelling>

CC: wagner@elegosoft.com; m3devel@elegosoft.com<BR>From: hosking@cs.purdue.edu<BR>To: jayk123@hotmail.com<BR>Subject: Re: [M3devel] www.opencm3.net/m3tests<BR>Date: Tue, 6 May 2008 10:05:25 -0400<BR><BR>

<DIV><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">

<DIV style="WORD-WRAP: break-word">On May 6, 2008, at 6:57 AM, Jay wrote:</DIV></SPAN></DIV>

<DIV><BR class=EC_Apple-interchange-newline>

<BLOCKQUOTE><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">

<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">Olaf, I don't entirely agree.<BR>The logs should be fairly informative<SPAN class=EC_Apple-converted-space> </SPAN><EM>without<SPAN class=EC_Apple-converted-space> </SPAN></EM>intervention.<BR>Just not too verbose. I'd would rather remove the lines that say "compiling" and show the cm3cg invocations.<BR>But more than one line per source file is too much.<BR>-commands doesn't really work. Lots of bogus extra commands are echoed (rm .tmp), and not all the commands that are run are echoed.</DIV></SPAN></BLOCKQUOTE>

<DIV><BR></DIV>

<DIV>Not bogus - it does exactly what one would expect - showing all commands executed.   I'm  with  Olaf on this one.</DIV>

<DIV><BR></DIV>

<BLOCKQUOTE><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">

<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">I understand that stability for tests is also a goal, but information for the interactive user and for post mortem debugging via a log is also valuable, and these are contrary to stability-for-tests. Somehow contradictory goals need to be met.</DIV></SPAN></BLOCKQUOTE>

<DIV><BR></DIV>

<DIV>I prefer terse output for tests  that complete normally.  On detailed  investigation l can always turn on a verbose flag.</DIV><BR>

<BLOCKQUOTE><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">

<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">How about a compromise?<BR>How about we always log more stuff to TARGET/cm3.log?<BR> And then exactly what you want to stdout/stderr?<BR>While, as I said, more than one line per file is overkill, as part of this compromise I'd be willing to include the cm3cg and as invocation.<BR> <BR>Have folks used build.exe in the Windows NT DDK?<BR>It's model is close to what you get here.<BR>It has three sets of information:<BR>  to the console/stdout<SPAN class=EC_Apple-converted-space> </SPAN><BR>  build.log, build.exe is a wrapper over make, and this includes all the make output -- all the command lines run<SPAN class=EC_Apple-converted-space> </SPAN><BR>  build.err, a small subset of console/stdout output<BR> <BR>My "design" here has been to avoid over-verbosity. Link and mt run on the order of once, or a small number of times, per directory, so showing the full command line (response files...) isn't so verbose -- vs. say something shown once per compiled file.<BR> <BR>There's another "problem" here that I have partly fixed.<BR>Underlying errors are not shown on console/stdout/stderr.<BR>They are often in like TARGET/m3core.lst.<BR> <BR>I changed stuff to refer to that file, after having hunted the errors down myself slowly the first time.<BR> <BR>We could change things to alway says "see TARGET/cm3.log" for more information, or somesuch.<BR> <BR> - Jay<BR><BR><BR>

<HR id=EC_stopSpelling>

<BR>> Date: Tue, 6 May 2008 10:07:11 +0200<BR>> From:<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:wagner@elegosoft.com">wagner@elegosoft.com</A><BR>> To:<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</A><BR>> Subject: Re: [M3devel]<SPAN class=EC_Apple-converted-space> </SPAN><A href="http://www.opencm3.net/m3tests" target=_blank>www.opencm3.net/m3tests</A><BR>><SPAN class=EC_Apple-converted-space> </SPAN><BR>> Quoting Jay <<A href="mailto:jayk123@hotmail.com">jayk123@hotmail.com</A>>:<BR>><SPAN class=EC_Apple-converted-space> </SPAN><BR>> > The "problem" here, a really really small one, is just that the link<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > and mt commands got echoed.<BR>> > Olaf made them not echoed. I then made them conditionally echoed.<BR>> > I made m3-sys\m3tests define M3TESTS so that NT386.common doesn't echo.<BR>> > It's not a big deal either way.<BR>> > Aha -- tests in other directories would have a problem, and I think<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > there are some.<BR>> ><BR>> > I like more echoing usually, so the system explains what is going on,<BR>> > instead of the vaguer "linking foo" sort of message.<BR>> > Granted, nobody bothers watching gcc run assembler commands, so I<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > guess it is just quite gray.<BR>><SPAN class=EC_Apple-converted-space> </SPAN><BR>> Jay, cm3 needs to behave the same on all platforms. By default<BR>> commands should _not_ be echoed to stdout or stderr; that's what the<BR>> -commands switch is for: this gives you exactly the commands the<BR>> compiler issues to invoke other tools.<BR>><SPAN class=EC_Apple-converted-space> </SPAN><BR>> For more verbose output, you may also depend on the -verbose or the<BR>> -debug switches.<BR>><SPAN class=EC_Apple-converted-space> </SPAN><BR>> Please adapt the configuration files that bey default all echoing<BR>> of commands is off.<BR>><SPAN class=EC_Apple-converted-space> </SPAN><BR>> Olaf<BR>><SPAN class=EC_Apple-converted-space> </SPAN><BR>> > I don't know how to run the Tinderbox either yet, sorry.<BR>> > I tried.<BR>> ><BR>> > For adding tests, well, there is m3-sys\m3tests.<BR>> > That is where a lot of the tests are, but not all.<BR>> > I am not sure where tests belong. I added a small number there.<BR>> > They are named with just a letter and a number.<BR>> > The letters have some meaning, explained in the m3makefile.<BR>> > "p" is programs that are run and their stdout/stderr compared<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > against expected<BR>> > "e" is programs build and the errors from the compiler checked to be<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > reasonable.<BR>> > I don't think in general they are expected to successfully compile<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > or run, though the case of "warnings" may be unclear.<BR>> > "c" is programs built so a human can look at the generated code.<BR>> > There is another case I think for human checking.<BR>> > The numbers are just 001, 002, 003, etc.<BR>> > Each hundred tests are in a separate directory, like p0\p001,<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > p0\p002, p1\p100, p1\101, etc.<BR>> ><BR>> > Something like this.<BR>> > Wherever I have details wrong, just look in m3-sys\m3tests. It's<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > pretty simple, obvious, and well commented.<BR>> ><BR>> > The output is a little clearer if you have a working diff.exe on the path.<BR>> > Then what you do is search for "@@" in the output.<BR>> ><BR>> > - Jay<BR>> ><BR>> ><BR>> > Date: Tue, 6 May 2008 03:46:27 +0200From:<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:dabenavidesd@yahoo.esTo">dabenavidesd@yahoo.esTo</A>:<SPAN class=EC_Apple-converted-space> </SPAN><BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:m3devel@elegosoft.comSubject">m3devel@elegosoft.comSubject</A>: [M3devel]<SPAN class=EC_Apple-converted-space> </SPAN><A href="http://www.opencm3.net/m3testsDear" target=_blank>www.opencm3.net/m3testsDear</A><SPAN class=EC_Apple-converted-space> </SPAN><BR>> > developers:Does the recent tests on NT386 seem broken because a<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > recent change on the m3-sys tree, or is the HTML bad generated, I<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > mean can you check the last tests Sunday, May 4th (p001 to p042) has<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > a red background<SPAN class=EC_Apple-converted-space> </SPAN><BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><A href="http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html" target=_blank>http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html</A></pre></td></tr> <tr class="bgred tl"><td> p002 </td><td class="small" width="45%"> Text</td><td class="small"><pre>Comparing files P0\P002\stdout.build and ..\SRC\P0\P002\STDOUT.BUILD***** P0\P002\stdout.buildlink @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1***** ..\SRC\P0\P002\STDOUT.BUILD*****Comparing files P0\P002\stderr.build and ..\SRC\P0\P002\STDERR.BUILDFC: no differences encounteredComparing files P0\P002\stdout.pgm and ..\SRC\P0\P002\STDOUT.PGMFC: no differences encounteredComparing files P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGMFC: no differences encounteredand almost the same pattern in the above tests.I would suggest if it is thinkable using NT386 variant with a complete dedicated machine/system, I can try to set up one this week and send the data back (the machine is behind a proxy), but I don't remember the mail explaining the set up, and also want to know if there is a chance of run the tests with one run script.Also what is the best natural way to put a new tests, and the standard name it should<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > have?Thanks<BR>> ><BR>> ><BR>> > Enviado desde Correo Yahoo!La bandeja de entrada m�s inteligente.<BR>><SPAN class=EC_Apple-converted-space> </SPAN><BR>><SPAN class=EC_Apple-converted-space> </SPAN><BR>><SPAN class=EC_Apple-converted-space> </SPAN><BR>> --<SPAN class=EC_Apple-converted-space> </SPAN><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>><SPAN class=EC_Apple-converted-space> </SPAN><A href="http://www.elegosoft.com/" target=_blank>http://www.elegosoft.com</A><SPAN class=EC_Apple-converted-space> </SPAN>| Gesch�ftsf�hrer: Olaf Wagner | Sitz: Berlin<BR>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<BR>><SPAN class=EC_Apple-converted-space> </SPAN><BR><BR></DIV></SPAN></BLOCKQUOTE></DIV><BR></BLOCKQUOTE></body>

</html>