[asdf-devel] Port of ASDF 184.108.40.206 to MKCL
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:
> >> 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
> #<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
> > else I haven't seen yet? Is it some concern about memory consumption in
> > development environment where memory use is through the roof already
> > I don't get it, and I am ready to wait until this becomes a
> > problem before I address it (I bet it will take a very long time to see
> > 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...
More information about the asdf-devel