Re: [Sbcl-devel] TYPE-SYSTEM-INITIALIZED

[William H. N. <wil...@ai...>]

On Thu, Jun 06, 2002 at 08:12:33PM +0100, Christophe Rhodes wrote:
> On Wed, Jun 05, 2002 at 03:27:12PM -0500, William Harold Newman wrote:
> > > [*] Why did we not notice various bits of breakage that this patch
> > > addresses? Well, basically because without *type-system-initialized*,
> > > PROCLAIM of TYPE and FTYPE are basically no-ops.
> > 
> > Yes. I spent some time trying to fix this without success, though I no
> > longer have the foggiest memory of what the problem was. If it's
> > easier to fix these days, or it's just easier for CSR to fix than it
> > was for WHN, it should be good for various reasons. (One that I
> > remember is that it should make it easy to cleanly get rid of lots of
> > annoying warnings about undefined functions like %COMPILER-DEFUN.)
> 
> Well. It seems relatively easy to fix, at least mostly; the attached
> patch (which differs from the previous one mostly in that I have fixed an
> error in the pathname-handling in LOAD that I introduced earlier in the
> month :-) builds and is generally happy. Some might quibble over the
> newly-introduced #+/#-sb-xc-host conditionals; doubtless there's a
> better fix, but for now I'm exploring...
> 
> However. Something odd happens to the globaldb between
> dump-after-xc.core time and cold-init-time; or possibly we're just not
> being careful enough about storing things up and using them when we can:
> 
> [ in after-xc.core:
> 
> * (sb!c::info :variable :type 'cl:*load-truename*)
> #<SB!KERNEL:UNION-TYPE (OR PATHNAME NULL)>, T
> * (sb!c::info :function :type 'sb!c::type-info-or-lose)
> #<SB!KERNEL:FUN-TYPE (FUNCTION (KEYWORD KEYWORD) SB!C::TYPE-INFO)>, T
> 
> This is different from previously, in that we have type information
> present; ]
> 
> [ in cold-sbcl.core:
> 
> * (sb!c::info :variable :type 'cl:*load-truename*)
> #<SB!KERNEL:NAMED-TYPE T>, NIL
> * (sb!c::info :function :type 'sb!c::type-info-or-lose)
> #<SB!KERNEL:FUN-TYPE (FUNCTION (T T) *)>, NIL

As far as I know (modulo imperfect memory and possible unexplored
complexity of CMU-CL-derived code:-) the globaldb isn't dumped by
genesis. So -- not clear from the text above whether you realize this,
and presumably most other readers don't -- it's not as though globaldb
is being mysteriously changed. Instead, the in-cold-init globaldb
(which is constructed by executing the various toplevel forms which
modify the globaldb, one of the many things the cold core is doing
when it thinks so hard at startup) is somehow being built differently
than the in-the-cross-compiler globaldb was built.
 
I can imagine any number of reasons that this could happen, most being
outright bugs like something being #+SB-XC-HOST when it shouldn't be.
I can't think of any brilliant way to diagnose it, just installing the
patch and playing with it. (And I suggest below that you check in the
patch so it's easier for others to install it and play with it.)

> This is the same as we currently get; I've rewritten the output to save
> the pain of looking at the structures directly rather than at the nice
> print-object output. ]
> 
> So while we're probably most of the way there, and possibly we have
> enough to fix the %DEFUN and %DEFMACRO bogus warning problems, it's not
> altogether clear to me what the next thing to do is.
> 
> Any comments?

Since the results that you report from cold-sbcl.core above are the
same as those from my checked-out sbcl, it's not as though the mystery
above is a new problem created by the patch. It appears that your
fixes just haven't fixed everything along the path from source to
final working SBCL, but that's not inconsistent with your fixes being
an improvement, so even if it's still unknown how to fix the rest of
the bugs, it could be OK to check in your fixes so far.

I'll stare at them a little more, but my first impression is that
they're all clear improvements, even if the overall goal hasn't been
reached yet.

-- 
William Harold Newman <wil...@ai...>
I fought the law of Demeter, and the law of Demeter won.
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C  B9 25 FB EE E0 C3 E5 7C