[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] types.db incorrect

From: Jörg F . Wittenberger
Subject: Re: [Chicken-users] types.db incorrect
Date: 08 Sep 2011 13:32:07 +0200

On Sep 6 2011, Felix wrote:

Thanks agauin, Joerg. I pushed this change as well.

If not, how would I turn the consequence - which is wrong code at this
time - into a warning?

You can check the results of specialization with "-debug P" (which dumps
the program after specialization has taken place). "-debug x" shows the
specializations done. You can switch off specialization by just compiling
with "-O2". That way you can check whether "-specialize" (enabled by
-O3 and higher) results in incorrect code.

Is there a switch to print the programm after basic macro expansion?

Somehow my problem is all too strange.  After about four years running
all sudden the tree is sometimes not balanced.  I inserted code to check
some invariants.  Since I did I don't understand anything at all anymore.

The same two tests applied twice.  First as two single tests:

(,%if (,(red? 't) r)
  (dbg2 "delmin: new root is bad (red) " r))
(,%if (,(red? 't) (,root-node t))
  (dbg2 "delmin: new root node is bad (red) " r))
,(check-tree t-delete-min 't)

And as the first thing in check-tree combined within an "or":

(or (,(red? 't) t) (,(red? 't) (,root-node t)))
  (dbg2 'root-red (,(red? 't) t) (,(red? 't) (,root-node t)) t)

The second one fires.  But not until after several hundred random insert
and deletions of the minimum.

However the strange thing is, both the values are explicitly set to
"black" at the line before the test.

I just went over the -debug P output.  It' hard to be sure with all
those generated names, but as far as I can see, there is no way codewise
that could make a black (#t) to red (#f).  Short of magic.

Unfortunately this situation paralyses me.  I too much depend on it.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]