Re: Method combination and ASDF
François-René ÐVB Rideau écrivait: > What are the methods defined by asdf-flv? In order to support file local variables, ASDF-FLV does this: (defmethod asdf:perform :around ((operation asdf:load-op) (file asdf:cl-source-file)) "Establish new dynamic bindings for file-local variables." (progv *file-local-variables* (mapcar #'symbol-value *file-local-variables*) (call-next-method))) (defmethod asdf:perform :around ((operation asdf:compile-op) (file asdf:cl-source-file)) "Establish new dynamic bindings for file-local variables." (progv *file-local-variables* (mapcar #'symbol-value *file-local-variables*) (call-next-method))) The problem, of course, is that loading ASDF-FLV will override any existing method with the same signature, and conversely, anything else loaded afterward will override ASDF-FLV. ASDF-FLV could subclass ASDF:CL-SOURCE-FILE and specialize only on that subclass, but that would defeat its pervasiveness and make it more difficult to have multiple extensions working together. Hence Robert's idea of mixins. My own idea was to have exported operations use a special method combination allowing multiple methods with the same signature. -- Resistance is futile. You will be jazzimilated. Jazz site: http://www.didierverna.com Other sites: http://www.didierverna.info
Re: Method combination and ASDF
François-René ÐVB Rideau écrivait: > What are the methods defined by asdf-flv? In order to support file local variables, ASDF-FLV does this: (defmethod asdf:perform :around ((operation asdf:load-op) (file asdf:cl-source-file)) "Establish new dynamic bindings for file-local variables." (progv *file-local-variables* (mapcar #'symbol-value *file-local-variables*) (call-next-method))) (defmethod asdf:perform :around ((operation asdf:compile-op) (file asdf:cl-source-file)) "Establish new dynamic bindings for file-local variables." (progv *file-local-variables* (mapcar #'symbol-value *file-local-variables*) (call-next-method))) The problem, of course, is that loading ASDF-FLV will override any existing method with the same signature, and conversely, anything else loaded afterward will override ASDF-FLV. ASDF-FLV could subclass ASDF:CL-SOURCE-FILE and specialize only on that subclass, but that would defeat its pervasiveness and make it more difficult to have multiple extensions working together. Hence Robert's idea of mixins. My own idea was to have exported operations use a special method combination allowing multiple methods with the same signature. -- Resistance is futile. You will be jazzimilated. Jazz site: http://www.didierverna.com Other sites: http://www.didierverna.info
Re: [RFC] subsystems vs. modules
Wilfredo Velazquez wrote: > Sorry in advance for not exactly answering your question, but out of > curiosity, what would 'conditionally included' entail exactly? Conditional in the ASDF sense, that is... > BTW See ASDF's `:if-feature` option. ... exactly that, or :feature, etc. -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
[RFC] subsystems vs. modules
Hi there, until now, I had a tendency to split a library into several systems (more or less without thinking much) as soon as such or such feature was conditional (e.g. depending on CFFI availability, thread support, etc.). Now I realize that in many cases, a conditionally included module or component would suffice, and so I'm starting to think that maybe I should do that, unless it makes sense for the conditional part to be loaded sort of standalone, independently from the rest, in which case a subsystem is more appropriate. So my question is: WDYT, is there a general recommendation about this? Thanks. -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: Next steps
Eric Timmons wrote: > So to prevent misinterpretation of 3.4.0-1, ASDF could either promise > to always use something like alpha/beta/etc, Then I suggest to also allow a, b, rc, and maybe p (for pre; equivalent of release candidate). That should cover a lot of ground. -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: Next steps
Stelian Ionescu wrote: >> Mostly sounds good to me. Assuming you're still interested in more >> expressive version numbers and constraints for 3.4, I'll work on moving >> that off the back burner. > > Adding fine-grained version constraints would be a big mistake. I do not have the time to check this thoroughly right now, but I recall having suggested that ASDF shouldn't impose any constraints on version "numbers", but rather defer version comparison to libraries when they use a version numbering scheme that ASDF doesn't understand. This can be done by providing generic functions like version-> etc., and letting people provide methods on them. There may even be an issue and a patch lurking around somewhere. Again, sorry for being fuzzy, this is just from the top of my head. -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: Dependency issue with program-op
François-René ÐVB Rideau écrivait: > Your manual (asdf:load-system ...) from the .asd file is equivalent to > a :defsystem-depends-on dependency. It creates a dependency at > system-definition-time, but not at runtime. Not at runtime, ergo, not > to be included in the executable. No, this is wrong. Like I said, there is ALSO a load-time (indirect) dependency on the setup system via :depends-on, so the setup system IS included in the executable. > If it defines packages that are required in the executable, it MUST be > added as a load-time dependency as well as a system-definition-time > dependency. Which, again, is exactly the case. After sleeping over it, I have a different hypothesis: a problem in the execution order of everything that's dumped. The reason for the LOAD-SYSTEM call is for this line in the system definition: :version #.(net.didierverna.clon.setup:version :short) So I don't really know how program-op works in ECL (in particular, what it does with the .asd files), but now I think that at the time this above function needs to be called, the setup system isn't hot yet, and so its package hasn't been created. Regardless, if that's indeed the case, the conclusion remains the same: in order to "program-op" a system depending on Clon with ECL, an explicit dependency on clon.setup needs to be added first. The other obvious solution would be for ASDF to let me provide a form to be executed without the need for #., but I seem to recall that you didn't want such things to be possible in system definitions. -- ¡En Seguida! -- New album: https://www.didierverna.com/records/en-seguida.php Available on all digital platforms now! Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: Dependency issue with program-op
Daniel Kochmański wrote: > If the setup is indirect dependency of a dumped system, then it is > most likely asdf bug Yes, it's an indirect dependency via a chain of :depends-on: :simple -> :net.didierverna.clon -> :net.didierverna.clon.core -> :net.didierverna.clon.setup -- ¡En Seguida! -- New album: https://www.didierverna.com/records/en-seguida.php Available on all digital platforms now! Lisp, Jazz, Aïkido: http://www.didierverna.info
Dependency issue with program-op
Hello, I'm cross-posting because I don't know if the issue is related to ASDF or ECL. I'm using the most recent repos of both. When dumping a very simple system defined like this: (asdf:defsystem :simple :depends-on (:net.didierverna.clon) :components ((:file "simple")) :entry-point "simple:main") with (asdf:operate 'asdf:program-op :simple), I'm getting a runtime error with the executable: Condition of type: SIMPLE-PACKAGE-ERROR There exists no package with name "NET.DIDIERVERNA.CLON.SETUP" No restarts available. Top level in: #. So it seems that the net.didierverna.clon.setup system is not dumped in the executable. In Clon, the dependency on setup is indirect: net.didierverna.clon <- net.didierverna.clon.core net.didierverna.clon.core <- net.didierverna.clon.setup If I add an explicit dependency on setup in the :simple ASDF system above like this: :depends-on (:net.didierverna.clon.setup :net.didierverna.clon)) the problem goes away. This doesn't happen with the 5 other Lisp implementations that I've tested. Also, it may be worth mentioning that Clon's setup system gets a special treatment. It's loaded explicitly at the top of several .asd files like this (with the utmost disrespect for the Almighty ASDF Gods recommendations): (asdf:load-system :net.didierverna.clon.setup) I'm wondering if this may have something to do with the problem. Thanks! -- ¡En Seguida! -- New album: https://www.didierverna.com/records/en-seguida.php Available on all digital platforms now! Lisp, Jazz, Aïkido: http://www.didierverna.info
Is program-op supported on Lispworks ?
Hi, sorry for asking, I can't test it locally (I only have the personal edition here). -- ¡En Seguida! -- New album: https://www.didierverna.com/records/en-seguida.php Available on all digital platforms now! Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: System cleanup
"Robert Goldman" écrivait: > Didier, would you mind posting a GitLab issue for this? It's feasible, > but I'm so overloaded right now that there's no chance I will get to > it before I forget. Sure! -- ¡En Seguida! -- New album: https://www.didierverna.com/records/en-seguida.php Available on all digital platforms now! Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: System cleanup
François-René ÐVB Rideau écrivait: > Before it can be ignored, it must be defined. And so as to define it, > its class must be defined. I suppose we could have some error class > that it used when the class it not defined, that would only trigger an > error at runtime if the feature is true. I'm sure the current / next > sucker^W maintainer will accept patches. Not a big deal. I just thought that since everything in that form are keywords (so no read-time problem, as opposed to parsing sb-grovel:grovel-constants-file), perhaps the intended behavior was different. So in the end, it seems that there's very little (if at all) to be gained by using :if-feature to conditionalize on implementation type. -- ¡En Seguida! -- New album: https://www.didierverna.com/records/en-seguida.php Available on all digital platforms now! Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: System cleanup
François-René ÐVB Rideau écrivait: > Using git log test/test-defsystem-depends-on.script it looks like this > is https://bugs.launchpad.net/asdf/+bug/1445638 Looking for that bug > in git log, it was fixed in 3.1.4.5 on 2015-04-23. I'm proceeding with the second issue in my system, and it seems that the problem is still here (ASDF 3.3.4.10). With this inside: :components (#+sbcl (sb-grovel:grovel-constants-file "sbcl/constants" :package :net.didierverna.clon :if-feature :sbcl) (:cffi-grovel-file "cffi/constants" :if-feature (:or :allegro :clisp :lispworks)) ...) SBCL complains (as well as all but ACL, CLISP, and LW): debugger invoked on a LOAD-SYSTEM-DEFINITION-ERROR in thread #: Error while trying to load definition for system net.didierverna.clon.termio from pathname /Users/didier/Documents/Science/Software/Common Lisp/clon/termio/net.didierverna.clon.termio.asd: don't recognize component type :CFFI-GROVEL-FILE If I understand :if-feature correctly, the whole component form should be ignored, right? -- ¡En Seguida! -- New album: https://www.didierverna.com/records/en-seguida.php Available on all digital platforms now! Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: System cleanup
"Robert Goldman" wrote: > This one seems complex enough -- and so much trouble to make a MWE -- > that maybe you want to just change it and see if it breaks. Yup, that's what I did locally, with recent versions of all compilers I have. Those shipping with ASDF seem to all have 3.2.0 at least now, but I was a bit curious as to when exactly the issues were fixed, and too lazy to investigate the change logs by myself ;-) -- ¡En Seguida! -- New album: https://www.didierverna.com/records/en-seguida.php Available on all digital platforms now!
Re: System cleanup
François-René ÐVB Rideau écrivait: > What more, even Xach seems to have miraculously seen the light: one > months and one week ago, he updated the fallback ASDF in Quicklisp > from 2.26 to 3.2.1! That's also what made me think I could perhaps do some clean up! > That was the first update of ASDF in Quicklisp since 2012, to a > version then-current, to a version 4 years old. By linear > extrapolation, we should expect the next update to happen in 2030, to > a version from 2022. I admit that I was thinking his next move would > be to downgrade ASDF to 1.369 (the last version before I took over). :-) :-) -- ¡En Seguida! -- New album: https://www.didierverna.com/records/en-seguida.php Available on all digital platforms now!
System cleanup
Hi, I would like to remove some old workaround code from a couple of systems, wrt to ASDF 3.1.4 bugs (see below). Is it safe to do so now, or are these "bugs" still lurking around? The relevant parts are as follows: :defsystem-depends-on (:net.didierverna.clon.setup/termio #+sbcl ;; BUG in ASDF 3.1.4: d-d-o can't deal dependency expanding to NIL (:feature :sbcl (:require :sb-grovel)) #+(or allegro clisp lispworks) (:feature (:or :allegro :clisp :lispworks) :cffi-grovel)) and :components (;; bug in ASDF 3.1.4: cannot deal with conditionally defined ;; component class! #+sbcl (sb-grovel:grovel-constants-file "sbcl/constants" :package :net.didierverna.clon :if-feature :sbcl) #+(or allegro clisp lispworks) (:cffi-grovel-file "cffi/constants" :if-feature (:or :allegro :clisp :lispworks)) Thank you! -- ¡En Seguida! -- New album: https://www.didierverna.com/records/en-seguida.php Available on all digital platforms now! Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: Where is my executable?
Eric Timmons wrote: > This should give you what you want: > > (asdf:output-files 'asdf:program-op "my-system") Cool! Thank you (both)! -- ¡En Seguida! -- New album: https://www.didierverna.com/records/en-seguida.php Available on all digital platforms now! Lisp, Jazz, Aïkido: http://www.didierverna.info
Where is my executable?
Hi, what's the proper way to find out where a dumped executable (resulting from a program-op) has landed? I would like to it to literally :move-here #p"./", to speak in MAKE-BUILD terms... Note that *I* know where it is in the cache; what I want is programmatic access to its location. Thanks! -- ¡En Seguida! -- New album: https://www.didierverna.com/records/en-seguida.php Available on all digital platforms now! Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: Extracting a UIOP's manual
"Robert Goldman" wrote: > On 15 Aug 2018, at 8:59, Hugo Ishimaru wrote: > > Hi all, > > I have extracted a UIOP's manual from docstrings: > https://privet-kitty.github.io/etc/uiop.html It's not perfect in any > means as docstring isn't written in a markup langugage, but will be > at least a comprehensive reference. The relevant fork of ASDF is in > Github: https://github.com/privet-kitty/asdf/tree/uiop-man/uiop/doc > The greater part of the generation conforms to that of Alexandria, > which depends on SBCL (sb-texinfo). > > I send this mail as it states > > Help wanted extracting working documentation from UIOP's docstrings. > in README.md though I might not understand a historical context. > > Regards > Hugo Ishimaru > > Thank you very, very much! I am going to be away from ASDF for about a > week now, but I will look for it as soon as I get back. This will be > very helpful indeed! FWIW, Quickref now also documents ASDF and UIOP. -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: long-description
Eitaro Fukamachi écrivait: > To be honest, I'm not a big fan of it anymore and I don't follow it in > my recent products. I'm willing to delete the code from CL-Project, > though I have nothing I can do for existing projects. Not a big fan either. What I usually do is use the description slot as a one-liner, and the long-description one as some kind of abstract about the project. My README files are usually longer, more elaborate. Also, FYI, Quickref uses README files as an introduction section in the generated reference manuals automatically. This is a functionality that I plan to move to Declt at some point. Having a whole README file in the long-description slot would look weird in Quickref-generated documentation. -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: Timing compilation
"Robert Goldman" écrivait: > This is yet another problem that comes from the fact that the build > plans are linear, instead of hierarchical -- for example there's no > subsequence that is identifiable as being the set of operations for a > particular module. > > Logically speaking, there's a tree structure in the build process that > is what you need, but I don't believe that there are any facilities in > ASDF to recover that tree structure. > > This may be the best you can do. I think I'll go with Faré's suggestion, scripting it for every library and changing the cache directory every time. -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: Timing compilation
"Robert Goldman" écrivait: > Depending on the host lisp you are using, couldn't you wrap the calls > to COMPILE-FILE and LOAD in code that times those operation? I could, but since I want per-library numbers, I would need to reconstruct that information afterwards... -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: Timing compilation
François-René ÐVB Rideau écrivait: > Simplest method: > 1- load the dependencies, possibly using (asdf:operate :prepare-op s) > 2- (time (asdf:make s)) Nice, thank you. If I want to time separately the compilation and loading phases of several libraries (which may depend on each other) however, I would need to restart my session every single time. Another way to do this and, say, report the timings to a file? -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
Timing compilation
Hello, I would like to collect information about the time it takes to compile an ASDF system (possibly also load it), dependencies excluded. I'm thinking there's probably a way to do this by :around'ing compile-op, or something like that, but if someone already has a clear view on how to make this happen, I'd be grateful for the time spared! Thanks. -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: locating a source directory
I wrote: > I would like to find the source directory of an installed ASDF system > even if it's not loaded and even if some of its dependencies are not > installed (so it couldn't be loaded anyway). It seems that I can't use > SYSTEM-SOURCE-DIRECTORY in such a case. What should I do? Replying to myself (I often do that when I'm alone :-D) it seems that LOCATE-SYSTEM could do the job... -- Resistance is futile. You will be jazzimilated. Jazz site: http://www.didierverna.com Other sites: http://www.didierverna.info
locating a source directory
Hello, I would like to find the source directory of an installed ASDF system even if it's not loaded and even if some of its dependencies are not installed (so it couldn't be loaded anyway). It seems that I can't use SYSTEM-SOURCE-DIRECTORY in such a case. What should I do? Thanks! -- Resistance is futile. You will be jazzimilated. Jazz site: http://www.didierverna.com Other sites: http://www.didierverna.info
Re: Removing content from README.md
Robert Goldman wrote: > I just looked over that README, and realized that it was not > maintained. I quickly concluded that I do not have the resources to > maintain both this file and the HTML file at > https://common-lisp.net/project/asdf/, and the latter is what I have > been updating with new releases. So the former must go. FWIW, I took the habit of maintaining only one documentation source (in Texinfo format) and extracting README files and others (such as INSTALL) from there, hence also avoiding the maintenance of duplicate information. It's easy to extract specific chapters from an Info file. For instance, here's a Makefile target that I have in Clon: INSTALL: doc/$(PROJECT)-user.info info --file=./doc/$(PROJECT)-user.info \ -n Installation\ -n Configuration \ -n 'Non-ANSI Features' \ -n 'Supported Platforms' \ --output=$@ perl -pi -e 's/^File:.*\n//g' $@ -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: :FEATURE dependency-def
François-René ÐVB Rideau wrote: > The traditional solution is to load a file that fails. i.e. create a > file unsupported-implementation.lisp that has an (error ...) form and > in your asd file, use a component (:file "unsupported-implementation" > :if-feature (:not :sbcl)) Hmmm, ok but then, if you're to error in a Lisp file proper, why use the ASDF logic at all? I mean, why not just depend on the file as a regular one and perform all the tests that you need from Lisp code? -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: :FEATURE dependency-def
Stelian Ionescu wrote: > #-feature > (error "FEATURE missing") > > at toplevel, so you get an error on reading the .asd file. Of course. I said a "declarative way" within the system itself tho ;-) -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: :FEATURE dependency-def
Robert Goldman écrivait: > I stubbed my toe on this absent-mindedly compiling Didier's decLt > system on Allegro Common Lisp. That system doesn't, and cannot, > function on ACL, but ASDF tells us it has compiled successfully. Following up to our private conversation on this... I think there's an error on my part to begin with. The core system of Declt has an :if-feature :sbcl, which prevents it from being loaded outside SBCL. This is mostly what's needed, but I hadn't realized that it /silently/ does so, instead of throwing an error if the feature is absent. So the question is: can I declaratively state that a system (or maybe more generally a component) depends on a feature, so that loading fails with an error otherwise ? I don't currently see a way. In fact, it seems to me that the current :depends-on (:feature :this :that) syntax is a misnomer. Perhaps it would have been more explicit to write :depends-on (:if-feature :this :that) in order to express that the conditional actually may fail silently. Now, what about extending the syntax with: :depends-on (:feature :this) to actually mean "if :this is not on the features list, fail with an error"? -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
[Q] figuring out a system / source file
Hello, starting from a file currently being processed (as per either *compile-file-truename* or *load-truename*), how can I retrieve the ASDF system currently being processed, and ultimately, the corresponding source file component (when *load-truename* returns a fasl) ? Thanks. -- My new Jazz CD entitled "Roots and Leaves" is out! Check it out: http://didierverna.com/records/roots-and-leaves.php Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: License field
François-René ÐVB Rideau écrivait: > I was considering just a string for now FWIW, I'm also in favor of strings. Using symbols is risky for case-sensitiveness. -- My new Jazz CD entitled "Roots and Leaves" is out! Check it out: http://didierverna.com/records/roots-and-leaves.php Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: License field
J'écrivais: > Good idea, although it seems to be missing the GNU All Permissive > license (the submission process looks quite cumbersome). Ended up doing it anyway. -- My new Jazz CD entitled "Roots and Leaves" is out! Check it out: http://didierverna.com/records/roots-and-leaves.php Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: License field
François-René ÐVB Rideau écrivait: > I propose we document that the license field should if possible > contain an identifier from > http://spdx.org/licenses/ > http://esr.ibiblio.org/?p=6867 Good idea, although it seems to be missing the GNU All Permissive license (the submission process looks quite cumbersome). -- My new Jazz CD entitled "Roots and Leaves" is out! Check it out: http://didierverna.com/records/roots-and-leaves.php Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: :require dependency
Robert Goldman wrote:
> According to the manual REQUIRE-SYSTEM is "... a version of
> @code{load-system} that skips trying to update systems that are
> already loaded."
>
> There is no REQUIRE-OP.
>
> There is a REQUIRE-SYSTEM which is a system whose loading is handled
> by REQUIRE instead of native ASDF.
OK, this is what I figured in the meantime. But then, this seems to
contradict what the manual says (the part you're mentioning above).
> This might be useful, e.g., on ACL, which has many bundled modules
> which are loaded by REQUIRE. I'm not sure there is a common
> implementation-independent use case, since people aren't distributing
> a lot of code to be loaded with REQUIRE, AFAICT.
I guess it's mostly useful for implementation-specific libraries. I
use it for sb-grovel for instance.
> Hope that helps. Sorry for the late answer: we've been grappling with
> some knotty bugs on Windows.
No worries. When I have bugs on windows, I usually close the blinds :-D
--
My new Jazz CD entitled "Roots and Leaves" is out!
Check it out: http://didierverna.com/records/roots-and-leaves.php
Lisp, Jazz, Aïkido: http://www.didierverna.info
:require dependency
Hello, can somebody explain to me what is the :require dependency specification, and how it compares to just a simple-component-name ? Thanks. -- My new Jazz CD entitled "Roots and Leaves" is out! Check it out: http://didierverna.com/records/roots-and-leaves.php Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: The dictatorship of versioning
Robert Goldman wrote: > Why would that be a win over just calling FORMATTED-VERSION on demand? > > I.e., we could just provide something like > > (defgeneric FORMATTED-VERSION (C &optional version) > (:method ((COMPONENT C) &optional version) > (or version (component-version c))) > > and then the programmer could extend this as needed. You're right of course. -- My new Jazz CD entitled "Roots and Leaves" is out! Check it out: http://didierverna.com/records/roots-and-leaves.php Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: The dictatorship of versioning
Robert Goldman wrote: > Just to clarify: I am NOT saying Pascal is wrong to want these things > or to do them himself. And I AM saying that ASDF should make it > possible for him to do so. ASDF could call FORMATTED-VERSION itself to initialize the corresponding slot (if any), and refrain from providing a writer for it. -- My new Jazz CD entitled "Roots and Leaves" is out! Check it out: http://didierverna.com/records/roots-and-leaves.php Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: The dictatorship of versioning
Robert Goldman wrote: > So what happens when the programmer updates the human readable version > and not the canonical version, or vice versa? Wouldn't it be better > to functionally derive one of these two forms from the other? E.g., > (defgeneric formatted-version (component version-spec)) Probably. The only advantage I see in PB's suggestion is for people actually reading the system definition's code. But then, don't do that. Use Declt to create the reference manual ;-) > I am also disinclined to add something like the proposed +1 -- My new Jazz CD entitled "Roots and Leaves" is out! Check it out: http://didierverna.com/records/roots-and-leaves.php Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: The dictatorship of versioning
Robert Goldman wrote: > Now: a request for management purposes: Didier, would you be so kind > as to describe the proposal (I think cut and paste out of your earlier > emails would do admirably) in a ticket on launchpad.net? OK. I will also add Pascal's suggestion to have both a canonical and human readable version slot. -- My new Jazz CD entitled "Roots and Leaves" is out! Check it out: http://didierverna.com/records/roots-and-leaves.php Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: The dictatorship of versioning
Faré wrote: > I kind of like the general idea of Pascal's proposal: separate a > human-readable-version-string from an asdf-comparable-version-string. > The exact names are to be determined. Maybe, by analogy with name and > long-name, description and long-description, we could make that > version (used by ASDF) and long-version (used by humans). Works for me, as long as it is also possible to delegate comparison to the concerned system. Or, you adopt my personal versioning scheme :-D. -- My new Jazz CD entitled "Roots and Leaves" is out! Check it out: http://didierverna.com/records/roots-and-leaves.php Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: The dictatorship of versioning
"Pascal J. Bourguignon" wrote: > Alternatively, we could have: > > (defsystem :foo >:version-major 1 >:version-minor 0 >:version-release 42 >:human-readable-version-string "1.0.gamma.XLII/pescadero:whasa") > > or: > > (defsystem :foo >:version (1 0 42) >:human-readable-version-string "1.0.gamma.XLII/pescadero:whasa") Actually, I had something like that in mind. With this idea of allowing individual systems to handle their own versioning logic, I intended to put something like '(1 3 :beta 4 "Release Name") in the :version slot. A human-readable version is different from a version specifier. ASDF already does something shaky in this regard, even for its simplistic versioning scheme: because it normalizes versions into strings, it needs to provide UNPARSE-VERSION! Yuck. So if ASDF (or its users) insists on have human readable version strings, I wouldn't mind systems having both :version and :version-string. -- My new Jazz CD entitled "Roots and Leaves" is out! Check it out: http://didierverna.com/records/roots-and-leaves.php Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: The dictatorship of versioning
Drake Wilson wrote:
> Curiosity: what _are_ your version numbers like, and how do you
> compare them? It was a little too hard to find this readily from your
> website. Maybe seeing a good example would help.
A version specifier has a major and a minor number, a status (alpha,
beta, release candidate and patchlevel), a status number and a name.
This is the beginning of the VERSION function in all my libraries:
(defun version (&optional (type :number))
"Return the current version of Clon.
TYPE can be one of :number, :short or :long.
A version number is computed as major*1 + minor*100 + patchlevel, leaving
two digits for each level. Alpha, beta and rc status are ignored in version
numbers.
A short version is something like 1.3{a,b,rc}4, or 1.3.4 for patchlevel.
Alpha, beta or rc levels start at 1. Patchlevels start at 0 but are ignored
in the output, so that 1.3.0 appears as just 1.3.
A long version is something like
1.3 {alpha,beta,release candidate,patchlevel} 4 \"Michael Brecker\". As for
the short version, a patchlevel of 0 is ignored in the output."
--
My new Jazz CD entitled "Roots and Leaves" is out!
Check it out: http://didierverna.com/records/roots-and-leaves.php
Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: The dictatorship of versioning
I wrote: > Thoughts ? Will this be enough to satisfy ASDF ? Not quite. I missed NORMALIZE-VERSION (ASDF attempting to be clever and doing all sorts of nasty DWIM stuff on version numbers). Attached patch would solve the problem, it seems. But then again, I don't really know what I'm doing. It wraps NORMALIZE-VERSION within a generic function which I can then specialize on my system, essentially bypassing normalization altogether, like this: (defmethod asdf/parse-defsystem:normalize-component-version ((system my-system) form &key pathname component parent) (declare (ignore pathname component parent)) form) diff --git a/parse-defsystem.lisp b/parse-defsystem.lisp index e674e0c..ade94d7 100644 --- a/parse-defsystem.lisp +++ b/parse-defsystem.lisp @@ -10,6 +10,7 @@ (:import-from :asdf/system #:depends-on #:weakly-depends-on) (:export #:defsystem #:register-system-definition + #:normalize-component-version #:class-for-type #:*default-component-class* #:determine-system-directory #:parse-component-form #:non-toplevel-system #:non-system-system @@ -119,7 +120,11 @@ (invalid (if-let (pv (parse-version v #'invalid-parse)) (unparse-version pv) - (invalid)) + (invalid) + (defgeneric* (normalize-component-version) (c form &key pathname component parent) +(:method (c form &key pathname component parent) + (declare (ignore c)) + (normalize-version form :pathname pathname :component component :parent parent ;;; "inline methods" @@ -233,7 +238,7 @@ system names contained using COERCE-NAME. Return the result." (let ((sysfile (system-source-file (component-system component ;; requires the previous (when (and (typep component 'system) (not bspp)) (setf (builtin-system-p component) (lisp-implementation-pathname-p sysfile))) - (setf version (normalize-version version :component name :parent parent :pathname sysfile))) + (setf version (normalize-component-version component version :component name :parent parent :pathname sysfile))) ;; Don't use the accessor: kluge to avoid upgrade issue on CCL 1.8. ;; A better fix is required. (setf (slot-value component 'version) version) -- My new Jazz CD entitled "Roots and Leaves" is out! Check it out: http://didierverna.com/records/roots-and-leaves.php Lisp, Jazz, Aïkido: http://www.didierverna.info
The dictatorship of versioning
Hi, in general, I don't like the way ASDF tries to force you to comply with its own design choices and policy. This is especially true for component versioning. ASDF complains that it doesn't like my version numbers (which, in fact, are not only numbers ;-), but I'm not ready to give up on them. They're much more informative than ASDF's simplistic 1.2.3. It seems that the only place ASDF uses our version numbers is in VERSION-SATISFIES. There is also a VERSION-COMPATIBLE-P somewhere, but it doesn't seem to be used. Fortunately, VERSION-SATISFIES is a generic function, so I'm thinking I could work around it. Not tested yet: 1. (defclass my-system-subclass (system) ()) 2. (defsystem :foo.bar.baz :class 'my-system-subclass #|...|#) 3. (defmethod version-satisfies ((c my-system-subclass) version) #|my own version handling code|#) Thoughts ? Will this be enough to satisfy ASDF ? In an ideal world, the whole versioning API (version-satisfies, version< etc.) should have been implemented as proper component-based protocols... -- My new Jazz CD entitled "Roots and Leaves" is out! Check it out: http://didierverna.com/records/roots-and-leaves.php Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: [asdf-devel] In defense of ASDF & Semantic versioning
Pascal Costanza wrote: > Just to chime in in the middle: There is no known solution to the > so-called "DLL hell" problem. You're right of course, but in practice, I think we have a lot to learn from guix/nixos. Ultimately, I would like to see quicklisp and asdf melt into a beast like that... -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: [asdf-devel] About some new system slots
Robert Goldman wrote: > The advantage of having the pair, of course, is that a simple URL does > not necessarily identify the form of VCS. But what would be the use for this information? I mean, having this information as part of the system desciption. -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: [asdf-devel] About some new system slots
Faré wrote: > Although, it isn't clear yet how source-control may or may not specify > the VCS used: should we prefix the URL with a git: or svn: or darcs: > or some such? ASDF uses: :source-control (:git > "git://common-lisp.net/projects/asdf/asdf.git") Personally, I would not complicate this slot and just go for a simple URL pointing to a VCS related web page. If you start specifying more information there, you will end up with a big mess (which VCS, which access backend, which access type (r/o r/w) etc.). That's just me of course. -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
[asdf-devel] About some new system slots
Hello, what's the purpose of the LONG-NAME slot in ASDF 3's system class? Also, can I assume that HOMEPAGE, SOURCE-CONTROL and BUG-TRACKER are meant to be URL strings ? Thanks. -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: [asdf-devel] component-load-dependencies
Faré wrote: > since you provide no justification for what you are trying to do, > anything can be "reasonable" or not. I'm not sure what I need to justify, since my original question was actually quite precise. > My bet is that this isn't what you really want in the end, > Usually, one wants to get a list of components within a system. > Then, one typically uses required-components, e.g. like this (YMMV): >> That's the opposite of what I want. Thank you very much, but even assuming I don't know what I want and you know what I want better than I know what I want, I'm still sure that I don't want the opposite of what I want. > Have fun playing with ASDF. Not really, no. -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: [asdf-devel] component-load-dependencies
I wrote: > All of this is way beyond me. But by looking at the code, it seems that the dependency names I'm looking for are in the SIDEWAY-DEPENDENCIES slot of the components. From there, it seems that I can use RESOLVE-DEPENDENCY-NAME to finally get a component object. Does this sound reasonable? -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: [asdf-devel] component-load-dependencies
Faré wrote: > what are you *really* trying to do? Really, trying to get the same thing that component-load-dependencies gives me, but as component objects instead of names. > Usually, one wants to get a list of components within a system. > Then, one typically uses required-components, e.g. like this (YMMV): > (asdf:required-components (asdf:find-system :fare-utils) > :component-type '(not asdf:system) :keep-operation 'asdf:load-op > :keep-component 'asdf:source-file) That's the opposite of what I want. It seems that component-load-dependencies gets me all the (direct) things a component depends on (for loading). That may be implicit in an ASDF system description if :serial t is used, or explicit with a :depend-on declaration. This is exactly what I want, but as objects, not names. > If you *really* want to walk the dependencies by yourself, use > asdf/plan:visit-dependencies. There are also functions > map-direct-dependencies, reduce-direct-dependencies, > direct-dependencies that you may want to use instead. More often than > not, it's a bad idea, though. Most of the time, if you need to go > under the hood, it is better to manually use traverse-action > traverse-actions traverse-sub-actions with your choice of plan, e.g. a > sequential-plan or filtered-sequential-plan. All of this is way beyond me. -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
[asdf-devel] component-load-dependencies
Hello, currently Declt advertises component dependencies by using COMPONENT-LOAD-DEPENDENCIES. This function however only returns a list of symbols naming the components. What would be the best way to retrieve a list of component objects instead ? Thanks! -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
[asdf-devel] Cannot use latest git ECL (asdf/quicklisp are involved)
Yothere, I upgraded ECL this morning to the latest repo version and I cannot use it anymore with my usual setup (-norc works). My local versions of Quicklisp and ASDF are also the lastest. I have this in my init file: ;; Do ASDF first (when a compiler provides it directly, I think it is better ;; to use its version than mine). (require :asdf #-(or sbcl cmu ccl ecl mkcl xcl allegro (and lispworks (not lispworks-personal-edition))) '(#p"/usr/local/share/common-lisp/source/asdf/build/asdf.lisp")) #-quicklisp (let ((quicklisp-init "/usr/local/share/common-lisp/source/quicklisp/setup.lisp")) (when (probe-file quicklisp-init) (load quicklisp-init))) With this configuration, running ECL on the command-line gives me this: didier(pts/4)% ecl Err 1 11:27 06/24/13 ;;; Loading #P"/home/didier/.clrc" ;;; Loading #P"/usr/local/lib/ecl-12.7.1/asdf.fas" ;;; Loading #P"/usr/local/lib/ecl-12.7.1/cmp.fas" ;;; Loading "/usr/local/share/common-lisp/source/quicklisp/setup.lisp" ASDF could not load sockets because Error while trying to load definition for system sockets from pathname /usr/local/lib/ecl-12.7.1/sockets.asd: No applicable method for SOURCE-FILE-TYPE with arguments of types COMPILED-FILE PREBUILT-SYSTEM. ;;; Error: ;;; in file impl.lisp, position 7644 ;;; at (DEFINE-IMPLEMENTATION-PACKAGE ECL ...) ;;; * The form (REQUIRE 'SOCKETS) was not evaluated successfully. ;;; Error detected: ;;; Error while trying to load definition for system sockets from pathname /usr/local/lib/ecl-12.7.1/sockets.asd: No applicable method for ASDF:SOURCE-FILE-TYPE with arguments of types ;;; COMPILED-FILE ;;; PREBUILT-SYSTEMAn error occurred during initialization: Error while invoking # on #. zsh: exit 1 ecl I see that ELC's version of ASDF is old, so I tried to load ASDF 3 by removing 'ecl from the #-() form above. Now I get this instead: didier(pts/4)% ecl Err 1 11:27 06/24/13 ;;; Loading #P"/home/didier/.clrc" ;;; Loading "/usr/local/share/common-lisp/source/asdf/build/asdf.lisp" An error occurred during initialization: Cannot delete the directory #P"/home/didier/.cache/common-lisp/ecl-12.7.1-52ca46e0-linux-x86/usr/local/share/common-lisp/source/asdf/build/asdf.fas". C library explanation: No such file or directory.. zsh: exit 1 ecl Any advice ? Thanks. -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: [asdf-devel] ASDF 2.26 in Quicklisp
Robert Goldman wrote: > Thanks. If I get some downtime, I'll try to either split these > subsections into nodes (if anyone has an emacs command that will do > that automagically, please LMK), or add anchors. You may want to start with C-x h C-u M-x texinfo-insert-node-lines. This will create all missing nodes for every sectionning command and fill them up with the proper title. However, you will most probably need to update the structure afterwards. -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] ASDF 2.26 in Quicklisp
Robert Goldman wrote:
> It would be nice if texinfo offered links to more specific locations
> than nodes, but it sounds like that's not available.
It is. You can do that manually with anchors. Cf. @anchor{} and
@ref{} (@xref, @pxref etc.)..
--
Resistance is futile. You will be jazzimilated.
Scientific site: http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com
___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] ASDF 2.26 in Quicklisp
rpgold...@sift.info wrote: > As far as I can tell, this is a misfeature of texinfo. The links only > work to the node level (at least in the info browser). So we would > need to reactor the document into smaller nodes to fix that. That's not really a misfeature. That fact is that Texinfo uses nodes as its primary sectionning mechanism. You need to think in terms of node first when you write Texinfo. Every sectionning command that you use should be associated with a node, and every node that has sub-nodes should have a menu. It seems that you only have nodes for chapters, which explains the shaky TOC. > Unfortunately, in addition to requiring some work, that would also > give us a document with very small pages, that would be a nuisance > when attempting to read in chunks (as opposed to jumping to a very > specific item). That is correct, although I don't find that this is such a nuisance, since you have all the hyperlinks you want. Otherwise, what you can do is generate a single web page for the whole doc (Cf. --no-split). What I do find missing from Makeinfo is a --split-level option instead of the --no-split one. It would be nice if, for instance, we could specify that we want to split at the chapters level only. -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] Using asdf with Corman Lisp 3
Faré wrote: > I had no idea that anyone was still using Corman Lisp. With the author > not replying to any of my emails for years, and the most active users > long gone, I have classified the platform as "dead until further > notice". I understand you too are trying to port your software to it, > but that might be wasted time. Noted. FWIW, I have made some progress: Corman Lisp's (user-homedir-pathname) happens to return a pathname with a file component, ie: - the directory part is \Users\ - the file part is Didier As a consequence, calling PATHNAME-DIRECTORY on it returns C:\Users\ and the source registry becomes C:\Users\.config\common-lisp\source-registry.conf (the actual user homedir is missing). This is easily fixed with a Siebel-like PATHNAME-AS-DIRECTORY function. However, I ran into a bunch of other problems after that (such as the lack of a TRANSLATE-LOGICAL-PATHNAME function). So given what you're saying above, I think I'll just give up. > Sorry, the only people who can make me touch a Windows machine without > paying me big bucks are my parents Well, I can always modify the envelope of my emails :-) -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
[asdf-devel] Using asdf with Corman Lisp 3
Hello, I'm trying to use ASDF (git repo) with Corman Lisp 3.0 natively on Windows. I managed to have Corman Lisp load ASDF, but now I have a configuration problem. I have a file C:\Users\Didier\.config\common-lisp\source-registry.conf which contains this: (:source-registry (:tree "C:\Program Files (x86)\Common Files\Common Lisp\") :inherit-configuration) But ASDF doesn't find any of the packages I put there. asdf::*source-registry* seems to be NIL. What am I doing wrong ? Thanks ! -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] asdf 2.23, and contribs
Faré wrote: > Speaking of which, some time ago, I started to collect asdf > extensions, and I just added a listing of them on the asdf webpage. > Please suggest more extensions that I may list on the page. ASDF-FLV, related to CDR #9. -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
[asdf-devel] Status of :feature
Hello, what is the current status of :feature in a list of dependencies? I mean, is it safe to replace #+ reader conditionals in the asd file with it? Thanks. -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com ___ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] ASDF 2 questions
Faré wrote: > That said, whatever you're doing that is hitting that bug is probably > itself a mistake. There is no reason for you to ever use > (component-pathname (find-system ...)) Instead, you should be using > (system-relative-pathname ...) or some such thing. Yup. In fact, I never used "(component-pathname (find-system ...))" (that was a simplification for the email). I hit the bug in a generic function doing (component-pathname ) in which would occasionally be a system. -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com ___ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] ASDF 2 questions
Faré wrote: >> 5/ Finally, I would like confirmation that ASDF now handles outdated >> fasl's correctly, and we don't need to do the black magick >> ourselves. >> > I'm not sure what you mean, so I'd say probably not. If you have > "black magick" that you think should be part of ASDF, please submit it > here, and/or as an ASDF bug on launchpad. Sorry for being too vague. For ASDF 1, I had a plug to automatically recompile outdated fasls (I probably found it on the internet years ago; don't remember): (defmethod asdf:perform :around ((o asdf:load-op) (c asdf:cl-source-file)) (handler-case (call-next-method o c) (#+sbcl sb-ext:invalid-fasl #+cmu ext:invalid-fasl #+allegro excl::file-incompatible-fasl-error #+lispworks conditions:fasl-error #-(or sbcl cmu allegro lispworks) error () (asdf:perform (make-instance 'asdf:compile-op) c) (call-next-method ... and I was wondering if ASDF 2 did something like this on its own. Thanks ! -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com ___ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
[asdf-devel] ASDF 2 questions
[ Please, Cc: me as I'm not on the mailing list ]
Hi,
I'm trying to upgrade my CL configuration to ASDF 2, and I have several
questions:
1/ why isn't "source-registry.conf" named "asdf-source-registry.conf" ?
2/ Should we understand that the convention of having a "systems"
directory with .asd files symlinked there is now obsolete ?
I still prefer to keep that because I can select which of the
installed sources I do want to be seen. I guess you could also use
exclude patterns for doing so, but it seems way more complicated.
Comments ?
3/ The following contents for source-registry.conf fails:
(:source-registry
(:directory (merge-pathnames "share/common-lisp/systems/"
(user-homedir-pathname)))
(:directory "/usr/local/share/common-lisp/systems")
(:directory "/usr/share/common-lisp/systems")
:inherit-configuration)
Am I to understand that this file cannot really contain Lisp code (and
so I couldn't use #'merge-pathnames)? Because in that case, this
sucks. I have several machines on which $HOME is different (e.g.
/home/ or /Users/, and no, I don't want to create a /home/ -> /Users/
symlink on my Macs)
4/ I'm also struggling with the output translations.
I'm happy with the default settings (using .cache/blabla) except for one
case. For lisp files located under ~/Science/Source/Common Lisp/
(recursively), I want the compiled files to remain at the same place,
under an implementation-specific subdirectory, like
asdf-binary-locations did for me before.
For instance, ~/Science/Source/Common Lisp/foo/bar/baz.lisp would
produce somthing like:
~/Science/Source/Common Lisp/foo/bar/sbcl-1.0.32.30-linux-x86-64/baz.fasl
I tried this:
(:output-translations
("/Users/didier/Science/Source/Common Lisp/"
(:current-directory :implementation))
:inherit-configuration)
but this doesn't work. SBCL says:
This is SBCL 1.0.42.52, an implementation of ANSI Common Lisp.
More information about SBCL is available at
Re: [asdf-devel] ASDF 2 questions
I wrote: > [ Please, Cc: me as I'm not on the mailing list ] here's another one: In ASDF 1, (component-pathname (find-system ...)) returned the system's *directory*, which was coherent because the system is a module, so its pathname is a directory just like for any other sub-module. In ASDF 2, it seems to return the .asd file instead. Is this intentional ? -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com ___ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
