From: Nicolas N. <Nic...@iw...> - 2003-10-13 09:15:02
|
Raymond Toy <to...@rt...> writes: > >>>>> "Nicolas" == Nicolas Neuss <Nic...@iw...> writes: > > Nicolas> Nicolas Neuss <Nic...@iw...> writes: > >> Dear maintainers. > >> > >> I would find it nice if a new release or a snapshot of a recent version > >> would be available for download. I am just writing an installation > >> script for my PDE tool box Femlisp where also Matlisp is needed. Since > >> V1.0b does not work any more with Femlisp this would require obtaining a > >> recent > > Nicolas> Correction: "... does not work with new CMUCL versions anymore ..." > > Femlisp or Matlisp? If the latter, I thought I had tried it out > (slightly) with a fairly recent version. (Ooh, maybe it's a defsystem > problem?) Matlisp almost works (Femlisp had more problems). I encounter the following problems with Matlisp: 1. With the snapshot cmucl-2003-10-x86-linux.tar.bz2, I get the following --------------------------------------------------------------------------- ; Loading #p"/home/neuss/FEMLISP/matlisp/start.lisp". ; Converted SETLOGICALROOT. ; Converted GETLOGICALROOT. ; Converted DEFLOGICALPATH. ;; Loading #p"/home/neuss/FEMLISP/matlisp/system.dcl". ;;; Loading #p"/home/neuss/FEMLISP/matlisp/defsystem.lisp". Warning: Old-style IN-PACKAGE. ; Compiling LAMBDA (PCL::.PV-CELL. PCL::.NEXT-METHOD-CALL. KERNEL::OBJECT STREAM): ; Compiling Top-Level Form: ; Compiling LAMBDA (PCL::.PV-CELL. PCL::.NEXT-METHOD-CALL. KERNEL::OBJECT STREAM): ; Compiling Top-Level Form: Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER: #() is not of type (OR CONS BASE-STRING LISP::PATTERN (MEMBER NIL :UNSPECIFIC :WILD)) [Condition of type TYPE-ERROR] Restarts: 0: [CONTINUE] Return NIL from load of "matlisp:system.dcl". 1: Return NIL from load of "start.lisp". 2: [ABORT ] Skip remaining initializations. Debug (type H for help) ("DEFUN MAKE-PATHNAME" 268431142 8)[:OPTIONAL] Source: Error finding source: Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists: target:code/pathname.lisp. 0] --------------------------------------------------------------------------- 2. This works with cmucl-2003-09-14-x86-linux.tar.bz2. I still get a conflict when loading the following package definition: (defpackage "ALGEBRA" (:use "COMMON-LISP" "GENERAL" "MACROS" "UTILITIES" "MATLISP") (:import-from "EXTENSIONS" "REQUIRED-ARGUMENT") (:export ...)) Namely: --------------------------------------------------------------------------- Error in function USE-PACKAGE: Use'ing package COMMON-LISP results in name conflicts for these symbols: (MATLISP:REAL MATLISP:REAL) [Condition of type SIMPLE-ERROR] Restarts: 0: [CONTINUE] Unintern the conflicting symbols in the ALGEBRA package. 1: Return NIL from load of "/home/neuss/FEMLISP/femlisp/src/algebra/algebra-defp.lisp". 2: Return NIL from load of "/home/neuss/FEMLISP/femlisp/src/start.lisp". 3: [ABORT ] Skip remaining initializations. --------------------------------------------------------------------------- After pressing RETURN here, everything works fine. > Nicolas> Maybe it would be time for a new release anyhow. 1.0b is about 3 years > Nicolas> old! > > Sorry, laziness on my part. And now it's in an somewhat incomplete > state because I've been modifying the matrix-ref methods to use clos > to dispatch instead of the hand-written dispatcher. Yes, "ref.lisp" looks a little messy now. Did it help in performance? I think that the separation in 1d and 2d access is right, at least it fitted well with my extensions. > I will however create a snapshot sometime soon, after some testing > with a recent CMUCL version. > > Ray > I'm looking forward to that snapshot... Nicolas. |