busfactor1 / mcl Goto Github PK

pathname-name can return :unspecific which, without "(eq  
name :unspecific)" creates an error when trying to compute the length  
of a symbol.

;; l1-files.lisp
(in-package :ccl)
(defun directory-pathname-p (path)
  (let ((name (pathname-name path))(type (pathname-type path)))
    (and (or (null name) (eq name :unspecific) (%izerop (length name)))
              (or (null type) (eq type :unspecific)))))

In order to make MCL behave like conventional Mac apps, a patch to allow MCL to 
quit without confirmation dialog.

(let ((*warn-if-redefine* nil)
      (*warn-if-redefine-kernel* nil))
  (defun ccl::do-quit-dialog () T)
  )

{Terje, where do contribs/mods go in Google code?}

The problem occurs after loading the portable usocket library, which defines a 
logical pathname translation with a .newest version component:

    (setf (logical-pathname-translations "usocket")
          `(("**;*.*.NEWEST" ,(loading-file-source-file))
            ("**;*.*" ,(loading-file-source-file))))

MCL doesn't properly resolve such logical pathnames. For example, probe-file 
signals an error reporting that NIL is not of the expected type (OR STRING 
ENCODED-STRING PATHNAME STREAM).

The following functions need to be modified to accommodate a "newest" pathname 
version component:

pathname-match-p
translate-pathname

What steps will reproduce the problem?

(progn
  (create-file "ccl:tmp1.tmp" :if-exists nil)
  (create-file "ccl:tmp2.tmp" :if-exists nil)
  (copy-file "ccl:tmp1.tmp" "ccl:tmp2.tmp" :if-exists nil))

What is the expected output? 

NIL

What do you see instead?

Error in process Listener: value NIL is not of the expected type (OR STRING 
CCL::ENCODED-
STRING PATHNAME STREAM).
> While executing: PATHNAME-NAME

Another irrelevance, posted in case of use to others ...

(defun test (x)
  (declare (double-float x)
           (optimize (speed 3) (safety 0)))
  (zerop (the double-float (mod x 100))))

Calling with fixnum rather than double 
  (WARNING: this causes sudden death crash):
(test 1)

CLZ manages to catch this gracefully.

The crash report shows:
Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x000000000000000a
...
so if you have some crash with this report, perhaps it is a type violation.

The get-string and set-string-resource functions in ccl:library;resources.lisp 
have malfunctioned 
since MCL 5.1. The fix is to modify get-string and set-string-resource to work 
with handles.

In MCL, stream-write-string requires the start and end arguments. In other 
Common Lisp 
implementations, including Clozure, the start and end arguments are optional:

http://www.lispworks.com/documentation/lw51/LWRM/html/lwref-643.htm
http://www.clos.org/support/documentation/7.0/doc/operators/excl/stream-write-st
ring.htm
http://franz.com/support/documentation/6.0/doc/pages/operators/excl/stream-write
-string.htm
http://www.sbcl.org/manual/Character-output-stream-methods.html

The different method definition in MCL for stream-write-string creates 
conflicts with portable code. I suggest stream write-string is changed to be 
consistent with other lisp implementations by 
making the start and end arguments optional.

#'machine-version reports wrong processor on Intel machines.

For example, when called on an Intel Core 2 Duo:

? (machine-version)
=>
MacBookPro3,1 with G4

Running RMCL under Snow Leopard suffers occasional logout crashes. That is,
unexpectedly the system logs out and back in again (Window Server crash)
with no apps running.  Apparently a rosetta bug in MacOS 10.6.  Maybe
impossible for RMCL to avoid as due to some problem the system has with PPC
apps (plus maybe keyboard interaction).  But in case anyone finds a
workaround or preventive measure, please report.

<http://discussions.apple.com/thread.jspa?threadID=2136412&tstart=45&start=30>
etc.

The mac-file-type function doesn't consistently recognize text files.

When moving the cursor in text (Fred  or Listener), it used to be that c-F
and c-B moved one character. m-F and m-B moved one part word, c-m-F did the
whole word or form.

Now m-F moves the whole word. Ie. it used to stop at #\- chars.

COMMON-LISP-USER::MOST-POSITIVE-FIXNUM
      ^    ^    ^     ^        ^      ^     old m-F
                ^                     ^     new m-F

(possible cause: Unicode side effect?)

The *mcl-revision* holds the revision code, but it is not displayed anywhere. 
Perhaps it should be 
displayed with the version number in the about dialog and/or in the welcome 
message in the 
listener?

Welcome to Macintosh Common Lisp Version 5.2.1!
? (read-from-string "0.6146281499692686  ")
0.61462814
19

? (setf *READ-DEFAULT-FLOAT-FORMAT* 'double-float)
DOUBLE-FLOAT

? (read-from-string "0.6146281499692686  ")
0.6146281332167046                              <<<<<< WHAT?
19

? (read-from-string "0.9847365829640571 ")
0.9847365829640571
19

The Font item of the Edit menu takes a long time to display the list of fonts 
and scrolls slowly, 
particularly under Rosetta.

The fix is to upgrade to a Font Panel as provided by Carbon and Cocoa.

The documentation for UNADVISE (spec &key when name) states that it:

"unadvises everything matching spec, when, and name. When the value of
spec is t and the values of when and name are nil, unadvise
unadvises everything ever advised; when spec is t, when is nil and
name is non-nil, unadvise unadvises everything with the given name."

However, unadvise unadvises everything when spec is T no matter the value of 
the when and name 
keywords.

The Macintosh Common Lisp Ref need to be included in the distribution.

Fix by adding a line in the gather-distribution script. 

The opentransport.lisp module does not support ports assigned by the OS for 
passive connections. 

Developers should be able to let the OS determine the port instead of always 
having to specify the 
port when opening a TCP stream.

on MacOS 10.6.1:

(loop ... finally return (values ...)) used to work in prior MCL 
releases, it does not appear to now. I assume this is inappropriate 
use of loop anyway.  (loop ... finally (return (values ...))) seems 
to work fine.

In the Apropos dialog, it could be useful to have a search history. Command-[ 
would inject last search keys in and execute.  Command-] to go forward again.

Load Extension Compare/Merge
execute command, at choose file dialog MCL freezes.
(seems intermittent)

Using Interface Toolkit, make new dialog, add any dialog item (eg. static 
text), double click to edit this, click Frame to edit background color ...

... system hangs (with Listener notice: "The timer probaly won't work here").
Only crash boot possible (which is exasperating when an hour of detailed GUI 
editing is lost!).

A nit (and not to do with recent ports/upgrades to MCL, but on a todo list
for anyone hacking in these parts):

Attempting to access outside the bounds of a vector with svref gives a not
very helpful error report.

(svref (vector 1) 1)
> Error: Too few arguments.
> While executing: CCL::%ERR-DISP
...

OK the debugger backtrace probably shows how things went awry, but I think
the initial error report is suboptimal (could be more user friendly).
(there ARE enough arguments in what I am looking at!)

When in a debugger backtrace window, it would be useful to be able to
navigate the backtrace listing rows using the arrow keys.
(wasn't this once the case).

 The view-click-event-handler method on stack-inspector-view is redefined to a legacy version. An old version of the method remains in the code.

The fix is to eliminate the old version.

RMCL doesn't allow opening of vanilla text files (such as CLZ (Clozure)
sources) under MacOS 10.5.* and 10.6.*.  

(ccl::choose-file-dialog) works fine, but command-O and other API file
openers do not.

Playing with the definition and varying mac-file-type and mac-file-creator
args has not helped.

mac-file-creator is bound to (application-file-creator *application*) which
is :CCL2.  (ccl::CHOOSE-FILE-DIALOG :mac-file-creator "????") does allow
CLZ source files to be chosen.

But I assume file type and creator codes are obsolete now.

Callers found are:
pop-up-path-menu calls (choose-file-dialog :directory item-dir
:mac-file-type "TEXT")
edit-select-file calls (choose-file-dialog :mac-file-type "TEXT")
get-doc-string-file  calls (choose-file-dialog :directory (or
(ignore-errors (probe-file "ccl:")) (startup-directory)) :mac-file-type :HELP)
load calls (choose-file-dialog :button-string "Load")
require calls (choose-file-dialog :button-string "Load" :mac-file-type
'(#-ppc-target :fasl #+ppc-target :pfsl :text))
ed-yank-file calls (choose-file-dialog :mac-file-type :text)

I would far rather err on the side of being allowed to open more file types
rather than less (even if erroneously).  MCL can be a very useful tool for
work in all sorts of situations beyond editing MCL source code.

Has [Tools] [List Definitions] stopped working?

Apple menu: [Tools] [Extensions] [Interface Toolkit] 
then [Design] [Edit Menubar] select File [Edit] =>

error: value (:SHIFT #\S) is not of the expected type CHARACTER.
> While executing: CCL::GRAFPORT-WRITE-CHAR-AT-POINT

Although the old Interface Toolkit may not be so relevant in these Cocoa
days, perhaps the bug crops up elsewhere (I haven't begun looking into it).

The Save... and Save As... navigation dialogs should be window modal (sheets) 
in MacOSX according 
to the UI guidelines.

The directory ccl:Level-0;ppc; seems to be missing from the second (latest)
5.2 distribution.

To reproduce, evaluate:

(trace error)

For each character subsequently typed into the listener, trace will report:

Calling (ERROR #<APPLEEVENT-ERROR #x34F1B56>) 

A backtrace reveals that the event has the class :|tsvc| and the id :|unim| 
(#$kTextService #$kUnicodeNotFromInputMethod).

MCL 6 (currently found in MCLIDE bundle contents) does not seem to have any 
release notes.  It seems unclear what has changed beyond presumably adding 
backtrace-fatality-patch.lisp from "ccl:Patches 6.0;" and the "Mods" directory 
contents (see ccl:Mods;mcl6.lisp). I.e. being integrated into the MCL image 
(Info version: 5.2b6).

on MacOS 10.6.1:

Apropos dialog: terminal whitespace in keys is not trimmed for search.

What steps will reproduce the problem?
1. Attempt to launch RMCL 5.2 on 10.6 (intel) will fail.
2.
3.

What is the expected output? What do you see instead?
I would at least expect to see *SOMETHING!*

What version of the product are you using? On what operating system?
5.2 on 10.6.1

Please provide any additional information below.

Nov  3 20:58:39 c-24-22-23-69 [0x0-0x2b22b2].com.digitool.MCL5.1b1[5958]: 
RMCL(5958,0x1d86ee00) malloc: *** mmap(size=1187840) failed (error code=12)
Nov  3 20:58:39 c-24-22-23-69 [0x0-0x2b22b2].com.digitool.MCL5.1b1[5958]: *** 
error: 
can't allocate region
Nov  3 20:58:39 c-24-22-23-69 [0x0-0x2b22b2].com.digitool.MCL5.1b1[5958]: *** 
set a 
breakpoint in malloc_error_break to debug
Nov  3 20:58:39 c-24-22-23-69 RMCL[5958]: RMCL(5958,0x1d86ee00) malloc: *** 
mmap(size=1187840) failed (error code=12)\n*** error: can't allocate 
region\n*** set a 
breakpoint in malloc_error_break to debug

? (save-application "MCL2" :size `(,(ash 1 26) ,(ash 1 26)))
> Error in process Initial: Invalid :SIZE argument : (67108864 67108864)

