[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Several Problems



Here are several issues that I have been saving up to ask help on.


a)
Every once in a while MCL seems to change the handling of floats.
This seems to occur after I have been using MCL for a long time...
Which means that I have performed all sort of calculations, 
undoubtedly aborted several operations, and generally used all
aspects of the system extensivly.

Today, having just started up I get correct behavior:

;;; <<<<<<<<<<<<<<<<<<<<<<<<<

? 0.9
0.9
? 1.0
1.0
? '(0.9 .1 .2 .3)
(0.9 0.1 0.2 0.3)
? (/ 0.0)
> Error: Can't divide by zero.
> While executing: /
> Type Command-. to abort.
See the RestartsI menu item for further choices.
1 > 
Aborted
? (exp (/ 1.0 (* -2 (- 1 (* 1 1)))))
> Error: Can't divide by zero.
> While executing: /
> Type Command-. to abort.
See the RestartsI menu item for further choices.
1 > 
Aborted
? 
;;; <<<<<<<<<<<<<<<<<<<<<<<<<

However on 4-FEB-93--before patch 1&2--I got:

? (/ 0.0)  
1.797693134862316E+308

? 
(exp (/ 1.0 (* -2 (- 1 (* 1 1)))))
1.797693134862316E+308

Which is of course MOST-POSITIVE-DOUBLE-FLOAT==
Value:1.7976931348623157E+308

;;; <<<<<<<<<<<<<<<<<<<<<<<<<

However on 16-JUN-93--WITH PATCH 1&2--after running for some time I
get:

? (format nil "~s" (list 0.90 .1 .2 .3))
"(0.8999999999999999 0.09999999999999999 0.19999999999999998 0.3)"
? 0.90
0.8999999999999999
? 1.0
1.0000000000000002
? (list 0.90 .1 .2 .3)
(0.8999999999999999 0.09999999999999999 0.19999999999999998 0.3)


In most cases this is rather inocuous except for formatting
but sometimes the calculations are wrong due to roundoff
as when a program branches based on a number being <= 1.

This rounding off appears to be random, once it starts to
occur.  That is once it starts to occur it is mostly 
persistent, but once in a while normal behavior occurs, which
makes the program extremely difficult to debug.

;;;
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxx ;;;
;;; <<<<<<<<<<<<<<<<<<<<<<<<<      >>>>>>>>>>>>>>>>>>>>>>>>> ;;;

b)

How can I set a package for (dialog) window's I create.
They seem to acquire the package of the listener at creation time,
so normally I set the package of the window and then create the
(dialog)
window.  This allows parameters or function names to evaluate
correctly 
inside dialog items.  

Using :window-package does not work as an init-argument to the
(dialog) window.  Nor does (set-window-package window) work.

;;; <<<<<<<<<<<<<<<<<<<<<<<<<      >>>>>>>>>>>>>>>>>>>>>>>>> ;;;

c)
Why is it that MCL crashes when WINDOW-HARDCOPY is sent a TRUE 
optional show-dialog? argument?  It usually crashes on the second
job.  I like to print series of drawings or folders of source code
and having to do this manually is quirky.  Does anyone have a 
solution.  Unfortunately I am printing on an ImagewriterII at the
moment which apparently clobbers the Gworld.


;;; <<<<<<<<<<<<<<<<<<<<<<<<<      >>>>>>>>>>>>>>>>>>>>>>>>> ;;;


d)
When I save an application with my own top-level function, which
simply makes sure that the user has been assigned a password
and then passes control to the normal #'TOPLEVEL-LOOP, I can
no longer dubble click on a document (or fasl file) and have it 
open (or load) with the application.  The application launches
correctly, but I have to go back to click on the document to
get it to open.

(defun SECURE-STARTUP ()
  (loop (when (logon)
          (return 'security-okay)
          ))
  (%set-toplevel #'TOPLEVEL-LOOP)
  )

I thought that the following code mentioned in the DIGEST might fix
it

;; Our development version already has this change back to opening
the file
;; immediately. Will put it in patch 3 as well. Here's the fix.

(in-package :ccl)

(defmethod open-application-document ((a application) path &optional
startup)
  (declare (ignore startup))
  (let ((type (mac-file-type path)))
    (if (eq type :fasl)
      (with-simple-restart (continue "Skip loading finder-selected
file.")
        (load path)
        t)
      (when (eq type :text)
       (ed path)
        nil))))

But in and of itself it does not correct the problem.  Do I need to
put
this funcall in my start-up-loop, or push it onto one of the startup
lists of functions like *LISP-STARTUP-FUNCTIONS* or
*restore-lisp-functions* ???