I applied Juanjo's patch for testing with ecl-bytecmp. Only affect test files.
Considering that there's been no action on the source code since last week, I propose that current version 2.017.6 is a pre-release for 2.018. Or maybe I'll call it 2.18 and loose the 0 which isn't very meaningful anymore?
Please test thoroughly. I intend to make a release after one more week or two of inaction.
So far, since 2.017: fix a component reuse bug noticed by Xach, and minor portability improvements with ECL, and minor testing improvements for ECL and SCL; everything relatively minor means we're slowly converging to something stable.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
On 10/2/11 Oct 2 -3:50 PM, Faré wrote:
I applied Juanjo's patch for testing with ecl-bytecmp. Only affect test files.
Considering that there's been no action on the source code since last week, I propose that current version 2.017.6 is a pre-release for 2.018. Or maybe I'll call it 2.18 and loose the 0 which isn't very meaningful anymore?
Please test thoroughly. I intend to make a release after one more week or two of inaction.
So far, since 2.017: fix a component reuse bug noticed by Xach, and minor portability improvements with ECL, and minor testing improvements for ECL and SCL; everything relatively minor means we're slowly converging to something stable.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Before we do our next release, I would like to see us grab the new tests from the RUN-SHELL-COMMAND branch and push them in. I don't think my modifications work well enough that /they/ should be included, but I think it would be very helpful if we were to have a way of telling which implementations correctly handle stdout, stderr, and exit status. Then we can get the code for RUN-SHELL-COMMAND fixed if and where it is needed. Right now I don't think we have a good way of telling which implementations support it. It would also be helpful as a way of getting information about how this stuff works on Windows since I don't believe either you or I run Windows.
I am not a competent bash programmer, so I had to use perl in some cases to get the tests in. Probably someone who knows bash better could replace my simple perl scripts with bash.
Cheers, r
P.S. I just rebased and pushed run-shell-command, which was not (of course) a fast-forward push....
cheers, r
Dear Robert,
On Mon, Oct 3, 2011 at 09:18, Robert Goldman rpgoldman@sift.info wrote:
P.S. I just rebased and pushed run-shell-command, which was not (of course) a fast-forward push....
regarding your rebase & push, it seems that you (probably intentionally) didn't push to master, only to a branch. To push to the branch, I recommend you delete the old branch and push to a new one. You could reuse the same name, but it would only create confusion to people pulling and not manually fixing their repo based on input from the mailing-list, so I suggest using a different name.
Also, regarding implementing a proper, portable, run-shell-command, see again how I do most of it in xcvb's driver.lisp, including universal proper quoting of arguments on either windows or unix. It's painful enough that I don't know if we want that for asdf. Also, xcvb's driver.lisp's run-program/* is geared toward processing the output of run-program rather than letting it happen on the console (for some value of console that might not make sense on Windows). If you can make it run portably in *both* situations, I'll be glad.
Another "solution" might be to deprecate asdf's run-shell-command and recommend that packages that previous were using it should instead be using another solution that actually works portably, whether xcvb's driver.lisp, trivial-shell, or any other solution that is being maintained.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
On 10/3/11 Oct 3 -9:34 AM, Faré wrote:
Dear Robert,
On Mon, Oct 3, 2011 at 09:18, Robert Goldman rpgoldman@sift.info wrote:
P.S. I just rebased and pushed run-shell-command, which was not (of course) a fast-forward push....
regarding your rebase & push, it seems that you (probably intentionally) didn't push to master, only to a branch. To push to the branch, I recommend you delete the old branch and push to a new one. You could reuse the same name, but it would only create confusion to people pulling and not manually fixing their repo based on input from the mailing-list, so I suggest using a different name.
You are right; I just pushed to the branch. I think the tests are CLOSE to being ready for merging to master, but I don't think they are ready yet.
Killing a topic branch and respawning every time one rebases it to master seems ... kludgy, and likely to be at least as disruptive as a non-fast-forward push, as far as I can tell. There is probably a more graceful way to handle this (rebase on the origin instead of in my working dor?), but I don't know what it is.
Also, regarding implementing a proper, portable, run-shell-command, see again how I do most of it in xcvb's driver.lisp, including universal proper quoting of arguments on either windows or unix. It's painful enough that I don't know if we want that for asdf. Also, xcvb's driver.lisp's run-program/* is geared toward processing the output of run-program rather than letting it happen on the console (for some value of console that might not make sense on Windows). If you can make it run portably in *both* situations, I'll be glad.
Another "solution" might be to deprecate asdf's run-shell-command and recommend that packages that previous were using it should instead be using another solution that actually works portably, whether xcvb's driver.lisp, trivial-shell, or any other solution that is being maintained.
Deprecating RUN-SHELL-COMMAND seems like a quite drastic change, and I'm not sure it solves the problem (since we still want RUN-SHELL-COMMAND to work during the period when it is being phased out). Also, a portable means of interacting with shell programs seems like the sort of thing the CL environment should provide "out of the box," and "with ASDF" is pretty close to "out of the box."
Anyway, for now, let's confine our ambitions to seeing if we can portably determine whether R-S-C is working in its current form!
Best, Robert
: fare
: rpgoldman
regarding your rebase & push, it seems that you (probably intentionally) didn't push to master, only to a branch. To push to the branch, I recommend you delete the old branch and push to a new one. You could reuse the same name, but it would only create confusion to people pulling and not manually fixing their repo based on input from the mailing-list, so I suggest using a different name.
You are right; I just pushed to the branch. I think the tests are CLOSE to being ready for merging to master, but I don't think they are ready yet.
Killing a topic branch and respawning every time one rebases it to master seems ... kludgy, and likely to be at least as disruptive as a non-fast-forward push, as far as I can tell. There is probably a more graceful way to handle this (rebase on the origin instead of in my working dor?), but I don't know what it is.
Note that since you CANNOT push a non-fast-forward, only delete the remote branch then push a new one, it's functionally the same whether you rename or not... except that renaming won't trip people who pull without having manually deleted their local branch.
To minimize renames, one strategy you could use would be to simply merge, not rebase, until you're ready to push to master. *THEN* do, once, a rebase from master, push to master and deleting of the branch. Hopefully that will work.
Another "solution" might be to deprecate asdf's run-shell-command and recommend that packages that previous were using it should instead be using another solution that actually works portably, whether xcvb's driver.lisp, trivial-shell, or any other solution that is being maintained.
Deprecating RUN-SHELL-COMMAND seems like a quite drastic change, and I'm not sure it solves the problem (since we still want RUN-SHELL-COMMAND to work during the period when it is being phased out). Also, a portable means of interacting with shell programs seems like the sort of thing the CL environment should provide "out of the box," and "with ASDF" is pretty close to "out of the box."
Well, as long as it keeps working "just as well" while it's being phased out over the next year or so, that should be alright.
I agree that interaction with shell programs should be there "out of the box" and that's why it's part of xcvb's driver.lisp (xcvb's runtime, that is present on the target lisp, as contrasted with xcvb's compile-time that runs in a separate process).
Maybe it could be part of asdf.asd but not asdf.lisp, just like asdf-ecl.lisp? Or part of some new asdf contrib?
As far as contribs or standard extensions go, perhaps as part of asdf.lisp itself, I'd like there be a standard way to provide a hook around compile-file, so users may specify things like bindings, optimization settings, warning muffling, etc. XCVB has such mechanisms, and it's incredibly useful. It would also help simplify the build of some pretty standard things like ironclad, that uses its own readtable extension.
Anyway, for now, let's confine our ambitions to seeing if we can portably determine whether R-S-C is working in its current form!
Sounds alright.
Tell me when you're done deleting/renaming/pushing, and I'll give a look at your branch.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
-
Faré -
Robert Goldman