<div dir="ltr"><div dir="auto">1- Regarding eval-when, see my livejournal post: <a href="https://fare.livejournal.com/146698.html">https://fare.livejournal.com/146698.html</a></div><div dir="auto"><br></div><div>2- features in build files are a very bad idea, inherited from the dark times of using REQUIRE to load code (not so portably). Please don't use them. Avoid using putting anything but build information in build files. Use :read-file-form or :read-file-line for :version, use :defsystem-depends-on for code.</div><div><br></div><div>3- Send patches to chipz, drakma, usocket. Users of bazel will thank you, too.</div><div><br></div><div><div>—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• <a href="http://fare.tunes.org">http://fare.tunes.org</a></div><div>Experience is the worst teacher. It always gives the test first and</div><div>the instruction afterward.</div></div><div><br></div><div><br></div><div><br></div><div dir="auto"><br><div dir="auto"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Oct 14, 2017 16:44, "Ben Vulpes" <<a href="mailto:benv@mavn.is" target="_blank">benv@mavn.is</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Fare et al.,<br>
<br>
The Postmodern/usocket problem I encountered was in fact due to<br>
cl-postgres not setting a feature flag in an :execute context:<br>
<a href="https://github.com/marijnh/Postmodern/blob/57dc8cb4acc4599aee757e8f81999a0fa83c7111/cl-postgres/features.lisp#L8" rel="noreferrer" target="_blank">https://github.com/marijnh/Pos<wbr>tmodern/blob/57dc8cb4acc4599ae<wbr>e757e8f81999a0fa83c7111/cl-<wbr>postgres/features.lisp#L8</a><br>
. To digress from the list topic for half a second, this confuses me,<br>
as that code refused to execute until I patched cl-postgres at that<br>
point to also eval-when in :execute, even when loading the<br>
concatenated sources with sbcl ... --load full-concatenation.lisp<br>
<br>
More relevant to the list, other observations include: chipz mutates<br>
*features* in :chipz-system, a package defined in chipz.asd, which<br>
causes problems because the .asd files are not concatenated with the<br>
sources (not suggesting this is something asdf should even concern<br>
itself with); and both drakma and usocket call (asdf:component-version<br>
(asdf:find-system ...)) at read time, which fails to find the package<br>
in question when loading the concatenated source on a machine without<br>
those packages in *central-registry*, because (I believe) as noted<br>
above, monolithic-concatenate-source-<wbr>op doesn't include system .asd<br>
files. Again, I'm not suggesting that this behavior change.<br>
<br>
Yours,<br>
Ben<br>
<br>
On Sat, Oct 14, 2017 at 11:52 AM, Faré <<a href="mailto:fahree@gmail.com" target="_blank">fahree@gmail.com</a>> wrote:<br>
> On Sat, Oct 14, 2017 at 1:17 PM, Robert Goldman <<a href="mailto:rpgoldman@sift.info" target="_blank">rpgoldman@sift.info</a>> wrote:<br>
>> Will you please clarify for my benefit, since I don't actually use any of<br>
>> the image operations.<br>
>><br>
>> Is the problem that somewhere in the process of loading Postmodern, or one<br>
>> of its dependencies, some bit of code invokes REQUIRE? Or is this an issue<br>
>> with ASDF's REQUIRE-SYSTEM.<br>
>><br>
> monolithic-concatenate-source-<wbr>op is supposed to create a source file<br>
> that has "all the (transitive) source code required to load a system".<br>
> Problem is, it is naive in that the current implementation believes<br>
> there are only source files to concatenate. And so it doesn't handle<br>
> (:require "foo") dependencies which would require to generate a<br>
> temporary "source file" that contains (require "FOO") in it — or<br>
> better a refactoring such that instead of source files, you use<br>
> arbitrary arguments to vomit-output, and for require dependencies you<br>
> use a function that outputs that instead of a pathname (and wrap a<br>
> map () 'vomit-output in a with-output-file).<br>
><br>
>> If it's the former, then I believe this is simply a bad implementation in<br>
>> the relevant system.<br>
>><br>
>> If it's the latter, we should do something about it. However, I believe that<br>
>> REQUIRE-SYSTEM, despite its name, doesn't actually use REQUIRE, instead it<br>
>> "acts like require."<br>
>><br>
> Well, there are unhappily two things called "require-system": the<br>
> class that backs the (:require "foo") dependencies, and the function<br>
> that is now deprecated because it didn't have a good composable<br>
> meaning in presence of multiple build phases. The one that matters<br>
> here is the former.<br>
><br>
> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• <a href="http://fare.tunes.org" rel="noreferrer" target="_blank">http://fare.tunes.org</a><br>
> All problems in computer science can be solved by another level of indirection<br>
> — David Wheeler<br>
> Almost all programming can be viewed as an exercise in caching<br>
> — Terje Mathisen, well-known programming optimization guru<br>
<br>
<br>
<br>
--<br>
Ben Vulpes<br>
<a href="tel:503-313-5838" value="+15033135838" target="_blank">503-313-5838</a><br>
MAVN<br>
</blockquote></div></div>
</div>