<div dir="ltr">Thanks for the detailed response. Comments inline,<div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 29, 2016 at 2:23 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-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Thu, Apr 28, 2016 at 8:05 PM, Ian Tegebo <<a href="mailto:ian.tegebo@gmail.com">ian.tegebo@gmail.com</a>> wrote:<br>
> I've been reading the manual, papers, and slides on ASDF and XCVB. As a<br>
> frame of reference, I prefer the qualities exhibited by Racket's<br>
> implementation of modules. I was disappointed both to see XCVB bitrot, and<br>
> then to see that a major ASDF overhaul would be necessary.<br>
><br></span>[...]<br>
As to me, if I had to design a build system today... see<br>
<a href="http://ngnghm.github.io/blog/2016/04/26/chapter-9-build-systems/" rel="noreferrer" target="_blank">http://ngnghm.github.io/blog/2016/04/26/chapter-9-build-systems/</a><span class=""><br></span></blockquote><div><br></div><div>I've booked travel to the Land of the Houyhnhnms , but have yet to depart.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> That said, ignoring Racket/ASDF/XCVB, I'm curious about how loading multiple<br>
> versions of the same system could possibly be implemented in Common Lisp<br>
> (CL). [...]<br>
><br>
</span>What is your use case? Do you want a fully automated general answer,<br>
or just a manual hack that works for one or a few very specific<br>
systems on a specific implementation? In the former case, you're<br>
facing an uphill battle. In the latter case, many hacks can help you.<br></blockquote><div><br></div><div>The former is intriguing, the latter's useful. Curiosity about a general solution is what prompted this thread, but I'm happy to learn of workarounds.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Various hacks:<br>
<br>[...]<br>
* detecting packages present before and after loading the system<br>
itself, so you can rename them away.<br>
* using my system package-renaming to cleverly rename relevant<br>
packages around the compilation, loading and/or use of one system.<br>
* fixing your systems to not refer to packages by name at run-time,<br>
and if possible not at load-time either (or make sure to wrapper<br>
load-time in proper package-renaming).</blockquote><div><br></div><div>With respect to package renaming, I've asked Michał Herda to comment on whatever issues he'd had with "destructive package renaming" [1]. I understand it as referring to the state-based global-reader implementation of packages, which seems to entail well known problems like reentrancy and readtable leakage.</div><div><br></div><div>Would you correct me or otherwise expand on the matter? I.e. I'm trying to understand the tradeoffs between package renaming methods. My use cases are:</div><div><br></div><div>a) package local nicknames for readability</div><div>b) implementing a variant of Racket's "#lang"</div><div>c) supporting multiple versions of a dependency</div><div><br></div><div>I know that some implementations directly support a), and that both a) and b) may be implemented with ASDF, but I didn't know about c).</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> On the JVM, there's the notion of "classloader" that can be used to load<br>
> multiple versions of the same class. Unfortunately, the only approach I can<br>
> imagine is to use some form of package renaming.<br>
<br>
</span>If what you want is a general way to have multiple versions of any<br>
system in a same image, you're out of luck, and/or [...]<br></blockquote><div><br></div><div>Yes, I'm primarily interested in a general way: thanks for entertaining the discussion.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
If what you want is a build system that is full-featured like XCVB<br>
with plenty of dependencies yet compiles things in-image like ASDF [...] </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Or then again,<br>
you could use the XCVB farmer model, where the build image with lots<br>
of dependencies farms the compilation to workers that only need to<br>
load a small stub, and no package renaming is necessary. </blockquote><div><br></div><div>This approach sounds like one motivated by version conflict between the build system and system being built. Is that correct?</div><div><br></div><div>I wasn't really thinking about that, but now that I am I'm reminded of various parts of your paper [2]. The bootstrapping, upgrading, and distribution of ASDF seems very thorny indeed.</div><div><br></div></div></div><div class="gmail_extra">[1]: <a href="https://github.com/phoe-krk/pseudonyms/issues/2#issuecomment-215534567">https://github.com/phoe-krk/pseudonyms/issues/2#issuecomment-215534567</a><br clear="all"><div>[2]: <a href="http://fare.tunes.org/files/asdf3/asdf3-2014.html">http://fare.tunes.org/files/asdf3/asdf3-2014.html</a></div><div><br></div>-- <br><div class="gmail_signature">Ian Tegebo</div>
</div></div>