Hi,
what follows is, as far as I am concerned, an observation, and not a bug report. Maybe it is an interesting issue to keep in mind.
So I upgraded to the new asdf, and observed the following. When I load matlisp with the .asd attached, I get an error that goes like this
/usr/bin/ld: cannot open output file /home/mommer/.cache/common-lisp/sbcl-1.0.37-linux-x86-64/home/mommer/dev/matlisp/lib/libmatlisp.so: No such file or directory collect2: ld returned 1 exit status
The reason for the ld error is that that ^.*/lib/.* does not exist, and again the reason seems to be this: (slightly edited)
-------------- [...]
(defsystem :matlisp :components ((:unix-dso "alien code" :pathname "" :dso-name "lib/libmatlisp" ;; barf :components ((:alien-module "BLAS" :pathname "LAPACK/BLAS/SRC/" [...] ----------------
I presume one can defend the new asdf here, and I can fix it for me by removing the "lib/" as it does not matter one iota. But I also would expect this to come up again.
Regards, Mario.
Oh and the .asd:
;;; -*- Mode: lisp; Syntax: ansi-common-lisp; Base: 10 -*- ;;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; ;;; Copyright (c) 2000 The Regents of the University of California. ;;; All rights reserved. ;;; ;;; Permission is hereby granted, without written agreement and without ;;; license or royalty fees, to use, copy, modify, and distribute this ;;; software and its documentation for any purpose, provided that the ;;; above copyright notice and the following two paragraphs appear in all ;;; copies of this software. ;;; ;;; IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY ;;; FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ;;; ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF ;;; THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF ;;; SUCH DAMAGE. ;;; ;;; THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES, ;;; INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF ;;; MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE ;;; PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF ;;; CALIFORNIA HAS NO OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ;;; ENHANCEMENTS, OR MODIFICATIONS. ;;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; ;;; $Id: matlisp.lisp,v 1.21 2003/06/01 15:21:59 rtoy Exp $ ;;; ;;; $Log: matlisp.lisp,v $ ;;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;(in-package "COMMON-LISP-USER")
(defpackage :matlisp.system (:use :cl :asdf))
(in-package :matlisp.system)
(defvar *fortran-compiler* "gfortran") (defvar *c-compiler* "gcc") (defvar *linker* "gfortran")
;; just warn on warnings. Some of the f2cl generated files cause problems ;; without this. See http://article.gmane.org/gmane.lisp.cclan.general/206 (setf asdf:*compile-file-failure-behaviour* :warn)
;;;BEGIN: code to do alien-files (defclass unix-dso (module) ((dso-name :reader dso-name :initarg :dso-name)))
(defun unix-name (pathname) (namestring (typecase pathname (logical-pathname (translate-logical-pathname pathname)) (t pathname))))
;; FIXME: this needs to know about alien-modules (defmethod asdf::input-files ((operation compile-op) (dso unix-dso)) (mapcar #'component-pathname (module-components dso))) ; (mapcar #'(lambda (x) ; (funcall #'asdf::input-files operation x)) ; (module-components dso)))
(defmethod output-files ((operation compile-op) (dso unix-dso)) (let ((dir (component-pathname dso))) (list (make-pathname :type "so" :name (dso-name dso) ;(car (last (pathname-directory dir))) :directory (pathname-directory dir) ;; (butlast (pathname-directory dir)) :defaults dir))))
(defclass alien-module (module) ())
(defmethod output-files ((op compile-op) (m alien-module)) (mapcan (lambda (c) (output-files op c)) (module-components m)))
(defmethod perform :after ((operation compile-op) (dso unix-dso)) (let ((dso-name (unix-name (car (output-files operation dso))))) (unless (or (operation-done-p operation dso) (zerop (run-shell-command "~A ~A -o ~S ~{~S ~} ~A" *linker* ; (if (sb-ext:posix-getenv "LDFLAGS") ; (sb-ext:posix-getenv "LDFLAGS") #+sunos "-shared -lresolv -lsocket -lnsl" #+darwin "-bundle -flat_namespace -undefined suppress" #-(or darwin sunos) "-shared" ; ) dso-name (mapcar #'unix-name (mapcan (lambda (c) (output-files operation c)) (module-components dso))) #+darwin ; "-L/sw/lib -lg2c -lm" ;;probably need more here... "-L/sw/lib -lf2c -lSystem -lcc_dynamic /usr/lib/bundle1.o" #-darwin "")));"-L/usr/lib/gcc-lib/i486-linux/3.3.3 -L/usr/lib/gcc-lib/i486-linux/3.3.3/../../.. -lfrtbegin -lg2c -lm"))) (error 'operation-error :operation operation :component dso))))
(defmethod perform ((o load-op) (c unix-dso)) (let ((co (make-instance 'compile-op))) (let ((filename (car (output-files co c)))) #+cmu (ext:load-foreign filename) #+sbcl (sb-alien:load-shared-object filename))))
(defclass fortran-source-file (source-file) ()) (defmethod asdf:source-file-type ((f fortran-source-file) (s module)) "f")
(defmethod output-files ((op compile-op) (f fortran-source-file)) (list (make-pathname :type "o" :defaults (component-pathname f))))
(defmethod perform ((op compile-op) (f fortran-source-file)) (unless (= 0 (run-shell-command "~A ~A -o ~S -c ~S" *fortran-compiler* #+darwin "-fPIC -O3" #-darwin "-fPIC -O3" (unix-name (car (output-files op f))) (unix-name (component-pathname f)))) (error 'operation-error :operation op :component f)))
(defmethod perform ((operation load-op) (f fortran-source-file)) t)
(defclass brittle-fortran-source-file (source-file) ()) (defmethod asdf:source-file-type ((f brittle-fortran-source-file) (s module)) "f")
(defmethod output-files ((op compile-op) (f brittle-fortran-source-file)) (list (make-pathname :type "o" :defaults (component-pathname f))))
(defmethod perform ((op compile-op) (f brittle-fortran-source-file)) (unless (= 0 (run-shell-command "~A ~A -o ~S -c ~S" *fortran-compiler* #+darwin "-fPIC -O0" #-darwin "-fPIC -O0" (unix-name (car (output-files op f))) (unix-name (component-pathname f)))) (error 'operation-error :operation op :component f)))
(defmethod perform ((operation load-op) (f brittle-fortran-source-file)) t)
;;;END: code to do alien-files
;; This is for macros.l which has a nonstandard suffix. (defclass cl-source-file* (cl-source-file) ()) (defmethod asdf:source-file-type ((c cl-source-file*) (s module)) "l")
(defsystem :matlisp ; :depends-on ("lazy-loader" ; "matlisp-packages") :components ((:unix-dso "alien code" :pathname "" :dso-name "libmatlisp" :components ((:alien-module "BLAS" :pathname "LAPACK/BLAS/SRC/" :components #.(mapcar (lambda (x) `(:fortran-source-file ,x)) '("dgemm" "dswap" "dtrmv" "lsame" "zdotu" "zhemv" "ztrmv" "dgemv" "dsymv" "dtrsm" "zher2" "ztrsm" "dasum" "dger" "dsyr" "dtrsv" "zdscal" "zher2k" "ztrsv" "daxpy" "dsyr2" "dzasum" "xerbla" "zgemm" "zherk" "dcabs1" "dnrm2" "dsyr2k" "dznrm2" "zaxpy" "zgemv" "zscal" "dcopy" "drot" "dsyrk" "idamax" "zcopy" "zgerc" "zswap" "ddot" "dscal" "dtrmm" "izamax" "zdotc" "zgeru" "ztrmm" "dsymm"))) (:alien-module "LAPACK" :pathname "LAPACK/SRC/" :components #.(cons '(:brittle-fortran-source-file "dlamch") (mapcar (lambda (x) `(:fortran-source-file ,x)) '("dlasq5" "dlasq6" "ieeeck" "zdrot" "dlabad" "dlarf" "dorglq" "zhetd2" "zlatrs" "dbdsqr" "dlabrd" "dlarfb" "dorgql" "zhetrd" "zpotf2" "dgebak" "dlacon" "dlarfg" "dorgqr" "zhseqr" "zpotrf" "dgebal" "dlacpy" "dlarft" "dorgtr" "zbdsqr" "zlabrd" "zrot" "dgebd2" "dladiv" "dlarfx" "dorm2r" "zdrscl" "zlacgv" "zsteqr" "dgebrd" "dlae2" "dlartg" "dormbr" "zgebak" "zlacon" "ztrevc" "dgeesx" "dlaev2" "dlas2" "dorml2" "zgebal" "zlacpy" "ztrexc" "dgeev" "dlaexc" "dlascl" "dormlq" "zgebd2" "zladiv" "ztrsen" "dgehd2" "dlag2" "dlaset" "dormqr" "zgebrd" "zlahqr" "ztrsyl" "dgehrd" "dlahqr" "dlasq1" "drscl" "zgeesx" "zlahrd" "zung2l" "dgelq2" "dlahrd" "dlasq2" "dsteqr" "zgeev" "zlange" "zung2r" "dgelqf" "dlaln2" "dlasq3" "dsterf" "zgehd2" "zlanhe" "zungbr" "dgelss" "dlasq4" "dsyev" "zgehrd" "zlanhs" "zunghr" "dgeqp3" "dlaqp2" "dlaqps" "zgeqp3" "zlaqp2" "zlaqps" "dgeqpf" "dlasr" "dsytd2" "zgelq2" "zlarf" "zungl2" "dgeqr2" "dlasrt" "dsytrd" "zgelqf" "zlarfb" "zunglq" "dgeqrf" "dlassq" "dtrevc" "zgelss" "zlarfg" "zungql" "dlasv2" "dtrexc" "zgeqpf" "zlarft" "zungqr" "dgesvd" "dtrsen" "zgeqr2" "zlarfx" "zungtr" "dgetf2" "dlange" "dlasy2" "dtrsyl" "zgeqrf" "zlartg" "zunm2r" "dlanhs" "dlatrd" "dzsum1" "zlascl" "zunmbr" "dlanst" "dorg2l""ilaenv" "zgesvd" "zlaset" "zunml2" "dggbal" "dlansy" "dorg2r""izmax1" "zgetf2" "zlasr" "zunmlq" "dgghrd" "dlanv2" "dorgbr" "zlassq" "zunmqr" "dhgeqz" "dlapy2" "dorghr" "dhseqr" "dlapy3" "dorgl2" "zheev" "zlatrd" ;;Atlas lapack objects "dgetrf" "zgetrf" "dgetrs" "zgetrs" "dlaswp" "zlaswp" "dgesv" "zgesv" )))) (:alien-module "DFFTPACK" :pathname "dfftpack/" :components #.(mapcar (lambda (x) `(:fortran-source-file ,x)) '("zfftb" "cfftb1" "zfftf" "cfftf1" "zffti" "cffti1" "dcosqb" "cosqb1" "dcosqf" "cosqf1" "dcosqi" "dcost" "dcosti" "ezfft1" "dzfftb" "dzfftf" "dzffti" "passb" "passb2" "passb3" "passb4" "passb5" "passf" "passf2" "passf3" "passf4" "passf5" "radb2" "radb3" "radb4" "radb5" "radbg" "radf2" "radf3" "radf4" "radf5" "radfg" "dfftb" "rfftb1" "dfftf" "rfftf1" "dffti" "rffti1" "dsinqb" "dsinqf" "dsinqi" "dsint" "sint1" "dsinti"))) (:alien-module "CPOLY" :pathname "lib-src/cpoly/" :components ((:fortran-source-file "cpoly"))) (:alien-module "SPECFUN" :pathname "lib-src/toms715/" :components #.(mapcar (lambda (x) `(:fortran-source-file ,x)) '("anorm" "besei0" "besei1" "besek0" "besek1" "besi0" "besi1" "besj0" "besj1" "besk0" "besk1" "besy0" "besy1" "calcei" "calci0" "calci1" "calck0" "calck1" "calerf" "caljy0" "caljy1" "daw" "derf" "derfc" "derfcx" "dgamma" "dlgama" "dsubn" "ei" "eone" "expei" "machar" "psi" "ribesl" "rjbesl" "rkbesl" "rybesl"))))) (:file "packages") #+(or) ;; asdf now does the loading (:module "alien code" :pathname "lib/" :depends-on ("packages") :components ((:file "lazy-loader"))) (:module "foreign-interface" :pathname "src/" :depends-on ("packages" "alien code") :components ((:file "f77-mangling") #+:cmu (:file "ffi-cmu") #+:sbcl (:file "ffi-sbcl") #+:allegro (:file "ffi-acl") )) (:module "foreign-functions" :pathname "src/" :depends-on ("foreign-interface" "alien code") :components ((:file "blas") (:file "lapack") #-:mswindows (:file "dfftpack") #+nil (:file "ranlib"))) (:module "matlisp-essentials" :pathname "src/" :depends-on ("foreign-interface" "foreign-functions" "alien code") :components ((:file "conditions") (:file "matrix") (:file "ref") (:file "print") (:file "copy"))) (:module "matlisp-blas-wrappers" :pathname "src/" :depends-on ("foreign-interface" "foreign-functions" "matlisp-essentials" "alien code") :components ((:file "axpy") (:file "scal") (:file "swap") (:file "gemm")))
(:module "matlisp-lapack-wrappers" :pathname "src/" :depends-on ("foreign-interface" "foreign-functions" "matlisp-essentials" "alien code") :components ((:file "gesv") (:file "geev") (:file "getrf") (:file "getrs") (:file "trsv")))
(:module "matlisp-functions" :pathname "src/" :depends-on ("foreign-interface" "foreign-functions" "matlisp-essentials" "matlisp-blas-wrappers" "matlisp-lapack-wrappers" "alien code") :components ((:file "compat") (:file "help") (:file "diag") (:file "special") (:file "reader") (:file "trans") (:file "realimag") (:file "reshape") (:file "join") (:file "svd") (:file "sum") (:file "norm") (:file "dot") (:file "trace") (:file "seq") (:file "vec") (:file "map") (:file "mplus") (:file "mminus") (:file "mtimes") (:file "mdivide") (:file "msqrt") #-:mswindows (:file "fft") (:file "geqr"))) (:module "special-functions" :pathname "src/" :depends-on ("matlisp-functions" "alien code") :components ((:file "specfun"))) ;; Various add-on packages for matlisp ;; This is just the f2cl macros we need, not all of f2cl. (:module "f2cl-macros" :pathname "lib-src/" ; :source-extension "l" :components ((:cl-source-file* "macros"))) ;; This is Quadpack, converted from the Fortran ;; implementation to Lisp via f2cl. (:module "quadpack-functions" :pathname "" ; :source-pathname "" ; :binary-pathname "" :depends-on ("f2cl-macros" "alien code") :components ((:module "quadpack-interface" :pathname "src/" :components ((:file "quadpack"))) (:module "quadpack-lib" :pathname "lib-src/quadpack/" ;; :package "QUADPACK" :components ( #+nil (:module mach-par :components ((:file "d1mach") (:file "i1mach"))) (:module src ;; :depends-on ("mach-par") :pathname "" :components ( ;; Support (:file "dqwgtf") (:file "dqcheb") (:file "dqk15w") (:file "dqwgts") (:file "dqwgtc") (:file "dgtsl") (:file "xerror")
;; Core integration routines (:file "dqk15") (:file "dqk31") (:file "dqk41") (:file "dqk51") (:file "dqk61") (:file "dqk21") (:file "dqk15i") (:file "dqelg") (:file "dqpsrt") (:file "dqc25s" :depends-on ("dqcheb" "dqk15w")) (:file "dqmomo") (:file "dqc25c" :depends-on ("dqcheb" "dqk15w")) (:file "dqc25f" :depends-on ("dgtsl" "dqcheb" "dqk15w" "dqwgtf")) ;; Basic integrators (:file "dqage" :depends-on ("dqk15" "dqk31" "dqk41" "dqk51" "dqk61" "dqk21" "dqpsrt")) (:file "dqagie" :depends-on ("dqelg" "dqk15i" "dqpsrt")) (:file "dqagpe" :depends-on ("dqelg" "dqpsrt" "dqk21" )) (:file "dqagse" :depends-on ("dqk21" "dqelg" "dqpsrt")) (:file "dqawfe" :depends-on ("dqagie" "dqawoe" "dqelg")) (:file "dqawoe" :depends-on ("dqc25f" "dqpsrt" "dqelg")) (:file "dqawse" :depends-on ("dqc25s" "dqmomo" "dqpsrt")) (:file "dqawce" :depends-on ("dqc25c" "dqpsrt")) ;; Simplified interface routines (:file "dqng" :depends-on ("xerror")) (:file "dqag" :depends-on ("dqage" "xerror")) (:file "dqags" :depends-on ("dqagse" "xerror")) (:file "dqagi" :depends-on ("dqagie" "xerror")) (:file "dqawf" :depends-on ("dqawfe" "xerror")) (:file "dqawo" :depends-on ("dqawoe" "xerror")) (:file "dqaws" :depends-on ("dqawse" "xerror")) (:file "dqawc" :depends-on ("dqawce" "xerror")))))))) (:module "minpack-functions" :depends-on ("f2cl-macros" "alien code") :pathname "" :components ( #+nil (:module "quadpack-interface" :pathname "src/" :components ((:file "quadpack"))) (:module "minpack-lib" :pathname "lib-src/minpack/" ;; :package "MINPACK" :components ((:file "dpmpar") (:file "enorm") (:file "fdjac2") (:file "qrsolv") (:file "lmpar") (:file "qrfac") (:file "lmdif") (:file "lmdif1") (:file "lmder") (:file "lmder1") (:file "dogleg") (:file "qform") (:file "r1mpyq") (:file "r1updt") (:file "hybrj" :depends-on ("dogleg" "qform" "r1mpyq" "r1updt")) (:file "hybrj1" :depends-on ("hybrj")) )))) (:module "lib-src" :components (#+nil (:file "d1mach" :package "MATLISP-LIB") (:module "cpoly" :components ((:file "cpoly") (:file "zeroin"))) #+(or :cmu :sbcl) (:module "gnuplot" :components ((:file "gnuplot")))))))
;; needed for lazy-loader
(setf (logical-pathname-translations "matlisp") (let ((matlisp-pathname (asdf:component-pathname (asdf:find-system :matlisp)))) `(("**;*.*.*" ,(namestring (merge-pathnames "**/*.*" matlisp-pathname))) ("*.*.*" ,(namestring (merge-pathnames "*.*" matlisp-pathname))))))
OK, so there's this dso that at some point ASDF thinks should be in a translated path, but isn't.
1- First you might want to have a method like this one to create the output directories:
(defmethod perform :before ((operation compile-op) (c unix-dso)) (map nil #'ensure-directories-exist (output-files operation c)))
(a similar method on source-file is defined in asdf.lisp)
2- Second, if you do NOT want your dso to be created in the cache, but instead to have it in the source directory (or whichever directory you want), then your output-files method should return (values (list ...) t) instead of just the (list ...).
Hope this helps.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Well, the fact is, God does exist and I'm His prophet. And my prophecy is that you shouldn't believe in God, for it would be a blasphemy against His gift of Reason to you. So don't you believe in Him, lest you go to Hell!
Hi,
there is an additional problem with matlisp.asd, and that is that it recompiles everything (but not the fortran code) everytime I load the system, even though I have loaded it before into the same lisp, and even though everything was already compiled before.
From looking at the .asd I have no clue about what might be wrong. Any
ideas on what to look for?
Regards, and thanks,
Mario
Does it work better with ASDF 1.672? If not, you might have to define some method for operation-done-p or some such.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] The equation that makes a harmonous society of free individuals: LIBERTY = RESPONSIBILITY = PROPERTY
On 9 April 2010 15:45, Mario S. Mommer m_mommer@yahoo.com wrote:
Hi,
there is an additional problem with matlisp.asd, and that is that it recompiles everything (but not the fortran code) everytime I load the system, even though I have loaded it before into the same lisp, and even though everything was already compiled before.
From looking at the .asd I have no clue about what might be wrong. Any ideas on what to look for?
Regards, and thanks,
Mario
asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Faré fahree@gmail.com writes:
Does it work better with ASDF 1.672? If not, you might have to define some method for operation-done-p or some such.
No, unfortunately it does not work better.
And operation-done-p is returning T's and NIL's with the new asdf as well as with the one packaged with sbcl, but the latter simply does not take that as a reason to recompile the lisp files, while the former does, or recompiles them for some other reason.
Regards, Mario
Ahem. I admit this is a part of ASDF I am not familiar with.
What does traverse return? Can you trace every exported defgeneric in ASDF and attach to a launchpad bug traces of what happens in either ASDF 1 or ASDF 2?
Sorry I'm not being very helpful.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] |/ ____ |/ ~@-/ oO -@~ /_( __/ )_\ __U_/
On 9 April 2010 23:45, Mario S. Mommer m_mommer@yahoo.com wrote:
Faré fahree@gmail.com writes:
Does it work better with ASDF 1.672? If not, you might have to define some method for operation-done-p or some such.
No, unfortunately it does not work better.
And operation-done-p is returning T's and NIL's with the new asdf as well as with the one packaged with sbcl, but the latter simply does not take that as a reason to recompile the lisp files, while the former does, or recompiles them for some other reason.
Regards, Mario
asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Hello,
Faré fahree@gmail.com writes:
Ahem. I admit this is a part of ASDF I am not familiar with.
What does traverse return? Can you trace every exported defgeneric in ASDF and attach to a launchpad bug traces of what happens in either ASDF 1 or ASDF 2?
I can try. For now I made a much smaller .asd, whith a defsystem that looks like this:
(defsystem :matlispbug :components ((:unix-dso "alien code" :pathname "" :dso-name "libmatlisp" :components ((:alien-module "CPOLY" :pathname "lib-src/cpoly/" :components ((:fortran-source-file "cpoly"))))) (:file "packages") (:module "foreign-interface" :pathname "src/" :depends-on ("packages" "alien code") :components ((:file "f77-mangling") (:file "ffi-sbcl")))))
and that shows the behavior of interest. That is, with the new asdf, the module "foreign-interface" gets compiled every time I load the system, whereas under the old asdf that does not happen. From staring at the source of the .asd, I haven't been able to see what is wrong.
I have uploaded a tarball with an abridged (to reduce size) version of matlisp to common-lisp.net, in case anyone wants to try:
http://common-lisp.net/~mmommer/matlispasdfissue.tar.gz
The shortened .asd is called matlispbug.asd.
To readers in the future: I will remove the file as soon as this issue is resolved, and then this link will be broken.
Regards, and thanks,
Mario.
good afternoon;
if one invoked load-system with the factors traced which contribute to done-ness, it reads as if operation-done-p needs to be specialized for modules to delegate to the constituents. of the asdf/test/*module*.asd examples, there is one which has a similar structure. it is not obvious clear why the matlisp .asd behaves differently.
On 2010-04-11, at 13:28 , Mario S. Mommer wrote:
Hello,
Faré fahree@gmail.com writes:
Ahem. I admit this is a part of ASDF I am not familiar with.
What does traverse return? Can you trace every exported defgeneric in ASDF and attach to a launchpad bug traces of what happens in either ASDF 1 or ASDF 2?
I can try. For now I made a much smaller .asd, whith a defsystem that looks like this:
(defsystem :matlispbug :components ((:unix-dso "alien code" :pathname "" :dso-name "libmatlisp" :components ((:alien-module "CPOLY" :pathname "lib-src/cpoly/" :components ((:fortran-source-file "cpoly"))))) (:file "packages") (:module "foreign-interface" :pathname "src/" :depends-on ("packages" "alien code") :components ((:file "f77-mangling") (:file "ffi-sbcl")))))
and that shows the behavior of interest. That is, with the new asdf, the module "foreign-interface" gets compiled every time I load the system, whereas under the old asdf that does not happen. From staring at the source of the .asd, I haven't been able to see what is wrong.
I have uploaded a tarball with an abridged (to reduce size) version of matlisp to common-lisp.net, in case anyone wants to try:
http://common-lisp.net/~mmommer/matlispasdfissue.tar.gz
The shortened .asd is called matlispbug.asd.
To readers in the future: I will remove the file as soon as this issue is resolved, and then this link will be broken.
Regards, and thanks,
Mario.
asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Unfortunately, I don't believe this is possible. This is YA problem arising from the fact that asdf has no object that stands for the module with it's components. Operation-done-p on a module doesn't mean the op is done on this module & components, only on the suffix of the module after it's components.
E.g., if you have a module m & component c, for op o, you will see first (perform o c) Then (perform o m) In the plan, so operation-done-p does not prevent doing o on c, only on the m object itself.
Traverse does a postorder traversal on the system tree.
I could not figure out how to fix this while maintaining any semblance of backward compatibility.
On Apr 11, 2010, at 8:09, james anderson james.anderson@setf.de wrote:
good afternoon;
if one invoked load-system with the factors traced which contribute to done-ness, it reads as if operation-done-p needs to be specialized for modules to delegate to the constituents. of the asdf/test/*module*.asd examples, there is one which has a similar structure. it is not obvious clear why the matlisp .asd behaves differently.
On 2010-04-11, at 13:28 , Mario S. Mommer wrote:
Hello,
Faré fahree@gmail.com writes:
Ahem. I admit this is a part of ASDF I am not familiar with.
What does traverse return? Can you trace every exported defgeneric in ASDF and attach to a launchpad bug traces of what happens in either ASDF 1 or ASDF 2?
I can try. For now I made a much smaller .asd, whith a defsystem that looks like this:
(defsystem :matlispbug :components ((:unix-dso "alien code" :pathname "" :dso-name "libmatlisp" :components ((:alien-module "CPOLY" :pathname "lib-src/cpoly/" :components ((:fortran-source-file "cpoly"))))) (:file "packages") (:module "foreign-interface" :pathname "src/" :depends-on ("packages" "alien code") :components ((:file "f77-mangling") (:file "ffi-sbcl")))))
and that shows the behavior of interest. That is, with the new asdf, the module "foreign-interface" gets compiled every time I load the system, whereas under the old asdf that does not happen. From staring at the source of the .asd, I haven't been able to see what is wrong.
I have uploaded a tarball with an abridged (to reduce size) version of matlisp to common-lisp.net, in case anyone wants to try:
http://common-lisp.net/~mmommer/matlispasdfissue.tar.gz
The shortened .asd is called matlispbug.asd.
To readers in the future: I will remove the file as soon as this issue is resolved, and then this link will be broken.
Regards, and thanks,
Mario.
asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
good afternoon;
reading traverse is not my idea of a good time, but when i persevere, i do not arrive at the same conclusion. in addition, when i specialize a method for operation-done-p for compile-op and module to iterate over the constituents and collect the results, the matlispbug system behaves as my reading of traverse would imply: it compiles the f77/ffi code once only.
the first time through it compiles everything. the second time through it first asks each constituent individually, in turn, if it is done (this is the traverse recursion in its module- ops clause) and then asks each one again as a consequence of asking the module (this is the operation-done-p for the module itself in the when clause). if the results are consistently "done", the dependents do not recompile.
?
nb. if the method is specialized on (operation component), things do not turn out well, but that looks like it may be unrelated to the general issue and instead an interaction with the particular way the system's specialized components implements compilation.
On 2010-04-11, at 15:48 , Robert P. Goldman wrote:
Unfortunately, I don't believe this is possible. This is YA problem arising from the fact that asdf has no object that stands for the module with it's components. Operation-done-p on a module doesn't mean the op is done on this module & components, only on the suffix of the module after it's components.
E.g., if you have a module m & component c, for op o, you will see first (perform o c) Then (perform o m) In the plan, so operation-done-p does not prevent doing o on c, only on the m object itself.
Traverse does a postorder traversal on the system tree.
I could not figure out how to fix this while maintaining any semblance of backward compatibility.
On Apr 11, 2010, at 8:09, james anderson james.anderson@setf.de wrote:
good afternoon;
if one invoked load-system with the factors traced which contribute to done-ness, it reads as if operation-done-p needs to be specialized for modules to delegate to the constituents. of the asdf/test/*module*.asd examples, there is one which has a similar structure. it is not obvious clear why the matlisp .asd behaves differently.
On 2010-04-11, at 13:28 , Mario S. Mommer wrote:
Hello,
Faré fahree@gmail.com writes:
Ahem. I admit this is a part of ASDF I am not familiar with.
What does traverse return? Can you trace every exported defgeneric in ASDF and attach to a launchpad bug traces of what happens in either ASDF 1 or ASDF 2?
I can try. For now I made a much smaller .asd, whith a defsystem that looks like this:
(defsystem :matlispbug :components ((:unix-dso "alien code" :pathname "" :dso-name "libmatlisp" :components ((:alien-module "CPOLY" :pathname "lib-src/cpoly/" :components ((:fortran-source-file "cpoly"))))) (:file "packages") (:module "foreign-interface" :pathname "src/" :depends-on ("packages" "alien code") :components ((:file "f77-mangling") (:file "ffi-sbcl")))))
and that shows the behavior of interest. That is, with the new asdf, the module "foreign-interface" gets compiled every time I load the system, whereas under the old asdf that does not happen. From staring at the source of the .asd, I haven't been able to see what is wrong.
I have uploaded a tarball with an abridged (to reduce size) version of matlisp to common-lisp.net, in case anyone wants to try:
http://common-lisp.net/~mmommer/matlispasdfissue.tar.gz
The shortened .asd is called matlispbug.asd.
To readers in the future: I will remove the file as soon as this issue is resolved, and then this link will be broken.
Regards, and thanks,
Mario.
asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
On 4/11/10 Apr 11 -10:28 AM, james anderson wrote:
good afternoon;
reading traverse is not my idea of a good time, but when i persevere, i do not arrive at the same conclusion.
Here is the logic as I understand it. I will cite line numbers. I wish I knew how to do this reliably --- I can only say that these numbers work for me as of this writing (git pull done).
Jargon: I think of this as a tree walk, so use the term "node" and "component" interchangeably. Plan = return value of TRAVERSE; an ordered sequences (specifically a list) of Planops Planop = a piece of a plan: a dotted pair whose car is an operation and whose cdr is a component.
1. L1400: make sure we don't visit the same nodes in the tree > 1. If we have already visited this, skip. A pruned-op may be returned. Check for circular dependencies, and mark this node (component) as in progress (visiting).
2. loop at 1414: check all of the current nodes dependencies. This loop side-effects onto the local variable FORCED. FORCED is going to accumulate all the operations needed for this sub-plan (i.e., the part of the TRAVERSE plan that is generated from the current component).
3. 1421: block that is run only for the benefit of components of type MODULE (which includes SYSTEMs). Note that at the top we bind a number of variables, including the FORCED special, which is the only way to permit us to call do-one-dep here [someday, in my fantasy world, traverse will be rewritten to be purely functional and not side-effect onto FORCED everywhere.]. As a result of running the code in this block, we will bind the MODULE-OPS lexical variable, which tells us what operations need to be performed on the current module.
3.1 1428: MUST-OPERATE is bound to tell us whether the components of the current module must be operated on. The check is whether there is *FORCING* bound around us, or if the component is not a system. This is my attempt to see if the component IS a module simpliciter. [In my ideal world, ASDF would be refactored so that there are three classes --- HAS-COMPONENTS, MODULE and SYSTEM, and MODULE isa HAS-COMPONENTS and SYSTEM isa HAS-COMPONENTS but SYSTEM is no longer a sub-class of MODULE... Currently there is no really reliable way to tell that something is "just" an internal module, since the class hierarchy is mutable...]: (and (not (typep c 'system)) forced) recall that FORCED was bound earlier to the set of planops that must be performed on this node's dependencies.
This was done for backward compatibility, and because we don't have good tests for a system being operated on. Space does not permit me to explain this here.
Note that there is no check here for OPERATION-DONE-P on the module itself. That test is performed downstream.
3.2 1435: Foreach of the module's components, bind *FORCING* to MUST-OPERATE. This ensures that all the modules components will be operated on if any of the module's dependencies have changed. Then traverse each of the component's children, checking for component dependency failures.
4. 1456: If we have a module as our node, then we are done here operating on the module's components and are now working on the module object proper. So you see what I have been saying about the module object representing, at one and the same time, both the module as thing with components AND any post-operations on the module, after the operation has been done on its components (postorder tree traversal).
4.1 Do we need to operate on the object? OR: 1456: are there upstream operations done (FORCED) or were operations done on this components children (if any --- MODULE-OPS)? 1457: are all operations forced (*FORCING*)? 1458: is this operation as yet not done (OPERATION-DONE-P)? As you see, the OPERATION-DONE-P test on a module will be performed AFTER working on its children in step 3. Note that *it must be this way* for backward compatibility. This is a consequence of the double-meaning of MODULE. 1459 - 1470: A test that I do not understand and was too frightened of to remove or rewrite. 1471-1473: The op x component's DO-FIRSTs are processed. 1475-7: accumulate the return values. 1478-9: update the visiting logic
5. Mark the node as visited and return the sub-plan.
I think this analysis bears out my claim. I can't pretend to respond to your experience with this particular system; I can't make MATLISPBUG run on my linux box. Currently, if I try to do load-system on it a second time, it crashes my lisp hard, taking down SLIME. I am updating SLIME and SBCL now, and will try again when I have time.
Hope this analysis helps. Fare, maybe it would be worth writing an article about ASDF and the ASDF2-ing for ILC. This reconstruction might be an important part of such an article.
best, r
1- Would making unix-dso a subclass of component but not of module somehow help solve the problem?
2- I admit I have little familiarity with TRAVERSE. Looking at it makes me shudder. I really don't want to try understanding it enough to be able to modify it in ways that I can say for sure will be backwards compatible with all previous reasonable uses. It's one of the reasons I'd rather spend time on XCVB.
3- To debug with a 32-bit implementation on a 64-bit architecture, give the -m32 flag to gcc. Dunno exactly about ld; same flag or different flag might be needed. Otherwise, you can install a 32-bit chroot installation and run stuff inside it.
4- Is there an ILC this year? Where, when? I could talk about ASDF 2, but I wouldn't be able to talk competently about TRAVERSE. If some kind soul would co-present a paper with me, we could do the whole thing.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Every task involves constraint, Solve the thing without complaint; There are magic links and chains Forged to loose our rigid brains. Structures, strictures, though they bind, Strangely liberate the mind.
On 11 April 2010 17:04, Robert Goldman rpgoldman@sift.info wrote:
On 4/11/10 Apr 11 -10:28 AM, james anderson wrote:
good afternoon;
reading traverse is not my idea of a good time, but when i persevere, i do not arrive at the same conclusion.
Here is the logic as I understand it. I will cite line numbers. I wish I knew how to do this reliably --- I can only say that these numbers work for me as of this writing (git pull done).
Jargon: I think of this as a tree walk, so use the term "node" and "component" interchangeably. Plan = return value of TRAVERSE; an ordered sequences (specifically a list) of Planops Planop = a piece of a plan: a dotted pair whose car is an operation and whose cdr is a component.
- L1400: make sure we don't visit the same nodes in the tree > 1. If
we have already visited this, skip. A pruned-op may be returned. Check for circular dependencies, and mark this node (component) as in progress (visiting).
- loop at 1414: check all of the current nodes dependencies. This
loop side-effects onto the local variable FORCED. FORCED is going to accumulate all the operations needed for this sub-plan (i.e., the part of the TRAVERSE plan that is generated from the current component).
- 1421: block that is run only for the benefit of components of type
MODULE (which includes SYSTEMs). Note that at the top we bind a number of variables, including the FORCED special, which is the only way to permit us to call do-one-dep here [someday, in my fantasy world, traverse will be rewritten to be purely functional and not side-effect onto FORCED everywhere.]. As a result of running the code in this block, we will bind the MODULE-OPS lexical variable, which tells us what operations need to be performed on the current module.
3.1 1428: MUST-OPERATE is bound to tell us whether the components of the current module must be operated on. The check is whether there is *FORCING* bound around us, or if the component is not a system. This is my attempt to see if the component IS a module simpliciter. [In my ideal world, ASDF would be refactored so that there are three classes --- HAS-COMPONENTS, MODULE and SYSTEM, and MODULE isa HAS-COMPONENTS and SYSTEM isa HAS-COMPONENTS but SYSTEM is no longer a sub-class of MODULE... Currently there is no really reliable way to tell that something is "just" an internal module, since the class hierarchy is mutable...]: (and (not (typep c 'system)) forced) recall that FORCED was bound earlier to the set of planops that must be performed on this node's dependencies.
This was done for backward compatibility, and because we don't have good tests for a system being operated on. Space does not permit me to explain this here.
Note that there is no check here for OPERATION-DONE-P on the module itself. That test is performed downstream.
3.2 1435: Foreach of the module's components, bind *FORCING* to MUST-OPERATE. This ensures that all the modules components will be operated on if any of the module's dependencies have changed. Then traverse each of the component's children, checking for component dependency failures.
- 1456: If we have a module as our node, then we are done here
operating on the module's components and are now working on the module object proper. So you see what I have been saying about the module object representing, at one and the same time, both the module as thing with components AND any post-operations on the module, after the operation has been done on its components (postorder tree traversal).
4.1 Do we need to operate on the object? OR: 1456: are there upstream operations done (FORCED) or were operations done on this components children (if any --- MODULE-OPS)? 1457: are all operations forced (*FORCING*)? 1458: is this operation as yet not done (OPERATION-DONE-P)? As you see, the OPERATION-DONE-P test on a module will be performed AFTER working on its children in step 3. Note that *it must be this way* for backward compatibility. This is a consequence of the double-meaning of MODULE. 1459 - 1470: A test that I do not understand and was too frightened of to remove or rewrite. 1471-1473: The op x component's DO-FIRSTs are processed. 1475-7: accumulate the return values. 1478-9: update the visiting logic
- Mark the node as visited and return the sub-plan.
I think this analysis bears out my claim. I can't pretend to respond to your experience with this particular system; I can't make MATLISPBUG run on my linux box. Currently, if I try to do load-system on it a second time, it crashes my lisp hard, taking down SLIME. I am updating SLIME and SBCL now, and will try again when I have time.
Hope this analysis helps. Fare, maybe it would be worth writing an article about ASDF and the ASDF2-ing for ILC. This reconstruction might be an important part of such an article.
best, r
On 4/11/10 Apr 11 -11:42 AM, Faré wrote:
1- Would making unix-dso a subclass of component but not of module somehow help solve the problem?
<blush>I didn't even carefully read the system definition --- I just dug in to trying to make it load. You are right --- I don't see any reason why this should be a subclass of module instead of component.</blush>
2- I admit I have little familiarity with TRAVERSE. Looking at it makes me shudder. I really don't want to try understanding it enough to be able to modify it in ways that I can say for sure will be backwards compatible with all previous reasonable uses. It's one of the reasons I'd rather spend time on XCVB.
Right. I /have/ tried to understand and modify it, and there are still a few corners that I truly don't understand.
3- To debug with a 32-bit implementation on a 64-bit architecture, give the -m32 flag to gcc. Dunno exactly about ld; same flag or different flag might be needed. Otherwise, you can install a 32-bit chroot installation and run stuff inside it.
Thanks.
4- Is there an ILC this year? Where, when? I could talk about ASDF 2, but I wouldn't be able to talk competently about TRAVERSE. If some kind soul would co-present a paper with me, we could do the whole thing.
I would be delighted to coauthor a paper with you about ASDF. I thought the ILC was going to be in Japan. If so, I'm sorry, but my back and height put Japan out of range by coach flight, so no co-presenting! But I've been dying for an excuse to go to Europe for a lisp symposium! ;-)
Best, r
Robert Goldman rpgoldman@sift.info writes:
On 4/11/10 Apr 11 -11:42 AM, Faré wrote:
1- Would making unix-dso a subclass of component but not of module somehow help solve the problem?
<blush>I didn't even carefully read the system definition --- I just dug in to trying to make it load. You are right --- I don't see any reason why this should be a subclass of module instead of component.</blush>
Well, I think it is a module because it has components. In that small example it has only one, but the in the full matlisp.asd there are a few submodules to it.
good evening;
On 2010-04-11, at 18:04 , Robert Goldman wrote:
On 4/11/10 Apr 11 -10:28 AM, james anderson wrote:
good afternoon;
reading traverse is not my idea of a good time, but when i persevere, i do not arrive at the same conclusion.
Here is the logic as I understand it. I will cite line numbers. I wish I knew how to do this reliably --- I can only say that these numbers work for me as of this writing (git pull done).
Jargon: I think of this as a tree walk, so use the term "node" and "component" interchangeably. Plan = return value of TRAVERSE; an ordered sequences (specifically a list) of Planops Planop = a piece of a plan: a dotted pair whose car is an operation and whose cdr is a component.
[1. - 3. ok, but not directly relevant ]
- 1456: If we have a module as our node, then we are done here
operating on the module's components and are now working on the module object proper. So you see what I have been saying about the module object representing, at one and the same time, both the module as thing with components AND any post-operations on the module, after the operation has been done on its components (postorder tree traversal).
4.1 Do we need to operate on the object? OR: 1456: are there upstream operations done (FORCED) or were operations done on this components children (if any --- MODULE-OPS)?
this is where the module's spurious op planup causes the dependent to believe it needs a planop.
[ ... not relevant ] 1458: is this operation as yet not done (OPERATION-DONE-P)? As
you see, the OPERATION-DONE-P test on a module will be performed AFTER working on its children in step 3. Note that *it must be this way* for backward compatibility. This is a consequence of the double- meaning of MODULE.
this is where the method for modules causes the module itself to add a planop.
[... also true, but not relevant]
Hope this analysis helps. Fare, maybe it would be worth writing an article about ASDF and the ASDF2-ing for ILC. This reconstruction might be an important part of such an article.
traverse reads as if the lines most pertinent to this issue are 1417-19, 1435-38, and 1456-58. strip everything else out. it is a straight depth-first walk to collect planops. we can neglect a true force, as none appears here. in which case, a planop is added for a given component depends if either one was added for a dependent (1419 through the recursion at 1334) or the component itself is not done.
where modules are never done, they always generate planops.
here is a transcript with probes of this sort:
(format *trace-output* "~&traverse: (~a ~a) initially: ~s~%" (type-of operation) (asdf:component-name c) forced)
added at lines 1407, 1456, and 1479 and tracing for traverse and perform. you will observer that, when the modules are never done, that contribute to spurious "forced" values for their dependents.
* (asdf:load-system :matlispbug) 0: (ASDF::TRAVERSE #<ASDF:LOAD-OP NIL {B4E07F1}> #<ASDF:SYSTEM "matlispbug" {B046A99}>) traverse: (LOAD-OP matlispbug) initially: NIL 1: (ASDF::TRAVERSE #<ASDF:COMPILE-OP NIL {B4E58C9}> #<ASDF:SYSTEM "matlispbug" {B046A99}>) traverse: (COMPILE-OP matlispbug) initially: NIL 2: (ASDF::TRAVERSE #<ASDF:COMPILE-OP NIL {B4E58C9}> #<ASDF:UNIX-DSO "alien code" {B0F0A91}>) traverse: (COMPILE-OP alien code) initially: NIL 3: (ASDF::TRAVERSE #<ASDF:COMPILE-OP NIL {B4E58C9}> #<MATLISP.SYSTEM::ALIEN-MODULE "CPOLY" {B0F0AA1}>) traverse: (COMPILE-OP CPOLY) initially: NIL 4: (ASDF::TRAVERSE #<ASDF:COMPILE-OP NIL {B4E58C9}> #<MATLISP.SYSTEM::FORTRAN-SOURCE-FILE "cpoly" {B0F0AB1}>) traverse: (COMPILE-OP cpoly) initially: NIL traverse: (COMPILE-OP cpoly) itself: NIL 5: (ASDF:OPERATION-DONE-P #<ASDF:COMPILE-OP NIL {B4E58C9}> #<MATLISP.SYSTEM::FORTRAN- SOURCE-FILE "cpoly" {B0F0AB1}>) 5: ASDF:OPERATION-DONE-P returned T traverse: (COMPILE-OP cpoly) result: NIL 4: ASDF::TRAVERSE returned NIL traverse: (COMPILE-OP CPOLY) itself: NIL 4: (ASDF:OPERATION-DONE-P #<ASDF:COMPILE-OP NIL {B4E58C9}> #<MATLISP.SYSTEM::ALIEN-MODULE "CPOLY" {B0F0AA1}>) 4: ASDF:OPERATION-DONE-P returned NIL traverse: (COMPILE-OP CPOLY) result: ((#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<MATLISP.SYSTEM::ALIEN- MODULE "CPOLY" {B0F0AA1}>)) 3: ASDF::TRAVERSE returned ((#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<MATLISP.SYSTEM::ALIEN-MODULE "CPOLY" {B0F0AA1}>)) traverse: (COMPILE-OP alien code) itself: NIL traverse: (COMPILE-OP alien code) result: ((#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<MATLISP.SYSTEM::ALIEN-MODULE "CPOLY" {B0F0AA1}>) (#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:UNIX-DSO "alien code" {B0F0A91}>)) 2: ASDF::TRAVERSE returned ((#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<MATLISP.SYSTEM::ALIEN-MODULE "CPOLY" {B0F0AA1}>) (#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:UNIX-DSO "alien code" {B0F0A91}>)) 2: (ASDF::TRAVERSE #<ASDF:COMPILE-OP NIL {B4E58C9}> #<ASDF:CL-SOURCE-FILE "packages" {B0F0AC1}>) traverse: (COMPILE-OP packages) initially: NIL traverse: (COMPILE-OP packages) itself: NIL 3: (ASDF:OPERATION-DONE-P #<ASDF:COMPILE-OP NIL {B4E58C9}> #<ASDF:CL-SOURCE-FILE "packages" {B0F0AC1}>) 3: ASDF:OPERATION-DONE-P returned T traverse: (COMPILE-OP packages) result: NIL 2: ASDF::TRAVERSE returned NIL 2: (ASDF::TRAVERSE #<ASDF:COMPILE-OP NIL {B4E58C9}> #<ASDF:MODULE "foreign-interface" {B0F0A61}>) traverse: (COMPILE-OP foreign-interface) initially: NIL 3: (ASDF::TRAVERSE #<ASDF:COMPILE-OP NIL {B4E58C9}> #<ASDF:UNIX-DSO "alien code" {B0F0A91}>) 3: ASDF::TRAVERSE returned ((ASDF::PRUNED-OP . #<ASDF:UNIX-DSO "alien code" {B0F0A91}>)) 3: (ASDF::TRAVERSE #<ASDF:COMPILE-OP NIL {B4E58C9}> #<ASDF:CL-SOURCE-FILE "packages" {B0F0AC1}>) 3: ASDF::TRAVERSE returned NIL 3: (ASDF::TRAVERSE #<ASDF:COMPILE-OP NIL {B4E58C9}> #<ASDF:CL-SOURCE-FILE "f77- mangling" {B0F0A81}>) traverse: (COMPILE-OP f77-mangling) initially: NIL traverse: (COMPILE-OP f77-mangling) itself: NIL traverse: (COMPILE-OP f77-mangling) result: ((#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:CL-SOURCE-FILE "f77- mangling" {B0F0A81}>)) 3: ASDF::TRAVERSE returned ((#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:CL-SOURCE-FILE "f77-mangling" {B0F0A81}>)) 3: (ASDF::TRAVERSE #<ASDF:COMPILE-OP NIL {B4E58C9}> #<ASDF:CL-SOURCE-FILE "ffi-sbcl" {B0F0A71}>) traverse: (COMPILE-OP ffi-sbcl) initially: NIL traverse: (COMPILE-OP ffi-sbcl) itself: NIL traverse: (COMPILE-OP ffi-sbcl) result: ((#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:CL-SOURCE-FILE "ffi-sbcl" {B0F0A71}>)) 3: ASDF::TRAVERSE returned ((#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:CL-SOURCE-FILE "ffi-sbcl" {B0F0A71}>)) traverse: (COMPILE-OP foreign-interface) itself: ((ASDF::PRUNED-OP . #<ASDF:UNIX-DSO "alien code" {B0F0A91}>)) 3: (ASDF::TRAVERSE #<ASDF:LOAD-OP NIL {B5374F1}> #<ASDF:CL-SOURCE-FILE "packages" {B0F0AC1}>) traverse: (LOAD-OP packages) initially: NIL 4: (ASDF::TRAVERSE #<ASDF:COMPILE-OP NIL {B539A09}> #<ASDF:CL-SOURCE-FILE "packages" {B0F0AC1}>) 4: ASDF::TRAVERSE returned NIL traverse: (LOAD-OP packages) itself: NIL 4: (ASDF:OPERATION-DONE-P #<ASDF:LOAD-OP NIL {B5374F1}> #<ASDF:CL-SOURCE-FILE "packages" {B0F0AC1}>) 4: ASDF:OPERATION-DONE-P returned T traverse: (LOAD-OP packages) result: NIL 3: ASDF::TRAVERSE returned NIL 3: (ASDF::TRAVERSE #<ASDF:LOAD-OP NIL {B545431}> #<ASDF:UNIX-DSO "alien code" {B0F0A91}>) traverse: (LOAD-OP alien code) initially: NIL 4: (ASDF::TRAVERSE #<ASDF:COMPILE-OP NIL {B547A09}> #<ASDF:UNIX-DSO "alien code" {B0F0A91}>) 4: ASDF::TRAVERSE returned ((ASDF::PRUNED-OP . #<ASDF:UNIX-DSO "alien code" {B0F0A91}>)) 4: (ASDF::TRAVERSE #<ASDF:LOAD-OP NIL {B545431}> #<MATLISP.SYSTEM::ALIEN-MODULE "CPOLY" {B0F0AA1}>) traverse: (LOAD-OP CPOLY) initially: NIL 5: (ASDF::TRAVERSE #<ASDF:COMPILE-OP NIL {B54D5C1}> #<MATLISP.SYSTEM::ALIEN-MODULE "CPOLY" {B0F0AA1}>) 5: ASDF::TRAVERSE returned ((ASDF::PRUNED-OP . #<MATLISP.SYSTEM::ALIEN-MODULE "CPOLY" {B0F0AA1}
))
5: (ASDF::TRAVERSE #<ASDF:LOAD-OP NIL {B545431}> #<MATLISP.SYSTEM::FORTRAN-SOURCE-FILE "cpoly" {B0F0AB1}>) traverse: (LOAD-OP cpoly) initially: NIL 6: (ASDF::TRAVERSE #<ASDF:COMPILE-OP NIL {B5531D9}> #<MATLISP.SYSTEM::FORTRAN-SOURCE- FILE "cpoly" {B0F0AB1}>) 6: ASDF::TRAVERSE returned NIL traverse: (LOAD-OP cpoly) itself: NIL traverse: (LOAD-OP cpoly) result: ((#<ASDF:LOAD-OP NIL {B545431}> . #<MATLISP.SYSTEM::FORTRAN- SOURCE-FILE "cpoly" {B0F0AB1}>)) 5: ASDF::TRAVERSE returned ((#<ASDF:LOAD-OP NIL {B545431}> . #<MATLISP.SYSTEM::FORTRAN-SOURCE-FILE "cpoly" {B0F0AB1}>)) traverse: (LOAD-OP CPOLY) itself: ((ASDF::PRUNED-OP . #<MATLISP.SYSTEM::ALIEN-MODULE "CPOLY" {B0F0AA1}>)) traverse: (LOAD-OP CPOLY) result: ((#<ASDF:LOAD-OP NIL {B545431}> . #<MATLISP.SYSTEM::FORTRAN- SOURCE-FILE "cpoly" {B0F0AB1}>) (#<ASDF:LOAD-OP NIL {B545431}> . #<MATLISP.SYSTEM::ALIEN-MODULE "CPOLY" {B0F0AA1}>)) 4: ASDF::TRAVERSE returned ((#<ASDF:LOAD-OP NIL {B545431}> . #<MATLISP.SYSTEM::FORTRAN-SOURCE-FILE "cpoly" {B0F0AB1}>) (#<ASDF:LOAD-OP NIL {B545431}> . #<MATLISP.SYSTEM::ALIEN-MODULE "CPOLY" {B0F0AA1}>)) traverse: (LOAD-OP alien code) itself: ((ASDF::PRUNED-OP . #<ASDF:UNIX-DSO "alien code" {B0F0A91}>)) traverse: (LOAD-OP alien code) result: ((#<ASDF:LOAD-OP NIL {B545431}> . #<MATLISP.SYSTEM::FORTRAN- SOURCE-FILE "cpoly" {B0F0AB1}>) (#<ASDF:LOAD-OP NIL {B545431}> . #<MATLISP.SYSTEM::ALIEN- MODULE "CPOLY" {B0F0AA1}>) (#<ASDF:LOAD-OP NIL {B545431}> . #<ASDF:UNIX-DSO "alien code" {B0F0A91}>)) 3: ASDF::TRAVERSE returned ((#<ASDF:LOAD-OP NIL {B545431}> . #<MATLISP.SYSTEM::FORTRAN-SOURCE-FILE "cpoly" {B0F0AB1}>) (#<ASDF:LOAD-OP NIL {B545431}> . #<MATLISP.SYSTEM::ALIEN-MODULE "CPOLY" {B0F0AA1}>) (#<ASDF:LOAD-OP NIL {B545431}> . #<ASDF:UNIX-DSO "alien code" {B0F0A91}>)) traverse: (COMPILE-OP foreign-interface) result: ((#<ASDF:LOAD-OP NIL {B545431}> . #<MATLISP.SYSTEM::FORTRAN-SOURCE-FILE
"cpoly" {B0F0AB1}>) (#<ASDF:LOAD-OP NIL {B545431}> . #<MATLISP.SYSTEM::ALIEN-MODULE
"CPOLY" {B0F0AA1}>) (#<ASDF:LOAD-OP NIL {B545431}> . #<ASDF:UNIX-DSO "alien code" {B0F0A91}>) (#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:CL- SOURCE-FILE "f77-mangling" {B0F0A81}>) (#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:CL- SOURCE-FILE "ffi- sbcl" {B0F0A71}>) (#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:MODULE "foreign- interface" {B0F0A61}>)) 2: ASDF::TRAVERSE returned ((#<ASDF:LOAD-OP NIL {B545431}> . #<MATLISP.SYSTEM::FORTRAN-SOURCE-FILE "cpoly" {B0F0AB1}>) (#<ASDF:LOAD-OP NIL {B545431}> . #<MATLISP.SYSTEM::ALIEN-MODULE "CPOLY" {B0F0AA1}>) (#<ASDF:LOAD-OP NIL {B545431}> . #<ASDF:UNIX-DSO "alien code" {B0F0A91}>) (#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:CL-SOURCE-FILE "f77-mangling" {B0F0A81}>) (#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:CL-SOURCE-FILE "ffi-sbcl" {B0F0A71}>) (#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:MODULE "foreign-interface" {B0F0A61}>)) traverse: (COMPILE-OP matlispbug) itself: NIL traverse: (COMPILE-OP matlispbug) result: ((#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<MATLISP.SYSTEM::ALIEN-MODULE "CPOLY" {B0F0AA1}>) (#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:UNIX-DSO "alien code" {B0F0A91}>) (#<ASDF:LOAD-OP NIL {B545431}> . #<MATLISP.SYSTEM::FORTRAN-SOURCE-FILE "cpoly" {B0F0AB1}>) (#<ASDF:LOAD-OP NIL {B545431}> . #<MATLISP.SYSTEM::ALIEN-MODULE "CPOLY" {B0F0AA1}>) (#<ASDF:LOAD-OP NIL {B545431}> . #<ASDF:UNIX-DSO "alien code" {B0F0A91}>) (#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:CL-SOURCE-FILE "f77- mangling" {B0F0A81}>) (#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:CL-SOURCE-FILE "ffi-sbcl" {B0F0A71}>) (#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:MODULE "foreign- interface" {B0F0A61}>) (#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:SYSTEM "matlispbug" {B046A99}>)) 1: ASDF::TRAVERSE returned ((#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<MATLISP.SYSTEM::ALIEN-MODULE "CPOLY" {B0F0AA1}>) (#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:UNIX-DSO "alien code" {B0F0A91}>) (#<ASDF:LOAD-OP NIL {B545431}> . #<MATLISP.SYSTEM::FORTRAN-SOURCE-FILE "cpoly" {B0F0AB1}>) (#<ASDF:LOAD-OP NIL {B545431}> . #<MATLISP.SYSTEM::ALIEN-MODULE "CPOLY" {B0F0AA1}>) (#<ASDF:LOAD-OP NIL {B545431}> . #<ASDF:UNIX-DSO "alien code" {B0F0A91}>) (#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:CL-SOURCE-FILE "f77-mangling" {B0F0A81}>) (#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:CL-SOURCE-FILE "ffi-sbcl" {B0F0A71}>) (#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:MODULE "foreign-interface" {B0F0A61}>) (#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:SYSTEM "matlispbug" {B046A99}>)) 1: (ASDF::TRAVERSE #<ASDF:LOAD-OP NIL {B4E07F1}> #<ASDF:UNIX-DSO "alien code" {B0F0A91}>) 1: ASDF::TRAVERSE returned ((ASDF::PRUNED-OP . #<ASDF:UNIX-DSO "alien code" {B0F0A91}>)) 1: (ASDF::TRAVERSE #<ASDF:LOAD-OP NIL {B4E07F1}> #<ASDF:CL-SOURCE-FILE "packages" {B0F0AC1}>) 1: ASDF::TRAVERSE returned NIL 1: (ASDF::TRAVERSE #<ASDF:LOAD-OP NIL {B4E07F1}> #<ASDF:MODULE "foreign-interface" {B0F0A61}>) traverse: (LOAD-OP foreign-interface) initially: NIL 2: (ASDF::TRAVERSE #<ASDF:COMPILE-OP NIL {B57BE41}> #<ASDF:MODULE "foreign-interface" {B0F0A61}>) 2: ASDF::TRAVERSE returned ((ASDF::PRUNED-OP . #<ASDF:MODULE "foreign- interface" {B0F0A61}>)) 2: (ASDF::TRAVERSE #<ASDF:LOAD-OP NIL {B4E07F1}> #<ASDF:UNIX-DSO "alien code" {B0F0A91}>) 2: ASDF::TRAVERSE returned ((ASDF::PRUNED-OP . #<ASDF:UNIX-DSO "alien code" {B0F0A91}
))
2: (ASDF::TRAVERSE #<ASDF:LOAD-OP NIL {B4E07F1}> #<ASDF:CL-SOURCE-FILE "packages" {B0F0AC1}>) 2: ASDF::TRAVERSE returned NIL 2: (ASDF::TRAVERSE #<ASDF:LOAD-OP NIL {B4E07F1}> #<ASDF:CL-SOURCE-FILE "f77- mangling" {B0F0A81}>) traverse: (LOAD-OP f77-mangling) initially: NIL 3: (ASDF::TRAVERSE #<ASDF:COMPILE-OP NIL {B587069}> #<ASDF:CL-SOURCE-FILE "f77- mangling" {B0F0A81}>) 3: ASDF::TRAVERSE returned ((ASDF::PRUNED-OP . #<ASDF:CL-SOURCE-FILE "f77-mangling" {B0F0A81}>)) traverse: (LOAD-OP f77-mangling) itself: ((ASDF::PRUNED-OP . #<ASDF:CL-SOURCE-FILE "f77- mangling" {B0F0A81}>)) traverse: (LOAD-OP f77-mangling) result: ((#<ASDF:LOAD-OP NIL {B4E07F1}> . #<ASDF:CL-SOURCE-FILE "f77- mangling" {B0F0A81}>)) 2: ASDF::TRAVERSE returned ((#<ASDF:LOAD-OP NIL {B4E07F1}> . #<ASDF:CL-SOURCE-FILE "f77-mangling" {B0F0A81}>)) 2: (ASDF::TRAVERSE #<ASDF:LOAD-OP NIL {B4E07F1}> #<ASDF:CL-SOURCE-FILE "ffi-sbcl" {B0F0A71}>) traverse: (LOAD-OP ffi-sbcl) initially: NIL 3: (ASDF::TRAVERSE #<ASDF:COMPILE-OP NIL {B5907D1}> #<ASDF:CL-SOURCE-FILE "ffi-sbcl" {B0F0A71}>) 3: ASDF::TRAVERSE returned ((ASDF::PRUNED-OP . #<ASDF:CL-SOURCE-FILE "ffi- sbcl" {B0F0A71}>)) traverse: (LOAD-OP ffi-sbcl) itself: ((ASDF::PRUNED-OP . #<ASDF:CL-SOURCE-FILE "ffi- sbcl" {B0F0A71}>)) traverse: (LOAD-OP ffi-sbcl) result: ((#<ASDF:LOAD-OP NIL {B4E07F1}> . #<ASDF:CL-SOURCE-FILE "ffi- sbcl" {B0F0A71}>)) 2: ASDF::TRAVERSE returned ((#<ASDF:LOAD-OP NIL {B4E07F1}> . #<ASDF:CL-SOURCE-FILE "ffi-sbcl" {B0F0A71}>)) traverse: (LOAD-OP foreign-interface) itself: ((ASDF::PRUNED-OP . #<ASDF:MODULE "foreign-interface" {B0F0A61}>) (ASDF::PRUNED-OP . #<ASDF:UNIX-DSO "alien code" {B0F0A91}>)) traverse: (LOAD-OP foreign-interface) result: ((#<ASDF:LOAD-OP NIL {B4E07F1}> . #<ASDF:CL-SOURCE-FILE "f77- mangling" {B0F0A81}>) (#<ASDF:LOAD-OP NIL {B4E07F1}> . #<ASDF:CL-SOURCE-FILE "ffi- sbcl" {B0F0A71}>) (#<ASDF:LOAD-OP NIL {B4E07F1}> . #<ASDF:MODULE "foreign-interface" {B0F0A61}>)) 1: ASDF::TRAVERSE returned ((#<ASDF:LOAD-OP NIL {B4E07F1}> . #<ASDF:CL-SOURCE-FILE "f77-mangling" {B0F0A81}>) (#<ASDF:LOAD-OP NIL {B4E07F1}> . #<ASDF:CL-SOURCE-FILE "ffi-sbcl" {B0F0A71}>) (#<ASDF:LOAD-OP NIL {B4E07F1}> . #<ASDF:MODULE "foreign-interface" {B0F0A61}>)) traverse: (LOAD-OP matlispbug) itself: ((#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<MATLISP.SYSTEM::ALIEN- MODULE "CPOLY" {B0F0AA1}>) (#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:UNIX-DSO "alien code" {B0F0A91}>) (#<ASDF:LOAD-OP NIL {B545431}> . #<MATLISP.SYSTEM::FORTRAN- SOURCE-FILE "cpoly" {B0F0AB1}>) (#<ASDF:LOAD-OP NIL {B545431}> . #<MATLISP.SYSTEM::ALIEN- MODULE "CPOLY" {B0F0AA1}>) (#<ASDF:LOAD-OP NIL {B545431}> . #<ASDF:UNIX-DSO "alien code" {B0F0A91}>) (#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:CL-SOURCE-FILE "f77-mangling" {B0F0A81}>) (#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:CL-SOURCE-FILE "ffi-sbcl" {B0F0A71}>) (#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:MODULE "foreign- interface" {B0F0A61}>) (#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:SYSTEM "matlispbug" {B046A99}>)) traverse: (LOAD-OP matlispbug) result: ((#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<MATLISP.SYSTEM::ALIEN- MODULE "CPOLY" {B0F0AA1}>) (#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:UNIX-DSO "alien code" {B0F0A91}>) (#<ASDF:LOAD-OP NIL {B545431}> . #<MATLISP.SYSTEM::FORTRAN- SOURCE-FILE "cpoly" {B0F0AB1}>) (#<ASDF:LOAD-OP NIL {B545431}> . #<MATLISP.SYSTEM::ALIEN- MODULE "CPOLY" {B0F0AA1}>) (#<ASDF:LOAD-OP NIL {B545431}> . #<ASDF:UNIX-DSO "alien code" {B0F0A91}>) (#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:CL-SOURCE-FILE "f77-mangling" {B0F0A81}>) (#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:CL-SOURCE-FILE "ffi-sbcl" {B0F0A71}>) (#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:MODULE "foreign- interface" {B0F0A61}>) (#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:SYSTEM "matlispbug" {B046A99}>) (#<ASDF:LOAD-OP NIL {B4E07F1}> . #<ASDF:CL-SOURCE-FILE "f77-mangling" {B0F0A81}>) (#<ASDF:LOAD-OP NIL {B4E07F1}> . #<ASDF:CL-SOURCE-FILE "ffi-sbcl" {B0F0A71}>) (#<ASDF:LOAD-OP NIL {B4E07F1}> . #<ASDF:MODULE "foreign- interface" {B0F0A61}>) (#<ASDF:LOAD-OP NIL {B4E07F1}> . #<ASDF:SYSTEM "matlispbug" {B046A99}>)) 0: ASDF::TRAVERSE returned ((#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<MATLISP.SYSTEM::ALIEN-MODULE "CPOLY" {B0F0AA1}>) (#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:UNIX-DSO "alien code" {B0F0A91}>) (#<ASDF:LOAD-OP NIL {B545431}> . #<MATLISP.SYSTEM::FORTRAN-SOURCE-FILE "cpoly" {B0F0AB1}>) (#<ASDF:LOAD-OP NIL {B545431}> . #<MATLISP.SYSTEM::ALIEN-MODULE "CPOLY" {B0F0AA1}>) (#<ASDF:LOAD-OP NIL {B545431}> . #<ASDF:UNIX-DSO "alien code" {B0F0A91}>) (#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:CL-SOURCE-FILE "f77-mangling" {B0F0A81}>) (#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:CL-SOURCE-FILE "ffi-sbcl" {B0F0A71}>) (#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:MODULE "foreign-interface" {B0F0A61}>) (#<ASDF:COMPILE-OP NIL {B4E58C9}> . #<ASDF:SYSTEM "matlispbug" {B046A99}>) (#<ASDF:LOAD-OP NIL {B4E07F1}> . #<ASDF:CL-SOURCE-FILE "f77-mangling" {B0F0A81}>) (#<ASDF:LOAD-OP NIL {B4E07F1}> . #<ASDF:CL-SOURCE-FILE "ffi-sbcl" {B0F0A71}>) (#<ASDF:LOAD-OP NIL {B4E07F1}> . #<ASDF:MODULE "foreign-interface" {B0F0A61}>) (#<ASDF:LOAD-OP NIL {B4E07F1}> . #<ASDF:SYSTEM "matlispbug" {B046A99}>)) 0: (ASDF:PERFORM #<ASDF:COMPILE-OP NIL {B4E58C9}> #<MATLISP.SYSTEM::ALIEN-MODULE "CPOLY" {B0F0AA1}>) 0: ASDF:PERFORM returned NIL 0: (ASDF:PERFORM #<ASDF:COMPILE-OP NIL {B4E58C9}> #<ASDF:UNIX-DSO "alien code" {B0F0A91}>) 1: (ASDF:OPERATION-DONE-P #<ASDF:COMPILE-OP NIL {B4E58C9}> #<ASDF:UNIX-DSO "alien code" {B0F0A91}>) 1: ASDF:OPERATION-DONE-P returned T 0: ASDF:PERFORM returned NIL 0: (ASDF:PERFORM #<ASDF:LOAD-OP NIL {B545431}> #<MATLISP.SYSTEM::FORTRAN-SOURCE-FILE "cpoly" {B0F0AB1}>) 0: ASDF:PERFORM returned T 0: (ASDF:PERFORM #<ASDF:LOAD-OP NIL {B545431}> #<MATLISP.SYSTEM::ALIEN-MODULE "CPOLY" {B0F0AA1}>) 0: ASDF:PERFORM returned NIL 0: (ASDF:PERFORM #<ASDF:LOAD-OP NIL {B545431}> #<ASDF:UNIX-DSO "alien code" {B0F0A91}>) 0: ASDF:PERFORM returned #P"/home/asdf/.cache/common-lisp/sbcl-1.0.36-linux-x86/ebs/ source/upload/net/common-lisp/matlisp/libmatlisp.so" 0: (ASDF:PERFORM #<ASDF:COMPILE-OP NIL {B4E58C9}> #<ASDF:CL-SOURCE-FILE "f77-mangling" {B0F0A81}>) ; compiling file "/ebs/source/upload/net/common-lisp/matlisp/src/f77- mangling.lisp" (written 18 MAR 2010 10:22:00 PM): ; compiling (IN-PACKAGE "FORTRAN-FFI-ACCESSORS") ; compiling (DEFCONSTANT +F77-LOWER-CASE+ ...) ; compiling (DEFCONSTANT +F77-UNDERSCORE+ ...) ; compiling (DEFCONSTANT +F77-EXTRA-UNDERSCORE+ ...) ; compiling (DEFUN %CAT% ...) ; compiling (DEFUN SCAT ...) ; compiling (DEFUN MAKE-FORTRAN-FFI-NAME ...) ; compiling (DEFUN MAKE-FORTRAN-NAME ...) ; file: /ebs/source/upload/net/common-lisp/matlisp/src/f77-mangling.lisp ; in: DEFUN MAKE-FORTRAN-NAME ; (IF FORTRAN-FFI-ACCESSORS::+F77-UNDERSCORE+ ; "_" ; "") ; ==> ; "" ; ; note: deleting unreachable code
; (AND FORTRAN-FFI-ACCESSORS::+F77-EXTRA-UNDERSCORE+ ; FORTRAN-FFI-ACCESSORS::INTERNAL-UNDERSCORE-P) ; --> IF AND THE ; ==> ; FORTRAN-FFI-ACCESSORS::INTERNAL-UNDERSCORE-P ; ; note: deleting unreachable code
; (IF (AND FORTRAN-FFI-ACCESSORS::+F77-EXTRA-UNDERSCORE+ ; FORTRAN-FFI-ACCESSORS::INTERNAL-UNDERSCORE-P) ; "_" ; "") ; ==> ; "_" ; ; note: deleting unreachable code
; (IF FORTRAN-FFI-ACCESSORS::+F77-LOWER-CASE+ ; (STRING-DOWNCASE FORTRAN-FFI-ACCESSORS::NAME) ; FORTRAN-FFI-ACCESSORS::NAME) ; ==> ; FORTRAN-FFI-ACCESSORS::NAME ; ; note: deleting unreachable code
; /home/asdf/.cache/common-lisp/sbcl-1.0.36-linux-x86/ebs/source/ upload/net/common-lisp/matlisp/src/f77-mangling.fasl written ; compilation finished in 0:00:00.036 0: ASDF:PERFORM returned NIL 0: (ASDF:PERFORM #<ASDF:COMPILE-OP NIL {B4E58C9}> #<ASDF:CL-SOURCE-FILE "ffi-sbcl" {B0F0A71}>) ; compiling file "/ebs/source/upload/net/common-lisp/matlisp/src/ffi- sbcl.lisp" (written 18 MAR 2010 10:21:59 PM): ; compiling (IN-PACKAGE "FORTRAN-FFI-ACCESSORS") ; compiling (DEFUN PARSE-DOC-&-PARAMETERS ...) ; compiling (DEFUN CAST-AS-ARRAY-P ...) ; compiling (DEFUN GET-READ-IN-TYPE ...) ; compiling (DEFUN GET-READ-OUT-TYPE ...) ; compiling (DEFUN GET-READ-IN-STYLE ...) ; compiling (DEFUN GET-READ-OUT-STYLE ...) ; compiling (DEFUN PARSE-FORTRAN-PARAMETERS ...) ; compiling (DEFUN DEF-FORTRAN-INTERFACE ...) ; compiling (DEFMACRO DEF-FORTRAN-ROUTINE ...) ; compiling (DEFMACRO INCF-SAP ...) ; compiling (DEFTYPE MATLISP-SPECIALIZED-ARRAY ...) ; compiling (DECLAIM (INLINE VECTOR-DATA-ADDRESS)) ; compiling (DEFUN VECTOR-DATA-ADDRESS ...) ; compiling (DEFMACRO WITH-FORTRAN-FLOAT-MODES ...) ; compiling (DEFMACRO WITH-VECTOR-DATA-ADDRESSES ...) ; compiling (DEFMACRO WITH-GENSYMS ...)
; /home/asdf/.cache/common-lisp/sbcl-1.0.36-linux-x86/ebs/source/ upload/net/common-lisp/matlisp/src/ffi-sbcl.fasl written ; compilation finished in 0:00:00.652 0: ASDF:PERFORM returned NIL 0: (ASDF:PERFORM #<ASDF:COMPILE-OP NIL {B4E58C9}> #<ASDF:MODULE "foreign-interface" {B0F0A61}>) 0: ASDF:PERFORM returned NIL 0: (ASDF:PERFORM #<ASDF:COMPILE-OP NIL {B4E58C9}> #<ASDF:SYSTEM "matlispbug" {B046A99}>) 0: ASDF:PERFORM returned NIL 0: (ASDF:PERFORM #<ASDF:LOAD-OP NIL {B4E07F1}> #<ASDF:CL-SOURCE-FILE "f77-mangling" {B0F0A81}>) 0: ASDF:PERFORM returned (T) 0: (ASDF:PERFORM #<ASDF:LOAD-OP NIL {B4E07F1}> #<ASDF:CL-SOURCE-FILE "ffi-sbcl" {B0F0A71}>) 0: ASDF:PERFORM returned (T) 0: (ASDF:PERFORM #<ASDF:LOAD-OP NIL {B4E07F1}> #<ASDF:MODULE "foreign-interface" {B0F0A61}>) 0: ASDF:PERFORM returned NIL 0: (ASDF:PERFORM #<ASDF:LOAD-OP NIL {B4E07F1}> #<ASDF:SYSTEM "matlispbug" {B046A99}>) 0: ASDF:PERFORM returned NIL ; ; compilation unit finished ; printed 4 notes #<ASDF:LOAD-OP NIL {B4E07F1}> *
Hello,
I was wondering - what is the working hypothesis? Is this a bug in the .asd or a bug in the new version of asdf? :-)
Regards, and thanks,
Mario.
On 4/11/10 Apr 11 -12:47 PM, Mario S. Mommer wrote:
Hello,
I was wondering - what is the working hypothesis? Is this a bug in the .asd or a bug in the new version of asdf? :-)
I still can't get this to run twice (whether or not with an excess recompile) --- running it twice causes what seems like an unrelated crash.
This is SBCL 1.0.37.57 on linux x86_64. The first load-system completes successfully; the second gives me the following transcript.
I'm more than happy to help debug ASDF issues, but I don't understand the crash I'm getting here, and it doesn't seem to be ASDF-related. I don't understand why SB-ACLREPL is on the stack, either. I made sure that I wasn't loading it, and then just to be doubly-sure, I retried using sbcl --no-userinit, and got a similar (but not identical) crash. So it's not my .sbclrc, and it's not SLIME --- I get this behavior running SBCL from a shell. The error is just different (see further down).
Error transcript using my normal SBCL, at the shell:
CL-USER(5): (asdf:load-system :matlispbug)
; compiling file "/home/rpg/lisp/matlisp/src/f77-mangling.lisp" (written 11 APR 2010 10:30:03 AM): ; compiling (IN-PACKAGE "FORTRAN-FFI-ACCESSORS") ; compiling (DEFCONSTANT +F77-LOWER-CASE+ ...) ; compiling (DEFCONSTANT +F77-UNDERSCORE+ ...) ; compiling (DEFCONSTANT +F77-EXTRA-UNDERSCORE+ ...) ; compiling (DEFUN %CAT% ...) ; compiling (DEFUN SCAT ...) ; compiling (DEFUN MAKE-FORTRAN-FFI-NAME ...) ; compiling (DEFUN MAKE-FORTRAN-NAME ...) ; file: /home/rpg/lisp/matlisp/src/f77-mangling.lisp ; in: DEFUN MAKE-FORTRAN-NAME ; (IF FORTRAN-FFI-ACCESSORS::+F77-UNDERSCORE+ ; "_" ; "") ; ==> ; "_" ; ; note: deleting unreachable code
; (AND FORTRAN-FFI-ACCESSORS::+F77-EXTRA-UNDERSCORE+ ; FORTRAN-FFI-ACCESSORS::INTERNAL-UNDERSCORE-P) ; --> IF AND THE ; ==> ; FORTRAN-FFI-ACCESSORS::INTERNAL-UNDERSCORE-P ; ; note: deleting unreachable code
; (IF (AND FORTRAN-FFI-ACCESSORS::+F77-EXTRA-UNDERSCORE+ ; FORTRAN-FFI-ACCESSORS::INTERNAL-UNDERSCORE-P) ; "_" ; "") ; ==> ; "_" ; ; note: deleting unreachable code
; (IF FORTRAN-FFI-ACCESSORS::+F77-LOWER-CASE+ ; (STRING-DOWNCASE FORTRAN-FFI-ACCESSORS::NAME) ; FORTRAN-FFI-ACCESSORS::NAME) ; ==> ; FORTRAN-FFI-ACCESSORS::NAME ; ; note: deleting unreachable code
; /home/rpg/.cache/common-lisp/sbcl-1.0.37.57-linux-x86-64/home/rpg/lisp/matlisp/src/f77-mangling.fasl written ; compilation finished in 0:00:00.015 ; compiling file "/home/rpg/lisp/matlisp/src/ffi-sbcl.lisp" (written 18 MAR 2010 05:21:59 PM): ; compiling (IN-PACKAGE "FORTRAN-FFI-ACCESSORS") ; compiling (DEFUN PARSE-DOC-&-PARAMETERS ...) ; compiling (DEFUN CAST-AS-ARRAY-P ...) ; compiling (DEFUN GET-READ-IN-TYPE ...) ; compiling (DEFUN GET-READ-OUT-TYPE ...) ; compiling (DEFUN GET-READ-IN-STYLE ...) ; compiling (DEFUN GET-READ-OUT-STYLE ...) ; compiling (DEFUN PARSE-FORTRAN-PARAMETERS ...) ; compiling (DEFUN DEF-FORTRAN-INTERFACE ...) ; compiling (DEFMACRO DEF-FORTRAN-ROUTINE ...) ; compiling (DEFMACRO INCF-SAP ...) ; compiling (DEFTYPE MATLISP-SPECIALIZED-ARRAY ...) ; compiling (DECLAIM (INLINE VECTOR-DATA-ADDRESS)) ; compiling (DEFUN VECTOR-DATA-ADDRESS ...) ; compiling (DEFMACRO WITH-FORTRAN-FLOAT-MODES ...) ; compiling (DEFMACRO WITH-VECTOR-DATA-ADDRESSES ...) ; compiling (DEFMACRO WITH-GENSYMS ...)
; /home/rpg/.cache/common-lisp/sbcl-1.0.37.57-linux-x86-64/home/rpg/lisp/matlisp/src/ffi-sbcl.fasl written ; compilation finished in 0:00:00.104 ; ; compilation unit finished ; printed 4 notes #<ASDF:LOAD-OP NIL {1003BE9C31}> CL-USER(5): debugger invoked on a SB-INT:SIMPLE-STREAM-ERROR in thread #<THREAD "initial thread" RUNNING {1002AB6031}>: couldn't check whether #<SB-SYS:FD-STREAM for "standard input" {1002AB65F1}> is readable: Bad file descriptor
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level.
(SB-IMPL::SIMPLE-STREAM-PERROR "couldn't check whether ~S is readable" #<SB-SYS:FD-STREAM for "standard input" {1002AB65F1}> 9) 0] backtrace
0: (SB-IMPL::SIMPLE-STREAM-PERROR "couldn't check whether ~S is readable" #<SB-SYS:FD-STREAM for "standard input" {1002AB65F1}> 9) 1: (SB-IMPL::SYSREAD-MAY-BLOCK-P #<SB-SYS:FD-STREAM for "standard input" {1002AB65F1}>) 2: (SB-IMPL::REFILL-INPUT-BUFFER #<SB-SYS:FD-STREAM for "standard input" {1002AB65F1}>) 3: (SB-IMPL::INPUT-CHAR/UTF-8 #<SB-SYS:FD-STREAM for "standard input" {1002AB65F1}> NIL :EOF) 4: ((LAMBDA (&REST REST)) #<SB-SYS:FD-STREAM for "standard input" {1002AB65F1}> NIL :EOF) 5: ((LAMBDA (&REST REST)) #<SB-SYS:FD-STREAM for "standard input" {1002AB65F1}> NIL :EOF)[:OPTIONAL] 6: (READ-CHAR #<SB-SYS:FD-STREAM for "standard input" {1002AB65F1}> NIL :EOF #<unused argument>) 7: (PEEK-CHAR NIL #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {100019E381}> NIL :EOF #<unused argument>) 8: (SB-ACLREPL::PEEK-CHAR-NON-WHITESPACE #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {100019E381}>) 9: (SB-ACLREPL::READ-CMD #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {100019E381}>) 10: (SB-ACLREPL::REPL-READ-FORM-FUN #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {100019E381}> #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDOUT* {10001DAAB1}>) 11: (SB-ACLREPL::REP-ONE) 12: (SB-ACLREPL::REPL)[:EXTERNAL] 13: ((LAMBDA (SB-ACLREPL::NOPRINT)) NIL) 14: ((LAMBDA ())) 15: (SB-IMPL::%WITH-REBOUND-IO-SYNTAX #<CLOSURE (LAMBDA #) {1002BA7679}>) 16: (SB-IMPL::TOPLEVEL-REPL NIL) 17: (SB-IMPL::TOPLEVEL-INIT) 18: ((LABELS SB-IMPL::RESTART-LISP))
0]
The first load-system gave me this:
CL-USER(4): (asdf:load-system :matlispbug)
; loading system definition from /home/rpg/lisp/matlisp/matlispbug.asd into ; #<PACKAGE "ASDF0"> ; registering #<SYSTEM :MATLISPBUG {1003A24391}> as MATLISPBUG WARNING: Redefining DEFTYPE type to be a class: REAL
; compiling file "/home/rpg/lisp/matlisp/src/f77-mangling.lisp" (written 11 APR 2010 10:30:03 AM): ; compiling (IN-PACKAGE "FORTRAN-FFI-ACCESSORS") ; compiling (DEFCONSTANT +F77-LOWER-CASE+ ...) ; compiling (DEFCONSTANT +F77-UNDERSCORE+ ...) ; compiling (DEFCONSTANT +F77-EXTRA-UNDERSCORE+ ...) ; compiling (DEFUN %CAT% ...) ; compiling (DEFUN SCAT ...) ; compiling (DEFUN MAKE-FORTRAN-FFI-NAME ...) ; compiling (DEFUN MAKE-FORTRAN-NAME ...) ; file: /home/rpg/lisp/matlisp/src/f77-mangling.lisp ; in: DEFUN MAKE-FORTRAN-NAME ; (IF FORTRAN-FFI-ACCESSORS::+F77-UNDERSCORE+ ; "_" ; "") ; ==> ; "_" ; ; note: deleting unreachable code
; (AND FORTRAN-FFI-ACCESSORS::+F77-EXTRA-UNDERSCORE+ ; FORTRAN-FFI-ACCESSORS::INTERNAL-UNDERSCORE-P) ; --> IF AND THE ; ==> ; FORTRAN-FFI-ACCESSORS::INTERNAL-UNDERSCORE-P ; ; note: deleting unreachable code
; (IF (AND FORTRAN-FFI-ACCESSORS::+F77-EXTRA-UNDERSCORE+ ; FORTRAN-FFI-ACCESSORS::INTERNAL-UNDERSCORE-P) ; "_" ; "") ; ==> ; "_" ; ; note: deleting unreachable code
; (IF FORTRAN-FFI-ACCESSORS::+F77-LOWER-CASE+ ; (STRING-DOWNCASE FORTRAN-FFI-ACCESSORS::NAME) ; FORTRAN-FFI-ACCESSORS::NAME) ; ==> ; FORTRAN-FFI-ACCESSORS::NAME ; ; note: deleting unreachable code
; /home/rpg/.cache/common-lisp/sbcl-1.0.37.57-linux-x86-64/home/rpg/lisp/matlisp/src/f77-mangling.fasl written ; compilation finished in 0:00:00.015 ; compiling file "/home/rpg/lisp/matlisp/src/ffi-sbcl.lisp" (written 18 MAR 2010 05:21:59 PM): ; compiling (IN-PACKAGE "FORTRAN-FFI-ACCESSORS") ; compiling (DEFUN PARSE-DOC-&-PARAMETERS ...) ; compiling (DEFUN CAST-AS-ARRAY-P ...) ; compiling (DEFUN GET-READ-IN-TYPE ...) ; compiling (DEFUN GET-READ-OUT-TYPE ...) ; compiling (DEFUN GET-READ-IN-STYLE ...) ; compiling (DEFUN GET-READ-OUT-STYLE ...) ; compiling (DEFUN PARSE-FORTRAN-PARAMETERS ...) ; compiling (DEFUN DEF-FORTRAN-INTERFACE ...) ; compiling (DEFMACRO DEF-FORTRAN-ROUTINE ...) ; compiling (DEFMACRO INCF-SAP ...) ; compiling (DEFTYPE MATLISP-SPECIALIZED-ARRAY ...) ; compiling (DECLAIM (INLINE VECTOR-DATA-ADDRESS)) ; compiling (DEFUN VECTOR-DATA-ADDRESS ...) ; compiling (DEFMACRO WITH-FORTRAN-FLOAT-MODES ...) ; compiling (DEFMACRO WITH-VECTOR-DATA-ADDRESSES ...) ; compiling (DEFMACRO WITH-GENSYMS ...)
; /home/rpg/.cache/common-lisp/sbcl-1.0.37.57-linux-x86-64/home/rpg/lisp/matlisp/src/ffi-sbcl.fasl written ; compilation finished in 0:00:00.118 ; ; compilation unit finished ; printed 4 notes #<ASDF:LOAD-OP NIL {10035B43B1}>
Error transcript using --no-userinit: * debugger invoked on a SB-INT:SIMPLE-STREAM-ERROR in thread #<THREAD "initial thread" RUNNING {1002AB6101}>: couldn't check whether #<SB-SYS:FD-STREAM for "standard input" {1002AB66C1}> is readable: Bad file descriptor
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level.
(SB-IMPL::SIMPLE-STREAM-PERROR "couldn't check whether ~S is readable" #<SB-SYS:FD-STREAM for "standard input" {1002AB66C1}> 9) 0] backtrace
0: (SB-IMPL::SIMPLE-STREAM-PERROR "couldn't check whether ~S is readable" #<SB-SYS:FD-STREAM for "standard input" {1002AB66C1}> 9) 1: (SB-IMPL::SYSREAD-MAY-BLOCK-P #<SB-SYS:FD-STREAM for "standard input" {1002AB66C1}>) 2: (SB-IMPL::REFILL-INPUT-BUFFER #<SB-SYS:FD-STREAM for "standard input" {1002AB66C1}>) 3: (SB-IMPL::INPUT-CHAR/UTF-8 #<SB-SYS:FD-STREAM for "standard input" {1002AB66C1}> NIL #:EOF-OBJECT) 4: ((LAMBDA (&REST REST)) #<SB-SYS:FD-STREAM for "standard input" {1002AB66C1}> NIL #:EOF-OBJECT) 5: ((LAMBDA (&REST REST)) #<SB-SYS:FD-STREAM for "standard input" {1002AB66C1}> NIL #:EOF-OBJECT)[:OPTIONAL] 6: (READ-CHAR #<SB-SYS:FD-STREAM for "standard input" {1002AB66C1}> NIL #:EOF-OBJECT #<unused argument>) 7: (READ-CHAR #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {100019E381}> NIL #:EOF-OBJECT #<unused argument>) 8: (SB-IMPL::%READ-PRESERVING-WHITESPACE #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {100019E381}> NIL (NIL) T) 9: (SB-IMPL::%READ-PRESERVING-WHITESPACE #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {100019E381}> NIL (NIL) NIL) 10: (READ #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {100019E381}> NIL (NIL) NIL) 11: (SB-IMPL::REPL-READ-FORM-FUN #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {100019E381}> #<unavailable argument>) 12: (SB-IMPL::REPL-FUN NIL) 13: ((LAMBDA ())) 14: (SB-IMPL::%WITH-REBOUND-IO-SYNTAX #<CLOSURE (LAMBDA #) {1002AB99F9}>) 15: (SB-IMPL::TOPLEVEL-REPL NIL) 16: (SB-IMPL::TOPLEVEL-INIT) 17: ((LABELS SB-IMPL::RESTART-LISP))
0]
Best, r
Hi,
The error with the fd-stream is ignorable. In slime just let the buffer with C-x 1 while in the repl, and that's it. As far as I know, that is a gfortran bug that is not there in the next version. If you bury the buffer with that error you can continue to work without trouble. Strange, but true. I've been doing that for about a year :-)
If that does not work, I'll attempt to do a lisp-only or some other non-fd-crashing thing.
(re aclrepl: maybe you built sbcl with sb-aclrepl?)
Regards, and thanks,
Mario.
Robert Goldman rpgoldman@sift.info writes:
On 4/11/10 Apr 11 -12:47 PM, Mario S. Mommer wrote:
Hello,
I was wondering - what is the working hypothesis? Is this a bug in the .asd or a bug in the new version of asdf? :-)
I still can't get this to run twice (whether or not with an excess recompile) --- running it twice causes what seems like an unrelated crash.
This is SBCL 1.0.37.57 on linux x86_64. The first load-system completes successfully; the second gives me the following transcript.
I'm more than happy to help debug ASDF issues, but I don't understand the crash I'm getting here, and it doesn't seem to be ASDF-related. I don't understand why SB-ACLREPL is on the stack, either. I made sure that I wasn't loading it, and then just to be doubly-sure, I retried using sbcl --no-userinit, and got a similar (but not identical) crash. So it's not my .sbclrc, and it's not SLIME --- I get this behavior running SBCL from a shell. The error is just different (see further down).
Error transcript using my normal SBCL, at the shell:
CL-USER(5): (asdf:load-system :matlispbug)
; compiling file "/home/rpg/lisp/matlisp/src/f77-mangling.lisp" (written 11 APR 2010 10:30:03 AM): ; compiling (IN-PACKAGE "FORTRAN-FFI-ACCESSORS") ; compiling (DEFCONSTANT +F77-LOWER-CASE+ ...) ; compiling (DEFCONSTANT +F77-UNDERSCORE+ ...) ; compiling (DEFCONSTANT +F77-EXTRA-UNDERSCORE+ ...) ; compiling (DEFUN %CAT% ...) ; compiling (DEFUN SCAT ...) ; compiling (DEFUN MAKE-FORTRAN-FFI-NAME ...) ; compiling (DEFUN MAKE-FORTRAN-NAME ...) ; file: /home/rpg/lisp/matlisp/src/f77-mangling.lisp ; in: DEFUN MAKE-FORTRAN-NAME ; (IF FORTRAN-FFI-ACCESSORS::+F77-UNDERSCORE+ ; "_" ; "") ; ==> ; "_" ; ; note: deleting unreachable code
; (AND FORTRAN-FFI-ACCESSORS::+F77-EXTRA-UNDERSCORE+ ; FORTRAN-FFI-ACCESSORS::INTERNAL-UNDERSCORE-P) ; --> IF AND THE ; ==> ; FORTRAN-FFI-ACCESSORS::INTERNAL-UNDERSCORE-P ; ; note: deleting unreachable code
; (IF (AND FORTRAN-FFI-ACCESSORS::+F77-EXTRA-UNDERSCORE+ ; FORTRAN-FFI-ACCESSORS::INTERNAL-UNDERSCORE-P) ; "_" ; "") ; ==> ; "_" ; ; note: deleting unreachable code
; (IF FORTRAN-FFI-ACCESSORS::+F77-LOWER-CASE+ ; (STRING-DOWNCASE FORTRAN-FFI-ACCESSORS::NAME) ; FORTRAN-FFI-ACCESSORS::NAME) ; ==> ; FORTRAN-FFI-ACCESSORS::NAME ; ; note: deleting unreachable code
; /home/rpg/.cache/common-lisp/sbcl-1.0.37.57-linux-x86-64/home/rpg/lisp/matlisp/src/f77-mangling.fasl written ; compilation finished in 0:00:00.015 ; compiling file "/home/rpg/lisp/matlisp/src/ffi-sbcl.lisp" (written 18 MAR 2010 05:21:59 PM): ; compiling (IN-PACKAGE "FORTRAN-FFI-ACCESSORS") ; compiling (DEFUN PARSE-DOC-&-PARAMETERS ...) ; compiling (DEFUN CAST-AS-ARRAY-P ...) ; compiling (DEFUN GET-READ-IN-TYPE ...) ; compiling (DEFUN GET-READ-OUT-TYPE ...) ; compiling (DEFUN GET-READ-IN-STYLE ...) ; compiling (DEFUN GET-READ-OUT-STYLE ...) ; compiling (DEFUN PARSE-FORTRAN-PARAMETERS ...) ; compiling (DEFUN DEF-FORTRAN-INTERFACE ...) ; compiling (DEFMACRO DEF-FORTRAN-ROUTINE ...) ; compiling (DEFMACRO INCF-SAP ...) ; compiling (DEFTYPE MATLISP-SPECIALIZED-ARRAY ...) ; compiling (DECLAIM (INLINE VECTOR-DATA-ADDRESS)) ; compiling (DEFUN VECTOR-DATA-ADDRESS ...) ; compiling (DEFMACRO WITH-FORTRAN-FLOAT-MODES ...) ; compiling (DEFMACRO WITH-VECTOR-DATA-ADDRESSES ...) ; compiling (DEFMACRO WITH-GENSYMS ...)
; /home/rpg/.cache/common-lisp/sbcl-1.0.37.57-linux-x86-64/home/rpg/lisp/matlisp/src/ffi-sbcl.fasl written ; compilation finished in 0:00:00.104 ; ; compilation unit finished ; printed 4 notes #<ASDF:LOAD-OP NIL {1003BE9C31}> CL-USER(5): debugger invoked on a SB-INT:SIMPLE-STREAM-ERROR in thread #<THREAD "initial thread" RUNNING {1002AB6031}>: couldn't check whether #<SB-SYS:FD-STREAM for "standard input" {1002AB65F1}> is readable: Bad file descriptor
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level.
(SB-IMPL::SIMPLE-STREAM-PERROR "couldn't check whether ~S is readable" #<SB-SYS:FD-STREAM for "standard input" {1002AB65F1}> 9) 0] backtrace
0: (SB-IMPL::SIMPLE-STREAM-PERROR "couldn't check whether ~S is readable" #<SB-SYS:FD-STREAM for "standard input" {1002AB65F1}> 9) 1: (SB-IMPL::SYSREAD-MAY-BLOCK-P #<SB-SYS:FD-STREAM for "standard input" {1002AB65F1}>) 2: (SB-IMPL::REFILL-INPUT-BUFFER #<SB-SYS:FD-STREAM for "standard input" {1002AB65F1}>) 3: (SB-IMPL::INPUT-CHAR/UTF-8 #<SB-SYS:FD-STREAM for "standard input" {1002AB65F1}> NIL :EOF) 4: ((LAMBDA (&REST REST)) #<SB-SYS:FD-STREAM for "standard input" {1002AB65F1}> NIL :EOF) 5: ((LAMBDA (&REST REST)) #<SB-SYS:FD-STREAM for "standard input" {1002AB65F1}> NIL :EOF)[:OPTIONAL] 6: (READ-CHAR #<SB-SYS:FD-STREAM for "standard input" {1002AB65F1}> NIL :EOF #<unused argument>) 7: (PEEK-CHAR NIL #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {100019E381}> NIL :EOF #<unused argument>) 8: (SB-ACLREPL::PEEK-CHAR-NON-WHITESPACE #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {100019E381}>) 9: (SB-ACLREPL::READ-CMD #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {100019E381}>) 10: (SB-ACLREPL::REPL-READ-FORM-FUN #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {100019E381}> #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDOUT* {10001DAAB1}>) 11: (SB-ACLREPL::REP-ONE) 12: (SB-ACLREPL::REPL)[:EXTERNAL] 13: ((LAMBDA (SB-ACLREPL::NOPRINT)) NIL) 14: ((LAMBDA ())) 15: (SB-IMPL::%WITH-REBOUND-IO-SYNTAX #<CLOSURE (LAMBDA #) {1002BA7679}>) 16: (SB-IMPL::TOPLEVEL-REPL NIL) 17: (SB-IMPL::TOPLEVEL-INIT) 18: ((LABELS SB-IMPL::RESTART-LISP))
0]
The first load-system gave me this:
CL-USER(4): (asdf:load-system :matlispbug)
; loading system definition from /home/rpg/lisp/matlisp/matlispbug.asd into ; #<PACKAGE "ASDF0"> ; registering #<SYSTEM :MATLISPBUG {1003A24391}> as MATLISPBUG WARNING: Redefining DEFTYPE type to be a class: REAL
; compiling file "/home/rpg/lisp/matlisp/src/f77-mangling.lisp" (written 11 APR 2010 10:30:03 AM): ; compiling (IN-PACKAGE "FORTRAN-FFI-ACCESSORS") ; compiling (DEFCONSTANT +F77-LOWER-CASE+ ...) ; compiling (DEFCONSTANT +F77-UNDERSCORE+ ...) ; compiling (DEFCONSTANT +F77-EXTRA-UNDERSCORE+ ...) ; compiling (DEFUN %CAT% ...) ; compiling (DEFUN SCAT ...) ; compiling (DEFUN MAKE-FORTRAN-FFI-NAME ...) ; compiling (DEFUN MAKE-FORTRAN-NAME ...) ; file: /home/rpg/lisp/matlisp/src/f77-mangling.lisp ; in: DEFUN MAKE-FORTRAN-NAME ; (IF FORTRAN-FFI-ACCESSORS::+F77-UNDERSCORE+ ; "_" ; "") ; ==> ; "_" ; ; note: deleting unreachable code
; (AND FORTRAN-FFI-ACCESSORS::+F77-EXTRA-UNDERSCORE+ ; FORTRAN-FFI-ACCESSORS::INTERNAL-UNDERSCORE-P) ; --> IF AND THE ; ==> ; FORTRAN-FFI-ACCESSORS::INTERNAL-UNDERSCORE-P ; ; note: deleting unreachable code
; (IF (AND FORTRAN-FFI-ACCESSORS::+F77-EXTRA-UNDERSCORE+ ; FORTRAN-FFI-ACCESSORS::INTERNAL-UNDERSCORE-P) ; "_" ; "") ; ==> ; "_" ; ; note: deleting unreachable code
; (IF FORTRAN-FFI-ACCESSORS::+F77-LOWER-CASE+ ; (STRING-DOWNCASE FORTRAN-FFI-ACCESSORS::NAME) ; FORTRAN-FFI-ACCESSORS::NAME) ; ==> ; FORTRAN-FFI-ACCESSORS::NAME ; ; note: deleting unreachable code
; /home/rpg/.cache/common-lisp/sbcl-1.0.37.57-linux-x86-64/home/rpg/lisp/matlisp/src/f77-mangling.fasl written ; compilation finished in 0:00:00.015 ; compiling file "/home/rpg/lisp/matlisp/src/ffi-sbcl.lisp" (written 18 MAR 2010 05:21:59 PM): ; compiling (IN-PACKAGE "FORTRAN-FFI-ACCESSORS") ; compiling (DEFUN PARSE-DOC-&-PARAMETERS ...) ; compiling (DEFUN CAST-AS-ARRAY-P ...) ; compiling (DEFUN GET-READ-IN-TYPE ...) ; compiling (DEFUN GET-READ-OUT-TYPE ...) ; compiling (DEFUN GET-READ-IN-STYLE ...) ; compiling (DEFUN GET-READ-OUT-STYLE ...) ; compiling (DEFUN PARSE-FORTRAN-PARAMETERS ...) ; compiling (DEFUN DEF-FORTRAN-INTERFACE ...) ; compiling (DEFMACRO DEF-FORTRAN-ROUTINE ...) ; compiling (DEFMACRO INCF-SAP ...) ; compiling (DEFTYPE MATLISP-SPECIALIZED-ARRAY ...) ; compiling (DECLAIM (INLINE VECTOR-DATA-ADDRESS)) ; compiling (DEFUN VECTOR-DATA-ADDRESS ...) ; compiling (DEFMACRO WITH-FORTRAN-FLOAT-MODES ...) ; compiling (DEFMACRO WITH-VECTOR-DATA-ADDRESSES ...) ; compiling (DEFMACRO WITH-GENSYMS ...)
; /home/rpg/.cache/common-lisp/sbcl-1.0.37.57-linux-x86-64/home/rpg/lisp/matlisp/src/ffi-sbcl.fasl written ; compilation finished in 0:00:00.118 ; ; compilation unit finished ; printed 4 notes #<ASDF:LOAD-OP NIL {10035B43B1}>
Error transcript using --no-userinit:
debugger invoked on a SB-INT:SIMPLE-STREAM-ERROR in thread #<THREAD "initial thread" RUNNING {1002AB6101}>: couldn't check whether #<SB-SYS:FD-STREAM for "standard input" {1002AB66C1}> is readable: Bad file descriptor
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level.
(SB-IMPL::SIMPLE-STREAM-PERROR "couldn't check whether ~S is readable" #<SB-SYS:FD-STREAM for "standard input" {1002AB66C1}> 9) 0] backtrace
0: (SB-IMPL::SIMPLE-STREAM-PERROR "couldn't check whether ~S is readable" #<SB-SYS:FD-STREAM for "standard input" {1002AB66C1}> 9) 1: (SB-IMPL::SYSREAD-MAY-BLOCK-P #<SB-SYS:FD-STREAM for "standard input" {1002AB66C1}>) 2: (SB-IMPL::REFILL-INPUT-BUFFER #<SB-SYS:FD-STREAM for "standard input" {1002AB66C1}>) 3: (SB-IMPL::INPUT-CHAR/UTF-8 #<SB-SYS:FD-STREAM for "standard input" {1002AB66C1}> NIL #:EOF-OBJECT) 4: ((LAMBDA (&REST REST)) #<SB-SYS:FD-STREAM for "standard input" {1002AB66C1}> NIL #:EOF-OBJECT) 5: ((LAMBDA (&REST REST)) #<SB-SYS:FD-STREAM for "standard input" {1002AB66C1}> NIL #:EOF-OBJECT)[:OPTIONAL] 6: (READ-CHAR #<SB-SYS:FD-STREAM for "standard input" {1002AB66C1}> NIL #:EOF-OBJECT #<unused argument>) 7: (READ-CHAR #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {100019E381}> NIL #:EOF-OBJECT #<unused argument>) 8: (SB-IMPL::%READ-PRESERVING-WHITESPACE #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {100019E381}> NIL (NIL) T) 9: (SB-IMPL::%READ-PRESERVING-WHITESPACE #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {100019E381}> NIL (NIL) NIL) 10: (READ #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {100019E381}> NIL (NIL) NIL) 11: (SB-IMPL::REPL-READ-FORM-FUN #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {100019E381}> #<unavailable argument>) 12: (SB-IMPL::REPL-FUN NIL) 13: ((LAMBDA ())) 14: (SB-IMPL::%WITH-REBOUND-IO-SYNTAX #<CLOSURE (LAMBDA #) {1002AB99F9}>) 15: (SB-IMPL::TOPLEVEL-REPL NIL) 16: (SB-IMPL::TOPLEVEL-INIT) 17: ((LABELS SB-IMPL::RESTART-LISP))
0]
Best, r
On 4/11/10 Apr 11 -2:51 PM, Mario S. Mommer wrote:
Hi,
The error with the fd-stream is ignorable. In slime just let the buffer with C-x 1 while in the repl, and that's it. As far as I know, that is a gfortran bug that is not there in the next version. If you bury the buffer with that error you can continue to work without trouble. Strange, but true. I've been doing that for about a year :-)
If that does not work, I'll attempt to do a lisp-only or some other non-fd-crashing thing.
(re aclrepl: maybe you built sbcl with sb-aclrepl?)
There seems to be a lot of contingent stuff here that may be obscuring any ASDF issues.
Question: is it possible to get an analogous issue using only lisp files?
Thanks, r
Robert Goldman rpgoldman@sift.info writes:
Question: is it possible to get an analogous issue using only lisp files?
Yes, up to one thing. I use cat instead of a linker (and do not load the resulting file, but I think that is irelevant)
I uploaded a tarball
http://common-lisp.net/~mmommer/matlispasdfissue.tar.gz
which is the same as before, but that includes a definition file called abug.asd that does not use any alien business. There are no fortran components, only plain lisp ones and instead of the so, some bogus file is generated using cat on the components of unix-dso, which is never loaded. I just wanted to preserve the semantincs of a module that has components but itself does something with the components once the components are done. The operation-done-p has this bogus file to check if it should run the op or not.
With the old asdf, compilation happens only on the first load, while in the new asdf, files get compiled again.
Interestingly, with the old asdf, the following happens:
CL-USER> (asdf:operate 'asdf:load-op 'abug) ;;; stuff elided. ; $ cat "/home/mommer/borrar/matlisp/nothere.fasl" > "/home/mommer/borrar/matlisp/libmatlisp.fasalad" ;;; more stuff elided. CL-USER> (asdf:operate 'asdf:load-op 'abug) ; $ cat "/home/mommer/borrar/matlisp/nothere.fasl" > "/home/mommer/borrar/matlisp/libmatlisp.fasalad" ;;; whoa. It ran the "linker" again! NIL CL-USER> (asdf:operate 'asdf:load-op 'abug) NIL CL-USER>
Any ideas?
Regards, and thanks, Mario
On 2010-04-11, at 21:57 , Robert Goldman wrote:
On 4/11/10 Apr 11 -2:51 PM, Mario S. Mommer wrote:
Hi,
The error with the fd-stream is ignorable. In slime just let the buffer with C-x 1 while in the repl, and that's it. As far as I know, that is a gfortran bug that is not there in the next version. If you bury the buffer with that error you can continue to work without trouble. Strange, but true. I've been doing that for about a year :-)
If that does not work, I'll attempt to do a lisp-only or some other non-fd-crashing thing.
(re aclrepl: maybe you built sbcl with sb-aclrepl?)
There seems to be a lot of contingent stuff here that may be obscuring any ASDF issues.
Question: is it possible to get an analogous issue using only lisp files?
not in the standard configuration. the unix-dso has output files, which result causes operation-done-p to assert that it is never done. a vanilla module does not.
however, take the matlispbug system definition, - strip out everything except the file, components, and module terms, - declare all the files to be :file, declare all the modules to be :module, - make the proper arrangements in the file system, _and_ add a gratuitous in-line output-files method to the initial modules to return a list of files,
and you will observe that an operation gets carried through dependency on the module.
Trying to test this now, on my linux box, but am having problems. I'd like to use ACL, which has a debugger I'm more familiar with, but have 32-bit ACL on a 64-bit linux. Even installing 32-bit gnu fortran, I get a failure, probably because the makefile is detecting that I have a 64-bit OS.
If you can help me through this, I might be able to solve your ASDF problems.
best, r
On 4/11/10 Apr 11 -10:06 AM, Robert Goldman wrote:
Trying to test this now, on my linux box, but am having problems. I'd like to use ACL, which has a debugger I'm more familiar with, but have 32-bit ACL on a 64-bit linux. Even installing 32-bit gnu fortran, I get a failure, probably because the makefile is detecting that I have a 64-bit OS.
If you can help me through this, I might be able to solve your ASDF problems.
best, r
Do you think you could publish a version of this that is loadable on ACL?
The current version has sb-alien:: package hard-coded into the .asd file....
I'll have a whack at this with SBCL, but I'm substantially crippled by my lack of familiarity with SBCL's debugger and with SLIME....
thanks, r
Hi Robert,
Robert Goldman rpgoldman@sift.info writes:
Do you think you could publish a version of this that is loadable on ACL?
The current version has sb-alien:: package hard-coded into the .asd file....
the only line wehere sb-alien is used is on line 102 of matlispbug.asd. If you comment out that line (and close parentheses appropriately) and it should "work" everywhere. Up to stuff in the actual files to be loaded.
Regards, and thanks,
Mario.
On 4/11/10 Apr 11 -12:45 PM, Mario S. Mommer wrote:
Hi Robert,
Robert Goldman rpgoldman@sift.info writes:
Do you think you could publish a version of this that is loadable on ACL?
The current version has sb-alien:: package hard-coded into the .asd file....
the only line wehere sb-alien is used is on line 102 of matlispbug.asd. If you comment out that line (and close parentheses appropriately) and it should "work" everywhere. Up to stuff in the actual files to be loaded.
Tried this, putting #+sbcl in front of the sb-alien call and #+allegro (load ...) in, since ACL docs say to load .so files with LOAD.
This crashes for me for a reason we discussed earlier --- ASDF tries to find the .so file in the cache created by asdf-output-translations, rather than where-ever it should be....
This may be my fault for using ACL/problem with the fortran compilation. With ACL, because of the punitive pricing on 64-bit versions, you can't count on the user having a 64-bit lisp on his/her 64-bit OS. So on ACL at least (possibly other lisps, as well?) need to ask the lisp if it's 32 or 64-bit and then compile the fortran accordingly. Is that right?
I'm old, but not old enough ever to have used fortran ;-)
r
Hi Robert,
well, the 32/64 bit thing would indeed be a good addition to that .asd. Primarily, I wonder if this is a problem of the .asd or of asdf. I think it definately highlights an incompatibility between the old regime and the new one...
Let me try to cook up an example that does not die from portability issues.
Regards, Mario.
Robert Goldman rpgoldman@sift.info writes:
On 4/11/10 Apr 11 -12:45 PM, Mario S. Mommer wrote:
Hi Robert,
Robert Goldman rpgoldman@sift.info writes:
Do you think you could publish a version of this that is loadable on ACL?
The current version has sb-alien:: package hard-coded into the .asd file....
the only line wehere sb-alien is used is on line 102 of matlispbug.asd. If you comment out that line (and close parentheses appropriately) and it should "work" everywhere. Up to stuff in the actual files to be loaded.
Tried this, putting #+sbcl in front of the sb-alien call and #+allegro (load ...) in, since ACL docs say to load .so files with LOAD.
This crashes for me for a reason we discussed earlier --- ASDF tries to find the .so file in the cache created by asdf-output-translations, rather than where-ever it should be....
This may be my fault for using ACL/problem with the fortran compilation. With ACL, because of the punitive pricing on 64-bit versions, you can't count on the user having a 64-bit lisp on his/her 64-bit OS. So on ACL at least (possibly other lisps, as well?) need to ask the lisp if it's 32 or 64-bit and then compile the fortran accordingly. Is that right?
I'm old, but not old enough ever to have used fortran ;-)
r
On 4/9/10 Apr 9 -1:31 PM, Mario S. Mommer wrote:
Hi,
what follows is, as far as I am concerned, an observation, and not a bug report. Maybe it is an interesting issue to keep in mind.
So I upgraded to the new asdf, and observed the following. When I load matlisp with the .asd attached, I get an error that goes like this
/usr/bin/ld: cannot open output file /home/mommer/.cache/common-lisp/sbcl-1.0.37-linux-x86-64/home/mommer/dev/matlisp/lib/libmatlisp.so: No such file or directory collect2: ld returned 1 exit status
The reason for the ld error is that that ^.*/lib/.* does not exist, and again the reason seems to be this: (slightly edited)
[...]
(defsystem :matlisp :components ((:unix-dso "alien code" :pathname "" :dso-name "lib/libmatlisp" ;; barf :components ((:alien-module "BLAS" :pathname "LAPACK/BLAS/SRC/" [...]
I presume one can defend the new asdf here, and I can fix it for me by removing the "lib/" as it does not matter one iota. But I also would expect this to come up again.
I would, too. But I guess I'm a little surprised that this worked before. ASDF-BINARY-LOCATIONS didn't necessarily play well with either data files (often found through use of *load-truename*) or foreign libraries. Such foreign libraries often were generated using make...
best, r