Opened 10 years ago

Closed 10 years ago

#610 closed defect (invalid)

regression (not really sure how to classify this)

Reported by: ddp Owned by: rme
Priority: normal Milestone: Clozure CL 1.4
Component: other Version: 1.4
Keywords: Cc:

Description

This is a regression relative to 1.3. (This is the start of my .ccl-init.lisp.)

~/src/ccl-1.4/dx86cl64 --no-init --load foo.lisp

...where 'foo.lisp' is:

(require 'asdf) (pushnew "ccl:tools;asdf-install;" asdf:*central-registry* :test #'string-equal)

...results in this:

fluffy% ~/src/ccl-1.4/dx86cl64 --no-init --load foo.lisp

Error: value (DIRECTORY-NAMESTRING *DEFAULT-PATHNAME-DEFAULTS*) is not of the expected type (OR STRING SYMBOL CHARACTER). While executing: CCL::%FIXED-STRING-EQUAL, in process listener(1). Type :GO to continue, :POP to abort, :R for a list of available restarts. If continued: Skip loading "foo.lisp" Type :? for other options.

Change History (2)

comment:1 Changed 10 years ago by rme

  • Component changed from ANSI CL Compliance to other
  • Owner changed from gb to rme
  • Status changed from new to assigned

This appears to be due to a change in upstream ASDF.

The default value of asdf:*central-registry* is now '((directory-namestring *default-pathname-defaults*)). The first element of the list isn't a string designator, thus the error. The default value used to be '(*default-pathname-defaults*), which worked with the #'string-equal test.

You could use #'equalp as the test instead of #'string-equal. Alternately, you could set asdf:*central-registry* from scratch in your init file, so that you'd avoid the new default value.

http://common-lisp.net/project/asdf/getting-started.html#x:2Acentral-registry:2A explains ASDF's notion of a system directory designator.

comment:2 Changed 10 years ago by rme

  • Resolution set to invalid
  • Status changed from assigned to closed

I'm going to close this ticket as "invalid", which isn't meant to say that you're wrong to report that there's a change. But, asdf:*central-registry* has never supposed to have been a list of strings, either, so I think this is not a bug.

Note: See TracTickets for help on using tickets.