Custom Query (1030 matches)

On Win32 (Windows XP SP3), it seems CCL r14647 and later cause exceptions at the time of a disconnection.

This is the quote from *inferior-lisp* buffer:

%eax = 0x00000001
%ecx = 0x77bdc2e3
%edx = 0x00570608
%ebx = 0x012bb2b8
%esp = 0x015af510
%ebp = 0x015af528
%esi = 0x7ffaee88
%edi = 0x012bd320
%eip = 0x00026612
%eflags = 0x00010246

%cs = 0x001b
%ds = 0x0023
%ss = 0x0023
%es = 0x0023
%fs = 0x003b
%gs = 0x0000
Exception on foreign stack

%eax = 0x012b8998
%ecx = 0x015aee98
%edx = 0x00000001
%ebx = 0x7ffaee88
%esp = 0x015aeed0
%ebp = 0x015aeee8
%esi = 0x7ffdce88
%edi = 0x00000000
%eip = 0x00027255
%eflags = 0x00010287

%cs = 0x001b
%ds = 0x0023
%ss = 0x0023
%es = 0x0023
%fs = 0x003b
%gs = 0x0000
Exception on foreign stack

...

Can I ignore it?

From Section 22.3.3.1

If both w and d are omitted, then the effect is to print the value using ordinary free-format output; prin1 uses this format for any number whose magnitude is either zero or between 10^{-3 (inclusive) and 10}7 (exclusive).

free-format is defined in this section to be the same format used by prin1 for the range 10^-3 through 10⁷. This is covered in section 22.1.3.1.3:

If the magnitude of the float is either zero or between 10^-3 (inclusive) and 10⁷ (exclusive), it is printed as the integer part of the number, then a decimal point, followed by the fractional part of the number; there is always at least one digit on each side of the decimal point. If the sign of the number (as determined by float-sign) is negative, then a minus sign is printed before the number. If the format of the number does not match that specified by *read-default-float-format*, then the exponent marker for that format and the digit 0 are also printed. For example, the base of the natural logarithms as a short float might be printed as 2.71828S0.

22.3.3.1 does go on to say that if the width would be greater than 100, exponential notation may be used. However, it follows from the specification that (for example)

(format t "~F" 1e7)

should print:

10000000.0

Not:

1.0E+7

Calls to HASH-TABLE-COUNT on lock-free hash-tables spend a lot of time in LOCK-FREE-COUNT-ENTRIES. This is at least an issue for GBBOpen (​http://gbbopen.org/svn/GBBopen/trunk/ISSUES)