? (save-application "MCL2" :size (ash 1 26)
> Error in process Initial: value 67108864 is not of the expected type LIST.

Work-around:

(let* ((handle (#_NewHandle 4)))
  (setf (%hget-unsigned-long handle 0) (ash 1 26))
  (save-application "MCL2" :resources `((,handle "NSIZ" 1))))

Fatal crashes sometimes occur during crashes or errors.

I have tracked this issue to backtracing and the frame-supplied-args function, 
which may call frame-vsp with NIL if that is returned by parent-frame. The 
frame-vsp function will return a bogus value if called with NIL.

(every #'< '(1 2 3) (cdr '(1 2 3)))
=> T

(defun sorted (predicate list)
  (every predicate list (cdr list)))

(sorted #'< '(1 2 3))
=> NIL ; !!!

The RMCL 5.2 distribution displays as version "5.1b1" in the Finder's Get Info 
dialog.

 The following bit of code (originally from MCLIDE) seem to introduce instability that may lead to a hard crash some seconds later:

(destructuring-bind (name command &rest properties &key default install 
&allow-other-keys) imp
    (declare (ignore command properties))

The instability only occurs if both command and properties are ignored.

Using the opentransport module, %io-buffer-stream-write-string from 
io-buffer.lisp ends up in an 
endless loop after a call to clear-output on the stream. The problem seems to 
stem from that io-
buffer-outcount stays at zero forever in the first loop of 
%io-buffer-stream-write-string.

RMCL 5.2 greets the developer with a "Welcome to Macintosh Common Lisp Version 
5.1b1!".

The open-tcp-stream function and the opentransport classes will create a 
passive/listener TCP stream if the 
host is NIL. However, there is no way to create a TCP stream that listens to 
the loopback interface rather than 
making the listener public.

A patch is to use a parameter to pass the loopback address to 
ot-conn-tcp-passive-connect:

(defparameter *passive-interface-address* NIL
  "Address to use for passive connections - optionally bind to loopback address while opening a tcp stream")

 This can be integrated into ot-conn-tcp-passive-connect rather than being an advise:

(advise local-interface-ip-address
 (or *passive-interface-address* (:do-it))
 :when :around :name override-local-interface-ip-address) 

Here is a new open-tcp-listener function that demonstrates the patch - call 
with :loopback as host:

(defun open-tcp-listener (host port &rest rest)
  "Open a passive tcp stream listening at the port, with same keyword arguments as open-tcp-stream. 
Use NIL for host to allow public access and :loopback to only allow connections 
from the computer."
  (declare (dynamic-extent rest))
  (let ((*passive-interface-address* 
         (etypecase host
           (null NIL)
           ((eql :loopback) #.(ccl::get-host-address "127.0.0.1"))
           ((unsigned-byte 32) host)
           (string (ccl::get-host-address host)))))
    (apply #'ccl::open-tcp-stream NIL (or port #$kOTAnyInetAddress) rest)))

(rref wptr windowrecord.visible) seems deprecated
but (#_IsWindowVisible wptr) seem an alternative

What steps will reproduce the problem?
1. call (choose-directory-dialog)
2. eval any expression returning float: value returned will always be 0.0, e.g.

? 3.3
0.0

What is the expected output? What do you see instead?

expected:

? 3.3
3.3

The dock icon bounces for a long time during app startup.

According to Toomas Altosaar:

"The problem was that the 5.2 version of RMCL reserves 1 Gb of RAM 
... which this old machine does not have. So after many minutes of 
startup, the Listener finally appeared. The solution was to use the 
hint presented by Andrew a few days ago on changing the amount of 
memory requested:

I evaled this in the listener:

(let* ((handle (#_NewHandle 4)))
  (setf (%hget-unsigned-long handle 0) (ash 1 29)) ; 1.5 GB ==> 0.5 GB
  (save-application "smaller-rmcl" :resources `((,handle "NSIZ" 1))))

and now the new app called smaller-mcl starts up in a second."

From info-mcl September 17, 2009 11:01:00 AM PDT:

apparent bug in MCL/RMCL  
implementation of expt?

;; problem: dependence of expt on *read-default-float-format*
;; MCL -- causes inappropriate error when *read-default-float-format*  
should not matter
;; RMCL -- crashes the application


(setq *read-default-float-format* 'double-float)

;; appropriate error -- floating point overflow
(null (expt 2.0e7 2.0e7))
Error: FLOATING-POINT-OVERFLOW detected
       performing EXPT on (2.0D+7 2.0D+7)

;; no error
(null (expt 2.0e7 6.0))



(setq *read-default-float-format* 'short-float)

;; appropriate error -- floating point overflow
(null (expt 2.0e7 2.0e7))
Error: FLOATING-POINT-OVERFLOW detected
       performing EXPT on (2.0D+7 2.0D+7)

;; inappropriate error in MCL, crashes RMCL
;; nobody asked for type coercion to short-float!!!!
(null (expt 2.0e7 6.0))
Error: Can't coerce 6.4D+43 to SHORT-FLOAT
While executing: CCL::%DOUBLE-FLOAT->SHORT-FLOAT

--------------

*read-default-float-format* is relevant here:

"Controls the floating-point format that is to be used when reading a  
floating-point number that has noexponent marker or that has e or E  
for an exponent marker."

So 2.0e7 is a double-float if *read-default-float-format* is double- 
float.

The RMCL crash is definitely a bug. I'm not sure why regular MCL is  
working with double-floats when you set *read-default-float-format* to  
short-float.

The dialog resulting from evaluating (choose-new-file-dialog) lists "MCL 5.1 
Document" as one of 
the options (the default) in the Format pop-up menu.