Re: [cmucl-imp] Upgrade issues
CMUCL is one of the three implementations, together with ABCL and CLISP, where I ultimately punted on ASDF hot-upgrade, by just trying to rename away the ASDF package if it's too old. My package surgery looks like it works, but it looks like CMUCL refuses to invalidate old CLOS methods when I fmakunbound an object, and/or refuses to invalidate them in some caches. Therefore, the old methods keep getting called and the upgrade fails in weird ways. Trying to unintern the symbols for individual offending functions doesn't work either; I don't remember the symptoms. It's too late to fix the old ASDF so it is easier to upgrade, but maybe there are declarations I can put in the current ASDF to prevent some of these "optimizations" to be in place? If you're interested in fixing this kind of issues, I can try to come up with reduced examples. Anyway, please test the latest ASDF with CMUCL, I think it's ripe for release, except for those upgrade woes. I'd like your feedback considering the massive amount of hacking that happened. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Antivirus alert: file .signature infected by signature virus. Hi! I'm a signature virus. Copy me into your sig file and help me spread!
"Fare" == Far <Far> writes:
Fare> My package surgery looks like it works, but it looks like CMUCL refuses Fare> to invalidate old CLOS methods when I fmakunbound an object, and/or Fare> refuses to invalidate them in some caches. Therefore, the old methods Fare> keep getting called and the upgrade fails in weird ways. Fare> Trying to unintern the symbols for individual offending functions Fare> doesn't work either; I don't remember the symptoms. What is the recipe for a hot-upgrade? Fare> If you're interested in fixing this kind of issues, I can try to come up Fare> with reduced examples. I'm interested, but I hate looking at pcl. :-( Fare> Anyway, please test the latest ASDF with CMUCL, Fare> I think it's ripe for release, except for those upgrade woes. Fare> I'd like your feedback considering the massive amount of hacking Fare> that happened. I ran the testsuite again. All 43 tests pass. There are 3 notes compiling asdf, one of which can probably by fixed by not assigning to ensure-directory in resolve-location. (Based on the compiler note; I didn't look to see if this is a real issue or not.) I get a message from file3-only about one sequence being a different length from another. There are more messages there about two things yielding the same path. ASDF-ENCODINGS test was skipped. asdf.texinfo has a couple of warnings about a misplaced { and } on line 269. So, on whole, it seems asdf is working fine. Ray
participants (2)
-
Faré -
Raymond Toy