[Openmcl-devel] asdf problem in CCL

[Bruce O'Neel]

Hi,

On MacOS with ccl 1.12.1-5 if I run the following commands 

(load "~/quicklisp/setup.lisp")

(ql:quickload "drakma")

(ql:quickload "climacs")

(ql:quickload "clim-examples")

I get

% ls
~/.slime/fasl/2.26.1/clozure-version_1.12.1_\(v1.12.1-5-g110c2306\)_darwinx8664-darwin-x86-64

backend.dx64fsl gray.dx64fsl packages.dx64fsl

ccl.dx64fsl match.dx64fsl rpc.dx64fsl

contrib metering.dx64fsl swank.dx64fsl

% ls ~/.cache/common-lisp/ccl-1.12-f98-macosx-x64 

Users

% ls ~/.cache/common-lisp/ccl-1.12-f98-macosx-x64/      

Users

%  

The .local one must come from some linux system I run.

cheers

bruce

On 2022-04-04T19:07:19.000+02:00, Robert Goldman <rpgoldman at sift.info>
wrote:

> Interesting. I (obviously) use ASDF, but I do not see a
> common-lisp/systems directory in $HOME/.local/share. What is in that
> directory for you? And what OS are you using, Windows, Linux, or
> MacOS?
> 
> Thanks,
> R
> 
> On 4 Apr 2022, at 1:22, Bruce O'Neel wrote:
> 
>>  Hi all,
>>  
>>  The list of commands in my shell script to clean up when I switch
>>  versions with quicklisp is:
>>  
>>  rm -rf $HOME/.cache/common-lisp
>>  
>>  rm -rf $HOME/.local/share/common-lisp/systems/
>>  
>>  rm -rf $HOME/.slime
>>  
>>  The .slime one is newish but must be because I have chosen a new
>>  package.  The list is empirical.  It works on my old MacOS
>>  system with ccl and sbcl, as well as my assorted linux systems.
>>  
>>  If I run this and then reload my Quicklisp packages they all
>>  recompile from scratch.  Which btw is the only way that I trust
>>  things.
>>  
>>  cheers
>>  
>>  bruce
>>  
>>  On 2022-04-04T01:03:28.000+02:00, dbm at refined-audiometrics.com
>>  <dbm at refined-audiometrics.com> wrote: 
>>  
>>>   HI Paul,
>>>   
>>>   I don’t know if this is the source of your problems, but ASDF keeps a cache copy of previously compiled Lisp files. There is a separate folder for each version of Lisp system that you use. Changing ASDF versions does not appear to have any effect on which cache folder is being used.
>>>   
>>>   When making such large changes to your environment, I always discard the contents of the cache folder (in my case ~/.cache and below), before attempting the load up with a new environment.
>>>   
>>>   - DM
>>>   
>>>>    On Apr 3, 2022, at 2:35 PM, Paul Krueger
>>>>    <plkrueger at comcast.net> wrote:
>>>>    
>>>>    I’m running Clozure Common Lisp Version 1.12.1 (v1.12.1)
>>>>    DarwinX8664 that I built from scratch a few months ago.
>>>>    
>>>>    I understand that asdf and quickload are included as part of
>>>>    the distribution.
>>>>    CCL says it is running version 3.3.4 of asdf:
>>>>    ? (asdf:asdf-version)
>>>>    “3.3.4"
>>>>    
>>>>    That has worked just fine when using quickload for both things
>>>>    that I have created previously myself that are located in
>>>>    ~/common-lisp/…
>>>>    and for loading other packages supported by quickload.
>>>>    
>>>>    However when trying to load a new system that is defined in
>>>>    ~/common-lisp/pkclide/pkclide.asd I get the following:
>>>>    ? (asdf:find-system "pkclide")
>>>>    
>>>>>     Error: Error Component "pkclide" not found
>>>>>     While executing: (:INTERNAL (ASDF/SYSTEM:FIND-SYSTEM
>>>>>     (STRING))), in process Listener(4).
>>>>>     Type cmd-. to abort, cmd-\ for a list of available restarts.
>>>>>     Type :? for other options.
>>>>     1 (truename "~/common-lisp/pkclide/pkclide.asd")
>>>>    #P"/Users/paul/common-lisp/pkclide/pkclide.asd"
>>>>    1
>>>>    
>>>>    I wanted to test to see if I had the same problem with SBCL,
>>>>    so I first made sure that I had the latest quickload
>>>>    installation (which includes an asdf.lisp file to use if no
>>>>    other one is available). When I start SBCL and load quickload
>>>>    in the recommended way, I end up with asdf version 3.3.1. As
>>>>    it turns out, this has no difficulty finding new systems that
>>>>    are in ~/common-lisp/…
>>>>    
>>>>    I tried to blow away some cached things, but that made no
>>>>    difference. However I’m pretty sure that I did not get all
>>>>    the right things because I can still load older systems
>>>>    defined in that same ~/common-lisp/ directory (“older”
>>>>    meaning those that were quickload'ed sometime previous to my
>>>>    latest upgrade of CCL).
>>>>    
>>>>    I next tried to load the same 3.3.1 version of asdf.lisp that
>>>>    SBCL is using into CCL, but there were all sorts of conflicts
>>>>    with the existing 3.3.4 version.
>>>>    
>>>>    I next downloaded the 3.3.5 asdf.lisp and loaded it into both
>>>>    CCL and SBCL … AND GOT EXACTLY THE SAME RESULTS! It was
>>>>    found in SBCL, but not in CCL.
>>>>    
>>>>    So apparently it isn’t a problem with one version of asdf or
>>>>    another, it is something different about how asdf runs in the
>>>>    CCL environment vs. the SBCL environment.
>>>>    
>>>>    After spending more than a day working on this and getting no
>>>>    closer to a solution, I have a basically one question for
>>>>    anyone who knows more than I do about this stuff: What the
>>>>    heck am I missing here? It almost seems like it must have
>>>>    something to do with what is cached in the two environments
>>>>    although it seems strange that this would prohibit finding
>>>>    something that is completely new in the ~/common-lisp
>>>>    directory.
>>>>    
>>>>    Any and all suggestions for the next thing to try are
>>>>    appreciated ...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.clozure.com/pipermail/openmcl-devel/attachments/20220404/1f90f35e/attachment.htm>