I think the whole "temporary package" thing is a failure, and we should just have an ASDF-USER package that uses ASDF. Does anyone have any objection to having .asd files be loaded in a shared ASDF-USER rather than a temporary ASDF~D package? If you want to define your own private functions in their private namespace, there's defpackage for you. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org There are two types of people in the world: People who think there are two kinds of people, and people who don't.
On Sat, 2013-01-26 at 19:12 -0500, Faré wrote:
I think the whole "temporary package" thing is a failure, and we
What problems does it actually cause ? -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib
On Sat, Jan 26, 2013 at 7:20 PM, Stelian Ionescu <sionescu@cddr.org> wrote:
On Sat, 2013-01-26 at 19:12 -0500, Faré wrote:
I think the whole "temporary package" thing is a failure, and we
What problems does it actually cause ?
It causes having to maintain this weird system, having functions and classes the symbols of which become inaccessible, etc. It causes users having the wrong expectations and/or having to learn some magic semantics that do not apply to other cases. If someone wants first class lexical namespaces for CL, let them do it the right way. A half-assed "solution" special-cased to .asd files. It's not a major big deal, but one more cleanup I want to make on the way to ASDF 3. I appreciate Dan Barlow having made various experiments when he wrote ASDF; some of the experiments were successes, other were failures. Successes: * User-extensible methods specialized on the dual operation and component class hierarchy. Big big win. * moving pathname management out of individual system files into asdf itself. Big big win. * Using TRUENAME to simplify .asd management with a link farm. Big win at the time, though ultimately not scalable. * Restarts :around compilation and loading (dunno if mk-defsystem did that). Win. Failures: * not propagating timestamps at all (failure inherited from mk-defsystem). Big fail. * having some dependencies implicit via the clunky TRAVERSE algorithm in general. Related fail, though still not worse than mk-defsystem. * the run-shell-command dead-end (inherited from mk-defsystem). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org There is a difference between knowing the path and walking the path. — Morpheus, in "The Matrix"
On Sat, 2013-01-26 at 19:47 -0500, Faré wrote:
On Sat, Jan 26, 2013 at 7:20 PM, Stelian Ionescu <sionescu@cddr.org> wrote:
On Sat, 2013-01-26 at 19:12 -0500, Faré wrote:
I think the whole "temporary package" thing is a failure, and we
What problems does it actually cause ?
It causes having to maintain this weird system, having functions and classes the symbols of which become inaccessible, etc. It causes users having the wrong expectations and/or having to learn some magic semantics that do not apply to other cases.
Why inaccessible ? [...]
Successes: * User-extensible methods specialized on the dual operation and component class hierarchy. Big big win. * moving pathname management out of individual system files into asdf itself. Big big win. * Using TRUENAME to simplify .asd management with a link farm. Big win at the time, though ultimately not scalable.
I still use this and love it. Actually, I'd like to be able to be allowed to return to the old behavior where ASDF re-initializes the source registry on every find-system. Given that I only use quicklisp and a symlink directory on an SSD, that's preferable(I don't use the :directory scanning thing). -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib
On Sat, Jan 26, 2013 at 7:58 PM, Stelian Ionescu <sionescu@cddr.org> wrote:
I think the whole "temporary package" thing is a failure, and we
What problems does it actually cause ?
It causes having to maintain this weird system, having functions and classes the symbols of which become inaccessible, etc. It causes users having the wrong expectations and/or having to learn some magic semantics that do not apply to other cases.
Why inaccessible ?
Because the package was delete-package'd in an unwind-protect form after loading the .asd file, and its symbols are thereafter uninterned.
* Using TRUENAME to simplify .asd management with a link farm. Big win at the time, though ultimately not scalable.
I still use this and love it. Actually, I'd like to be able to be allowed to return to the old behavior where ASDF re-initializes the source registry on every find-system. Given that I only use quicklisp and a symlink directory on an SSD, that's preferable(I don't use the :directory scanning thing).
I respect the *central-registry* feature and will keep supporting it. It's great for advanced developers like you. Don't want no caching? Keep using the *central-registry*, it's not going away any time soon. However, the caching is a big win for those of us who use :tree, especially on implementations on which scanning is slow. And that means most end-users and newbies, who want things to just work with minimal configuration (i.e. none at all if possible). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The ultimate result of shielding men from the effects of folly is to fill the world with fools. — Herbert Spencer
On Sat, 2013-01-26 at 20:48 -0500, Faré wrote:
On Sat, Jan 26, 2013 at 7:58 PM, Stelian Ionescu <sionescu@cddr.org> wrote:
I think the whole "temporary package" thing is a failure, and we
What problems does it actually cause ?
It causes having to maintain this weird system, having functions and classes the symbols of which become inaccessible, etc. It causes users having the wrong expectations and/or having to learn some magic semantics that do not apply to other cases.
Why inaccessible ?
Because the package was delete-package'd in an unwind-protect form after loading the .asd file, and its symbols are thereafter uninterned.
Then keep it, store it somewhere and perhaps delete it only when no longer referenced.
* Using TRUENAME to simplify .asd management with a link farm. Big win at the time, though ultimately not scalable.
I still use this and love it. Actually, I'd like to be able to be allowed to return to the old behavior where ASDF re-initializes the source registry on every find-system. Given that I only use quicklisp and a symlink directory on an SSD, that's preferable(I don't use the :directory scanning thing).
I respect the *central-registry* feature and will keep supporting it. It's great for advanced developers like you. Don't want no caching? Keep using the *central-registry*, it's not going away any time soon.
However, the caching is a big win for those of us who use :tree, especially on implementations on which scanning is slow. And that means most end-users and newbies, who want things to just work with minimal configuration (i.e. none at all if possible).
That's fine, but I'd like to be able to disable caching. And I'm not using *central-registry* but this configuration: (:source-registry (:directory (:home "lisp/systems")) :inherit-configuration) -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib
Because the package was delete-package'd in an unwind-protect form after loading the .asd file, and its symbols are thereafter uninterned.
Then keep it, store it somewhere and perhaps delete it only when no longer referenced.
I have no way to know when the package is not referenced. ASDF currently assumes nothing useful will be done with it after the asd is done loading. That's just wrong. I say stop trying to shield users from the responsibility of namespace management by making things more complex. They already need to create private packages for private uses, anyway, and they already can create all the clashes they want, anyway.
I respect the *central-registry* feature and will keep supporting it. It's great for advanced developers like you. Don't want no caching? Keep using the *central-registry*, it's not going away any time soon.
However, the caching is a big win for those of us who use :tree, especially on implementations on which scanning is slow. And that means most end-users and newbies, who want things to just work with minimal configuration (i.e. none at all if possible).
That's fine, but I'd like to be able to disable caching. And I'm not using *central-registry* but this configuration:
(:source-registry (:directory (:home "lisp/systems")) :inherit-configuration)
Maybe what you want is this: (defmethod asdf:operate :before (o c &key &allow-other-keys) (declare (ignorable o c)) (unless asdf::*system-being-operated* (asdf:initialize-source-registry))) I'm not convinced anyone but you wants this behavior, or I'd add a flag for it. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A pretty face is not a passport; it's a visa and it runs out fast.
On Sat, 2013-01-26 at 23:11 -0500, Faré wrote:
Because the package was delete-package'd in an unwind-protect form after loading the .asd file, and its symbols are thereafter uninterned.
Then keep it, store it somewhere and perhaps delete it only when no longer referenced.
I have no way to know when the package is not referenced.
Keep a list of all temporary packages created and keep a mapping system->temporary-package. After each find-system, run a garbage collection.
ASDF currently assumes nothing useful will be done with it after the asd is done loading. That's just wrong. I say stop trying to shield users from the responsibility of namespace management by making things more complex. They already need to create private packages for private uses, anyway, and they already can create all the clashes they want, anyway.
I think ASDF should be as DWIM-ish as possible, which benefits everybody; or, in other words, better avoid responsibility and concentrate it into a central place(ASDF). Unnecessary responsibility just causes headaches.
I respect the *central-registry* feature and will keep supporting it. It's great for advanced developers like you. Don't want no caching? Keep using the *central-registry*, it's not going away any time soon.
However, the caching is a big win for those of us who use :tree, especially on implementations on which scanning is slow. And that means most end-users and newbies, who want things to just work with minimal configuration (i.e. none at all if possible).
That's fine, but I'd like to be able to disable caching. And I'm not using *central-registry* but this configuration:
(:source-registry (:directory (:home "lisp/systems")) :inherit-configuration)
Maybe what you want is this:
(defmethod asdf:operate :before (o c &key &allow-other-keys) (declare (ignorable o c)) (unless asdf::*system-being-operated* (asdf:initialize-source-registry)))
Thanks, I'll try it. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib
On 1/26/13 Jan 26 -6:12 PM, Faré wrote:
I think the whole "temporary package" thing is a failure, and we should just have an ASDF-USER package that uses ASDF.
Does anyone have any objection to having .asd files be loaded in a shared ASDF-USER rather than a temporary ASDF~D package?
If you want to define your own private functions in their private namespace, there's defpackage for you.
I am sympathetic to your concerns here, but I am worried that it will cause lots of breakage. I have always done the old-school thing and defined a new package for my system definition. This makes for a pleasing symmetry between behavior where I incrementally evaluate forms, and when I load the system into an image. *HOWEVER*, some CL pundits seem to think that making extra packages is bad, and in a spirit of (to me, misguided) parsimony, strongly encouraged people to rely on the creation of the temporary packages. I fear that this means that loading all the package definitions into a single ASDF-USER package is likely to cause breakage from namespace collisions. Also, I fear that this will be a nuisance to catch in testing, because it is likely to require testing large numbers of *combinations* of loaded systems to simulate behavior downstream programmers might see. In my customary role as backward compatibility buzz-kill, I suggest that we keep the old behavior. Best, r
On Sun, Jan 27, 2013 at 12:13 PM, Robert Goldman <rpgoldman@sift.info> wrote:
On 1/26/13 Jan 26 -6:12 PM, Faré wrote:
I think the whole "temporary package" thing is a failure, and we should just have an ASDF-USER package that uses ASDF.
Does anyone have any objection to having .asd files be loaded in a shared ASDF-USER rather than a temporary ASDF~D package?
If you want to define your own private functions in their private namespace, there's defpackage for you.
I am sympathetic to your concerns here, but I am worried that it will cause lots of breakage.
I have always done the old-school thing and defined a new package for my system definition. This makes for a pleasing symmetry between behavior where I incrementally evaluate forms, and when I load the system into an image.
*HOWEVER*, some CL pundits seem to think that making extra packages is bad, and in a spirit of (to me, misguided) parsimony, strongly encouraged people to rely on the creation of the temporary packages.
I fear that this means that loading all the package definitions into a single ASDF-USER package is likely to cause breakage from namespace collisions.
Also, I fear that this will be a nuisance to catch in testing, because it is likely to require testing large numbers of *combinations* of loaded systems to simulate behavior downstream programmers might see.
In my customary role as backward compatibility buzz-kill, I suggest that we keep the old behavior.
I know that quicklisp is not *everything*, but I did a quick survey and found nothing clashy: A=( $(grep -L in-package ~/quicklisp/dists/quicklisp/software/**/*.asd) ) fgrep '(def' $A | grep -v 'defsystem\|defpackage\|defmethod \(asdf:\)\?\(perform\|operation-done-p\)' | less The most clashy thing I found was hemlock defining variables the name of which start with *hemlock- which actually seem perfectly fine to me. There are plenty of scary-looking definitions in optima.asd, but that's actually documentation in #| |#. I say anyone who does something clashy deserves the lossage he gets, and so do people who use his software. There is already plenty of namespace management around, ASDF cannot substitute to using proper namespace management techniques. And if Common Lisp is lacking in this regard, let's fix Common Lisp, not add a crock to ASDF. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Soccer riots kill at most tens. Intellectuals' ideological riots sometimes kill millions.— John McCarthy
On 1/27/13 Jan 27 -11:33 AM, Faré wrote:
On Sun, Jan 27, 2013 at 12:13 PM, Robert Goldman <rpgoldman@sift.info> wrote:
On 1/26/13 Jan 26 -6:12 PM, Faré wrote:
I think the whole "temporary package" thing is a failure, and we should just have an ASDF-USER package that uses ASDF.
Does anyone have any objection to having .asd files be loaded in a shared ASDF-USER rather than a temporary ASDF~D package?
If you want to define your own private functions in their private namespace, there's defpackage for you.
I am sympathetic to your concerns here, but I am worried that it will cause lots of breakage.
I have always done the old-school thing and defined a new package for my system definition. This makes for a pleasing symmetry between behavior where I incrementally evaluate forms, and when I load the system into an image.
*HOWEVER*, some CL pundits seem to think that making extra packages is bad, and in a spirit of (to me, misguided) parsimony, strongly encouraged people to rely on the creation of the temporary packages.
I fear that this means that loading all the package definitions into a single ASDF-USER package is likely to cause breakage from namespace collisions.
Also, I fear that this will be a nuisance to catch in testing, because it is likely to require testing large numbers of *combinations* of loaded systems to simulate behavior downstream programmers might see.
In my customary role as backward compatibility buzz-kill, I suggest that we keep the old behavior.
I know that quicklisp is not *everything*, but I did a quick survey and found nothing clashy:
A=( $(grep -L in-package ~/quicklisp/dists/quicklisp/software/**/*.asd) ) fgrep '(def' $A | grep -v 'defsystem\|defpackage\|defmethod \(asdf:\)\?\(perform\|operation-done-p\)' | less
The most clashy thing I found was hemlock defining variables the name of which start with *hemlock- which actually seem perfectly fine to me. There are plenty of scary-looking definitions in optima.asd, but that's actually documentation in #| |#.
I say anyone who does something clashy deserves the lossage he gets, and so do people who use his software. There is already plenty of namespace management around, ASDF cannot substitute to using proper namespace management techniques. And if Common Lisp is lacking in this regard, let's fix Common Lisp, not add a crock to ASDF.
Good point. I went back and checked some of the postings that said "you don't need a package in your system definition file," and any that I found pointed out that if you were defining new classes, etc., you *should* put a new package in. So I suspect we will be OK, after all, or at least we will find that code that breaks is pretty clearly deprecated. best, r
participants (3)
-
Faré -
Robert Goldman -
Stelian Ionescu