RE: Extracting a UIOP's manual

2018-08-15 Thread Antoniotti Marco
I had extracted a manual for UIOP using HELambdaP (

I use it as a test bed


Sent from my Windows Phone

From: Robert Goldman
Sent: ‎15/‎08/‎2018 17:30
To: Hugo Ishimaru
Subject: Re: Extracting a UIOP's manual

On 15 Aug 2018, at 8:59, Hugo Ishimaru wrote:

Hi all,

I have extracted a UIOP's manual from docstrings:
It's not perfect in any means as docstring isn't written in a markup langugage, 
but will be at least a comprehensive reference. The relevant fork of ASDF is in 
The greater part of the generation conforms to that of Alexandria, which 
depends on SBCL (sb-texinfo).

I send this mail as it states
> Help wanted extracting working documentation from UIOP's docstrings.
in though I might not understand a historical context.

Hugo Ishimaru

Thank you very, very much! I am going to be away from ASDF for about a week 
now, but I will look for it as soon as I get back. This will be very helpful 


RE: [asdf-devel] Alternate default lisp system location

2014-03-12 Thread Antoniotti Marco
Well. Quicklisp can change the unit files. Doesn't it?

I suppose it's the chicken and egg problem that is both ring you


Sent from my Windows Phone

From: Zach
Sent: ‎12/‎03/‎2014 17.33
To: Marco
Subject: Re: [asdf-devel] Alternate default lisp system location

Marco Antoniotti writes:

 On Mar 12, 2014, at 15:32 , Zach Beane wrote:

 Robert Goldman writes:

 Zach Beane wrote:
 The complexity of the registry configuration is one reason why I added
 the ~/quicklisp/local-projects/ mechanism.

 Right, so I don't see why there's such a huge objection to having a
 similar mechanism for ASDF.  Stellian suggests using
 ~/quicklisp/local-projects/.  So why is it wrong for ASDF to have a
 local-projects directory?

 All I am suggesting is to have the local projects directory for ASDF be
 visible, instead of invisible.

 I stand corrected about using a name that the user might have already
 had (thanks, Pascal!) but I don't yet see a solution that's as easy as a
 default directory location.

 I think having a similar mechanism would be good. (And the
 loading-from-a-file thing could be nice too.)

 I think the main problem is that giving it a nice name means that the
 chance is high of it clashing with a nice name one or more users is
 already using.

 A while ago I was thinking it would be nice to have an API like this:

  register-system-directory directory key permanently

Registers DIRECTORY as a directory to search for system files. If
PERMANENTLY is true, make the registration persist across sessions.

 But then I got hung up about how to make PERMANENTLY work -- I don't
 think there's any way to ask ASDF what directory is suitable for saving
 a config file.

 And I am 100% in favor of a nice solution that does not involve
 Quicklisp. The simpler, the better.

 That is what MK:DEFSYSTEM used to (actually still does) have.

 mk:add-registry-location pathname

 I don’t think you want the ‘permanently’.  Your init file should be able to 
 deal with that.

I'd like to use this interface *instead* of thinking about which config
file to extend, and extend a cross-platform data file instead.

But I can't figure out how to do it, so it's a bit moot right now.