tracing messages

[Serge D. Mechveliani]

On Thu, Jan 28, 2010 at 02:39:56PM +0000, Simon Marlow wrote:
> On 28/01/2010 14:27, Serge D. Mechveliani wrote:
> >Dear GHC team,
> >
> >this is on  tracing in  ghc-6.12.1
> >(made from source on Debian Linux i-386-like machine).
> >
> >I wonder what is the reason for this tracing message
> >(starting with  `Step1 ...' ):
> >
> >----------------------------
> >...
> >equations calc =
> >[j<  i ->  true,
> >m<= p ->  true,
> >p<= q ->  true,
> >q<= n ->  true,
> >(A p)<= (A q) ->  false,
> >(X<= Y) | (Y<  X) ->  true,
> >| {not (Y<= n), not (m<= X), not (X<  i), not (j<  Y), (A X)<= (A Y)} ->
> >true,
> >| {not (X<= Y), not (Y<= j), not (m<= X), (A X)<= (A Y)} ->  true,
> >| {not (XStep 1.  Starting mutual pre-reduction. The number of rules is  
> >25.
> >Pre-reduction done. Initial numbers of equations is  9,
> >after reduction:  9,  the pre-reduction cost is 484.
> >...
> >...
> >----------------------------
> >
> >The  main  program does the following in succession:
> >1) finds  eqs,
> >2) prints
> >    "equations calc =\n",      shows eqs "\n\n",
> >    "Starting completion.\n",
> >    "remaining goals = ",
> >3) finds  res  by completion (`complete'),
> >4) prints
> >           shows (completionGoalRem res) "\n"
> >
> >The  trace  calls are set only in the function `complete'.
> >The above message
> >   Step 1.  Starting mutual pre-reduction. The number of rules is  25.
> >   Pre-reduction done. Initial numbers of equations is  9,
> >
> >occurs the first message of this tracing.
> >But the main program must have printed the full last equation in
> >eqs,  and only after this any tracing message could appear.
> >Instead, it breaks the last equation printing with the tracing messages.
> >The further evaluation is long, so I interrupted it, without seeing the
> >final result. But this printing break looks strange, because  eqs
> >does not depend on the results of `complete', the reverse holds: the
> >latter applies to  eqs.
> >Generally, I often observe an effect of this kind; it is harmless, but
> >I wonder, what might be the reason.
> 
> Perhaps your program output is going to stdout, and the trace messages 
> are going to stderr?  Buffering would make them appear out of order.
> 
> If you're using Debug.trace, I wouldn't recommend that for production 
> use, only debugging.
> 
> Cheers,
> 	Simon


Thank you. 
Probably, this is the matter of  stdout+stderr+bufering.

I run it by   Main > & log,  and then, see  ./log.

-----------------
Serge Mechveliani
mechvel at botik.ru