On 6/13/11 Jun 13 -8:51 AM, Chun Tian (binghe) wrote:
OK, people, please clam down ...
I suggest we putting our efforts on solving real issues but arguing. Today I heard that Faré just bought his first Mac computer, I believe he will take care of RMCL better than before.
I very much agree with this. Please also make allowances --- RMCL is an obscure implementation of an already (regrettably) obscure programming languages. Those of us trying to maintain ASDF may need very clear assistance in replicating bugs related to this implementation.
[As a point of process, it might help us somewhat if these bugs would appear on launchpad, instead of only on the mailing list.]
I understand that Faré are trying to make ASDF2 perfect: supporting all available CL platforms so that other ASDF-based packages could have chances to run. From my personal view in these months, maybe ASDF2 grows too fast, as a build tool it grows even faster than other CL packages which do real world function. As a common Lisper using CL on work and maintain some CL packages, I think I just need:
- asdf:*central-registry* works the same way as before,
I use asdf:*central-registry* as before, and have had no troubles with it. I have done so on Mac, Linux and Windows, SBCL, ACL and (a little) CCL.
- Quicklisp works,
I don't use this, but Xach seems to be actively monitoring the state of ASDF, and I believe the record shows that bugs he reports have been fixed promptly.
- All my previous written valid .asd files won't fail.
I don't believe this should ever be a problem, with the proviso that behavior may change as bugs are fixed (see below).
As Fare has said before, it would /really/ help if people would contribute test cases that exercise the asdf:*central-registry*.
other things, I don't care. I think Faré is a very good Lisp programmer, I can see this from ASDF2 source code, I hope Faré could help us (MCL users) solving necessary issues which is caused by ASDF2 development when Faré don't have a Mac, and no doubt all MCL users will say thanks. And I think every ASDF user should want it stable than feature-rich, maybe Faré could consider this option someway in the future.
There has been some feature addition, but there has been no substantial revision of existing functionality, except in cases which were clearly bug fixes (e.g., the badly broken module dependencies; the erratic behavior of the :pathname initargs).
I would also point out that there are still some known bugs in ASDF /that we did not put there/. We have not meddled with them precisely because of concern for stability, and despite the fact that some of these are clearly bugs, and even critical bugs. Chief among these is the fact that ASDF does not notice changes in upstream systems.
ASDF 2 is, in fact, quite conservative in its changes. The primary changes have been in attempts to make configuration more reliable across implementations and operating systems. The DEFSYSTEM API has been quite stable.
Attentive readers of this mailing list should be able to assess this claim themselves. Reviewing their memory or mailing list archives, they will find that a number of changes to the API, even such changes that appeared to be clearly improvements, have been rejected on the grounds of backwards compatibility and stability.
Indeed, if anything I would like to see a move to start an ASDF 3 branch where some issues like the aforementioned system dependencies could be addressed. I understand and respect Fare's lack of desire to operate such a branch in favor of XCVB, however.
Yours sincerely, r