Custom Query (1030 matches)

I'm an average level Common LISP user/programmer, not familiar with the environment's internals, using

• CCL Version 1.11.1 (16714) downloaded 05/19/2017 from Apple's App Store
• MacOS Sierra 10.12.5 (16F73)

I use a $HOME/ccl-init.lisp file to load other personal files upon CCL double-clic startup. I use the Macintosch IDE. My cl-init.lisp file allows me to choose between a couple of (load #P"/blabla...") forms. My personal files are loaded indeed, but leading to strange behaviors. In all cases, the following fixes the problem(s):

1. open the concerned file(s) in editor window(s) (i.e. File menu > Open...)
2. re-evaluate the whole file(s) (i.e. <cmd><shift><E>) or appropriate part(s) of it (i.e. <cmd><E>)

From then on, things work properly. It's as if the files had been first carelessly loaded upon startup, some elements skipped or something of that sort... (I know this is absurd.)

Example 1 A class defined in a file loaded by cl-init.lisp is defined indeed (it's not reported as undefined), but with one of its slots missing or bugged: the slot's initarg is reported invalid. It's fixed as soon as I re-evaluate manually the defclass source code.

Example 2 A function is defined (not reported as undefined), but gives wrong results when called (details not significant). It's fixed as soon as I re-evaluate manually the defun source code.

Example 3 A function is defined (not reported as undefined), but gives this error when called:

> Error: The value NIL is not of the expected type NUMBER.
> While executing: CCL::+-2, in process Listener(5).

Similar issue in LW (Lispworks)? Example 3 seems to me similar to the following error when opening a file with my older LW 6.1 in the newer MacOS Sierra 10.12.5:

 Error in process "Cocoa Event Loop" {undebuggable process}
 In + of (NIL 0) arguments should be of type NUMBER.

In LW 7.0, I have learned from experience with an Evaluation license that the latter bug and other oddities are somehow fixed within four (pre compiled) files in the private-patches folder. However, I'm switching to CCL to avoid purchasing LW 7.0, aside from the pleasure of going back to an environment similar to MCL, which I used a lot until 2008 on Motorola Macs, and liked very much.

Tentative causes

• Problem between CCL and Cocoa in MacOS Sierra 10.12.5? (I'm afraid I have only a vague idea about what Cocoa really is in fact...)
• Differences (ex. character set) between files as stored on disk and once opened in editor window buffers?

Sorry for the lengthy report!

Environment: CCL version 1.11-r16635 64bit under Windows 10 64bit

Possible issue: The Format function's F directive's k parameter fails to move the decimal point of the floating point argument to the right when preceded by a tilde and 2 consecutive commas. This fails in Clozure, but works in SBCL v1.3.15 64bit and in Clisp 2.49 when tested.

Example1: The Clozure prompt is "?".

? (format t "10 Percent ~,,2f ~%" .10)
10 Percent 0.1
NIL

Example2: The SBCL prompt is an asterisk "*". Clisp produces the same result.

* (format t "10 Percent ~,,2f ~%" .10)
10 Percent 10.0
NIL

Other scenarios seem to work fine...

Example3: Clozure produces the same result as SBCL Example4 if a 1 is entered for the d parameter (decimal digits) between the two commas.

? (format t "10 Percent ~,1,2f ~%" .10)
10 Percent 10.0
NIL

Example4: SBCL produces the same result as Clozure Example3 when entering a 1 between the two commas.

* (format t "10 Percent ~,1,2f ~%" .10)
10 Percent 10.0
NIL

Example5: Clozure "?" & SBCL "*" produce the same results when entering a 0 between the two commas.

? (format t "10 Percent ~,0,2f ~%" .10)
10 Percent 10.
NIL

* (format t "10 Percent ~,0,2f ~%" .10)
10 Percent 10.
NIL

Reference:

CLHS: 22.3.3.1 Tilde F: Fixed-Format Floating-Point.

"The full form is ~w,d,k,overflowchar,padcharF. The parameter w is the width of the field to be printed; d is the number of digits to print after the decimal point; k is a scale factor that defaults to zero."

​http://www.lispworks.com/documentation/HyperSpec/Body/22_cca.htm

Github ticket on roswell project: ​https://github.com/roswell/roswell/issues/254

Roswell is a tool which assists in managing multiple Common Lisp implementations. It also supports maintaining multiple versions of the same implementation.

For Windows, distributions prior to 1.11 were named "-windowsx86.zip." This apparently changed in 1.11, which breaks the roswell tool. Please consider continuing to use the same suffix you have used in prior versions.

For roswell users, the workaround is to download the distribution file into roswell's archives directory, then rename the file to include the x86 suffix.