Custom Query (1030 matches)
Results (874 - 876 of 1030)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #1414 | notabug | Unreliable (load <file>) with MacOS Sierra 10.12.5 | ||
| Description |
I'm an average level Common LISP user/programmer, not familiar with the environment's internals, using
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):
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
Sorry for the lengthy report! |
|||
| #1163 | duplicate | Typed structure slot being checked incorrectly | ||
| Description |
Welcome to Clozure Common Lisp Version 1.9-r15758 (DarwinX8632)! ? (defstruct (foo (:constructor make-foo (mask)))
(make-foo 4177526783)
|
|||
| #868 | fixed | Random whacky behaviour (memory corruption?) | ||
| Description |
On moving a Lisp application to a newer Linux box, we get random, whacky behaviour. This is demonstrated by the following file: === process-test.lisp ===
(in-package :cl-user)
(defun big-sum (n)
(let ((total n))
(dotimes (i n total)
(incf total i))))
(defun test ()
(ccl:process-run-function "25" #'big-sum 250000000)
(ccl:process-run-function "26" #'big-sum 260000000)
(ccl:process-run-function "27" #'big-sum 270000000)
(ccl:process-run-function "28" #'big-sum 280000000))
and session transcript: $ uname -a Linux startle 2.6.32-30-generic #59-Ubuntu SMP Tue Mar 1 21:30:21 UTC 2011 i686 GNU/Linux $ ccl Welcome to Clozure Common Lisp Version 1.6 (LinuxX8632)! ? (load "process-test.lisp") #P"/home/startle/startle/process-test.lisp" ? (test) #<PROCESS 28(5) [Reset] #x1828FA76> ? > Error: Fault during read of memory address #x634 > While executing: CCL::*-2, in process 26(3). ;;; ;;; #<PROCESS 26(3) [Active] #x182901B6> requires access to Shared Terminal Input ;;; Type (:y 3) to yield control to this thread. ;;; > Error: value #<BOGUS object @ #x284E4729> is not of the expected type NUMBER. > While executing: CCL::+-2, in process 27(4). ;;; ;;; #<PROCESS 27(4) [Active] #x1828FE16> requires access to Shared Terminal Input ;;; Type (:y 4) to yield control to this thread. ;;; > Error: value #<Unprintable CCL::IMMEDIATE : #x34D0C3> is not of the expected type NUMBER. > While executing: CCL::*-2, in process 28(5). ;;; ;;; #<PROCESS 28(5) [Active] #x1828FA76> requires access to Shared Terminal Input ;;; Type (:y 5) to yield control to this thread. ;;; The exact error messages are variable. Above transcript from x86 Ubuntu 10.04 box; similar behaviour from x86 Centos 5.6. However, x86 Centos 5.3 (and earlier) does not show this, nor does Darwin/PPC (CCL 1.4). |
|||
