[Openmcl-devel] re ...the sky is falling

[wws2 new]

Since I confused some people on the list yesterday re the "sky is falling problem when doing meta-dot on files which are shared between MCL and CCL,"  let me try to gather my observations and try again.   

As far as I can tell the problem is related to different line ending expectations between MCL (#\return) and Clozure (#\linefeed).  This can be hard to capture as MCL, CCL and mail programs all try to do some work to change line endings.  So if you send or open a file in a given program it can be changed by that act.  Anyway I believe the root problem here is that Clozure can compile MCL files (somehow re-interpretting the line-endings) but that info (how to get past the line-endings) is not passed on to the storage mechanism for function definitions (or the open in a buffer and show the location part), so meta-dot fails and the sky falls. 

EXAMPLE (1) 

To illustrate this take any file created in MCL.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: UrWerk.lisp
Type: application/octet-stream
Size: 5228 bytes
Desc: not available
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20100405/aa826477/attachment.obj>
-------------- next part --------------


Load it in CCL (without opening the file)  (load "/Users/muse/Desktop/UrWerk.lisp")

Then do meta-dot on one of the definitions and get thrown into the "sorry but what can I do" world.


Example (2)

Yesterday Alex sent me afile for Eval-Apple-Script presumably created in RMCL (note the R) or CCL, as the line endings are al #\linefeed rather than #\return.   (If you were confused by my posts yesterday it would be for the good reason that I mistakenly sent that file in one attempt and it would work fine with meta-dot in CCL.  Sorry.)  As a result, if I open that file in MCL, as shown below, everything is on one commented line, so although it "loads" fine nothing is actually loaded.    (It loads fine in RMCL.)  In MCL I can quickly fix that using a user-contributed menu-item (aren't they great!) for going between UNIX, Mac and PC formats. 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Picture 2.png
Type: image/png
Size: 54143 bytes
Desc: not available
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20100405/aa826477/attachment.png>
-------------- next part --------------


Example (3)

More of a problem is when one opens and edits files in more than one LISP environment (as then the file-wide line ending get munged).  For example CCL munged this MCL-RMCL file, when I opened and edited it to debug it in Clozure-common-lisp.  (You need to see the little square boxes (#\linefeeds) that are not interpreted as #\return by MCL.  As a result, some lines of code can move onto lines of comments and vice-versa.  Worse compiler-flags can become inoperative as the s-expressions are no longer what they should be.   The automated heuristics for changing files from one format (UNIX) to another (MAC) break down once a file has a mixture of #\linefeeds and #\returns in them so this situation is hard to rectify.  In porting my code, or rather getting the same source files to compile in MCL, RMCL and CCL I have adopted a strategy of editing in FRED and only compiling and running-data in Clozure.  Never save a file in CCL.  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Picture 1.png
Type: image/png
Size: 47927 bytes
Desc: not available
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20100405/aa826477/attachment-0001.png>
-------------- next part --------------


General Note on the perils of #\newline.

The underlying hassle is not just with "the sky is falling" but relates to #\newline, which for the same obscure reason is (eq #\linefeed ) in CCL and (eq #\return) in MCL and RMCL.

> Welcome to Clozure Common Lisp Version 1.4-r13119  (DarwinX8664)!
> ? (char-code #\newline) 
> 10
> ? (char-code (aref (format nil "~%") 0)) 
> 10 
> ? 


> Welcome to Macintosh Common Lisp Version 5.2.1!
> ? (char-code #\newline)
> 13
> ? (char-code (aref (format nil "~%") 0))
> 13
> ? 


So if I download data from various vendors that comes with PC line-endings (ie #\return #\linefeed) both MCL and CCL appear (and only by accident) to handle the data correctly by line and field (because both have an extra white space which is usually ignored during read).  When that data is then manipulated and saved by line using (format stream "~%~{~A~^	~}" data-list) it can no longer be read correctly by both MCL and CCL by line! as they have different conceptions of what read-line should do.    Since I have historic data files, they can also not be read-written by both programs by line.  

The solution is (a) to always do   (format stream "~C~{~A~^	~}" my-line-ending-character data-list) and (b) I have to role-my-own (read-line :using my-line-ending-character) routines.

I thought Common-LISP was meant to be portable?!

In an ideal world, new characters called #\universal-linefeed and #\universal-field-separator would be agreed and implemented in all computer systems so that all new code could be more easily transported without being munged, and safely read by line and field.



On Apr 4, 2010, at 8:23 AM, Joakim Sandgren wrote:

> if I understand it right ;
> i load urwerk
> i load my file
> i do meta dot on a function in my file
> and here is the console :
> was this the procedure you expected me to do ?
> sincerely
> joakim