[Openmcl-devel] Unreliable (load <file>) with MacOS Sierra 10.12.5

Tue May 23 12:41:08 PDT 2017

Dear Shannon and Ron,

Thank a lot Shannon for what you have done. You have precisely spotted the cause. It is indeed a french accented problem. I also found the solution by trial and error, but didn't access the precise character coding involved as you did.

It does 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 first message yesterday). The concerned characters are OK in such a window, but definitely not on disk when coming from LispWorks. My second guess was right.

All the best and thanks for your time.

--
Denis Lorrain
Site: http://denislorrain.org
Email: dlo at denislorrain.org________________________________
De : Shannon Spires <svs at bearlanding.com>
À : Denis Lorrain <dlo at denislorrain.org> 
Cc : Shannon Spires <svs at bearlanding.com>; "openmcl-devel at clozure.com" <openmcl-devel at clozure.com>
Envoyé le : Mardi 23 mai 2017 18h10
Objet : Re: [Openmcl-devel] Unreliable (load <file>) with MacOS Sierra 10.12.5

Your file is opening as iso-8859-1. When I re-saved the file as UTF-8 instead, then restarted CCL, the form (new 'midi-score :name "poipoi") worked fine. My guess is that the accent characters in your comment <où le score a été sauvegardé> are somehow causing the line <(modif  :initarg :modif )> to be interpreted by the reader as part of the previous comment. Likewise, after I removed that comment, it worked fine even in iso-8859-1 mode. In other words, the reader is not seeing the #\Newline at the end of that line when the file is interpreted with iso-8859-1 encoding, even though the editor quite clearly sees the #\Newline.

I’m curious as to why this file is opening as iso-8859-1 instead of UTF-8 in the first place, and why the #\Newline is not seen by the reader.
Perhaps I’m missing something obvious. If not, this bears further investigation.

-SS

On May 22, 2017, at 1:19 PM, Denis Lorrain <dlo_lorrain at yahoo.fr> wrote:

> Dear Shannon and Ron,
> 
> Many thanks for your interest and help. The attached ccl-init.lisp file causes directly the Example 1 problem of my first message. No other file is loaded.
> 
> 1. Put it in the home directory
> 2. Start CCL with a double-click
> 3. After some compiler warnings (cf. initial comment in the file) here's what you get when calling function new:
> ----------------------------------------------------------------------------
> | Welcome to Clozure Common Lisp Version 1.11-store-r16714  (DarwinX8664)!
> | 
> | CCL is developed and maintained by Clozure Associates. For more information
> | about CCL visit http://ccl.clozure.com.  To enquire about Clozure's Common Lisp
> | consulting services e-mail info at clozure.com or visit http://www.clozure.com.
> | 
> | ? (new 'midi-score :name "poipoi")
> | > 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.
> ----------------------------------------------------------------------------
> 4. Open the ccl-init.lisp file and manually evaluate the defclass midi-score... form with Lisp menu > Execute selection or <cmd><E>:
> ----------------------------------------------------------------------------
> | 1 > 
> | #<STANDARD-CLASS MIDI-SCORE>
> ----------------------------------------------------------------------------
> 5. The same call to function new now works OK and returns a midi-score object:
> ----------------------------------------------------------------------------
> | 1 > (new 'midi-score :name "poipoi")
> | #<MIDI-SCORE #x302000EB244D>
> | 1 > 
> ----------------------------------------------------------------------------
> 
> 
> That's it... Many thanks in advance.
> --
> Denis Lorrain
> Site: http://denislorrain.org
> Email: dlo at denislorrain.org________________________________
> De : Shannon Spires <svs at bearlanding.com>
> À : Denis Lorrain <dlo at denislorrain.org> 
> Cc : Shannon Spires <svs at bearlanding.com>; "openmcl-devel at clozure.com" <openmcl-devel at clozure.com>
> Envoyé le : Lundi 22 mai 2017 17h28
> Objet : Re: [Openmcl-devel] Unreliable (load <file>) with MacOS Sierra 10.12.5
> 
> This sounds like more of a package problem than a Sierra problem, but without the files in question it’s hard to say. Can you distill down the ccl-init file to a single form that fails as you describe and post it here?
> -SS
> 
> 
> On May 22, 2017, at 7:35 AM, Denis Lorrain <dlo_lorrain at yahoo.fr> wrote:
> 
>> I'm looking for help with the following issue. 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 Macinstosh IDE. My cl-init.lisp file allows me to chose between a couple of (load #P"/blabla...") forms. My personal files are loaded indeed, but leading to strange behaviours. 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, 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 as 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).
>> 
>> Comparison with LispWorks
>> Example 3 seems to me similar to the following error when opening a file with my older LispWorks 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 LispWorks 7.0, I have learned from experience with an Evaluation license that this 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 windows?
>> 
>> Sorry for the lengthy report! I have also reported this by creating a ticket:
>> https://trac.clozure.com/ccl/ticket/1414
>> 
>> --
>> Denis Lorrain
>> Site: http://denislorrain.org
>> Email: dlo_lorrain at yahoo.fr
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> https://lists.clozure.com/mailman/listinfo/openmcl-devel

> <ccl-init.lisp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FrenchAccents.zip
Type: application/zip
Size: 4715 bytes
Desc: not available
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20170523/2791b0e4/attachment.zip>