Custom Query (1030 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (532 - 534 of 1030)

Ticket Resolution Summary Owner Reporter
#887 fixed COMPILER-WARNING-SOURCE-NOTEs when not saving source locations Gary Byers
Description

Given:

$ cat warning.lisp
xyz    ;;; e.g., a reference to a non-special free variable

;;; EOF
$

we can get:

? (compile-file "foo.lisp" :save-source-locations nil)
> Error: value NIL is not of the expected type NUMBER.
> While executing: --2, in process listener(1).
> Type :POP to abort, :R for a list of available restarts.
> Type :? for other options.

The error comes from code which tries to ensure that the COMPILER-WARNING will have an associated SOURCE-NOTE (presumably since if it didn't, the COMPILER-WARNING wouldn't have an associated SOURCE-NOTE ...) The SOURCE-NOTE's start-pos and end-pos are initialized to the value of *FCOMP-STREAM-POSITION*, which is NIL by the time this warning is signaled.

 (7FDCCEF42138) : 0 (--2 NIL NIL) 5245
 (7FDCCEF42170) : 1 (ENCODE-FILE-RANGE NIL NIL) 69
 (7FDCCEF42190) : 2 (MAKE-SOURCE-NOTE :FILENAME "home:warning.lisp.newest" :START-POS NIL :END-POS NIL :SOURCE NIL) 101
 (7FDCCEF421F8) : 3 (FCOMP-SIGNAL-OR-DEFER-WARNINGS (#<COMPILER-WARNING #x30200279B3ED>) #<LEXICAL-ENVIRONMENT #x30200279B67D>) 333
 (7FDCCEF42250) : 4 (FCOMP-NAMED-FUNCTION (LAMBDA NIL (PROGN XYZ)) NIL #<LEXICAL-ENVIRONMENT #x30200279CD9D> NIL) 597
 (7FDCCEF422C0) : 5 (FCOMP-COMPILE-TOPLEVEL-FORMS #<LEXICAL-ENVIRONMENT #x30200279CD9D>) 693
#889 fixed certain symbols with print names like floats cause printer error John Carroll
Description

Simple test case, in 1.7-r14925M (DarwinX8664):

(print '|40s40|)

Error: FLOATING-POINT-OVERFLOW detected

performing SCALE on (0 363797880709171295166015625000 40)

While executing: CCL::FLOAT-AND-SCALE-AND-ROUND, in process listener(1).

The error comes from %parse-number-token, which tries too hard to actually create a float which could have the same printed representation as the symbol print name.

#891 fixed Results of CL:DIRECTORY when symlinks are involved Zach Beane
Description

Based on the discussion at http://clozure.com/pipermail/openmcl-devel/2011-November/013137.html it would be nice to have the following change in CCL:

With a directory structure like this:

    src/bar/foo.asd
    foo/bar -> ../src/bar
    foo/baz/quux.asd

Currently, starting ccl in the "foo" directory and evaluating (directory "*/*.asd") returns only quux.asd. It would be nice if it returned both foo.asd and quux.asd, as most other implementations do.

Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.