[asdf-devel] Port of ASDF 3.1.0.94 to MKCL

Jean-Claude Beaudoin jean.claude.beaudoin at gmail.com
Thu Mar 27 21:33:25 UTC 2014


On Thu, Mar 27, 2014 at 1:01 PM, Faré <fahree at gmail.com> wrote:

> Hi,
>
> >> 1- encodings...
> > The fix should be in the MKCL git repo master head now.
> It works perfectly.
>

Thank you for the confirmation.


>
> However, somehow ASDF upgrade is broken:
> > (require :asdf)
> ("ASDF" "asdf" "UIOP")
> > (asdf:load-system :asdf)
> Debugger called in: #<thread "Initial" active (4648) 0x7f7c4f74b700
> 0000000001be2000>.
>
> #<a INVALID-SLOT 89384352>:
>     The index 35 (max: 33) is not a valid slot index in the object
> #<ASDF/PACKAGE-SYSTEM:PACKAGE-SYSTEM "asdf">.
>
> It looks like you're failing to call upgrade-instance-for-redefined-class
> before you're calling a new method on an extended class.
>

Thank you for the bug report. It will take a little while (2 or 3 days) for
a fix since I am stuck in something else right now.


>
> >> 3- if I uncomment the lines:
> >>   ;;(unless (or #+ecl (use-ecl-byte-compiler-p))
> >>   ;;  (setf *load-system-operation* 'load-bundle-op))
> >>   I get an error in test-logical-pathname,
> >>   with the .fasb apparently mapped to the wrong directory.
> >
> > I am still scratching my head on this one.  It feels so much like an
> > optimization concern of questionable wisdom...  Is it the fear of hitting
> > some wall I am unaware of, like the 1024 file descriptor one, or
> something
> > else I haven't seen yet?  Is it some concern about memory consumption in
> a
> > development environment where memory use is through the roof already
> anyway?
> > I don't get it, and I am ready to wait until this becomes a
> real/confirmed
> > problem before I address it (I bet it will take a very long time to see
> that
> > happen). Can't we just drop this one?
> >
> We can drop it, but the bugs it uncovers are real.
> It does appear to work with MKCL, though.
> I suspect it's related to some bad shadowing of initialization function
> in ECL, whereby the version from the old object file is called, instead
> of the version from the new one.
>
> Did you change something in MKCL regarding initialization functions,
> e.g. using attributes to mark some functions as being in an initialization
> section that will cause them to be called at by the linker,
> when ECL for portability to old systems still makes its own function
> and calls it?
>
>
Quite a few things have been changed at those low levels since the fork but
nothing comes clearly enough to my mind to be an obvious explanation.  I
will need to do real archeology to figure this one out...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20140327/4b36592a/attachment.html>


More information about the asdf-devel mailing list