-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fails to load multiple times on ABCL #5
Comments
Gary, are you here to handle that? I could push your patch (using #-abcl rather than #+(not abcl)), but I'm not sure what the code does and why your patch fixes things. Can you explain how you came up with that patch? |
I hunted down the failure and traced it to this point. Adding #-abcl made the problem go away(what I use cl containers for didn't break and I could load cl containers) . But I would be really unhappy if this patch was pushed quickly, as it REALLY needs a bit of root cause analysis IMO. I am sure the code does something vital I haven't needed yet. Regards, Sent from my phone. |
I'll give a few days to Gary so he may comment, as I am wholly unfamiliar with this part of the code. If you need something urgent, I propose you use a git branch in the mean time. Sorry. |
make-load-form* is defined in metatilities-base/dev/generic-lisp.lisp, and should expand to How is that causing a problem for containers:abstract-container but not for containers:container-node-mixin ??? They are both defined by similar defclass* forms in the same file containers.lisp!!! Can you submit a backtrace? Or is it a matter of you using one and not the other, with a runtime error? |
Those are great questions! There is an illogicity to the matter. It's been a few months since I patched in the hack in on my development machine and only brought it up since I saw avodonsov's remark on the abcl-devel mailing list the other day. Anyway, for reproducing this morning - I removed cl-containers from quicklisp and reloaded. What appears to be happening is that cl-containers is loading correctly the first time and failing the second time (when the ABCL FASL is invoked). Some nuanced interaction appears to be occuring in the Using 1.0.1 and 1.3.0 ABCL I can reproduce this issue, but I have to remove both forms to load the FASL. I'm not sure how I was getting away with only commenting out one form. One variance between then and now is upgrading Java to 1.8.
At any rate, I have a backtrace included below, it's dreadfully dreary reading. To reproduce, follow these steps:
The error does not go away when the TRY-RECOMPILING restart is selected; this yields a condition about the classname already existing in metabang-utilities, e.g.:
I find this particular error interesting, as it suggests to my slightly undercaffinated mind that the symbol is not being created in the correct pacakge. But, I don't know the deep code semantics here that are being shuffled around and thus might be quite wrong. Backtrace:
|
This certainly makes more sense. It looks like ABCL gets confused about the package in which those symbols reside. What if you modify utilities-integration.lisp to use (in-package :containers) then explicitly prefix export-exported-symbols and make-load-form* with metatilities: ? |
Did you open a bug request against ABCL? |
The suggested modification works (that is to say, it fasl-loads). Exploratory testing with the heap and the red-black tree indicates that it does not break functionality.
|
No, I'm not even sure what to tell ABCL yet besides, "Derp, there's a broken. Maybe some sort of FASL thing with symbols, packages, and |
It looks like their make-load-form might involve printing symbols in one package context and reading them in another; but who am I to tell? So yes, give them some explanation, steps to reproduce, proposed fixes, and link to this page. |
Ticket logged here http://abcl.org/trac/ticket/357. |
Hi Faré and Paul, Thanks for bringing this up and tracking it down. It does look like an ABCL thing to me (but I certainly haven't delved deeply!). AFAICT, you (Paul) have a work-around and hopefully ABCL will chime in as to whether the package analysis is the root cause. thanks again, |
As the cl-test-grid maintainer recently noted[1,2], a bug exists in cl-containers on ABCL, where it will outright refuse to load due to abstract-container not being found.
A short-cut to fix this is given here, but I don't think it's a valid fix.
Note that we can conditionally avoid loading abstract-container, but still load the container-node-mixin. Further, both abstract container and container-node-mixin are still visible in ABCL with this patch applied:
Please advise on the purpose of
make-load-form*
. I would really quite like to use cl-container in ABCL.[1] Copy from the mailing list, which appears to have issues with its archive feature...
The only suspicious bug is cl-containers in the second report.
But I guess it's not a regressions, the problem happens on the
previous ABCL versions too.
I tested it manually on ABCL 1.2.1, 1.3.0 and 1.3.1-rc.
When you quickload cl-containers first time, it compiles OK.
When you quickload it second time, it fails with the error
"no class named ABSTRACT-CONTAINER".
The difference in test results may be caused by different
build order of quicklisp libraries when testing on ABCL 1.3.0 and 1.3.1-rc,
because some libraries and their dependencies fail on one ABCL
but succeed on another.
[2] http://common-lisp.net/project/cl-test-grid/abcl/abcl-diff22.html
The text was updated successfully, but these errors were encountered: