<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 8, 2016 at 11:28 AM, Faré <span dir="ltr"><<a href="mailto:fahree@gmail.com" target="_blank">fahree@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div id=":82a" class="">clean-op is an impossible operation to fix, because its meaning isn't<br>
defined in general, and CANNOT be defined in general. And while some<br>
specific subsets and variants of it CAN be defined, they remain so<br>
specific as to not be of general purpose and/or there are enough<br>
subtly different variants of it to require a breakdown of the vague<br>
idea into clearly separated concepts.<br>
<br>
For instance, in the context of using git, you might "just" do a:<br>
<br>
git clean -xfd<br>
<br>
and call it quits. Yet, unless you specifically configured your<br>
output-translations to point to under the current git repository,<br>
it won't clean your fasl-translated cache, which would be in e.g.<br>
<br>
~/.cache/common-lisp/ccl-1.12-f102-linux-x86/home/fare/common-lisp/arnesi/<br>
<br>
Then comes the question: should clean-op clean only for the<br>
current implementation, or should it also remove objects for<br>
sbcl, ecl, allegro, etc.? A git clean might erase files that<br>
you'd like to preserve, that you failed to git add. A<br>
<br>
        rm -rf ~/.cache/common-lisp/ccl-1.12-f102-linux-x86/home/fare/common-lisp/arnesi/<br>
<br>
would fail to remove fasls from dependencies or on other<br>
implementations. You could try<br>
<br>
        rm -rf ~/.cache/common-lisp/ccl-1.12-f102-linux-x86/<br>
<br>
or even<br>
<br>
        rm -rf ~/.cache/common-lisp/<br>
<br>
but then that might remove too many things, including things you might<br>
like to keep at that time. And if you have a non-standard<br>
configuration for output-translations, this might still miss some<br>
files you might want to remove.</div></blockquote></div><div class="gmail_extra"><br></div><div class="gmail_extra">These certainly are dicey issues given the default mapping of output files.</div><br>Something I've been looking into is moving towards "project-based" CL development.  Most other languages now have some variant of this, where dependencies and build artifacts are typically contained within some sub-directory.  At this point in time, it's surprising that ASDF/Quicklisp doesn't do things this way.  I've only found one project attempting to do this,</div><div class="gmail_extra"><br></div><div class="gmail_extra"><a href="https://github.com/fukamachi/qlot">https://github.com/fukamachi/qlot</a></div><div class="gmail_extra">(after a quick read, I don't think it's mapping output-files underneath the project directory like one might expect)  <br></div><div class="gmail_extra"><br></div><div class="gmail_extra">If you only expect to load files from within that project/directory, and run separate lisp images for different projects/directories, then cleaning is more intuitive for those coming from mainstream environments, i.e. you just delete the build/ sub-directory.  I'd be interested to hear about similar approaches and complications, e.g. you'd want a user-global quicklisp cache to avoid re-fetching remote deps as in Maven with its ~/.m2. <br clear="all"><div><br></div>-- <br><div class="gmail_signature">Ian Tegebo</div>
</div></div>