I just released ASDF 1.600 in the official repository.
Since my last "official release" 1.502, there is * AOT replacing ABL. AOT allows you to define a set of pathname translations in a configuration file. * Some cleanup of the ECL integration. * *asdf-revision* has been replaced by *asdf-version* * minor updates to tests, documentation
I think I did all the major changes I wanted for upgradability and configuration. Now for a round of testing, bug fixes and documentation before I try to push the result as "ASDF 2".
You are welcome to try the new functionality and send feedback, remarks, questions. Which glaring bugs would you like to see fix before an official release?
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] A student who changes the course of history is probably taking an exam.
On Thu, Feb 4, 2010 at 1:23 AM, Faré fahree@gmail.com wrote:
I just released ASDF 1.600 in the official repository.
Please do not feel offended by the following: I am grateful that ASDF is moving so quickly.
However, for the future, I think you should avoid by all means the word "release" and "release numbers" that are approaching the hundred-ths. There is no way for unknowledgeable users nor busy implementors to find milestones or real _releases_ that we should ship with our implementations.
Maybe if the next release is ASDF 2.0 one should begin thinking on a different numbering, distinguishing individual sets of fixes pushed via git from monthly releases that aim at broader testing -- by that I mean with something like http://ecls.sf.net/logs.html but replacing platforms with implementations. I would not mind help on the latter at some point, but commercial implementations would be out of my reach.
Juanjo
While I don't have clear numbering plans for ASDF post 2.0, my plan until we reach 2.0 is that I will try to get near 1.x00 when a major feature is added.
We're currently at 1.601. It is hopefully stable enough for implementors to use. At least that's the intent. But it is not yet extensively tested (though no worse than previous ASDFs), and not yet extensively documented. So it doesn't qualify as the desired 2.0 release.
I would certainly like it if Lisp implementations would upgrade ASDF already, and I made a special effort to merge what you sent me for ECL. But I admit I am not going to fight for it, either, until the time is ripe, because I have only so many forces for fighting, and might not be able to pull it off twice.
And so, regarding ECL: please upgrade ASDF to 1.601 if you can. It would be nice. And reduce the asdf self-upgrade strictures.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] You're currently going through a difficult transition period called "Life."
On 4 February 2010 03:04, Juan Jose Garcia-Ripoll juanjose.garciaripoll@googlemail.com wrote:
On Thu, Feb 4, 2010 at 1:23 AM, Faré fahree@gmail.com wrote:
I just released ASDF 1.600 in the official repository.
Please do not feel offended by the following: I am grateful that ASDF is moving so quickly. However, for the future, I think you should avoid by all means the word "release" and "release numbers" that are approaching the hundred-ths. There is no way for unknowledgeable users nor busy implementors to find milestones or real _releases_ that we should ship with our implementations. Maybe if the next release is ASDF 2.0 one should begin thinking on a different numbering, distinguishing individual sets of fixes pushed via git from monthly releases that aim at broader testing -- by that I mean with something like http://ecls.sf.net/logs.html but replacing platforms with implementations. I would not mind help on the latter at some point, but commercial implementations would be out of my reach. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com
On Thu, Feb 4, 2010 at 9:23 AM, Faré fahree@gmail.com wrote:
And so, regarding ECL: please upgrade ASDF to 1.601 if you can. It would be nice. And reduce the asdf self-upgrade strictures.
The point is that I upgraded to 1.596 on Samium's request and assurance that it works with ECL, and now we reached 1.601 I want to make a release of ECL soon and need somehow a hint that the choice is right and will not be broken in the near future.
Juanjo
Dear Juanjo,
ASDF 1.596 includes all the fixes I have for ECL. From there to 1.601 I also made a few fixes for the sake of passing tests, and defined and exported a function COMPILE-FILE-PATHNAME* but 1.601 and 1.596 are probably functionally equivalent as far as delivering on ECL goes. I still would recommend 1.601 as it is an "official" release (whatever that means) whereas 1.596 isn't.
Note that ECL passes tests, if only I tell the test suite to not worry about the warnings ECL issues while compiling asdf.lisp. It is probably a bug in ECL that it should issue these warnings: plenty of unused variable warnings for variables used while dispatching methods, warnings about an unused variables CLOS::.GENERIC-FUNCTION.SI::TEMP as introduced by ECL itself in some macro. Also annoying notes about .COMBINED-METHOD-ARGS. was undefined. Compiler assumes it is a global. Unknown type (VALUES &REST T) And one about ECL expecting two arguments from unintern. The problem with ignoring warnings from ECL is that, though I ignore bogus warnings now, I may be ignoring valid warnings tomorrow.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Due to circumstances beyond your control, you are master of your fate and captain of your soul.
On 4 February 2010 04:10, Juan Jose Garcia-Ripoll juanjose.garciaripoll@googlemail.com wrote:
On Thu, Feb 4, 2010 at 9:23 AM, Faré fahree@gmail.com wrote:
And so, regarding ECL: please upgrade ASDF to 1.601 if you can. It would be nice. And reduce the asdf self-upgrade strictures.
The point is that I upgraded to 1.596 on Samium's request and assurance that it works with ECL, and now we reached 1.601 I want to make a release of ECL soon and need somehow a hint that the choice is right and will not be broken in the near future.
On Thu, Feb 4, 2010 at 4:04 PM, Faré fahree@gmail.com wrote:
I still would recommend 1.601 as it is an "official" release (whatever that means) whereas 1.596 isn't.
Thanks. That is all I was asking for.
Note that ECL passes tests, if only I tell the test suite to not worry about the warnings ECL issues while compiling asdf.lisp. It is probably a bug in ECL that it should issue these warnings: plenty of unused variable warnings for variables used while dispatching methods, warnings about an unused variables CLOS::.GENERIC-FUNCTION.SI::TEMP as introduced by ECL itself in some macro. Also annoying notes about .COMBINED-METHOD-ARGS. was undefined. Compiler assumes it is a global. Unknown type (VALUES &REST T) And one about ECL expecting two arguments from unintern. The problem with ignoring warnings from ECL is that, though I ignore bogus warnings now, I may be ignoring valid warnings tomorrow.
I was aware of some of those warnings (.combined-method-args., *next-method*), as reported by other users and now fixed in the upcoming release, but not of others (temp?). In this case you should have immediately reported that problem so that I look at it, which I will do before the next release.
Juanjo
On 2/4/10 Feb 4 -9:55 AM, Juan Jose Garcia-Ripoll wrote:
On Thu, Feb 4, 2010 at 4:04 PM, Faré <fahree@gmail.com mailto:fahree@gmail.com> wrote:
I still would recommend 1.601 as it is an "official" release (whatever that means) whereas 1.596 isn't.
Thanks. That is all I was asking for.
Note that ECL passes tests, if only I tell the test suite to not worry about the warnings ECL issues while compiling asdf.lisp. It is probably a bug in ECL that it should issue these warnings: plenty of unused variable warnings for variables used while dispatching methods, warnings about an unused variables CLOS::.GENERIC-FUNCTION.SI::TEMP as introduced by ECL itself in some macro. Also annoying notes about .COMBINED-METHOD-ARGS. was undefined. Compiler assumes it is a global. Unknown type (VALUES &REST T) And one about ECL expecting two arguments from unintern. The problem with ignoring warnings from ECL is that, though I ignore bogus warnings now, I may be ignoring valid warnings tomorrow.
I was aware of some of those warnings (.combined-method-args., *next-method*), as reported by other users and now fixed in the upcoming release, but not of others (temp?). In this case you should have immediately reported that problem so that I look at it, which I will do before the next release.
FWIW, I was having this problem with SBCL, too, and one of my recent patches is to make the test suite ignore style-warnings when compiling asdf.lisp (which used to cause the test suite to crash).
r
Dear Juanjo,
I just released 1.602 that quashes more warnings with ECL and passes more tests with more implementations, but it is functionally identical to 1.601 or 1.596 (except for the addition of COMPILE-FILE-PATHNAME*).
ASDF didn't use to support ECL for testing at all. I just added this support and found about the warnings, so it counts as my having warned you immediately.
Other annoying notes: Unknown type (VALUES &REST T) Removing unused variable G42 notes about checking types of arguments of functions (particularly generated functions)
But apart from that, ECL passed all tests like a champ without further need of hacking, unlike other implementations. Way to go!
Thanks a lot for ECL,
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] You may easily play a joke on a man who likes to argue — agree with him. — Edgar Waston Howe
On Thu, Feb 4, 2010 at 7:50 PM, Faré fahree@gmail.com wrote:
ASDF didn't use to support ECL for testing at all. I just added this support and found about the warnings, so it counts as my having warned you immediately.
How can I run the tests? run-tests.sh is not working for me.
Juanjo
On 2/4/10 Feb 4 -2:29 PM, Juan Jose Garcia-Ripoll wrote:
On Thu, Feb 4, 2010 at 7:50 PM, Faré <fahree@gmail.com mailto:fahree@gmail.com> wrote:
ASDF didn't use to support ECL for testing at all. I just added this support and found about the warnings, so it counts as my having warned you immediately.
How can I run the tests? run-tests.sh is not working for me.
What's going wrong?
r
If it's the compile-asdf script hanging instead of exiting, I just pushed 1.603 that has a fix for running tests in ECL w/o manual intervention. My apologies. (No functional change to asdf itself, only to the test script infrastructure.)
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] You think you know when you can learn, are more sure when you can write, even more when you can teach, but certain when you can program. — Alan Perlis
ASDF didn't use to support ECL for testing at all. I just added this support and found about the warnings, so it counts as my having warned you immediately.
How can I run the tests? run-tests.sh is not working for me.
What's going wrong?
On Thu, Feb 4, 2010 at 9:49 PM, Faré fahree@gmail.com wrote:
If it's the compile-asdf script hanging instead of exiting, I just pushed 1.603 that has a fix for running tests in ECL w/o manual intervention. My apologies. (No functional change to asdf itself, only to the test script infrastructure.)
I am currently getting one failure. Is this due to the warnings? I can not see them.
; loading system definition from ; /Users/jjgarcia/src/asdf/test/try-reloading-1.asd into #<ASDF0 package> ;;; Loading "/Users/jjgarcia/src/asdf/test/try-reloading-1.asd" ; registering #<SYSTEM TRY-RELOADING-1 10093480> as TRY-RELOADING-1 Caught error component "try-reloading-dependency" not found, required by #<ASDF:SYSTEM "try-reloading-1" 10093480>; $ cp try-reloading-depen dency.hidden try-reloading-dependency.asd
-#--------------------------------------- Using /Users/jjgarcia/bin/ecl -norc Ran 18 tests: 17 passing and 1 failing failing test(s): test-retry-loading-component-1.script -#---------------------------------------
On Thu, Feb 4, 2010 at 9:49 PM, Faré fahree@gmail.com wrote:
If it's the compile-asdf script hanging instead of exiting, I just pushed 1.603 that has a fix for running tests in ECL w/o manual intervention. My apologies. (No functional change to asdf itself, only to the test script infrastructure.)
1.603 has now been pushed into ECL's repository as well.
Juanjo