Custom Query (1030 matches)

Clicking the mouse in a text window moves the point but does not terminate incremental search. Subsequent typing doesn't get inserted at the point (as one would expect), it gets appended to the search string and the search resumes. This usually ends with confusing messages about search strings not being found.

Codebase has GET-COMPLES-{SINGLE, DOUBLE}-FLOAT again, as in http://trac.clozure.com/ccl/ticket/1270

$ grep -R "comples" * compiler/X86/x862.lisp: (! get-comples-single-float reg result-reg) compiler/X86/x862.lisp: (! get-comples-double-float reg result-reg)

Causing

Unknown vinsn: CCL::GET-COMPLES-DOUBLE-FLOAT

[Condition of type SIMPLE-ERROR]

Backtrace:

0: (CCL::NEED-VINSN-TEMPLATE CCL::GET-COMPLES-DOUBLE-FLOAT #<HASH-TABLE :TEST EQ size 600/687 #x3020001D16ED>)

Locals:

NAME = CCL::GET-COMPLES-DOUBLE-FLOAT TEMPLATES = #<HASH-TABLE :TEST EQ size 600/687 #x3020001D16ED>

1: (CCL::SELECT-VINSN CCL::GET-COMPLES-DOUBLE-FLOAT #<HASH-TABLE :TEST EQ size 600/687 #x3020001D16ED> (#<LREG 14 FPR {0}/COMPLEX-DOUBLE-FLOAT> #<LREG 8 GPR [6]/LISP>))

Locals:

TEMPLATE-OR-NAME = CCL::GET-COMPLES-DOUBLE-FLOAT TEMPLATE-HASH = #<HASH-TABLE :TEST EQ size 600/687 #x3020001D16ED> VREGS = (#<LREG 14 FPR {0}/COMPLEX-DOUBLE-FLOAT> #<LREG 8 GPR [6]/LISP>)

2: (CCL::%EMIT-VINSN #<VINSN-LIST #x302001B4638D> CCL::GET-COMPLES-DOUBLE-FLOAT #<HASH-TABLE :TEST EQ size 600/687 #x3020001D16ED> #<LREG 14 FPR {0}/COMPLEX-DOUBLE-FLOAT> #<LREG 8 GPR [6]/LISP>)

Locals:

VLIST = #<VINSN-LIST #x302001B4638D> NAME = CCL::GET-COMPLES-DOUBLE-FLOAT VINSN-TABLE = #<HASH-TABLE :TEST EQ size 600/687 #x3020001D16ED> VREGS = (#<LREG 14 FPR {0}/COMPLEX-DOUBLE-FLOAT> #<LREG 8 GPR [6]/LISP>)

etc etc

I have a shiny new Linux box running Ubuntu 11.10.

On installing CCL, everything appears OK when I do the rebuild-ccl step. However, in the resulting Lisp image, all math functions (i.e. log and trig functions) are no longer available: all attempts to use such give a "Can't resolve foreign symbol" error.

I've discovered that a 'workaround' is to manually load libm using open-shared-library; the load is remembered through invocations of save-application. However, I'm pretty sure this shouldn't be necessary.

I've found that this behaviour occurs with the latest versions of both CCL 1.6 and 1.7.