Opened 3 years ago

Closed 2 years ago

#1414 closed defect (notabug)

Unreliable (load <file>) with MacOS Sierra 10.12.5

Reported by: dlo_lorrain Owned by:
Priority: normal Milestone:
Component: other Version: 1.11
Keywords: Cc:

Description

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!

Attachments (1)

FrenchAccents.zip (3.9 KB) - added by dlo_lorrain 3 years ago.
Bug when CCL loads accented characters coded by LispWorks?

Download all attachments as: .zip

Change History (3)

Changed 3 years ago by dlo_lorrain

Bug when CCL loads accented characters coded by LispWorks?

comment:1 Changed 3 years ago by dlo_lorrain

Save your time and energy for other issues: I've found the cause of my problems.

It comes from french accented characters [é,è,ê,ù,à etc.] in comments when located inside the LISP code. My files were formerly created with LispWorks?, which seems to use a different encoding for such characters. Comments outside the code do no harm.

There are three short files attached. I have removed everything except this single problematic instance. You can try loading them from the interpreter/Listener. That is: evaluate

(load #P"/...")
  • 0-BADACCENTS.lisp comes directly from LispWorks?
  • 1-NOACCENTS.lisp has no french accents at all
  • 2-GOODACCENTS.lisp has the accents retyped from a CCL editor window

The 0-BADACCENTS.lisp and 2-GOODACCENTS look the same in an editor window, but are definitely not on disk.

You just have to evaluate

(make-instance 'midi-score)

after loading one of the files. Here is what you get. It shows the accented characters in 0-BADACCENTS.lisp (as coded by LispWorks?) make something kaput in the code when loaded by CCL, precisely from the line where the first accented character [ù] is located.

? (load #P"/tmp/0-BADACCENTS.lisp")
#P"/private/tmp/0-BADACCENTS.lisp"
? (make-instance 'midi-score)
> Error: :MODIF is an invalid initarg to INITIALIZE-INSTANCE for #<STANDARD-CLASS MIDI-SCORE>.
>        Valid initargs: (:NAME :EVENTS :FORMAT :SORTED :LENGTH :FILE).
> While executing: CCL::CHECK-INITARGS, in process Listener(4).
> Type cmd-. to abort, cmd-\ for a list of available restarts.
> Type :? for other options.
1 > 
? (load #P"/tmp/1-NOACCENTS.lisp")
#P"/private/tmp/1-NOACCENTS.lisp"
? (make-instance 'midi-score)
#<MIDI-SCORE #x302000CEFBCD>
? (load #P"/tmp/2-GOODACCENTS.lisp")
#P"/private/tmp/2-GOODACCENTS.lisp"
? (make-instance 'midi-score)
#<MIDI-SCORE #x302000DAF4CD>
? (load #P"/tmp/0-BADACCENTS.lisp")
#P"/private/tmp/0-BADACCENTS.lisp"
? (make-instance 'midi-score)
> Error: :MODIF is an invalid initarg to INITIALIZE-INSTANCE for #<STANDARD-CLASS MIDI-SCORE>.
>        Valid initargs: (:NAME :EVENTS :FORMAT :SORTED :LENGTH :FILE).
> While executing: CCL::CHECK-INITARGS, in process Listener(4).
> Type cmd-. to abort, cmd-\ for a list of available restarts.
> Type :? for other options.
1 >

This explains why re-evaluating the code from an editor window solved the problems (cf. my ticket from yesterday). The concerned characters are OK in such a window, but definitely not on disk when coming from LispWorks?. My second guess was right, but the problem has nothing to do with MacOS 10.12.5.

comment:2 Changed 2 years ago by rme

  • Resolution set to notabug
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.