Custom Query (1030 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (532 - 534 of 1030)

Ticket Resolution Summary Owner Reporter
#1264 wontfix hash tables, make-load-form bug? Jared Davis
Description

Hi,

I believe there may be a problem with the latest CCL trunk. The problem occurs when I try to load the :chunga library from a recent Quicklisp distribution.

The attached script can be used to recreate the problem.

Here is the error and a backtrace:

   [package chunga]..
   > Error: Special operator or global macro-function CCL::NHASH.MIN-SIZE can't be FUNCALLed or APPLYed
   > While executing: #<CCL::STANDARD-KERNEL-METHOD MAKE-LOAD-FORM (HASH-TABLE)>, in process listener(1).
   > Type :POP to abort, :R for a list of available restarts.
   > Type :? for other options.
   :b
   *(2B6B9E1701D8) : 0 (FUNCALL #'#<#<CCL::STANDARD-KERNEL-METHOD MAKE-LOAD-FORM (HASH-TABLE)>> #<HASH-TABLE :TEST EQUAL size 77/82 #x302000B7E21D> #<CCL::LEXICAL-ENVIRONMENT #x302000B236AD>) 189
    (2B6B9E1702C8) : 1 (FASL-SCAN-USER-FORM #<HASH-TABLE :TEST EQUAL size 77/82 #x302000B7E21D>) 197
    (2B6B9E1702F8) : 2 (FASL-SCAN-CLFUN #<Compiled-function CHUNGA:AS-KEYWORD (Non-Global)  #x302000B90F4F>) 197
    (2B6B9E170330) : 3 (FASL-SCAN ((23 81) (47 "home:ql-bug;bug_temp;inst;dists;quicklisp;software;chunga-1.1.6;known-words.lisp.newest") (70 #<# #:#-# #>) (4 #) (70 #<# #:#-# #>) ...)) 469
    (2B6B9E1703C8) : 4 (FASL-SCAN-FORMS-AND-DUMP-FILE ((23 81) (47 "home:ql-bug;bug_temp;inst;dists;quicklisp;software;chunga-1.1.6;known-words.lisp.newest") (70 #<# #:#-# #>) (4 #) (70 #<# #:#-# #>) ...) "/home/users/jared/.cache/common-lisp/ccl-1.11-f96-linux-x64/home/users/jared/ql-bug/bug_temp/inst/dists/quicklisp/software/chunga-1.1.6/known-words-TMP.lx64fsl" #<CCL::LEXICAL-ENVIRONMENT #x302000B236AD>) 237
    (2B6B9E170468) : 5 (%COMPILE-FILE "/home/users/jared/ql-bug/bug_temp/inst/dists/quicklisp/software/chunga-1.1.6/known-words.lisp" "/home/users/jared/.cache/common-lisp/ccl-1.11-f96-linux-x64/home/users/jared/ql-bug/bug_temp/inst/dists/quicklisp/software/chunga-1.1.6/known-words-TMP.lx64fsl" NIL NIL T T NIL T :DEFER NIL #<BACKEND LINUXX8664 #x3020001C645D> :UTF-8 NIL 0) 2965

It appears that this is provoked by the Chunga file known-words.lisp, found in:

   dists/quicklisp/software/chunga-1.1.6/known-words.lisp

I don't see that this file is particularly doing anything strange, so perhaps there is a CCL problem?

I notice that MAKE-LOAD-FORM has been changed recently:

svn blame:
     6         gb (defmethod make-load-form ((hash hash-table) &optional env)
     6         gb   (declare (ignore env))
 10731         gz   (let ((keytransF (nhash.keytransF hash))
     6         gb         (compareF (nhash.compareF hash))
     6         gb         (vector (nhash.vector hash))
  2584         gb         (private (if (nhash.owner hash) '*current-process*))
 16340         gz         (lock-free-p (hash-lock-free-p hash)))
 16340         gz 
     6         gb     (flet ((convert (f)
     6         gb              (if (or (fixnump f) (symbolp f))
     6         gb                `',f
     6         gb                `(symbol-function ',(function-name f)))))
     6         gb       (values
     6         gb        `(%cons-hash-table
 10731         gz          nil nil nil ,(nhash.grow-threshold hash) ,(nhash.rehash-ratio hash) ,(nhash.rehash-size hash)
 16340         gz         nil nil ,private ,lock-free-p ,(nhash.min-size hash))
 10731         gz        `(%initialize-hash-table ,hash ,(convert keytransF) ,(convert compareF) ',vector)))))

Thanks,

Jared

#1273 fixed bug with inlining/bignums/type declarations Jared Davis
Description

Hi,

This looks like a bug -- can you reproduce?

I am using CCL version 1.11-dev-r16355M-trunk, built just now on Linux, X86-64.

(declaim (inline part-select-width-low
                 part-select-low-high))

(defun part-select-width-low (x width low)
    (logand (1- (ash 1 width))
            (ash x (- low))))

(defun part-select-low-high (x low high)
    (part-select-width-low x (+ 1 (- high low)) low))

(defun fpreg->rawexpt (x)
  (declare (type (unsigned-byte 80) x))
  (part-select-low-high x 64 78))

(list :wrapper (fpreg->rawexpt (1- (expt 2 80)))
      :direct  (part-select-low-high (1- (expt 2 80)) 64 78))

Expected result: (:WRAPPER 32767 :DIRECT 32767)

Actual result: varies, examples shown below:

;; ? (list :wrapper (fpreg->rawexpt (1- (expt 2 80)))
;;         :direct  (part-select-low-high (1- (expt 2 80)) 64 78))
;; (:WRAPPER 13483 :DIRECT 32767)
;;
;; ? (list :wrapper (fpreg->rawexpt (1- (expt 2 80)))
;;         :direct  (part-select-low-high (1- (expt 2 80)) 64 78))
;; (:WRAPPER 12543 :DIRECT 32767)
;;
;; ? (list :wrapper (fpreg->rawexpt (1- (expt 2 80)))
;;         :direct  (part-select-low-high (1- (expt 2 80)) 64 78))
;; (:WRAPPER 11675 :DIRECT 32767)
;;
;; ? (list :wrapper (fpreg->rawexpt (1- (expt 2 80)))
;;         :direct  (part-select-low-high (1- (expt 2 80)) 64 78))
;; (:WRAPPER 10807 :DIRECT 32767)
;;
;; ? (list :wrapper (fpreg->rawexpt (1- (expt 2 80)))
;;         :direct  (part-select-low-high (1- (expt 2 80)) 64 78))
;; (:WRAPPER 9939 :DIRECT 32767)
;;
;; ...

Thanks!

Jared

#1283 fixed win64 build fails R. Matthew Emerson Jared Davis
Description

Hi,

It looks like there's a mismatched #ifndef/#endif pair in ccl/lisp-kernel/lisp-debug.c for Windows here:

    void
    redirect_debugger_io()
    {
    #ifndef WINDOWS
      if (1 || !isatty(fileno(dbgin))) {
        int fd = open("/dev/tty", O_RDWR);
        if (fd >=0) {
          dbgin=fdopen(fd,"r");
          open_debug_output(fd);
        }
    #endif   <--- too soon?
      }
    }

This causes the build to fail with:

x86_64-w64-mingw32-gcc -include ../platform-win64.h -c ../lisp-debug.c -DWIN_64 -DWINDOWS -D_REENTRANT -DX86 -DX8664 -D_GNU_SOURCE -DHAVE_TLS -DEMUTLS -DTCR_IN_GPR -DSVN_REVISION="16387" -g -O2 -Wno-format  -m64 -o lisp-debug.o
../lisp-debug.c:234:1: error: expected identifier or '(' before '}' token
 }
 ^
Makefile:74: recipe for target 'lisp-debug.o' failed
make: *** [lisp-debug.o] Error 1

I think the #endif just needs to come after the subsequent }. After moving it the build seems to succeed for me.

Thanks,

Jared

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