Re: [asdf-devel] Tutorial ASDF(?)
Dear Robert,
However, I have one question: what is the reason that these output translations are apparently not applied to the .asd files? The way I understand my output-translations, I have globally specified that all fasls are in an implementation-specific directory just below my source files. For me, .asd files are just source files, so why not place them where the other fasls are written?
Not sure I fully understand. As you say, the .asd files are just source files, and they are never compiled, so there is no need to do any output translations for them.
I may not have fully followed the question....
concerning the .asd files, I use cl path/to/..asd in the REPL and both sbcl and acl try to find fasls for them. If there is no corresponding fasl, they write one. At present, I do an explicit (load #P"path/to/system.asd") to prevent Lisp from writing fasls. So, the question comes from a habit developed over the years: why aren't defsystem files trated the same way as source files, i.e., treated according to what is specified in asdf-output-translations.conf? Hopefully this explains a bit of the backgrond of my question. Further comments later. Kind regards, good weekend, Ernst asdf-devel-request@common-lisp.net schreef op vr 20-05-2011 om 12:00 [-0700]:
Re: Tutorial ASDF(?)
Ernst van Waning <evw@infometrics.nl> writes:
Dear Robert,
However, I have one question: what is the reason that these output translations are apparently not applied to the .asd files? The way I understand my output-translations, I have globally specified that all fasls are in an implementation-specific directory just below my source files. For me, .asd files are just source files, so why not place them where the other fasls are written?
Not sure I fully understand. As you say, the .asd files are just source files, and they are never compiled, so there is no need to do any output translations for them.
I may not have fully followed the question....
concerning the .asd files, I use cl path/to/..asd in the REPL and both sbcl and acl try to find fasls for them. If there is no corresponding fasl, they write one.
At present, I do an explicit (load #P"path/to/system.asd") to prevent Lisp from writing fasls. So, the question comes from a habit developed over the years: why aren't defsystem files trated the same way as source files, i.e., treated according to what is specified in asdf-output-translations.conf?
Hopefully this explains a bit of the backgrond of my question.
.asd files should not be loaded directly with cl:load or any shortcut that involves cl:load, like cl path/to/whatever.asd. ASDF sets up an environment when loading an .asd file that is not the same as the environment established by cl:load. The only way (with which I'm familiar) to properly load an .asd file is via asdf:find-system. Zach
On 20 May 2011 16:18, Zach Beane <xach@xach.com> wrote:
.asd files should not be loaded directly with cl:load or any shortcut that involves cl:load, like cl path/to/whatever.asd. ASDF sets up an environment when loading an .asd file that is not the same as the environment established by cl:load.
The only way (with which I'm familiar) to properly load an .asd file is via asdf:find-system.
Indeed. In recent versions of ASDF, I have factored out of find-system an internal function (asdf::load-sysdef "/path/to/foo.asd") that does the right thing. But I haven't exported the function so far, because I believe you should only be loading them via find-system, which for the longest time had been the only interface to that functionality. You should certainly never compile-file a .asd file — though I've been known to C-c C-k some of them at the SLIME REPL and regret it later. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Moving parts in rubbing contact require lubrication to avoid excessive wear. Honorifics and formal politeness provide lubrication where people rub together. Often the very young, the untraveled, the naïve, the unsophisticated deplore these formalities as "empty", "meaningless", or "dishonest", and scorn to use them. No matter how "pure" their motives, they thereby throw sand into machinery that does not work too well at best. — Robert Heinlein, "Time Enough For Love"
Fare, Zach, thank you for the comments. As you might have guessed, I was totally unaware of that. Always having loaded systems the way I described, I have never encountered a problem, adding immediately that I go to the directory where the software is that I want to work on, after perhaps having loaded some systems I regularly use in the same manner. Working with compiled .asd files never gave me a problem. Can you give a reason for not compiling .asd files? What are the advantages of accessing .asd files only by means of asdf:find-system? I surely must have configured something very wrongly, here it takes a very long time and chances are the system I am after will not be found... Sorry for insisting, but can you tell me why exactly, i.e., the advantages of (asdf:find-system <system.) and the disadvantages of mine? Hoping to hear & kind regards, Ernst Faré schreef op vr 20-05-2011 om 16:47 [-0400]:
On 20 May 2011 16:18, Zach Beane <xach@xach.com> wrote:
.asd files should not be loaded directly with cl:load or any shortcut that involves cl:load, like cl path/to/whatever.asd. ASDF sets up an environment when loading an .asd file that is not the same as the environment established by cl:load.
The only way (with which I'm familiar) to properly load an .asd file is via asdf:find-system.
Indeed.
In recent versions of ASDF, I have factored out of find-system an internal function (asdf::load-sysdef "/path/to/foo.asd") that does the right thing. But I haven't exported the function so far, because I believe you should only be loading them via find-system, which for the longest time had been the only interface to that functionality. You should certainly never compile-file a .asd file — though I've been known to C-c C-k some of them at the SLIME REPL and regret it later.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Moving parts in rubbing contact require lubrication to avoid excessive wear. Honorifics and formal politeness provide lubrication where people rub together. Often the very young, the untraveled, the naïve, the unsophisticated deplore these formalities as "empty", "meaningless", or "dishonest", and scorn to use them. No matter how "pure" their motives, they thereby throw sand into machinery that does not work too well at best. — Robert Heinlein, "Time Enough For Love"
On 20 May 2011 18:14, Ernst van Waning <evw@infometrics.nl> wrote:
Always having loaded systems the way I described, I have never encountered a problem, adding immediately that I go to the directory where the software is that I want to work on, after perhaps having loaded some systems I regularly use in the same manner. Working with compiled .asd files never gave me a problem.
Well, most asdf files are simple enough and you could load them without problems. Other ASDF files do ugly stuff, and in a IMNSHO vain attempt to protect users from stray symbols, etc., ASDF creates a new temporary package in which it loads the .asd files. Some people may or may not depend on it. I suppose I could break the assumption and see whether Xach comes to my house with an axe for breaking Quicklisp once more — or some user of a proprietary application I haven't heard of. I'd rather not do it without Xach being in the loop. If it were me, I'd just LOAD the damn file from either ASDF, CL-USER, or a new ASDF-USER package. Or better yet, I'd make it a data file in a well-defined DSL, rather than a full-fledged CL file. That's what XCVB does. Meh. Backward compatibility trumps all.
Can you give a reason for not compiling .asd files? Historical reasons: .asd files are meant to only contain simple stuff, and historically, compiling is slow (ASDF was written ten years ago on SBCL).
What are the advantages of accessing .asd files only by means of asdf:find-system? So that a proper package be defined, some magic be performed to prevent infinite recursion in corner cases (see recent bug reported by Nikodemus), and some error handling may happen.
I surely must have configured something very wrongly, here it takes a very long time and chances are the system I am after will not be found...
It may help to describe your configuration. Which implementation on which OS, which version of ASDF, and what do you have in your configuration?
Sorry for insisting, but can you tell me why exactly, i.e., the advantages of (asdf:find-system <system.) and the disadvantages of mine?
See the function load-sysdef, which explains the difference. Regards, —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Backwards compatible — If it's not backwards it's not compatible — Greg Newton <gregnewton@netscape.net>
Faré <fahree@gmail.com> writes:
I suppose I could break the assumption and see whether Xach comes to my house with an axe for breaking Quicklisp once more — or some user of a proprietary application I haven't heard of. I'd rather not do it without Xach being in the loop.
The assumption that most commonly breaks is that your defsystem file can look like this: ;; foo.asd (defsystem foo ...) That's a style used by hundreds of systems in Quicklisp. Zach
On 21 May 2011 02:00, Faré <fahree@gmail.com> wrote:
Can you give a reason for not compiling .asd files?
Historical reasons: .asd files are meant to only contain simple stuff,
Not that this really matters, but ... this is not so. .asd files have always been meant to contains things like custom component definitions and defmethods for them -- not "just simple stuff". Historically speaking compiling .asd files used to work fine, assuming they set up their packages right -- which is one of the major reasons for the (defpackage :foo-system ...) (in-package :foo-system) (defsystem :foo ...) pattern one sometimes sees. Not sure if it is still expected to work. Cheers, -- nikodemus
Historical reasons: .asd files are meant to only contain simple stuff,
Not that this really matters, but ... this is not so.
.asd files have always been meant to contains things like custom component definitions and defmethods for them -- not "just simple stuff". Historically speaking compiling .asd files used to work fine, assuming they set up their packages right -- which is one of the major reasons for the
(defpackage :foo-system ...)
(in-package :foo-system)
(defsystem :foo ...)
pattern one sometimes sees. Not sure if it is still expected to work.
It is still expected to work, and it is actually recommended if you're defining any ASDF extension: classes, methods, even just functions, that may have to be redefined, debugged, traced, or otherwise named. I wonder if ASDF shouldn't just define a ASDF-USER package that uses ASDF and CL, instead of creating temporary packages every time. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "Ask not what the government can do for you. Ask what the government is doing to you." — David Friedman, "The Machinery of Freedom", p. 21
On Sat, 21 May 2011, Faré wrote:
I wonder if ASDF shouldn't just define a ASDF-USER package that uses ASDF and CL, instead of creating temporary packages every time.
Barring user demand, I'd leave it be. IMO, ASDF is near the limit of its organic growth. Fundamental, breaking design changes are needed. Wait, is that XCVB I hear calling? ;) - Daniel
I don't think this would be the right thing. This package would turn into a conduit that would carry side effects between different system definition files. Better to stick with the status quo, I believe. Best, R -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. "Faré" <fahree@gmail.com> wrote:
Historical reasons: .asd files are meant to only contain simple stuff, > > Not that this really matters, but ... this is not so. > > .asd files have always been meant to contains things like custom > component definitions and defmethods for them -- not "just simple > stuff". Historically speaking compiling .asd files used to work fine, > assuming they set up their packages right -- which is one of the major > reasons for the > > (defpackage :foo-system ...) > > (in-package :foo-system) > > (defsystem :foo ...) > > pattern one sometimes sees. Not sure if it is still expected to work. > It is still expected to work, and it is actually recommended if you're defining any ASDF extension: classes, methods, even just functions, that may have to be redefined, debugged, traced, or otherwise named. I wonder if ASDF shouldn't just define a ASDF-USER package that uses ASDF and CL, instead of creating temporary packages every time. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "Ask not what the government can do for you. Ask what the government is doing to you." — David Friedman, "The Machinery of Freedom", p. 21_____________________________________________ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
On 5/20/11 May 20 -3:11 PM, Ernst van Waning wrote:
Dear Robert,
However, I have one question: what is the reason that these output translations are apparently not applied to the .asd files? The way I understand my output-translations, I have globally specified that all fasls are in an implementation-specific directory just below my source files. For me, .asd files are just source files, so why not place them where the other fasls are written?
Not sure I fully understand. As you say, the .asd files are just source files, and they are never compiled, so there is no need to do any output translations for them.
I may not have fully followed the question....
concerning the .asd files, I use cl path/to/..asd in the REPL and both sbcl and acl try to find fasls for them. If there is no corresponding fasl, they write one.
At present, I do an explicit (load #P"path/to/system.asd") to prevent Lisp from writing fasls. So, the question comes from a habit developed over the years: why aren't defsystem files trated the same way as source files, i.e., treated according to what is specified in asdf-output-translations.conf?
Hopefully this explains a bit of the backgrond of my question.
Ah, yes, I *almost* think I get it. If you do an explicit (load #P"path/to/system.asd") isn't that a request to CL to load the source and *not* compile the .asd file? In general, one should not compile .asd files at all. They should be loaded as source files, typically as a side-effect of asdf:load-system... When I do (load "obtw.asd") in my obtw directory, ACL just loads the .asd file; it does not generate and store a fasl. So I'm still not /quite/ sure I see the issue. best, r
participants (7)
-
Daniel Herring -
Ernst van Waning -
Faré -
Nikodemus Siivola -
Robert Goldman -
Robert P. Goldman
-
Zach Beane