<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 27, 2014 at 1:01 PM, Faré <span dir="ltr"><<a href="mailto:fahree@gmail.com" target="_blank">fahree@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Hi,<br>
<br>
>> 1- encodings...<br>
<div>> The fix should be in the MKCL git repo master head now.<br>
</div>It works perfectly.<br></blockquote><div><br></div><div>Thank you for the confirmation.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
However, somehow ASDF upgrade is broken:<br>
> (require :asdf)<br>
("ASDF" "asdf" "UIOP")<br>
> (asdf:load-system :asdf)<br>
Debugger called in: #<thread "Initial" active (4648) 0x7f7c4f74b700<br>
0000000001be2000>.<br>
<br>
#<a INVALID-SLOT 89384352>:<br>
    The index 35 (max: 33) is not a valid slot index in the object<br>
#<ASDF/PACKAGE-SYSTEM:PACKAGE-SYSTEM "asdf">.<br>
<br>
It looks like you're failing to call upgrade-instance-for-redefined-class<br>
before you're calling a new method on an extended class.<br></blockquote><div><br></div><div>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
>> 3- if I uncomment the lines:<br>
>>   ;;(unless (or #+ecl (use-ecl-byte-compiler-p))<br>
>>   ;;  (setf *load-system-operation* 'load-bundle-op))<br>
>>   I get an error in test-logical-pathname,<br>
>>   with the .fasb apparently mapped to the wrong directory.<br>
><br>
> I am still scratching my head on this one.  It feels so much like an<br>
> optimization concern of questionable wisdom...  Is it the fear of hitting<br>
> some wall I am unaware of, like the 1024 file descriptor one, or something<br>
> else I haven't seen yet?  Is it some concern about memory consumption in a<br>
> development environment where memory use is through the roof already anyway?<br>
> I don't get it, and I am ready to wait until this becomes a real/confirmed<br>
> problem before I address it (I bet it will take a very long time to see that<br>
> happen). Can't we just drop this one?<br>
><br>
</div>We can drop it, but the bugs it uncovers are real.<br>
It does appear to work with MKCL, though.<br>
I suspect it's related to some bad shadowing of initialization function<br>
in ECL, whereby the version from the old object file is called, instead<br>
of the version from the new one.<br>
<br>
Did you change something in MKCL regarding initialization functions,<br>
e.g. using attributes to mark some functions as being in an initialization<br>
section that will cause them to be called at by the linker,<br>
when ECL for portability to old systems still makes its own function<br>
and calls it?<br>
<div><br></div></blockquote><div><br></div><div>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...<br>
<br> <br></div></div></div></div>