On 18 March 2010 03:56, Juan Jose Garcia-Ripoll juanjose.garciaripoll@googlemail.com wrote:
On Thu, Mar 18, 2010 at 1:36 AM, Robert Goldman rpgoldman@sift.info wrote:
Is it possible that somehow the compilation of asdf-ecl is recording some information about the package that is somehow damaged by the package surgery?
I will dig into that later during the weekend. I think the point is something we discussed long at the ECL mailing list, namely that symbols are NOT created as a compiled file is run. Symbols are constants and as such a compiler is allowed to coalesce all references to symbols in the same compiled file. The problem would thus be the following. The compiler loads the file, it resolves all references to symbols, storing them in the array of constants, including PERFORM. The code is executed. PERFORM is uninterned and a new symbol is created. We reach the DEFMETHOD forms, which now are executed but since they reference the *old* version of the symbol, the method is installed with the wrong name in the wrong generic function. In other words, one can not expect the side effects that operations have in packages work the same for a compiled and a source file. It is just as if you expect that the side effects that aare caused by changing the readtable would also affect the way a cmpiled file behave.
It may very well be that my recent package manipulations (in hope of achieving hot upgrade of ASDF) are what broke ASDF on ECL, and not Robert's TRAVERSE fixes.
I apologize if that is the case. Can you pull 1.651 and see if it fixed the issue?
Once again, a test script would be swell.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Never explain. Your friends do not need it and your enemies will never believe you anyway. — Elbert Hubbard