[Asdf-devel] Need to do uiop:setup-temporary-directory in image built with uiop

[Faré]

On Tue, Jun 17, 2014 at 11:47 PM, Robert P. Goldman <rpgoldman at sift.info> wrote:
>> clear-configuration is the function you call
>> when configuration files may have been modified and
>> you want to invalidate any current configuration loaded from them.
>> All it does is call the functions in the *clear-configuration-hook*,
>> so you can extend what "the configuration" means.
>> UIOP itself has none (so far),
>
> I'm confused by this given what David Cooper says.  Now, it's maybe not
> a *user-managed* configuration, but isn't the cached temp directory
> setting a configuration?
>
That's one way of seeing it. But currently, there's no
clear-temporary-directory,
and it's not registered in either the clear-configuration-hook or the
image-dump-hook.

>> but ASDF has configuration for
>> source-registry and output-translations.
>
> Right, and that's what confuses me.  For the source-registry, we have
> CLEAR-SOURCE-REGISTRY, and for output-translations we have
> CLEAR-OUTPUT-TRANSLATIONS, so what's a one-sentence description of what
> UIOP:CLEAR-CONFIGURATION is supposed to do?  Does it subsume those two,
> so that calling UIOP:CLEAR-CONFIGURATION effectively clears both
> source-registry and output-translations?
>
Yes, these two functions are both registered in the clear-configuration-hook,
so that UIOP:CLEAR-CONFIGURATION will call them both.
Actually, nothing else currently uses the *clear-configuration-hook*,
but other systems may, and quite possibly should.

> Do you see what I mean?  Without a crisp definition of "configuration,"
> I don't know what "clear-configuration" should do...
>
It's an open question. The intent is that other libraries with similar
configuration needs
would register more stuff in the configuration hooks.

>> clear-configuration is itself registered as an image-dump-hook,
>> so when you save an image, you don't get configuration
>> from whichever user, process, machine dumped the image.
>>
>> I'm not completely sure whether you should
>> (register-configuration-hook 'clear-temporary-directory)
>> or more directly
>> (register-image-dump-hook 'clear-temporary-directory)
>>
>> Since default-temporary-directory (at least for now)
>> doesn't consult any configuration file, only an environment variable,
>> that is unlikely to change during execution,
>> an image-dump-hook is probably all you need.
>> It's a subtle difference in the intent of future possible modifications.


>> Well, so far UIOP is defined as a layer on top of what the
>> implementation provides
>> and not the other way around. That said, it might be great if the documentation
>> for these implementations would remind the users that if they use
>> these functions
>> while building their software with ASDF (or similar software),
>> they may want to explicitly  (uiop:call-image-dump-hook) and
>> (uiop:call-image-restore-hook) (or the equivalent for their software).
>
> Well, maybe UIOP is a layer on top, but it's a layer on top that seeps
> down (in a way that seems very much analogous to the way that the
> readtable seeps down from the REPL into the compiler...).
>
Well, yes, sometimes you want to call UIOP, and
sometimes, you want UIOP to call you, using its hooks.
Yes, it does require users to do proper configuration
— but just imagine how hard it is if they try to do it without UIOP:
now every system must invent its own API and implement it on every
implementation,
and every user must learn the API of every system. Ouch.
And if you don't use UIOP, it's not integrated with the system that
builds binaries,
so you have to write your own build scripts, too.

>>> Follow-up question: is it getting to be time to add a separate manual
>>> for UIOP?
>>>
>> That would be great. I was kind of hoping for one of the many automatic
>> documentation generators to be used based on the many docstrings.
>> There are just too many functions to hope to maintain the documentation
>> outside of said docstrings and other source comments.
>
> Maybe I'll see what I can manage with Didier's library.  I think it
> allows us to wrap structure around docstrings (like the way the SBCL doc
> gen does).  I like documentation generators for exactly the reason you
> do -- it keeps the documentation for functions close to their
> definitions so they don't stray.  But I *dislike* them when, like
> doxygen and javadoc, they just give you a big heap of unstructured mess.
>  I'd like to structure the docstrings into a manual-shaped skeleton.
>
> Wish I was going to ILC to talk about this with Didier.... :-(
>
You can fire him a mail, and maybe hangout — if he has time!

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
There are three types of people in the world;
those who can count, and those who can't.