[asdf-devel] Please test ASDF 2.017.6

[Faré]

>>: 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