OK for not supporting too an upgrade of an ASDF that is too old, only supporting an upgrade going forward. To me that means that we should try very hard to get upgradability (and configurability) right, then try to push for a "simultaneous" distribution of the upgradable ASDF to all implementations, and then declare future such distributions not necessary anymore.
However I'd still like to try one more time to get upgradability working for an older ECL, for not only is it a good exercise in preparation for the future, in addition to a minor feature -- if we can debug it for ECL, that might probably help with other implementations, too.
ECL-specific notes (please follow up only to the ECL list for these issues): when I run from the command-line, I get a debugger, but no debugging information for the frames above the ASDF invocation. So yes, maybe the solution is to re-compile asdf.fas with debugging information. How do I do that?
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Success is getting what you want. Happiness is wanting what you get. -- Dale Carnegie
2009/12/1 Juan Jose Garcia-Ripoll juanjose.garciaripoll@googlemail.com:
On Tue, Dec 1, 2009 at 12:17 PM, Faré fahree@gmail.com wrote:
OK, but then, I may as well drop the ECL-specific code I inserted to support upgrade from an older ASDF.
I would say that we can focus on ensuring that ASDF can be upgraded for ECL >= 9.12.1 and leave the older versions out.
Also, I deplore that errors occuring during initialization leave very little chance of debugging to the normal ECL user; I wouldn't even know where to insert break points for gdb.
The ECL command line arguments -load and -eval are not intended to open a debugger. Their primary use is scripting, where you do not want interaction with the user.
A different issue is whether you would get a debugger doing the same thing in the command line -- probably the extensions (ASDF, sockets, etc) are currently compiled without debug information, but I would have to look it up.
Juanjo