My latest procrastination was to convert the ASDF Makefile and supporting build and test scripts to CL.
On the one hand, the Makefile didn't translate into asdf secondary targets, like I expected: it's all regular CL functions, modulo some slightly elaborate calling conventions so that the appropriate functions can be called from the Makefile like before, as in: make t l=clisp t="test-utilities.script test-program.script" make bump-version v=4.0 etc.
It's all in the minimakefile branch. Dave, can you test that branch on Windows? I'm particularly curious about LispWorks on Windows, since it's the implementation that has always given us the most trouble with argument passing on Windows; but other Windows implementations make me curious too: there is this elaborate compose-eval-string in tools/invoke-lisp.lisp that produces a string without space, single or double quote or backslash, that is hopefully suitable for passing to the worst implementations of Windows command-line parsers.
The infrastructure now in asdf/tools/ could serve as the basic for a cross-implementation testing framework. I'm not interested in developing one, but those of you who deliver code on a lot of platforms might be.
Death to shell scripts, long live Lisp scripts!
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The rule is perfect: in all matters of opinion our adversaries are insane. — Mark Twain
Faré wrote:
My latest procrastination was to convert the ASDF Makefile and supporting build and test scripts to CL.
I fear that this will sound crabby, but.... I am not very happy with this new makefile as a maintainer user interface.
With the old makefile, I could look at the makefile and guess what the targets were that I wanted.
Better yet, as I got a relatively ok memory for what the targets were, bash completion would help me out.
The new Makefile, on the other hand, has essentially no affordances. At least not beyond "make". E.g., is "make test-all-no-upgrade" still provided? There's no way to tell.
Since there's not an API that will be called, the asdf-tools package.lisp file is empty. So there's no obvious place to begin to look for what commands to issue. Must we just read over the twelve lisp source files to figure out how to use the lisp functions? And how to invoke them through make?
And what happens to the old make variable processing?
./tools/asdf-tools make-target $@ l="$l" L="$L" u="$u" U="$u" v="$v" s="$s" t="$t"
this really isn't at all meaningful (I can guess -- but only based on past experience -- that l is the lisp implementation and t is a test name; other than that, I'm lost).
This also gives us the union of all possible arguments, instead of cueing the user about which arguments are wanted for which commands.
IMO we are better off, as the saying goes, "in for a penny, in for a pound." If one wants to replace the original makefile with lisp scripting, that lisp scripting (a) should be invoked from the shell with no make scrim in between; (b) should offer entry points, probably modeled on multiple entry point programs like git and svn ("asdf-tools help", "asdf-tools help test", etc.); (c) should have a bash completion script with it ("asdf-tools t<TAB>" ==> test, test-all, test-no-upgrade, etc.).
That said, while I'm sure that a halfway solution won't work, I'm not convinced that it's worth rewriting this into CL (although it's an interesting exercise).
I'm still skeptical: before lisp is ready for prime time scripting, it needs a *much more terse* way of specifying pathnames, at least as good as globbing; interaction with regexps in a less bloated way than PPCRE; and much more terse and transparent subprocess interaction (it's hard to beat "foo | bar"). Oh, and a backtrace facility where we don't have more than half the backtrace cluttered with pointless meta-trivia about the backtracing process, rather than with information about the error in question.
You have done stellar work giving CL the tools it needs to be a scripting language. But it still doesn't have syntax optimized for scripting, and the interaction between the shell and CL is still a lot more fussy than I'd like.
Getting that syntax done and right is a very interesting process, but not one I'm willing to interleave with my ordinary workaday tasks.
Cheers, r
I fear that this will sound crabby, but.... I am not very happy with this new makefile as a maintainer user interface.
I agree. The current minimakefile branch is basically working, but its interface needs to be souped up a lot. I just added a minimal help interface, based on extracted docstrings. There need be a better way to register functions and document the way to pass them arguments (probably as part of deftestcmd, that needs be souped up).
With the old makefile, I could look at the makefile and guess what the targets were that I wanted.
make help or ./tools/asdf-tools help will help a bit. Most docstrings need enhancement, but that's a start.
Better yet, as I got a relatively ok memory for what the targets were, bash completion would help me out.
I'm not proficient to help with bash completion, except that somehow phony Makefile targets could be added semi-automatically. I'll leave that to you.
The new Makefile, on the other hand, has essentially no affordances. At least not beyond "make". E.g., is "make test-all-no-upgrade" still provided? There's no way to tell.
Since there's not an API that will be called, the asdf-tools package.lisp file is empty. So there's no obvious place to begin to look for what commands to issue. Must we just read over the twelve lisp source files to figure out how to use the lisp functions? And how to invoke them through make?
Yes, I agree that's important. It's just that it was (as usual) more work to do the conversion that I expected, and I didn't get to improving the interface (yet).
And what happens to the old make variable processing?
./tools/asdf-tools make-target $@ l="$l" L="$L" u="$u" U="$u" v="$v"s="$s" t="$t"
this really isn't at all meaningful (I can guess -- but only based on past experience -- that l is the lisp implementation and t is a test name; other than that, I'm lost).
This also gives us the union of all possible arguments, instead of cueing the user about which arguments are wanted for which commands.
That's the only way I found to pass arguments to asdf-tools from make. Hopefully, some documentation can help explain what's going on, and Makefile hints, bash and/or zsh completion scripts can be automatically generated.
IMO we are better off, as the saying goes, "in for a penny, in for a pound." If one wants to replace the original makefile with lisp scripting, that lisp scripting (a) should be invoked from the shell with no make scrim in between; (b) should offer entry points, probably modeled on multiple entry point programs like git and svn ("asdf-tools help", "asdf-tools help test", etc.); (c) should have a bash completion script with it ("asdf-tools t<TAB>" ==> test, test-all, test-no-upgrade, etc.).
asdf-tools CAN be invoked without make, as in, e.g. ./tools/asdf-tools install-asdf lispworks
But that make offers an easy portable bootstrap that relies on an ubiquitous tool (make), without having to have any particular lisp or worse to detect one. If we could rely on either sbcl or cl-launch, we could do without make, but I believe that's not a reasonable assumption at this time. Also, I wanted to offer backward compatibility, at least for now.
That said, while I'm sure that a halfway solution won't work, I'm not convinced that it's worth rewriting this into CL (although it's an interesting exercise).
I don't think it was worth it, either, except as indeed a learning exercise. That said, now that it's done, I believe there's value in keeping it.
I'm still skeptical: before lisp is ready for prime time scripting, it needs a *much more terse* way of specifying pathnames, at least as good as globbing; interaction with regexps in a less bloated way than PPCRE; and much more terse and transparent subprocess interaction (it's hard to beat "foo | bar"). Oh, and a backtrace facility where we don't have more than half the backtrace cluttered with pointless meta-trivia about the backtracing process, rather than with information about the error in question.
Looking at the code in asdf-tools, I'm not sure how pathnames can usefully get terser.
The globbing has regressed indeed, but can be worked on: some existing globbing library could be used, or implemented. * still works as a wildcard, as in e.g. make test l=ccl t='test-*.script '
A better interface to cl-ppcre is optima.ppcre. I just didn't want to add yet another dependency without consulting you. But I just love it.
You have done stellar work giving CL the tools it needs to be a scripting language. But it still doesn't have syntax optimized for scripting, and the interaction between the shell and CL is still a lot more fussy than I'd like.
I agree — but it's only by writing, using and refining the tools that they can be made great. If we omit the very real but addressable UI issues you mention, I believe that the current CL script is much much better than the shell scripts it replaces: * better error-handling * much more general invoke-lisp.lisp extension to lisp-invocation.asd; the compose-eval-string utility is very useful. * the run-test-lisp abstraction that we were really missing with bash. * better, more uniform, defaulting. * better consistency checking, thanks to richer variable manipulation and less unwieldy computation than in the shell
Getting that syntax done and right is a very interesting process, but not one I'm willing to interleave with my ordinary workaday tasks.
Acknowledged. The tool can be used in quite close a syntax to the previous one, though — all it needs is enough documentation to describe parameter passing.
Also, it can be used from the SLIME REPL, which might be nicer than the shell command-line: (asdf:load-system :asdf-tools)
Well, let's try this again. I have looked more deeply, and it's amazing what you have achieved.
Thanks for your appreciation!
I am left with my concerns about the interface that this scripting offers, but maybe by adding cl-launch (to remove the makefile layer), and providing better interaction for the user (completion + documentation), we can get this to the point where it would be a good solution.
My only concern about removing the Makefile is that I'd like a way to bootstrap asdf.lisp from its many components without a working asdf (that cl-launch requires, though it could be from the implementation). Now that most implementations provide asdf, that's not as big an issue as that used to be, but still.
A remaining problem is that now getting an ASDF development environment starts to be more difficult. How are we to manage installing the dependencies if the ASDF development head is going to be *ahead* of the state of Quicklisp (and, I believe now, *incompatibly* ahead)?
Yeah, well, life on the bleeding edge can be painful. Hopefully, things will stabilize soon, and then all dependencies will be in Quicklisp.
It was already difficult for me using the bump script, but most of the makefile required only ASDF and a standard Linux or Mac + MacPorts|Homebrew install. I'm just worried about circular dependencies if we need to get a bunch of CL libraries to make this turn over.
That was my main reason for keeping a Makefile, albeit minimal.
In any case, please take another look and tell me if anything more is needed to merge into master.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Politicians are like diapers: they must be changed often. And for the same reasons. [Also, adults don't need either of them. — Faré]
Well, let's try this again. I have looked more deeply, and it's amazing what you have achieved.
I am left with my concerns about the interface that this scripting offers, but maybe by adding cl-launch (to remove the makefile layer), and providing better interaction for the user (completion + documentation), we can get this to the point where it would be a good solution.
A remaining problem is that now getting an ASDF development environment starts to be more difficult. How are we to manage installing the dependencies if the ASDF development head is going to be *ahead* of the state of Quicklisp (and, I believe now, *incompatibly* ahead)?
It was already difficult for me using the bump script, but most of the makefile required only ASDF and a standard Linux or Mac + MacPorts|Homebrew install. I'm just worried about circular dependencies if we need to get a bunch of CL libraries to make this turn over.
Cheers, r
On 2014-05-20 05:02 CEST, Robert Goldman rpgoldman@sift.net wrote:
A remaining problem is that now getting an ASDF development environment starts to be more difficult. How are we to manage installing the dependencies if the ASDF development head is going to be *ahead* of the state of Quicklisp (and, I believe now, *incompatibly* ahead)?
Trying to set up a build environment for the minimakefile branch, I also had to hunt the dependencies.
It was already difficult for me using the bump script, but most of the makefile required only ASDF and a standard Linux or Mac + MacPorts|Homebrew install. I'm just worried about circular dependencies if we need to get a bunch of CL libraries to make this turn over.
Would you consider using git subtree?
The dependencies can live in a vendor subdir but are part of the repo, which means that they don't have to be pulled in with a separate checkout step (as is the case with git submodule).
It is even possible to 'splice out' changes to the dependencies (e.g. bugfixes) and push them to their respective git repos.
The downside is that dependencies which are not maintained in git repos would need a git mirror.
I performed the corresponding commands for
- inferior-shell - cl-ppcre - lisp-invocation
which you can find in the lib/ dir in
https://github.com/darabi/asdf/commits/minimakefile
I use git subtree quite often and find it is a good way of keeping dependencies in one repo, if it is necessary.
Cheers
Kambiz
On Sat, May 31, 2014 at 3:28 AM, Kambiz Darabi darabi@m-creations.com wrote:
Trying to set up a build environment for the minimakefile branch, I also had to hunt the dependencies.
Same dependencies.
It was already difficult for me using the bump script, but most of the makefile required only ASDF and a standard Linux or Mac + MacPorts|Homebrew install. I'm just worried about circular dependencies if we need to get a bunch of CL libraries to make this turn over.
Would you consider using git subtree?
I'm no maintainer anymore, but I would recommend strongly against it in the main asdf git repo. We really really REALLY REALLY *R*E*A*L*L*Y* don't want people who checkout asdf to "magically" get incompatible versions of libraries they don't want being pulled in that they can't easily ignore in their configurations.
On the other hand, that might be a great idea for another repo, say asdf-test, that could be hosted alongside asdf, and would use e.g. git submodule or subtree to pull asdf and all its test-time dependencies (they are required neither for building nor for running, only for test and release).
The dependencies can live in a vendor subdir but are part of the repo, which means that they don't have to be pulled in with a separate checkout step (as is the case with git submodule).
It is even possible to 'splice out' changes to the dependencies (e.g. bugfixes) and push them to their respective git repos.
The downside is that dependencies which are not maintained in git repos would need a git mirror.
I performed the corresponding commands for
- inferior-shell
- cl-ppcre
- lisp-invocation
There are many more transitive dependencies. Just you try
CL-USER> (asdf:make :asdf-tools) (asdf:registered-systems)
You get:
("asdf/prelude" "asdf/driver" "asdf/defsystem" "asdf" "asdf-tools" "inferior-shell" "inferior-shell/test" "alexandria" "optima" "closer-mop" "fare-utils" "fare-quasiquote-extras" "fare-quasiquote-optima" "fare-quasiquote" "fare-quasiquote-readtable" "named-readtables" "named-readtables-test" "fare-mop" "cl-ppcre" "cl-ppcre-test" "lisp-invocation")
That's code from 11 different repos, including asdf.
which you can find in the lib/ dir in
https://github.com/darabi/asdf/commits/minimakefile
I use git subtree quite often and find it is a good way of keeping dependencies in one repo, if it is necessary.
We conspicuously do NOT want that in the asdf repo — but a *new* repo that uses git submodule (or subtree?) is most welcome.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org An apple every eight hours will keep three doctors away.
Kambiz Darabi wrote:
On 2014-05-20 05:02 CEST, Robert Goldman rpgoldman@sift.net wrote:
A remaining problem is that now getting an ASDF development environment starts to be more difficult. How are we to manage installing the dependencies if the ASDF development head is going to be *ahead* of the state of Quicklisp (and, I believe now, *incompatibly* ahead)?
Trying to set up a build environment for the minimakefile branch, I also had to hunt the dependencies.
I had the same trouble for the original makefile, which I resolved by setting up this environment variable:
export ASDF_DEVEL_SOURCE_REGISTRY="${HOME}/lisp/vendor/fare-utils:${HOME}/lisp/vendor/inferior-shell:${HOME}/lisp/vendor/fare-quasiquote:${HOME}/lisp/vendor/fare-mop:${HOME}/lisp/vendor/cl-ppcre:${HOME}/lisp/closer-mop:${HOME}/lisp/asdf//:${HOME}/lisp/vendor/named-readtables/:${HOME}/lisp/vendor/optima/:${HOME}/lisp/vendor/alexandria:"
The makefile checks for this environment variable (line 35):
ifdef ASDF_DEVEL_SOURCE_REGISTRY export CL_SOURCE_REGISTRY = ${ASDF_DEVEL_SOURCE_REGISTRY} endif
Probably something similar could be done in the minimakefile branch (although let's *not* share the same environment variable name!).
I don't see that it's necessary for you to use the minimakefile branch, although I certainly don't object to your doing so, if you prefer to.
Best, r
It should be possible to use Quicklisp for build script dependencies (except for lisp-invocation - I don't see it in Quicklisp so we will need to provide it).
Even if new ASDF is somehow incompatible with Quicklisp, the build script is a separate program with may rely on old dependencies and ASDF coming with Quicklisp.
How to use the build tools? I have tried `cd asdf; make` but it fails:
01.06.2014, 05:03, "Anton Vodonosov" avodonosov@yandex.ru:
How to use the build tools? I have tried `cd asdf; make` but it fails:
Sorry, I mean 'cd asdf; make clean' fails:
Delegating clean to asdf-tools Unhandled ASDF/FIND-SYSTEM:MISSING-COMPONENT in thread #<SB-THREAD:THREAD "main thread" RUNNING {1002A8B6A3}>: Component :ASDF-TOOLS not found
Just 'make' works, but I think it doesn't use build tools.
On Sat, May 31, 2014 at 9:03 PM, Anton Vodonosov avodonosov@yandex.ru wrote:
It should be possible to use Quicklisp for build script dependencies (except for lisp-invocation - I don't see it in Quicklisp so we will need to provide it).
The proper thing to do in this case is file a bug on quicklisp-projects: https://github.com/quicklisp/quicklisp-projects/issues/693
Even if new ASDF is somehow incompatible with Quicklisp, the build script is a separate program with may rely on old dependencies and ASDF coming with Quicklisp.
How to use the build tools? I have tried `cd asdf; make clean` but it fails:
works for me.
Delegating clean to asdf-tools Unhandled ASDF/FIND-SYSTEM:MISSING-COMPONENT: Component :ASDF-TOOLS not found
Just 'make' works, but I think it doesn't use build tools.
'make' indeed only depends on make, sh and cat. 'make clean' invokes asdf-tools, but it looks like your source-registry is misconfigured in a way that prevents asdf from finding asdf-tools. I have no idea what's happening. Did you define a bad ASDF_DEVEL_SOURCE_REGISTRY ?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org im always happy // even when im sad // im happy to be sad // it doesnt happen often // so its like gift for me // and gift make me happy — q
01.06.2014, 09:09, "Faré" fahree@gmail.com:
On Sat, May 31, 2014 at 9:03 PM, Anton Vodonosov avodonosov@yandex.ru wrote:
It should be possible to use Quicklisp for build script dependencies (except for lisp-invocation - I don't see it in Quicklisp so we will need to provide it).
The proper thing to do in this case is file a bug on quicklisp-projects: https://github.com/quicklisp/quicklisp-projects/issues/693
All the asdf-tools dependencies are in Quicklisp now, just do (ql:update-all-dists) (ql:update-client)
So now, people who use Quicklisp (unlike Robert) can get dependencies installed automatically by doing (ql:quickload :asdf-tools) instead of (asdf:load-system :asdf-tools).
For example, I have adjusted the main tools/asdf-tools script like this:
;;; ASDF3 is loaded, now use it! (eval-when (:compile-toplevel :load-toplevel :execute) - (asdf:load-system :asdf-tools)) + (load "~/quicklisp/setup.lisp")) +(eval-when (:compile-toplevel :load-toplevel :execute) + (ql:quickload :asdf-tools))
;;; Actually run the stuff! (uiop:restore-image :entry-point 'asdf-tools::entry-point)
After that I am able to run various build commands using asdf-tools instead of make. For example, generate docs:
export ASDF_DEVEL_SOURCE_REGISTRY=~/prj/asdf/:~/prj/asdf/tools/ tools/asdf-tools doc
BTW, note in the above asdf-tools patch, the ~/quicklisp/setup.lisp is loaded after the newest ASDF from sources. That way we always work with the recent ASDF (Quicklisp doesn't try to load its (old) version of ASDF when ASDF is already present in lisp image).
Best regards, - Anton
On Tue, Jul 8, 2014 at 9:58 PM, Anton Vodonosov avodonosov@yandex.ru wrote:
All the asdf-tools dependencies are in Quicklisp now, just do (ql:update-all-dists) (ql:update-client)
So now, people who use Quicklisp (unlike Robert) can get dependencies installed automatically by doing (ql:quickload :asdf-tools) instead of (asdf:load-system :asdf-tools).
I don't know whether quicklisp has sufficient versions of all the asdf dependencies, but if not, it will, eventually, and so I added quicklisp support to asdf-tools, with a variant of the code you proposed. Thanks!
I'm hoping that Robert will merge the minimakefile into master after the 3.1.3 release.
After that I am able to run various build commands using asdf-tools instead of make. For example, generate docs:
export ASDF_DEVEL_SOURCE_REGISTRY=~/prj/asdf/:~/prj/asdf/tools/ tools/asdf-tools doc
BTW, note in the above asdf-tools patch, the ~/quicklisp/setup.lisp is loaded after the newest ASDF from sources. That way we always work with the recent ASDF (Quicklisp doesn't try to load its (old) version of ASDF when ASDF is already present in lisp image).
I hadn't thought of that at first. In my recent commit, quicklisp is loaded last as per your advice, so it doesn't interfere with loading ASDF. I added plenty of comments as to why load-asdf was doing things in that order.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Maybe Jesus was right when he said that the meek shall inherit the earth — but they inherit very small plots, about six feet by three. — Robert Heinlein, "Time Enough For Love"
I had the same trouble for the original makefile, which I resolved by setting up this environment variable:
export ASDF_DEVEL_SOURCE_REGISTRY="${HOME}/lisp/vendor/fare-utils:${HOME}/lisp/vendor/inferior-shell:${HOME}/lisp/vendor/fare-quasiquote:${HOME}/lisp/vendor/fare-mop:${HOME}/lisp/vendor/cl-ppcre:${HOME}/lisp/closer-mop:${HOME}/lisp/asdf//:${HOME}/lisp/vendor/named-readtables/:${HOME}/lisp/vendor/optima/:${HOME}/lisp/vendor/alexandria:"
Note that in the minimakefile branch, asdf/tools/load-asdf.lisp should still heed this ASDF_DEVEL_SOURCE_REGISTRY variable.
Robert, can you test this branch again (and the syntax-control branch) and tell me what needs be done (if anything) before they can be merged in? I believe the minimakefile is now stable (I haven't made significant changes in over a week) and has feature parity with the master branch (and many new features made possible by rewriting from shell to CL).
Actually, if anyone on this list has the ambition of writing "the" test system for CL (presumably starting from one of the popular ones and bringing it to a point where it surpasses all existing ones), there are quite a few bits of code to steal from tools/asdf-tools.asd and test/script-support.lisp that allow for the portable testing of code on multiple implementations, driven from CL using run-program.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Of course, Third World leaders love you. By ascribing third world ills to First World sins, you absolve them of blame for their countries' failure to advance. — John McCarthy
Faré wrote:
Robert, can you test this branch again (and the syntax-control branch) and tell me what needs be done (if anything) before they can be merged in? I believe the minimakefile is now stable (I haven't made significant changes in over a week) and has feature parity with the master branch (and many new features made possible by rewriting from shell to CL).
This week I will do some tests on systems with non-trivial readtables to try to figure out what exactly is going on with the syntax-control branch.
Once I understand what's going on there, we can probably merge it.
minimakefile will have to wait. I don't see a pressing need to merge it. It provides no new functionality, only an experiment with using ASDF to enable CL to be used as a scripting langauge. That's nice, but until it *eases* my development, instead of complicating it, I don't expect to merge this branch. The existing makefile isn't broken in a way that the minimakefile fixes. I have already specified changes that need to be made in this branch before it can be merged:
1. It must provide bash completion that is *at least as* good as make does.
2. It must have more documentation.
Note that these are lower bounds. My ASDF development infrastructure is not a place for experimentation. Experiments that provide clear benefits *to me* are likely to be accepted. Experiments that further unrelated goals (develop CL as a scripting environment) will not: novel CL technology development is not my job as ASDF maintainer.
As the delays in reviewing the syntax-control branch illustrate, I don't have a lot of spare cycles for ASDF right now (a number of projects entering critical state this month). So ASDF items that don't provide a compelling benefit (bugfix or significantly easier development) are going to be back-burnered till more attention becomes available.
Sorry, but it's better that I restrict myself to doing what I can do competently, rather than overextend and do a crummy job on everything.
In general, I think this should be acceptable, because the heroic days of fixing the big bugs in ASDF are over. We are entering a stage of maintaining mature and successful technology.
Best, r
minimakefile will have to wait. I don't see a pressing need to merge it. It provides no new functionality, only an experiment with using ASDF to enable CL to be used as a scripting langauge. That's nice, but until it *eases* my development, instead of complicating it, I don't expect to merge this branch. The existing makefile isn't broken in a way that the minimakefile fixes. I have already specified changes that need to be made in this branch before it can be merged:
Actually, it now does provide some additional functionality: * make help to show all the commands, with a short documentation line for each. The old Makefile had no such thing. * all Lisp commands invoked are now specified according to a list of Lisp forms that isn't obfuscated for passing through bad Windows implementations; on error, messages are printed that work fine for reproducing the bug, with or without obfsuation.
- It must provide bash completion that is *at least as* good as make does.
Done (I hope)
- It must have more documentation.
Done — there was about none on the old scheme, there are docstrings everywhere not.
Note that these are lower bounds. My ASDF development infrastructure is not a place for experimentation. Experiments that provide clear benefits *to me* are likely to be accepted. Experiments that further unrelated goals (develop CL as a scripting environment) will not: novel CL technology development is not my job as ASDF maintainer.
I agree. I believe the new asdf-tools replacement for the Makefile is a success at making things easier. Release scripts are now possible in a way that they weren't before.
As the delays in reviewing the syntax-control branch illustrate, I don't have a lot of spare cycles for ASDF right now (a number of projects entering critical state this month). So ASDF items that don't provide a compelling benefit (bugfix or significantly easier development) are going to be back-burnered till more attention becomes available.
Sorry, but it's better that I restrict myself to doing what I can do competently, rather than overextend and do a crummy job on everything.
In general, I think this should be acceptable, because the heroic days of fixing the big bugs in ASDF are over. We are entering a stage of maintaining mature and successful technology.
I understand your position.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Lorsque la consigne est infâme, la désobéissance est un devoir
OK, this is much more favorable sounding. I will look into this branch as soon as the syntax-control one is resolved (thanks for your responses there -- I will turn my attention to them now).
-
Anton Vodonosov -
Faré -
Kambiz Darabi -
Robert Goldman -
Robert P. Goldman