Re: How to use the current directory?
On Fri, Sep 22, 2023 at 3:05 PM Blake McBride wrote: > How can I force asdf to load and use the package in the local directory > rather than the cached standard distribution? My understanding is that the following is poor form (I seem to recall ASDF:*CENTRAL-REGISTRY* is deprecated), however, perhaps it is still useful to you. Try: (push "./" asdf:*central-registry*) This helps ASDF see systems in the current directory, however, I guess I don't know whether this ensures that a system in the current directory is loaded instead of any identically-named systems in other directories. Hope this helps, Robert
asdf-dependency-grovel tests mostly passing now
I've made still more progress on getting asdf-dependency-grovel
running. At this point most of the unit tests are successful; there
are only a couple of failed tests, both having to do with DEFTYPE.
Here's what I'm getting now. I am working on an ancient Ubuntu (14.04)
system. In the interest of clarity I've suppressed the SBCL banner.
$ sbcl --no-userinit --script tests/run-tests.lisp
This is SBCL 2.1.6, an implementation of ANSI Common Lisp.
[...]
WARNING: :SB-EVAL is no longer present in *FEATURES*
;;; TESTS failed:
;; u-deftype.satisfies should have: ("p-deftype"), has NIL
;; u-deftype.bar should have: ("p-deftype"), has NIL
The warning about :SB-EVAL is coming from loading ASDF.
The failed test cases are, respectively,
(in-package :asdf-dependency-grovel-test)
(deftype uses-satisfies ()
`(satisfies satisfies-something))
and
(in-package :asdf-dependency-grovel-test)
(deftype uses-bar ()
`(or (not bar)
(and bar rational)))
while the corresponding provider is
(in-package :asdf-dependency-grovel-test)
(deftype foo () 'string)
(deftype bar () 'integer)
(defun satisfies-something (#1=#:a)
(declare (ignore #1#))
t)
I wonder why the appropriate dependency wasn't detected, but I'm not
too worried about it. ADG is still useful even if it misses these.
Here is the content of tests/run-tests.lisp, which I concocted after
tinkering a bit.
(load "/home/robert/by-others/asdf-3.1.5/build/asdf.lisp")
(push "/home/robert/by-others/asdf-dependency-grovel-master/"
asdf:*central-registry*)
(push "/home/robert/by-others/asdf-dependency-grovel-master/tests/"
asdf:*central-registry*)
(load "tests/grovel-tests.lisp")
(load "handlers/00-standard-handlers.lisp")
(asdf-dependency-grovel-tester:test-result)
There are various questionable aspects of that, which I'll point out,
although they don't really bother me too much -- I'm not responsible
for ADG.
(1) I was able to get ADG working only with this particular
combination of SBCL (2.1.6) and ASDF (3.1.5). There might be other
workable combinations, however, some or all later versions of ASDF
trigger errors in ADG.
(2) Use of ASDF:*CENTRAL-REGISTRY* is terrible. Okay, well, it works.
(3) It appears the handlers file is supposed to be loaded by ASDF,
which, I guess, is supposed to scan the handlers directory, but
something in that process didn't work, so it's loaded by hand.
ADG constructs a new .asd file from the inferred dependencies (and
writes it into the ASDF output cache -- maybe that could be mentioned
in a readme or something) and I present it here as a kind of trophy.
All the best,
Robert Dodier
PS. groveled-components.lisp:
;;; This file contains -*- lisp -*- expressions.
;;; AUTO-GENERATED file from system definition of system
(test-serial-system). Instead of directly editing this file, please
edit the system definition and re-generate this file.
(
("test-serial-system" :components
(
(:file "package"
:encoding :utf-8)
(:file "p-defmacro"
:depends-on ("package")
:encoding :utf-8)
(:file "p-define-method-combination"
:depends-on ("package")
:encoding :utf-8)
(:file "p-feature"
:depends-on ("package")
:encoding :utf-8)
(:file "p-defvar"
:depends-on ("package")
:encoding :utf-8)
(:file "p-define-setf-expander"
:depends-on ("package")
:encoding :utf-8)
(:file "p-defsetf"
:depends-on ("package")
:encoding :utf-8)
(:file "p-defclass"
:depends-on ("package")
:encoding :utf-8)
(:file "p-defstruct"
:depends-on ("package")
:encoding :utf-8)
(:file "p-defgeneric"
:depends-on ("package")
:encoding :utf-8)
(:file "p-defmethod"
:depends-on ("package")
:encoding :utf-8)
(:file "p-define-condition"
:depends-on ("package")
:encoding :utf-8)
(:file "p-defpackage"
:depends-on ("package")
:encoding :utf-8)
(:file "p-defun"
:depends-on ("package")
:encoding :utf-8)
(:file "p-define-symbol-macro"
:depends-on ("package")
:encoding :utf-8)
(:file "p-defconstant"
:depends-on ("package")
:encoding :utf-8)
(:file "p-deftype"
:depends-on ("package")
:encoding :utf-8)
(:file "u-defmacro"
:depends-on ("p-defmacro" "package")
:encoding :utf-8)
(:file "u-defmacro.indirect"
:depends-on ("p-defmacro" "package")
:encoding :utf-8)
(:file "u-define-method-combination"
:depends-on ("p-define-method-combination" "package")
:encoding :utf-8)
(:file &quo
Re: progress on asdf-dependency-grovel
On Fri, Dec 16, 2022 at 2:25 PM Faré wrote:
> sbcl --eval "'(#.(require :asdf) #.(in-package :asdf) #.(upgrade-asdf)
> #.(load-system :asdf-dependency-grovel))" --quit
> No error.
I tried it again with ASDF 3.3 + SBCL 2.1.1, and I can load adg
successfully, with a couple of (push "path/to/adg/"
asdf:*central-registry*) to help it along. However, when I try to run
the unit tests, I get an error from ASDF about "failed to mark it
done". There is also a warning about "proper dependencies" as well.
* (asdf-dependency-grovel-tester:test-result)
WARNING:
Deprecated recursive use of (ASDF/OPERATE:OPERATE 'ASDF/LISP-ACTION:LOAD-OP
'("test-serial-system")) while visiting
(ASDF-DEPENDENCY-GROVEL:DEPENDENCY-OP "test-serial"
"asdf-dependency-grovel-test/serial")
- please use proper dependencies instead
debugger invoked on a SIMPLE-ERROR in thread
#:
Just performed compiling # but failed to mark it done
I think this error is the reason that I decided to use an earlier
(3.1) version of ASDF -- sorry for getting mixed up in what I said
about it.
I'll look at the other debugging hints you mentioned.
best,
Robert
Re: progress on asdf-dependency-grovel
On Fri, Dec 16, 2022 at 3:07 AM Faré wrote: > Or later. I recommend testing with the latest ASDF. I tried a later version (3.2 or 3.3, I forget which) and adg fails to load. I think I'll stick w/ the last known working version until I sort out getting it to run ... > This output doesn't help me. Are the files now visited by the perform > method in order? It looks like that might be the case, but make sure. I'll take a look to see in what order files are processed. > If that still fails, rather than the asdf plumbing itself, can you > identify if the dependency instrumentation is still working on the > latest SBCL? How would I determine if the dependency instrumentation is working? It is not working in the sense that the known dependencies are not detected -- do you mean something else? > IIRC, adg relies on some low-level SBCL interfaces that > might have bitrotten. Okay, there is a warning about an internal SB-something function -- I'll look at whether the relevant code can be updated. Thanks for your help, Robert
progress on asdf-dependency-grovel
I've managed to get asdf-dependency-grovel to load. There is a comment
in adg/tests/grovel-test.lisp that ASDF 3.1 is required. Okay, I have
ASDF 3.1.5 laying around so I loaded that. Now SBCL can load adg.
The test script adg/tests/run-tests.sh runs (with modifications) but
all of the tests fail -- it appears that no dependencies are
identified. I enabled *DEBUG-TRACE* in variables.lisp, and I get some
output which suggests something is happening, which is encouraging.
Faré, can you say anything about what one should expect to see in the
debug output if stuff is working correctly? Can you see anything amiss
in the output shown below?
best,
Robert
PS. Here is the output for adg/tests/u-defconstant.lisp. That file contains just
(cl:in-package :asdf-dependency-grovel-test)
(defvar test-defconstant-user.1 test-defconstant.1)
which references TEST-DEFCONSTANT.1, which is defined in
p-defconstant.lisp, so that's the dependency that's supposed to be
detected. The output for other tests is similar.
- begin output -
DEBUG: Perform load-source-op
#
DEBUG: Operating on (:ASDF ("test-serial-system" "u-defconstant") :ASDF
("test-serial-system") . T)
DEBUG: Operating on (:FILE
#P"/home/robert/by-others/asdf-dependency-grovel-master/tests/u-defconstant.lisp"
:ASDF ("test-serial-system" "u-defconstant") :ASDF
("test-serial-system") . T)
DEBUG: Operating on ((:FORM 0 :FILE
#P"/home/robert/by-others/asdf-dependency-grovel-master/tests/u-defconstant.lisp"
:ASDF ("test-serial-system" "u-defconstant") :ASDF
("test-serial-system") . T)
0 "(IN-PACKAGE :ASDF-DEPENDENCY-GROVEL-TEST)")
DEBUG: Done operating on ((:FORM 0 :FILE
#P"/home/robert/by-others/asdf-dependency-grovel-master/tests/u-defconstant.lisp"
:ASDF ("test-serial-system" "u-defconstant") :ASDF
("test-serial-system") . T)
0 "(IN-PACKAGE :ASDF-DEPENDENCY-GROVEL-TEST)")
DEBUG: Operating on ((:FORM 1 :FILE
#P"/home/robert/by-others/asdf-dependency-grovel-master/tests/u-defconstant.lisp"
:ASDF ("test-serial-system" "u-defconstant") :ASDF
("test-serial-system") . T)
44 "(DEFVAR TEST-DEFCONSTANT-USER.1 ...)")
DEBUG: Done operating on ((:FORM 1 :FILE
#P"/home/robert/by-others/asdf-dependency-grovel-master/tests/u-defconstant.lisp"
:ASDF ("test-serial-system" "u-defconstant") :ASDF
("test-serial-system") . T)
44 "(DEFVAR TEST-DEFCONSTANT-USER.1 ...)")
DEBUG: Done operating on (:FILE
#P"/home/robert/by-others/asdf-dependency-grovel-master/tests/u-defconstant.lisp"
:ASDF ("test-serial-system" "u-defconstant") :ASDF
("test-serial-system") . T)
DEBUG: Done operating on (:ASDF ("test-serial-system" "u-defconstant") :ASDF
("test-serial-system") . T)
- end output -
Re: Lisp file and/or ASDF dependency analysis; trying to load asdf-dependency-grovel
Robert, thanks for your reply. I have made some progress. >> Just performed compiling #> "test-serial-system" "package"> but failed to mark it done > It would help to get a backtrace here. I can't tell from this if the error is > happening in ASDF or in ASDF-DEPENDENCY-GROVEL (which probably isn't > maintained). The "failed to mark it done" is coming from ASDF. The ASDF version (bundled with SBCL) is, I think, 3.2.something. I tried it with Clozure CL, which has (on my system at least) ASDF 3.1.something, and the same operation succeeds. I guess I'm not too worried about it, since I now have a workaround, but I'm curious to know what's going on here. > Also whose run-tests.sh are these? ASDF's tests or ASDF-dependency-grovel's? For the record, it's the run-tests.sh of asdf-dependency-grovel. > Again, it would help to have a backtrace from this circular dependency to > help us get started (if you can share it -- I suppose your system could be > private/proprietary). About the circular dependency, it's in Maxima's ASDF file. After puzzling over a backtrace (thanks for the hint) I figured out it's because :serial t is specified, and a module depends on something later in the .asd. I moved the offending module and that resolved the dependency error. Hurray! > I wonder if we should adopt asdf-dependency-grovel into the ASDF group on > cl.net's GitLab? There's no guarantee that would result in active > maintenance, though -- it should be obvious that I don't have a lot of cycles > to spare... Well, I think that sounds like a good idea. I know developing new code is unlikely but it would be great to at least make any updates necessary to keep up with new ASDF versions. asdf-dependency-grovel seems like a really great idea -- I am hoping to use it to analyze dependencies in Maxima, which, as you may know, is an ancient and pretty large system ... If asdf-dependency-grovel didn't exist, I would have to reinvent some wheels. best, Robert
Lisp file and/or ASDF dependency analysis; trying to load asdf-dependency-grovel
Hi, I'm interested in analyzing dependencies among a collection of
Lisp files, or analyzing dependencies stated in a .asd file, or both.
(1) Towards the goal of analyzing dependencies among Lisp files, I'm
trying to load asdf-dependency-grovel, and I'm not having any luck. I
obtained a tar.gz of the current version from Gitlab, from the project
https://gitlab.common-lisp.net/xcvb/asdf-dependency-grovel. I found it
necessary to patch tests/run-tests.sh to get anywhere (patch below)
and I get the following error at this point:
$ sh tests/run-tests.sh
This is SBCL 2.1.6, an implementation of ANSI Common Lisp.
WARNING: redefining UIOP/UTILITY:PARSE-BODY in DEFUN
WARNING:
Deprecated recursive use of (ASDF/OPERATE:OPERATE 'ASDF/LISP-ACTION:LOAD-OP
'("test-serial-system")) while visiting
(ASDF-DEPENDENCY-GROVEL:DEPENDENCY-OP "test-serial"
"asdf-dependency-grovel-test/serial")
- please use proper dependencies instead
debugger invoked on a SIMPLE-ERROR in thread
#:
Just performed compiling # but failed to mark it done
Can anyone offer any advice about the "failed to mark it done" error?
or the bit about "deprecated recursive use"?
(2) About looking at dependencies stated in a .asd file, I have a .asd
file which ASDF is refusing to load because it has a circular
dependency. Is there a way to get ASDF to tell me what that circular
dependency is? Failing that, can someone suggest any tools to extract
a directed graph from a .asd file? I suppose it wouldn't be too hard
to do it myself but no need to reinvent the wheel.
I'm thinking I could find a graph analysis library to extract any
cycles, if I had a directed graph in hand. I don't suppose someone has
already automated looking for cycles in .asd files?
Thanks in advance for any advice, I appreciate your help.
best,
Robert Dodier
PS. Here's my patch for asdf-dependency-grovel.
$ diff -u tests/run-tests.sh-original tests/run-tests.sh
--- tests/run-tests.sh-original 2022-12-13 22:39:50.174826971 -0800
+++ tests/run-tests.sh 2022-12-13 22:43:41.675974917 -0800
@@ -5,7 +5,10 @@
ADG_TEST_DIR="$(dirname $0)"
-$LISP --load ${ADG_TEST_DIR}/grovel-tests.lisp --eval '(uiop:quit
(asdf-dependency-grovel-tester:test-result))'
+$LISP --eval '(require (quote asdf))'\
+ --eval '(push
"/home/robert/by-others/asdf-dependency-grovel-master/"
asdf:*central-registry*)'\
+ --eval '(push
"/home/robert/by-others/asdf-dependency-grovel-master/tests/"
asdf:*central-registry*)'\
+ --load ${ADG_TEST_DIR}/grovel-tests.lisp --eval '(uiop:quit
(asdf-dependency-grovel-tester:test-result))'
STATUS=$?
rm -rf asdf-dependency-grovel-tmp-*
#$LISP --load ${ADG_TEST_DIR}/grovel-tests.lisp --eval
'(asdf-dependency-grovel-tester:check-base-deps)' --eval '(uiop:quit)'
Re: Next steps
On Wed, Nov 17, 2021 at 10:45 AM Robert Goldman wrote: > I favor something like this because it would be nice to have prerelease > versions of ASDF that perform version checks properly. > > What I mean is, if we are going to add a feature in version 3.4, right now > that would be in a prerelease version with a version number of something like > 3.3.5.22 > > It would be a lot better for realistic testing if we could instead use > 3.4.0-alpha1 or 3.4.0-1 and have ASDF know that 3.4.0-1 comes before 3.4.0, > not after. Hi Robert, hi everyone. I haven't been following closely, but while you are working out details, let me just mention that I recommend against version numbers that require special interpretation to discover their ordering, e.g. 3.4.0-1 < 3.4.0. Mostly I'm just thinking that somebody's not going to get the memo (it's usually me). For what it's worth, and all the best. Robert.
Re: Rejiggering the branches
On Mon, Jul 12, 2021 at 10:52 AM Rudolf Schlatte wrote: > In the first email you said that the purpose of that branch was to > permit continuation of the 3.3 release series, so maybe call the branch > "v3.3"? That way, there can be multiple such branches without resorting > to "stable", "oldstable" etc. names. Hi everyone, I am only an interested onlooker, but anyway I would like to second the motion for a branch named according to the version series. Specifically I'll suggest version-3_3 (I seem to recall Git forbids "." in branch names) with the understanding that every version on that branch will be 3.3.something. In this picture development continues on a branch named master or main or dev or whatever. Commits can be cherry picked from the, um, primary development branch to the release branch to backport any changes deemed appropriate. Any future releases would be on a new branch, presumably version-3_4 or version-4 or whatever; the version-3_3 branch would not be reused for that purpose. The benefit of such a scheme, I believe, is just to make it clearer what's what. FWIW Robert Dodier
How to tell if we're being loaded by ASDF?
Hi, this is a bit off the wall, but maybe there is a way to do it. A web search didn't seem to find anything about it. Is there a way to know that ASDF is loading stuff? I have this situation. A file might be loaded by ASDF or it might be loaded by hand. If it's being loaded by ASDF, then I'd like to do some stuff differently. Why might this file be loaded by hand, why not always use ASDF? Well, it's not a Lisp file, it's a Maxima file being loaded by some maxima-asdf hackery. I can't count on maxima-asdf working for anybody else so I'm expecting that people will load it by hand instead of ASDF. But if it is being loaded by ASDF, then I'd like to know that. Thanks a lot for any info, Robert Dodier
Re: Lowercase naming requirement for systems?
On Sun, Feb 17, 2019 at 4:08 PM Robert Goldman wrote: > It's actually there, at least if you are looking for it. In my own defense: I did look for it and I did find that text, but didn't find it helpful. It says the name of a system is conventionally lowercase -- this is not the same as saying that it is required to be lowercase. I found the text about pathname specifiers as well. I didn't see a requirement there because neither the system name nor component names were specified by the grammar or the commentary on the grammar to be pathname specifiers. Thanks again for your help, Robert Dodier
Re: Lowercase naming requirement for systems?
On Sun, Feb 17, 2019 at 6:25 AM Robert P. Goldman wrote: > Quick response for now: yes, lowercase naming is a requirement. Hi Robert, thanks for your reply. Got it, no problem. I will adjust my stuff accordingly. It would really help a lot if the policy for the name of the system and the corresponding .asd filename were spelled out in the ASDF manual. As it stands, the manual doesn't say anything about requirements for system-designator; there are incidental comments suggesting using lowercase but not a specification or requirement. If names are indeed restricted to lowercase letters, digits, and hyphens, it would be great to say so. On a separate topic, are there any restrictions on the names of components? As it stands the manual says only that component names may be either strings or symbols. Mixed case component names appear to work OK but that may be only fortuitous. Thanks again, and best wishes. Robert Dodier
Lowercase naming requirement for systems?
Hi,
The ASDF manual says that the name of a system is a lowercase string.
Is that actually a requirement?
I was trying to create an .asd system which has a name with mixed
upper- and lowercase characters and the system is stored in a file of
the same name on a case-sensitive file system (Linux). But I get
"Component Foo not found" for that. If I change the name of the system
and the name of the file to lowercase, the system is found.
For the record, I've pasted the would-be mixed-case named system
below. It contains stuff that will make it generally unloadable since
you don't have my maxima-file hackery. If it turns out we need to go
into this in more detail, I will devise a more minimal example. But
first maybe someone can say what the name requirement is.
best,
Robert Dodier
PS.
(defsystem "SolveSolvable2"
:defsystem-depends-on ("maxima-file")
:author "Yasuaki Honda"
:license "GNU Lesser General Public License, version 2"
:description "Program SolveSolvable2 of GaloisGroupSolver, a Maxima
package for solving polynomials based on their Galois Groups"
:components
((:maxima-file "Gal")
(:maxima-file "FiniteGroup")
(:maxima-file "ExtendedField")
(:maxima-file "Stage3")
(:maxima-file "Verify")
(:maxima-file "SolveSolvable2")))
Re: Problems with DEFSYSTEM-DEPENDS-ON
Thanks to everyone for their interest in this topic. In reference to https://github.com/quicklisp/quicklisp-client/pull/128/, it is only a minimal stop-gap measure which I found could fix the immediate problem which I encountered. I know very little about ASDF and Quicklisp, so I certainly had no conscious intent to assert that one condition or another must prevail. Any improvements by more knowledgeable people would be welcomed by me. All the best, Robert Dodier
Re: follow-up about handling .info file and index
Thanks for your comments, Robert. I've revised the INFO-INDEX class and made it a lot simpler (and still working the same). For what it's worth, I've pasted it below. I noticed that UIOP:COPY-FILE doesn't seem to behave well if told to copy a file to itself -- it clobbers the file. That seems like unfriendly behavior; it seems better that either it should complain or do nothing. Thanks for your help, I think I'm in good shape on this front now. best, Robert Dodier PS. ;; info-index.lisp -- ASDF component type for Maxima documentation index ;; copyright 2018 by Robert Dodier ;; I release this work under terms of the GNU General Public License (require 'asdf) (require 'uiop) (in-package :asdf) (defclass info-index (cl-source-file) ()) ;; An info index file is a Lisp source file, which is compiled ;; just the same as an ordinary Lisp file, with the additional ;; step of copying the .info to the same location to where the ;; compiler output will go. (defmethod perform ((o compile-op) (c info-index)) (let* ((system-name (component-name (component-system c))) (info-name (make-pathname :name system-name :type "info")) (info-in-file (merge-pathnames info-name (first (input-files o c (info-out-file (merge-pathnames info-name (first (output-files o c) ;; INFO-IN-FILE and INFO-OUT-FILE should be different, ;; but just to be safe, silently refuse to copy file to itself. (unless (uiop:pathname-equal info-in-file info-out-file) (uiop:copy-file info-in-file info-out-file)) (call-next-method)))
Re: follow-up about handling .info file and index
On Tue, Mar 20, 2018 at 7:30 PM, Faré <fah...@gmail.com> wrote: > If your index is just a lisp file, > why do you even need to subclass cl-source-file, to begin with? > And if you do, why do you need override any method or initform? > Let the CL source files be compiled the normal way! Yes, well, the only specific thing is to copy the .info file to the place where the fasl goes, then it punts to whatever cl-source-file says to do. > As to locating the .info file, while not just use the recommended > asdf:system-relative-pathname ? Well, the info index is something that's used in non-ASDF contexts in Maxima, and I didn't want to change it. I agree that asdf:system-relative-pathname would be the right way to go, if I were able to start over. > NB: If you're that masochist, please contact me as I'm pushing for > something broadly similar in gerbil-scheme's clan libraries; Well, I do endure a lot of self-inflicted suffering, but unfortunately I already have an unending to-do list for Maxima ... >> (1) In the class definition for INFO-INDEX, it >> seems to be necessary to intone (type :initform "lisp"). >> > This is not necessary. You are confused. See Robert Goldman's response. Yup, I will revise the code in light of Robert's comments. > However, note that this pattern is NOT currently in use > in asdf/component.lisp or asdf/lisp-action.lisp -- yet. > I would recommend that a future ASDF maintainer should in the future > replace all current occurrences of static slots :initform with this style I dunno -- I think I'm going to play it safe and use the old pattern, if it's necessary at all ... I'm a pretty casual ASDF user, I don't know if I can invest the time to figure the old vs new stuff. All the best, Robert Dodier
using most recent .asd file, if multiple are present
Hi, I wonder if it's possible that if multiple .asd's with the same name are present, I can ensure that the .asd with the most recent timestamp is used. The use case I have in mind is that I'm trying to set up a system to download automatically-generated tarballs which contain a snapshot of a project. Snapshots contain whatever was available (in Git) at the time the tarball is generated. These are unpacked (by Quicklisp) and all files in the tarball are given timestamps equal to the time at which the tarball was unpacked (not the time the tarball was generated and not the time of the most recent file modification or commit). Each tarball has a different name (derived from Git project name + most recent commit hash) so there will be multiple .asd files with the same name in different directories. But since they all have different time stamps, I think I'm in good shape: I just need to be able to identify the most recent one. I see the ASDF manual says: "When looking in a tree, if one system is found, the search succeeds. If multiple systems are found, the consequences are unspecified: the search may succeed with any of the found systems, or an error may be raised. ASDF currently returns the first system found, ...". Is there any way to intervene to return a specific system, specifically the most recent one? Thank you once again for your help, Robert Dodier
follow-up about handling .info file and index
Hi, I was asking recently about how to handle a .info file and its index (CL) in ASDF. What I finally settled on is this. When the operation is COMPILE-OP, the .info file is copied to same location where the index fasl will go (because the index has some code to read the .info and it assumes the .info is in the same place as the fasl). In the .asd file, I say (defsystem-depends-on "info-index") and (:info-index "foo-index") for the component foo-index.lisp. This seems to be working as intended. I've pasted the code I devised as a PS below. If anyone has any comments about it, I would be interested to hear it. I have a couple of specific questions about the code, which you can see in the comments. (1) In the class definition for INFO-INDEX, it seems to be necessary to intone (type :initform "lisp"). Is that actually necessary? If so, why is that? I would have expected (on little reason) that the parent class CL-SOURCE-FILE would supply that. (2) In INPUT-FILES, why doesn't (info-index-type c) yield "lisp"? Doesn't INFO-INDEX have an accessor INFO-INDEX-TYPE? I may well be very confused about simple things. Thank you for your patience, I appreciate it. Robert Dodier PS. info-index.lisp: ;; info-index.lisp -- ASDF component type for Maxima documentation index ;; copyright 2018 by Robert Dodier ;; I release this work under terms of the GNU General Public License (require 'asdf) (in-package :asdf) (defclass info-index (cl-source-file) ((type :initform "lisp"))) ;; ISN'T THIS INHERITED FROM CL-SOURCE-FILE ?? (defmethod perform ((o load-source-op) (c info-index)) (call-next-method)) (defmethod perform ((o load-op) (c info-index)) (call-next-method)) (defmethod input-files ((o compile-op) (c info-index)) (let* ((foo (call-next-method)) ;; WHY DOESN'T THE FOLLOWING LINE WORK ?? ;; (bar (info-index-type c)) (bar "lisp") (baz (merge-pathnames (make-pathname :type bar) (first foo (list baz))) (defmethod output-files ((o compile-op) (c info-index)) (call-next-method)) (defun silly-copy (in-file out-file) (unless (equalp in-file out-file) ;; silently refuse to copy file to itself (with-open-file (in in-file) (with-open-file (out out-file :direction :output :if-exists :supersede) (do ((c (read-char in nil) (read-char in nil))) ((null c)) (write-char c out)) (defmethod perform ((o compile-op) (c info-index)) (let* ((system-name (component-name (component-system c))) (info-name (make-pathname :name system-name :type "info")) (info-in-file (merge-pathnames info-name (first (input-files o c (info-out-file (merge-pathnames info-name (first (output-files o c) (silly-copy info-in-file info-out-file) (call-next-method)))
Re: Finding out from where the .asd was loaded and/or referencing a non-executable data file
On Fri, Mar 16, 2018 at 1:59 PM, Robert Goldman <rpgold...@sift.info> wrote: > Another trick you could try is to define a special class of files for the > info files (probably just a subclass of cl-source-file). Then you could tell > ASDF not to move that class of files, by providing a method on OUTPUT-FILES. > You can return T for the second value in order to have output-translations > not apply, IIRC. Actually, one way to achieve the effect that I want is to have the info file copied into the place where the fasls end up (because then *LOAD-PATHNAME* points to the place where the info file is found, just as it is when the index.lisp is loaded via LOAD). I suppose I could create a class that has the effect of copying the info files without any other operation on them? best, Robert Dodier
Re: Finding out from where the .asd was loaded and/or referencing a non-executable data file
Thanks, Robert, that helps a lot. Using ASDF:SYSTEM-RELATIVE-PATHNAME is a big step forward. A follow-up question: Is there a way to know, within a file which is being loaded, whether or not it's being loaded via ASDF? The index file might be loaded via CL:LOAD also. Just to clarify the situation a little, the .info is created from .texi by makeinfo, and then it's parsed (by a Perl script -- OH MY WHAT HAVE I DONE?? Ha ha, only serious) to get the offset and length of each documentation item, which is stored in the index, which is implemented as a Lisp program that reads the .info and builds suitable hash tables, to be used by Maxima's documentation system at run time. All that with makeinfo and the info parser happens long before ASDF comes into the picture. The .info and index.lisp are packaged with the rest of the code, and that's the package that ASDF sees. I don't doubt that this systems has flaws, but at this point I am taking it as a given; I'm trying to make progress on a lot of fronts, and cleaning up this monstrosity is a lower priority item. best, Robert Dodier
Re: Finding out from where the .asd was loaded and/or referencing a non-executable data file
On Fri, Mar 16, 2018 at 11:05 AM, Lucien P <druro...@gmail.com> wrote: > ASDF will put your static file into the FASL location without touching it > then you can find it to load using ASDF:FIND-COMPONENT. One of the > component's slots will have the pathname of the "compiled" file in it, you > don't have to use *LOAD-TRUENAME*. Hmm, examining the cache after running ASDF, I don't see the static files there. But I think using the component slot to get the file location is promising, I will give that a try. best, Robert Dodier
Finding out from where the .asd was loaded and/or referencing a non-executable data file
Hi, I am resuming my tinkering on the Maxima interface to ASDF. I have bumped into a kind of minor problem for which I don't see a solution. Maxima can read .info files for documentation items. An index file (Lisp) which is created ahead of time (not run time) tells where the items are in the .info. The .asd, index, and .info are all in the same directory. Some code in the index file tells Maxima to read the .info from the same place from which the index is loaded (via *LOAD-PATHNAME*). That works great when the asd is loaded via LOAD-SOURCE-OP since *LOAD-PATHNAME* points to the directory where the .info file is. But when the asd is loaded via LOAD-OP, it doesn't work, since *LOAD-PATHNAME* points into the place that ASDF puts fasls. I gather from the ASDF reference manual that there isn't any way to load, without compiling, only the index file (I'm looking at "How do I mark a source file to be loaded only and not compiled?"). So I'm thinking about some other way to locate the .info file. Is there a special variable or something which tells the path from which the .asd is being loaded? I looked at the documentation and the list of external symbols but couldn't puzzle out anything. The more general idea is that the system contains a non-Lisp data file. Is there a general approach to work with that? Thanks for any light you can shed on this problem. Robert Dodier
Re: maintaining non-Lisp systems with ASDF
On Wed, Sep 23, 2015 at 2:39 PM, Faré <fah...@gmail.com> wrote:
> What you really need to do is:
Thanks, I will take a look at that. It is working well enough for the
moment, but I will circle back later to polish it up.
I have a question now about how to ensure that the :maxima-file
component type is defined before it is used. Let's say I have foo.asd
which has :maxima-file components. Ideally I would like to simply say
(asdf:load-system :foo) without having to load the maxima-file
definition before. It occurred to me to put (defsystem foo :depends-on
("maxima-file") ...) and move the :maxima-file stuff into another
system. But that doesn't work, of course, because :maxima-file is not
yet defined before the :foo system is parsed, and I get an error about
:maxima-file being unrecognized.
I can put (load-system :maxima-file) before (defsystem foo ...) and
then it works OK. I'm happy that it works, but it seems a little messy
to me -- there are now two kinds of dependencies, one kind that has to
be loaded before the defsystem, and the other after ...
It's not a big deal, but can anyone think of a way to move the
maxima-file dependency back into the :depends-on list?
Thanks for your help,
Robert Dodier
Re: maintaining non-Lisp systems with ASDF
Hey everybody,
I've made some more progress with a Maxima extension for ASDF
(attached). At this point it works pretty much as expected, for the
simple examples I've tried. I think you should be able to use in
Maxima like this: load("maxima_asdf.lisp"); asdf_load("foo"); to load
foo.asd, which may contain :maxima-file components. asdf_load
translates :maxima-files and compiles the resulting Lisp, while
asdf_load_source just interprets the :maxima-files.
At this point the only thing I wish I could change (and this is a
minor item) is that output file paths are something like
$HOME/.cache/common-lisp/.
I'm constructing the /... part of it. I wonder if it's
possible to tell ASDF it doesn't need to put in the
part.
Thanks for your help, and if you have any comments, I would be
interested to hear about it.
best
Robert Dodier
maxima_asdf.lisp
Description: Binary data
Re: maintaining non-Lisp systems with ASDF
Thanks a lot to everybody for the advice. I think I've made some progress. I've attached a patch showing the initial changes I've made, and with this much I can load a trivial system into Maxima. I'm working with asdf.lisp 2.26 which is packaged with Quicklisp, since the larger goal is to use Quicklisp to download and install Maxima packages. Incidentally I'm working with Clisp 2.49. I've run into some strangeness, maybe someone can explain what's going on. (1) (asdf:load-system :foo) seems to always cause files to be compiled. That's kind of puzzling. (2) The first time asdf.lisp is loaded, Quicklisp writes asdf.fas into its own cache. The second time, I get an error about ASDF:OOS. Any ideas? Here's the error: $ maxima ;; Loading file /home/robert/.clisprc.lisp ... ;; Loading file /home/robert/quicklisp/setup.lisp ... HELLO FROM QUICKLISP/ASDF.LISP !! *** - EVAL: undefined function ASDF:OOS The following restarts are available: USE-VALUE :R1 Input a value to be used instead of (FDEFINITION 'ASDF:OOS). RETRY :R2 Retry STORE-VALUE:R3 Input a new value for (FDEFINITION 'ASDF:OOS). SKIP :R4 skip (LET # #) RETRY :R5 retry (LET # #) STOP :R6 stop loading file /home/robert/quicklisp/setup.lisp SKIP :R7 skip (LET # #) RETRY :R8 retry (LET # #) STOP :R9 stop loading file /home/robert/.clisprc.lisp Break 1 QL-SETUP[4]> Thanks again, Robert PS. Here's the example foo.asd I've been working with. (defsystem foo :name "foo" :version "2015.09.21" :maintainer "Robert Dodier" :author "Robert Dodier" :licence "GPL" :description "Foo, Bar, and Baz" :long-description "Apply Foo's algorithm to Bar, yielding Baz" :components ((:maxima-source-file "foo1") (:maxima-source-file "foo2"))) tmp-asdf-maxima-wip-2015-09-21-patch Description: Binary data
maintaining non-Lisp systems with ASDF
Hi, I am exploring the possibility of using ASDF to define systems of non-Lisp code, specifically for Maxima (http://maxima.sourceforge.net). Maxima is written in Lisp but has its own language. I'd like to be able to load programs written in Maxima's language and/or Lisp. It seems like ASDF should be suitable if I can just replace calls to COMPILE-FILE with Maxima's compile_file, and replace LOAD with Maxima's load. After looking over the 3.1.5 source code, it seems like one could clobber COMPILE-FILE* and LOAD* with Maxima-specific versions. That seems suboptimal, since it would be helpful to have the original versions of those functions for loading Lisp files. Can someone give some advice about how to go about adapting ASDF to Maxima? Have there been similar attempts for other applications? The bigger picture is that I'd like to use Quicklisp to download and install Maxima packages, and Quicklisp uses ASDF to compile and load stuff. Thanks in advance for any light you can shed on this problem. Robert Dodier
