How would you all feel about an alternate default location for lisp systems, in addition to
~/.local/share/common-lisp/source/
I'm sure that .local was chosen out of the (in)finite wisdom of XDG, but it just seems odd to me to hide the lisp systems from the user, which we are doing by putting them in a location that requires ls -a.
After all, these are systems, not configuration files.
What about ~/asdf-systems which doesn't make the poor user play peekaboo?
I came across this while editing the manual. I don't use this directory myself; maybe everyone loves it. Or maybe no one uses the standard default, and I shouldn't care.
Cheers, r
On Thu, 2014-02-27 at 22:30 -0600, Robert P. Goldman wrote:
How would you all feel about an alternate default location for lisp systems, in addition to
~/.local/share/common-lisp/source/
I'm sure that .local was chosen out of the (in)finite wisdom of XDG, but it just seems odd to me to hide the lisp systems from the user, which we are doing by putting them in a location that requires ls -a.
After all, these are systems, not configuration files.
What about ~/asdf-systems which doesn't make the poor user play peekaboo?
I came across this while editing the manual. I don't use this directory myself; maybe everyone loves it. Or maybe no one uses the standard default, and I shouldn't care.
I would ask you not to add any more hard-coded directories to ASDF, and remove the already existing ones. If what you want is making life easy for newcomers, make an additional tool that initializes a work environment with convenient values, but separate the configuration of ASDF from the core.
The only reason why ~/.local/share/common-lisp/source/ hasn't caused complaints is because nobody was already using it. In my case, ~/lisp has large numbers of duplicate .asd files and other systems I don't want to expose so a :tree recursion there would be very annoying. And please don't tell me to :ignore-inherited-configuration, for what's the point of the default configuration if so many people either don't use it or have to explicitly ignore it ?
to expose so a :tree recursion there would be very annoying. And please don't tell me to :ignore-inherited-configuration, for what's the point of the default configuration if so many people either don't use it or have to explicitly ignore it ?
well, for now it's two hard-core hackers, for whom it's probably marginal to get things back on track *if* it actually breaks something for them.
but we have no idea about the number of newcomers who fire up an apt-get install sbcl for the first time in their lives, and just want to try a piece of code copied from the net...
i still remember how goddamn high the fence was to first climb in to the CL+emacs garden. i'm with Robert on this.
i'm not sure how the defaults would help on this, though. probably a very slick quicklisp experience has more value than any of these defaults can create.
just some 2¢,
Attila Lendvai wrote:
to expose so a :tree recursion there would be very annoying. And please don't tell me to :ignore-inherited-configuration, for what's the point of the default configuration if so many people either don't use it or have to explicitly ignore it ?
well, for now it's two hard-core hackers, for whom it's probably marginal to get things back on track *if* it actually breaks something for them.
but we have no idea about the number of newcomers who fire up an apt-get install sbcl for the first time in their lives, and just want to try a piece of code copied from the net...
i still remember how goddamn high the fence was to first climb in to the CL+emacs garden. i'm with Robert on this.
i'm not sure how the defaults would help on this, though. probably a very slick quicklisp experience has more value than any of these defaults can create.
For the record, I agree with this. I believe that installing quicklisp is probably the best first step. But see my earlier discussion about Clojure. I just want to start playing around in a repl, stashing some code into files as I go. Please make this as easy for me as possible, and don't make me grok extra stuff.
I *will* ponder adding some introduction to Quicklisp to the ASDF manual, though. I think for lots of people that will be the easiest path into CL, and there's no reason we should pretend not to know about it in our documentation.
Cheers, r
Stelian Ionescu wrote:
On Thu, 2014-02-27 at 22:30 -0600, Robert P. Goldman wrote:
How would you all feel about an alternate default location for lisp systems, in addition to
~/.local/share/common-lisp/source/
I'm sure that .local was chosen out of the (in)finite wisdom of XDG, but it just seems odd to me to hide the lisp systems from the user, which we are doing by putting them in a location that requires ls -a.
After all, these are systems, not configuration files.
What about ~/asdf-systems which doesn't make the poor user play peekaboo?
I came across this while editing the manual. I don't use this directory myself; maybe everyone loves it. Or maybe no one uses the standard default, and I shouldn't care.
I would ask you not to add any more hard-coded directories to ASDF, and remove the already existing ones. If what you want is making life easy for newcomers, make an additional tool that initializes a work environment with convenient values, but separate the configuration of ASDF from the core.
The only reason why ~/.local/share/common-lisp/source/ hasn't caused complaints is because nobody was already using it. In my case, ~/lisp has large numbers of duplicate .asd files and other systems I don't want to expose so a :tree recursion there would be very annoying. And please don't tell me to :ignore-inherited-configuration, for what's the point of the default configuration if so many people either don't use it or have to explicitly ignore it ?
The problem with not adding hard-coded directories is that configuration is too demanding of a new user. I have just overhauled the manual, and there is WAY too much to have to know in order to just get started.
IMO, no one should have to learn a complex DSL, or how to structure a conf.d directory in order to write his or her first lisp system. Compare with 'make' -- since make doesn't have to find its systems, it's trivial to build a makefile for your first C program. That is not the case with ASDF -- you can write your first .asd file, but ASDF won't find it!
Since ASDF *does* have to find the user's first ASDF file, we must make that trivial to do.
I'm open to proposals that don't involve a default directory, but I'm not happy with the current state of affairs.
The thought experiment I suggest is the following: You meet a new Lisp user, who wants to write his or her first lisp system. It's so simple it doesn't have any external dependencies. How do you explain ASDF configuration so that it gets the system loaded, and is absolutely trivial?
I don't want to make an additional tool, since that requires somehow getting all the implementations to bundle said additional tool, and because (a) we don't have a good way to make such a tool invocable from the command line; (b) if we could do a, it would still be a problem to get it to work on Windows as well as the Unix family tree; (c) anything to do with modifying the file system is a bear because of the inadequacies of the CL spec in this area.
But I could be wrong about this! Do you see a way such a tool could simplify the novice's life and be implementable w/o too much effort?
Cheers, r
On Wed, 2014-03-12 at 08:51 -0500, Robert P. Goldman wrote:
Stelian Ionescu wrote:
On Thu, 2014-02-27 at 22:30 -0600, Robert P. Goldman wrote:
How would you all feel about an alternate default location for lisp systems, in addition to
~/.local/share/common-lisp/source/
I'm sure that .local was chosen out of the (in)finite wisdom of XDG, but it just seems odd to me to hide the lisp systems from the user, which we are doing by putting them in a location that requires ls -a.
After all, these are systems, not configuration files.
What about ~/asdf-systems which doesn't make the poor user play peekaboo?
I came across this while editing the manual. I don't use this directory myself; maybe everyone loves it. Or maybe no one uses the standard default, and I shouldn't care.
I would ask you not to add any more hard-coded directories to ASDF, and remove the already existing ones. If what you want is making life easy for newcomers, make an additional tool that initializes a work environment with convenient values, but separate the configuration of ASDF from the core.
The only reason why ~/.local/share/common-lisp/source/ hasn't caused complaints is because nobody was already using it. In my case, ~/lisp has large numbers of duplicate .asd files and other systems I don't want to expose so a :tree recursion there would be very annoying. And please don't tell me to :ignore-inherited-configuration, for what's the point of the default configuration if so many people either don't use it or have to explicitly ignore it ?
The problem with not adding hard-coded directories is that configuration is too demanding of a new user. I have just overhauled the manual, and there is WAY too much to have to know in order to just get started.
IMO, no one should have to learn a complex DSL, or how to structure a conf.d directory in order to write his or her first lisp system. Compare with 'make' -- since make doesn't have to find its systems, it's trivial to build a makefile for your first C program. That is not the case with ASDF -- you can write your first .asd file, but ASDF won't find it!
Since ASDF *does* have to find the user's first ASDF file, we must make that trivial to do.
I'm open to proposals that don't involve a default directory, but I'm not happy with the current state of affairs.
The thought experiment I suggest is the following: You meet a new Lisp user, who wants to write his or her first lisp system. It's so simple it doesn't have any external dependencies. How do you explain ASDF configuration so that it gets the system loaded, and is absolutely trivial?
1) install Quicklisp, it's easy and painless 2) put your projects in $QUICKLISPDIR/local-projects/
done.
I don't want to make an additional tool, since that requires somehow getting all the implementations to bundle said additional tool
That's not true. See for instance rbenv(ruby) and virtualenv(python). They're separate projects.
and because (a) we don't have a good way to make such a tool invocable from the command line; (b) if we could do a, it would still be a problem to get it to work on Windows as well as the Unix family tree; (c) anything to do with modifying the file system is a bear because of the inadequacies of the CL spec in this area.
I didn't say it must be written in Lisp. Since it would only be asking a few questions and thereafter creating a few directories and files it can very well be perl/python.
Stelian Ionescu wrote:
- install Quicklisp, it's easy and painless
- put your projects in $QUICKLISPDIR/local-projects/
done.
I get you, but I don't like it.
That's like saying "I want to make my first C program." "OK, let me teach you how to use apt-get."
Maybe this is the right answer, but it's not a path to getting a minimal understandable config for ASDF. All that's happening here is that Quicklisp is hiding the complexity.
I am reminded of Clojure: "I want to write my first Clojure program, what do I do?" "First learn how Leiningen works."
I am happy for people to tell novices to start with Quicklisp, don't get me wrong. And if that's their path into programming, instead of starting through ASDF, I'm fine with that, too. But it doesn't remove the need for a trivial path into ASDF.
Your email does suggest that ~/asdf-local-projects/ might be a suitable location...
Similarly, it's unacceptable to have as the first instruction in our manual "go off, find and install a script that configures our tool." That means that we have failed to provide an easily configurable tool.
I appreciate your thoughts, but they haven't yet pushed me away from the default directory solution.
Best, r
On Wed, 2014-03-12 at 09:20 -0500, Robert P. Goldman wrote:
Stelian Ionescu wrote:
- install Quicklisp, it's easy and painless
- put your projects in $QUICKLISPDIR/local-projects/
done.
I get you, but I don't like it.
That's like saying "I want to make my first C program." "OK, let me teach you how to use apt-get."
Yes, and it's a very good idea to do just that because either you want to use ASDF to load other libraries in which case you need QL, or a simple file will suffice.
Maybe this is the right answer, but it's not a path to getting a minimal understandable config for ASDF. All that's happening here is that Quicklisp is hiding the complexity.
Which is very good. People that write .asd files aren't beginners.
I am reminded of Clojure: "I want to write my first Clojure program, what do I do?" "First learn how Leiningen works."
Yes. Want to learn node.js ? Use npm. Want to learn ruby ? Use gems. Want to learn python ? Use pip. etc...
I am happy for people to tell novices to start with Quicklisp, don't get me wrong. And if that's their path into programming, instead of starting through ASDF, I'm fine with that, too. But it doesn't remove the need for a trivial path into ASDF.
Your email does suggest that ~/asdf-local-projects/ might be a suitable location...
Similarly, it's unacceptable to have as the first instruction in our manual "go off, find and install a script that configures our tool." That means that we have failed to provide an easily configurable tool.
What you want to provide is not an easily configurable tool, but an already-configured tool.
"Robert P. Goldman" rpgoldman@sift.info writes:
Stelian Ionescu wrote:
On Thu, 2014-02-27 at 22:30 -0600, Robert P. Goldman wrote:
How would you all feel about an alternate default location for lisp systems, in addition to
~/.local/share/common-lisp/source/
I'm sure that .local was chosen out of the (in)finite wisdom of XDG, but it just seems odd to me to hide the lisp systems from the user, which we are doing by putting them in a location that requires ls -a.
After all, these are systems, not configuration files.
What about ~/asdf-systems which doesn't make the poor user play peekaboo?
I came across this while editing the manual. I don't use this directory myself; maybe everyone loves it. Or maybe no one uses the standard default, and I shouldn't care.
I would ask you not to add any more hard-coded directories to ASDF, and remove the already existing ones. If what you want is making life easy for newcomers, make an additional tool that initializes a work environment with convenient values, but separate the configuration of ASDF from the core.
The only reason why ~/.local/share/common-lisp/source/ hasn't caused complaints is because nobody was already using it. In my case, ~/lisp has large numbers of duplicate .asd files and other systems I don't want to expose so a :tree recursion there would be very annoying. And please don't tell me to :ignore-inherited-configuration, for what's the point of the default configuration if so many people either don't use it or have to explicitly ignore it ?
The problem with not adding hard-coded directories is that configuration is too demanding of a new user. I have just overhauled the manual, and there is WAY too much to have to know in order to just get started.
IMO, no one should have to learn a complex DSL, or how to structure a conf.d directory in order to write his or her first lisp system. Compare with 'make' -- since make doesn't have to find its systems, it's trivial to build a makefile for your first C program. That is not the case with ASDF -- you can write your first .asd file, but ASDF won't find it!
Since ASDF *does* have to find the user's first ASDF file, we must make that trivial to do.
I think this could be simplified somewhat if it was easy to load or register a system if you have its pathname. I've seen some people recommend something like (load "/path/to/project.asd"), but I don't think that establishes the same environment that asdf's find-system mechanism does, so it could go wrong.
Is there some easy way, supported by ASDF, to make a system known to ASDF if you have its pathname?
The complexity of the registry configuration is one reason why I added the ~/quicklisp/local-projects/ mechanism.
Zach
Zach Beane wrote:
The complexity of the registry configuration is one reason why I added the ~/quicklisp/local-projects/ mechanism.
Right, so I don't see why there's such a huge objection to having a similar mechanism for ASDF. Stellian suggests using ~/quicklisp/local-projects/. So why is it wrong for ASDF to have a local-projects directory?
All I am suggesting is to have the local projects directory for ASDF be visible, instead of invisible.
I stand corrected about using a name that the user might have already had (thanks, Pascal!) but I don't yet see a solution that's as easy as a default directory location.
Cheers! r
On Wed, 2014-03-12 at 09:23 -0500, Robert Goldman wrote:
Zach Beane wrote:
The complexity of the registry configuration is one reason why I added the ~/quicklisp/local-projects/ mechanism.
Right, so I don't see why there's such a huge objection to having a similar mechanism for ASDF. Stellian suggests using ~/quicklisp/local-projects/. So why is it wrong for ASDF to have a local-projects directory?
For example because quicklisp was designed with the idea of allowing multiple istances. One can have a QL installation per project, which means that for each work environment, only the local-projects/ in that environment will be searched. OTOH, you propose a global directory that will conflict with existing configurations.
All I am suggesting is to have the local projects directory for ASDF be visible, instead of invisible.
I stand corrected about using a name that the user might have already had (thanks, Pascal!) but I don't yet see a solution that's as easy as a default directory location.
It's very easy not to have a default directory at all.
Stelian Ionescu wrote:
It's very easy not to have a default directory at all.
I'm sorry, I don't agree that this claim is correct. I have just pushed my current draft of the ASDF manual, and I urge you to read it.
I think you will find that the configuration of the source search path is *very* complex, indeed too complex for a beginner. It's great for hackers with complex requirements, but there's too much to be read if you just want to make one or two simple systems.
Please do skim at least the first few pages, and I think you will see what I mean.
Best, r
asdf is not a tool for beginners. Beginners will either deal with a bare Common Lisp implementation, or they want to experiment with third-party libraries, in which case they want to use quicklisp these days. Once you need to define your own systems, you're not a beginner anymore, and a good tutorial helps a lot more than any supporting wheels can. It's already hard enough to ensure that asdf doesn't accidentally find systems you don't want it to find, you shouldn't make it even harder.
On top of that, with the proposed scheme, you will create a situation where there are not only two "default" locations for user-defined systems, but three when quicklisp is active. I find it hard to imagine that beginners will find this easy to grasp.
Just my 0.02€...
Pascal
Sent from my iPad
On 12 Mar 2014, at 16:04, "Robert P. Goldman" rpgoldman@sift.info wrote:
Stelian Ionescu wrote:
It's very easy not to have a default directory at all.
I'm sorry, I don't agree that this claim is correct. I have just pushed my current draft of the ASDF manual, and I urge you to read it.
I think you will find that the configuration of the source search path is *very* complex, indeed too complex for a beginner. It's great for hackers with complex requirements, but there's too much to be read if you just want to make one or two simple systems.
Please do skim at least the first few pages, and I think you will see what I mean.
Best, r
On Wed, 2014-03-12 at 10:04 -0500, Robert P. Goldman wrote:
Stelian Ionescu wrote:
It's very easy not to have a default directory at all.
I'm sorry, I don't agree that this claim is correct.
You don't agree that it's always easier not to do anything ? Really ?
I have just pushed my current draft of the ASDF manual, and I urge you to read it.
I've read it.
I think you will find that the configuration of the source search path is *very* complex, indeed too complex for a beginner.
If it's complex, simplify it. You'd piling more stuff on top of the current behaviour.
It's great for hackers with complex requirements, but there's too much to be read if you just want to make one or two simple systems.
Nowadays, it's very rare to want to make "one or two simple systems" and not need additional dependencies, in which case better use QL.
Stelian Ionescu wrote:
I think you will find that the configuration of the source search path is *very* complex, indeed too complex for a beginner.
If it's complex, simplify it. You'd piling more stuff on top of the current behaviour.
No, that is not the case.
I would be *simplifying* "~/.local/share/common-lisp/source" to "~/asdf-local-projects/" and, perhaps most importantly, simplifying "ls -a ~/.local/share/common-lisp/source" to "ls ~/asdf-local-projects/"
That's all I'm planning to do.
[Actually, to be fair, we would be complexifying a little, because we would permit the users to continue to use ~/.local/share/common-lisp/source, in the unlikely event they are already doing so.]
I take the point that using quicklisp might be the easiest thing to do, but quicklisp is not my responsibility. My job is to make ASDF usable.
I'm afraid I still don't understand why this makes you object so strongly. How does this concretely make your life, or someone else's life more difficult?
I *do* get the objection that Pascal had, and I absolutely agree that we should not choose a directory name that will collide with existing users' directories.
I *do* get the objection that Pascal had, and I absolutely agree that we should not choose a directory name that will collide with existing users' directories.
when reading this i imagined my future child some decades down the road reading the ASDF manual (hopefull only for historical reasons while reifying CL semantics to have an environment where he can try his father's code)... and then pondering: what on earth made someone chose this weird ~/asdf-local-projects/ name instead of e.g. ~/common-lisp/ :)
IOW, i'd like to draw more attentinon to the fact that what we are weighting here is a few active complaints today from experts (who are already aware of this issue reading the mailing list, even before the change itself)... against all the yet to be born/educated CL programmers until the time when ASDF is eventually obsoleted (or for that matter CL altogether), and all the aggregate time these future people will waste reading manuals and asking questions.
i think a tendency towards not taking this into consideration has a lot to do why the CL community is not successful. the defaults of slime is another very good example of this, although it got much better since the times when i first climbed the CL/Emacs fence.
also note: as Fare already pointed out, if e.g. XCVB gains more traction, then some/most systems will have two system definition files, but all sitting under the asdf specific ~/asdf-local-projects/ name.
but hopefully by the time my children are old enough for programming computing systems will have finally obsoleted this silly idea that the base axioms for data storage is labeled binary numbers, and their labels organized into a tree... and with that rendering this whole question moot. hopefully...
sorry for the sentiments.
If asdf provides a simple and well documented way of disabling a default directory, the it can be any name. Then it can be ensured that future users are happy, and at the same time, current setups are unaffected.
Pascal
Sent from my iPad
On 13 Mar 2014, at 08:34, Attila Lendvai attila.lendvai@gmail.com wrote:
I *do* get the objection that Pascal had, and I absolutely agree that we should not choose a directory name that will collide with existing users' directories.
when reading this i imagined my future child some decades down the road reading the ASDF manual (hopefull only for historical reasons while reifying CL semantics to have an environment where he can try his father's code)... and then pondering: what on earth made someone chose this weird ~/asdf-local-projects/ name instead of e.g. ~/common-lisp/ :)
IOW, i'd like to draw more attentinon to the fact that what we are weighting here is a few active complaints today from experts (who are already aware of this issue reading the mailing list, even before the change itself)... against all the yet to be born/educated CL programmers until the time when ASDF is eventually obsoleted (or for that matter CL altogether), and all the aggregate time these future people will waste reading manuals and asking questions.
i think a tendency towards not taking this into consideration has a lot to do why the CL community is not successful. the defaults of slime is another very good example of this, although it got much better since the times when i first climbed the CL/Emacs fence.
also note: as Fare already pointed out, if e.g. XCVB gains more traction, then some/most systems will have two system definition files, but all sitting under the asdf specific ~/asdf-local-projects/ name.
but hopefully by the time my children are old enough for programming computing systems will have finally obsoleted this silly idea that the base axioms for data storage is labeled binary numbers, and their labels organized into a tree... and with that rendering this whole question moot. hopefully...
sorry for the sentiments.
-- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Disregard for the preferences and interests of individuals alive today in order to pursue some distant social goal that their rulers have claimed is their duty to promote has been a common cause of misery for people throughout the ages.” — Isaiah Berlin (1909–1997)
good morning;
On 13 Mar 2014, at 08:34, Attila Lendvai attila.lendvai@gmail.com wrote:
I *do* get the objection that Pascal had, and I absolutely agree that we should not choose a directory name that will collide with existing users' directories.
[…]
but hopefully by the time my children are old enough for programming computing systems will have finally obsoleted this silly idea that the base axioms for data storage is labeled binary numbers, and their labels organized into a tree... and with that rendering this whole question moot. hopefully...
one suspects, should that ever come to pass, the proponents will have necessarily admitted to the principle of orthogonal composition.
a notion from which asdf could benefit and which could well contribute to a coherent description of what problem the topic of this thread is intended to solve and perhaps even a case for why asdf must solve it.
i had the recent experience, that a colleague concluded it would be appropriate to bring some bit of cl infrastructure up to ubuntu’s latest version only to discover that the change introduced some “feature” which broke our build. i suspect it may have had something to do with yet another search and/or registry mechanism. i did not bother to find out, but pondered momentarily the same question as comes to mind in reaction to many of the threads here: do you gentlemen have no real work to do? fortunately, a downgrade and a directory deletion was sufficient to allow us to proceed with ours.
best regards, from berlin,
I think you will find that the configuration of the source search path is *very* complex, indeed too complex for a beginner. It's great for hackers with complex requirements, but there's too much to be read if you just want to make one or two simple systems.
FTR, even i was mildly irritated by this when i first approached the new ASDF config infrastructure.
but don't get me wrong, i have no ideas how to simplify it, and the docs are probably also much better these days...
Robert Goldman rpgoldman@sift.net writes:
Zach Beane wrote:
The complexity of the registry configuration is one reason why I added the ~/quicklisp/local-projects/ mechanism.
Right, so I don't see why there's such a huge objection to having a similar mechanism for ASDF. Stellian suggests using ~/quicklisp/local-projects/. So why is it wrong for ASDF to have a local-projects directory?
All I am suggesting is to have the local projects directory for ASDF be visible, instead of invisible.
I stand corrected about using a name that the user might have already had (thanks, Pascal!) but I don't yet see a solution that's as easy as a default directory location.
I think having a similar mechanism would be good. (And the loading-from-a-file thing could be nice too.)
I think the main problem is that giving it a nice name means that the chance is high of it clashing with a nice name one or more users is already using.
A while ago I was thinking it would be nice to have an API like this:
register-system-directory directory &key permanently
Registers DIRECTORY as a directory to search for system files. If PERMANENTLY is true, make the registration persist across sessions.
But then I got hung up about how to make PERMANENTLY work -- I don't think there's any way to ask ASDF what directory is suitable for saving a config file.
And I am 100% in favor of a nice solution that does not involve Quicklisp. The simpler, the better.
Zach
On Mar 12, 2014, at 15:32 , Zach Beane xach@xach.com wrote:
Robert Goldman rpgoldman@sift.net writes:
Zach Beane wrote:
The complexity of the registry configuration is one reason why I added the ~/quicklisp/local-projects/ mechanism.
Right, so I don't see why there's such a huge objection to having a similar mechanism for ASDF. Stellian suggests using ~/quicklisp/local-projects/. So why is it wrong for ASDF to have a local-projects directory?
All I am suggesting is to have the local projects directory for ASDF be visible, instead of invisible.
I stand corrected about using a name that the user might have already had (thanks, Pascal!) but I don't yet see a solution that's as easy as a default directory location.
I think having a similar mechanism would be good. (And the loading-from-a-file thing could be nice too.)
I think the main problem is that giving it a nice name means that the chance is high of it clashing with a nice name one or more users is already using.
A while ago I was thinking it would be nice to have an API like this:
register-system-directory directory &key permanently
Registers DIRECTORY as a directory to search for system files. If PERMANENTLY is true, make the registration persist across sessions.
But then I got hung up about how to make PERMANENTLY work -- I don't think there's any way to ask ASDF what directory is suitable for saving a config file.
And I am 100% in favor of a nice solution that does not involve Quicklisp. The simpler, the better.
That is what MK:DEFSYSTEM used to (actually still does) have.
mk:add-registry-location <pathname>
I don’t think you want the ‘permanently’. Your init file should be able to deal with that.
-- Marco Antoniotti
Marco Antoniotti marcoxa@cs.nyu.edu writes:
On Mar 12, 2014, at 15:32 , Zach Beane xach@xach.com wrote:
Robert Goldman rpgoldman@sift.net writes:
Zach Beane wrote:
The complexity of the registry configuration is one reason why I added the ~/quicklisp/local-projects/ mechanism.
Right, so I don't see why there's such a huge objection to having a similar mechanism for ASDF. Stellian suggests using ~/quicklisp/local-projects/. So why is it wrong for ASDF to have a local-projects directory?
All I am suggesting is to have the local projects directory for ASDF be visible, instead of invisible.
I stand corrected about using a name that the user might have already had (thanks, Pascal!) but I don't yet see a solution that's as easy as a default directory location.
I think having a similar mechanism would be good. (And the loading-from-a-file thing could be nice too.)
I think the main problem is that giving it a nice name means that the chance is high of it clashing with a nice name one or more users is already using.
A while ago I was thinking it would be nice to have an API like this:
register-system-directory directory &key permanently
Registers DIRECTORY as a directory to search for system files. If PERMANENTLY is true, make the registration persist across sessions.
But then I got hung up about how to make PERMANENTLY work -- I don't think there's any way to ask ASDF what directory is suitable for saving a config file.
And I am 100% in favor of a nice solution that does not involve Quicklisp. The simpler, the better.
That is what MK:DEFSYSTEM used to (actually still does) have.
mk:add-registry-location <pathname>
I don’t think you want the ‘permanently’. Your init file should be able to deal with that.
I'd like to use this interface *instead* of thinking about which config file to extend, and extend a cross-platform data file instead.
But I can't figure out how to do it, so it's a bit moot right now.
Zach
Well. Quicklisp can change the unit files. Doesn't it?
I suppose it's the chicken and egg problem that is both ring you
Marco
Sent from my Windows Phone ________________________________ From: Zach Beanemailto:xach@xach.com Sent: 12/03/2014 17.33 To: Marco Antoniottimailto:marcoxa@cs.nyu.edu Cc: ASDF-develmailto:asdf-devel@common-lisp.net Subject: Re: [asdf-devel] Alternate default lisp system location
Marco Antoniotti marcoxa@cs.nyu.edu writes:
On Mar 12, 2014, at 15:32 , Zach Beane xach@xach.com wrote:
Robert Goldman rpgoldman@sift.net writes:
Zach Beane wrote:
The complexity of the registry configuration is one reason why I added the ~/quicklisp/local-projects/ mechanism.
Right, so I don't see why there's such a huge objection to having a similar mechanism for ASDF. Stellian suggests using ~/quicklisp/local-projects/. So why is it wrong for ASDF to have a local-projects directory?
All I am suggesting is to have the local projects directory for ASDF be visible, instead of invisible.
I stand corrected about using a name that the user might have already had (thanks, Pascal!) but I don't yet see a solution that's as easy as a default directory location.
I think having a similar mechanism would be good. (And the loading-from-a-file thing could be nice too.)
I think the main problem is that giving it a nice name means that the chance is high of it clashing with a nice name one or more users is already using.
A while ago I was thinking it would be nice to have an API like this:
register-system-directory directory &key permanently
Registers DIRECTORY as a directory to search for system files. If PERMANENTLY is true, make the registration persist across sessions.
But then I got hung up about how to make PERMANENTLY work -- I don't think there's any way to ask ASDF what directory is suitable for saving a config file.
And I am 100% in favor of a nice solution that does not involve Quicklisp. The simpler, the better.
That is what MK:DEFSYSTEM used to (actually still does) have.
mk:add-registry-location <pathname>
I don’t think you want the ‘permanently’. Your init file should be able to deal with that.
I'd like to use this interface *instead* of thinking about which config file to extend, and extend a cross-platform data file instead.
But I can't figure out how to do it, so it's a bit moot right now.
Zach
Yay for the bikeshedding.
1- I think we should proceed and add a default path anyway. ~/cl/ and/or ~/common-lisp/ sound fine to me, and I've seen no one complain about that. You could make it ~/local/common-lisp/ if you're into larger paths.
2- Yes, we can add a programmatic way to manually register a .asd file: put in front of *system-definition-search-functions* a new sysdef-system-registry-search (please bikeshed a better name than that) that takes entries from a hash-table, with associated API (register-system name pathname-or-system) and (unregister-system name) Note that registering a system object rather than a pathname is dangerous in case of latter ASDF upgrade that would somehow invalidate the system class definition.
I'd like to use this interface *instead* of thinking about which config file to extend, and extend a cross-platform data file instead.
There used to be a "preference file" mechanism. We could reintroduce a ~/config/common-lisp/asdf-init.lisp and/or ~/.asdf-init.lisp, to be loaded when ASDF is loaded and reloaded, or lazily at the first operation like initialize-source-registry, which gives users the opportunity to disable it and to reenable it, which is essential when preparing a "clean" image.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org No man would listen to you talk if he didn't know it was his turn next. — Edgar Watson Howe
On Wed, Mar 12, 2014 at 1:04 PM, Faré fahree@gmail.com wrote:
1- I think we should proceed and add a default path anyway. ~/cl/ and/or ~/common-lisp/ sound fine to me, and I've seen no one complain about that. You could make it ~/local/common-lisp/ if you're into larger paths.
How about providing the following as part of this:
1. the option of a control file within that default path, to be able to specify subdirectories to be ignored. So anyone who already happens to have a ~/cl/ with a bunch of inactive subfolders with .asd files can make ~/cl/subdirs-to-exclude.asdc whose contents could be e.g.
("inactive-proj-1" "inactive-proj-2")
2. When registering systems in the default location, loudly announce that this is happening, e.g:
***** Automatically registering .asd systems under ~/cl/...
Protip: if you want to exclude certain subdirectories, create file
~/cl/subdirs-to-exclude.asdc
containing a list of the subdirectory names to be excluded, e.g.
("inactive-proj-1" "inactive-proj-2")
*****
Yuck...
Sent from my iPad
On 12 Mar 2014, at 18:41, Dave Cooper david.cooper@genworks.com wrote:
On Wed, Mar 12, 2014 at 1:04 PM, Faré fahree@gmail.com wrote:
1- I think we should proceed and add a default path anyway. ~/cl/ and/or ~/common-lisp/ sound fine to me, and I've seen no one complain about that. You could make it ~/local/common-lisp/ if you're into larger paths.
How about providing the following as part of this:
- the option of a control file within that default path, to be able to specify subdirectories to be ignored. So anyone who already happens to have a ~/cl/ with a bunch of inactive subfolders with .asd files can make ~/cl/subdirs-to-exclude.asdc whose contents could be e.g.
("inactive-proj-1" "inactive-proj-2")
- When registering systems in the default location, loudly announce that this is happening, e.g:
Automatically registering .asd systems under ~/cl/...Protip: if you want to exclude certain subdirectories, create file
~/cl/subdirs-to-exclude.asdc containing a list of the subdirectory names to be excluded, e.g. ("inactive-proj-1" "inactive-proj-2")
-- My Best,
Dave Cooper
On Wed, Mar 12, 2014 at 1:41 PM, Dave Cooper david.cooper@genworks.com wrote:
On Wed, Mar 12, 2014 at 1:04 PM, Faré fahree@gmail.com wrote:
1- I think we should proceed and add a default path anyway. ~/cl/ and/or ~/common-lisp/ sound fine to me, and I've seen no one complain about that. You could make it ~/local/common-lisp/ if you're into larger paths.
How about providing the following as part of this:
- the option of a control file within that default path, to be able to
specify subdirectories to be ignored. So anyone who already happens to have a ~/cl/ with a bunch of inactive subfolders with .asd files can make ~/cl/subdirs-to-exclude.asdc whose contents could be e.g.
("inactive-proj-1" "inactive-proj-2")
The source-registry :tree thing already provides for recursive exclusions.
I was thinking: since the :tree searcher already does a painful recursive directory listing, maybe it could recognize files named source-registry.conf or some such, that explain how things are laid out in this directory using :here. Although, this makes the configuration language and search procedure mutually recursive, which is dangerous.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Once a person has killed other people on behalf of an ideology, he becomes rather devoted to it. — John McCarthy
Faré wrote:
On Wed, Mar 12, 2014 at 1:41 PM, Dave Cooper david.cooper@genworks.com wrote:
On Wed, Mar 12, 2014 at 1:04 PM, Faré fahree@gmail.com wrote:
1- I think we should proceed and add a default path anyway. ~/cl/ and/or ~/common-lisp/ sound fine to me, and I've seen no one complain about that. You could make it ~/local/common-lisp/ if you're into larger paths.
I think I will put "asdf" into the pathname, per our earlier discussion, so that we don't step on pre-existing paths.
~/asdf-local-paths/
would work for me.
Squawks sooner rather than later, please.
How about providing the following as part of this:
- the option of a control file within that default path, to be able to
specify subdirectories to be ignored. So anyone who already happens to have a ~/cl/ with a bunch of inactive subfolders with .asd files can make ~/cl/subdirs-to-exclude.asdc whose contents could be e.g.
("inactive-proj-1" "inactive-proj-2")
The source-registry :tree thing already provides for recursive exclusions.
I was thinking: since the :tree searcher already does a painful recursive directory listing, maybe it could recognize files named source-registry.conf or some such, that explain how things are laid out in this directory using :here. Although, this makes the configuration language and search procedure mutually recursive, which is dangerous.
I'm reluctant to add this, versus trying to avoid name collisions, as an extra complexity that will have to be explained in the manual.
Plus it will piss Pascal off! ;-)
Adding that complexity would also mean that we must further delay 3.1.1 release, and it's already pretty darn late.
I'm thinking that this will become 3.2, actually. There are sufficiently many improvements....
Cheers, r
1- I think we should proceed and add a default path anyway. ~/cl/ and/or ~/common-lisp/ sound fine to me, and I've seen no one complain about that. You could make it ~/local/common-lisp/ if you're into larger paths.
I think I will put "asdf" into the pathname, per our earlier discussion, so that we don't step on pre-existing paths.
~/asdf-local-paths/
would work for me.
I really don't like including asdf in the name, especially since other tools than asdf exist and may exist in the future, and will want to share the common-lisp source code hierarchy.
~/local/common-lisp/ has the advantage of being clutter-limiting, XDG-like if not strictly XDG, clean, etc., and just one character longer than your proposal.
~/common-lisp/ is slightly more pretentious, but probably works, too.
~/cl/ is taking a lot of familiarity, and maybe I should keep it my personal configuration rather than a recommended default.
Squawks sooner rather than later, please.
Squawk, squawk!
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org *EULA: By reading or responding to this message you agree that all my stated or unstated opinions are correct.* "EULA" — patent pending.
Faré wrote:
1- I think we should proceed and add a default path anyway.
>>> ~/cl/ and/or ~/common-lisp/ sound fine to me, and I've seen no one >>> complain about that. >>> You could make it ~/local/common-lisp/ if you're into larger paths.
I think I will put "asdf" into the pathname, per our earlier discussion, so that we don't step on pre-existing paths.
~/asdf-local-paths/
would work for me.
I really don't like including asdf in the name, especially since other tools than asdf exist and may exist in the future, and will want to share the common-lisp source code hierarchy.
~/local/common-lisp/ has the advantage of being clutter-limiting, XDG-like if not strictly XDG, clean, etc., and just one character longer than your proposal.
I am less excited about the future and find it more appealing in terms of non-collision, to get "asdf" in the name. But I am willing to be overridden; my preference is weak.
OTOH, I don't like ~/local/common-lisp/ because it seems to me that the "local" pathname component doesn't mean anything. Its XDG-likeness seems to me a hazard -- it can be confused with ".local" and has no corresponding advantage.
Unless someone can convince me there's some useful tree to insert ourselves into, I think the default lisp code directory should be a direct subdirectory of ~, not an indirect one.
Does anyone have an argument for not being at the root?
~/common-lisp/ is slightly more pretentious, but probably works, too.
~/cl/ is taking a lot of familiarity, and maybe I should keep it my personal configuration rather than a recommended default.
These last two have been rejected by Pascal and others for what I feel are good reasons.
Thanks, everyone! I believe this discussion is leading us to a better place....
r
On Wed, Mar 12, 2014 at 3:17 PM, Robert P. Goldman rpgoldman@sift.info wrote:
Faré wrote:
~/local/common-lisp/ has the advantage of being clutter-limiting, XDG-like if not strictly XDG, clean, etc., and just one character longer than your proposal.
I am less excited about the future and find it more appealing in terms of non-collision, to get "asdf" in the name. But I am willing to be overridden; my preference is weak.
The future you may hate your current self if you get "asdf" in that name.
OTOH, I don't like ~/local/common-lisp/ because it seems to me that the "local" pathname component doesn't mean anything. Its XDG-likeness seems to me a hazard -- it can be confused with ".local" and has no corresponding advantage.
Fair enough. I admit I myself use a ~/local/ hierarchy that I manage with stow. I used to do it with /usr/local, but it's hassle to compete with what distributions and/or system administrators sometimes put there (on shared or managed machines).
Unless someone can convince me there's some useful tree to insert ourselves into, I think the default lisp code directory should be a direct subdirectory of ~, not an indirect one.
I think you have a point.
Does anyone have an argument for not being at the root?
Avoid clutter, if many languages each do that.
~/common-lisp/ is slightly more pretentious, but probably works, too.
That would be my preference.
~/cl/ is taking a lot of familiarity, and maybe I should keep it my personal configuration rather than a recommended default.
These last two have been rejected by Pascal and others for what I feel are good reasons.
I thought Pascal has just rejected ~/lisp/ because of his current setup. I haven't seen anyone comment on either ~/common-lisp/ or ~/cl/
I believe that ~/common-lisp/ is the Right Thing™ at this point.
Thanks, everyone! I believe this discussion is leading us to a better place....
Right before the 3.1 release is the perfect time for bikeshedding. Afterwards, it will be too late to say "you can depend on that predicated on #+asdf3.1".
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org One of the greatest discoveries a man makes, one of his great surprises, is to find he can do what he was afraid he couldn't do. — Henry Ford
~/common-lisp/ is slightly more pretentious, but probably works, too.
That would be my preference.
~/cl/ is taking a lot of familiarity, and maybe I should keep it my personal configuration rather than a recommended default.
These last two have been rejected by Pascal and others for what I feel are good reasons.
I thought Pascal has just rejected ~/lisp/ because of his current setup. I haven't seen anyone comment on either ~/common-lisp/ or ~/cl/
I believe that ~/common-lisp/ is the Right Thing™ at this point.
Are you saying that I just got lucky because I happen to be subscribed to this mailing list, but it's ok if other people have to suffer?
For the records, I don't like any of the suggested "default" paths.
Just make this a configuration option. For example, an environment variable, or so, then everybody can choose their own preferred name.
export ASDF_DEFAULT_PATH=~/common-lisp
...and please make this empty by default, so it doesn't mess up anything unless I ask it to do so...
Thanks, Pascal
Pascal Costanza wrote:
~/common-lisp/ is slightly more pretentious, but probably works, too.
That would be my preference.
~/cl/ is taking a lot of familiarity, and maybe I should keep it my personal configuration rather than a recommended default.
These last two have been rejected by Pascal and others for what I feel are good reasons.
I thought Pascal has just rejected ~/lisp/ because of his current setup. I haven't seen anyone comment on either ~/common-lisp/ or ~/cl/
I believe that ~/common-lisp/ is the Right Thing™ at this point.
Are you saying that I just got lucky because I happen to be subscribed to this mailing list, but it's ok if other people have to suffer?
No, I am saying that you correctly pointed out that we should avoid a pathname that people are likely already to be using.
For the records, I don't like any of the suggested "default" paths.
Just make this a configuration option. For example, an environment variable, or so, then everybody can choose their own preferred name.
export ASDF_DEFAULT_PATH=~/common-lisp
...and please make this empty by default, so it doesn't mess up anything unless I ask it to do so...
I'm sorry, but that is not on the table.
We are looking for a solution that will work without any active configuration by the user, beyond "put your system definition here, and you don't have to do anything."
Best, r
: Faré
: p-cos
: rpgoldman
asdf is not a tool for beginners. Beginners will either deal with a bare Common Lisp implementation, or they want to experiment with third-party libraries, in which case they want to use quicklisp these days. Once you need to define your own systems, you're not a beginner anymore, and a good tutorial helps a lot more than any supporting wheels can. It's already hard enough to ensure that asdf doesn't accidentally find systems you don't want it to find, you shouldn't make it even harder.
On top of that, with the proposed scheme, you will create a situation where there are not only two "default" locations for user-defined systems, but three when quicklisp is active. I find it hard to imagine that beginners will find this easy to grasp.
ASDF is a tool for everyone, beginners and experts alike, at least since ASDF2. The ability to just work out of the box yet be configurable by program > user > system, was a strong requirement for ASDF2, and I believe we have been by and large successful at it, despite the complexity (only to be seen by experts).
Yes, you can define your own systems without having to learn all the details of ASDF — or you should be able to. A better default location for code than ~/.local/share/common-lisp/ makes total sense, and I am 100% behind Robert on that. I only apologize for not making it happen as early as ASDF2.
I believe that ~/common-lisp/ is the Right Thing™ at this point.
Are you saying that I just got lucky because I happen to be subscribed to this mailing list, but it's ok if other people have to suffer?
No, I am saying that you correctly pointed out that we should avoid a pathname that people are likely already to be using.
On the other hand, anyone who already has his system configured in any way will have ASDF find his systems where he already configured it, and the defaults only apply for systems not already configured.
The only time a new default will cause a system you don't want to shadow a system you want is if you rely on earlier, lower priority defaults: if Pascal expects some system loaded from /usr/share/common-lisp/source/ but has an outdated copy in ~/lisp/old/ then he's in trouble. Otherwise, not.
Note that some of the XDG default paths were broken from 2.27 to 3.0.2 included (see commit 285a61e before 3.0.2.9), so effective changes in the defaults have happened in the past, and not anyone noticed except a few unhappy Debian users (my apologies to them).
I still believe that ~/common-lisp/ is a much better choice than ~/asdf-local-projects/ or anything.
For the records, I don't like any of the suggested "default" paths.
You don't have to like them. You're a big boy, you can easily override them. You can even use :ignore-inherited-configuration.
Just make this a configuration option. For example, an environment variable, or so, then everybody can choose their own preferred name.
export ASDF_DEFAULT_PATH=~/common-lisp
You can already do that: export CL_SOURCE_REGISTRY=~/common-lisp//
The question is about what defaults should be, for beginners.
...and please make this empty by default, so it doesn't mess up anything unless I ask it to do so...
I'm sorry, but that is not on the table.
We are looking for a solution that will work without any active configuration by the user, beyond "put your system definition here, and you don't have to do anything."
I totally agree with Robert.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Ever wonder why the SAME PEOPLE make up ALL the conspiracy theories?
Can I set CL_SOURCE_REGISTRY to a value that deactivates all "default" paths? Then I don't care what the default is...
Pascal
Sent from my iPad
On 12 Mar 2014, at 22:14, Faré fahree@gmail.com wrote:
: Faré
: p-cos
: rpgoldman
asdf is not a tool for beginners. Beginners will either deal with a bare Common Lisp implementation, or they want to experiment with third-party libraries, in which case they want to use quicklisp these days. Once you need to define your own systems, you're not a beginner anymore, and a good tutorial helps a lot more than any supporting wheels can. It's already hard enough to ensure that asdf doesn't accidentally find systems you don't want it to find, you shouldn't make it even harder.
On top of that, with the proposed scheme, you will create a situation where there are not only two "default" locations for user-defined systems, but three when quicklisp is active. I find it hard to imagine that beginners will find this easy to grasp.
ASDF is a tool for everyone, beginners and experts alike, at least since ASDF2. The ability to just work out of the box yet be configurable by program > user > system, was a strong requirement for ASDF2, and I believe we have been by and large successful at it, despite the complexity (only to be seen by experts).
Yes, you can define your own systems without having to learn all the details of ASDF — or you should be able to. A better default location for code than ~/.local/share/common-lisp/ makes total sense, and I am 100% behind Robert on that. I only apologize for not making it happen as early as ASDF2.
I believe that ~/common-lisp/ is the Right Thing™ at this point.
Are you saying that I just got lucky because I happen to be subscribed to this mailing list, but it's ok if other people have to suffer?
No, I am saying that you correctly pointed out that we should avoid a pathname that people are likely already to be using.
On the other hand, anyone who already has his system configured in any way will have ASDF find his systems where he already configured it, and the defaults only apply for systems not already configured.
The only time a new default will cause a system you don't want to shadow a system you want is if you rely on earlier, lower priority defaults: if Pascal expects some system loaded from /usr/share/common-lisp/source/ but has an outdated copy in ~/lisp/old/ then he's in trouble. Otherwise, not.
Note that some of the XDG default paths were broken from 2.27 to 3.0.2 included (see commit 285a61e before 3.0.2.9), so effective changes in the defaults have happened in the past, and not anyone noticed except a few unhappy Debian users (my apologies to them).
I still believe that ~/common-lisp/ is a much better choice than ~/asdf-local-projects/ or anything.
For the records, I don't like any of the suggested "default" paths.
You don't have to like them. You're a big boy, you can easily override them. You can even use :ignore-inherited-configuration.
Just make this a configuration option. For example, an environment variable, or so, then everybody can choose their own preferred name.
export ASDF_DEFAULT_PATH=~/common-lisp
You can already do that: export CL_SOURCE_REGISTRY=~/common-lisp//
The question is about what defaults should be, for beginners.
...and please make this empty by default, so it doesn't mess up anything unless I ask it to do so...
I'm sorry, but that is not on the table.
We are looking for a solution that will work without any active configuration by the user, beyond "put your system definition here, and you don't have to do anything."
I totally agree with Robert.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Ever wonder why the SAME PEOPLE make up ALL the conspiracy theories?
On Wed, Mar 12, 2014 at 6:07 PM, Pascal Costanza pc@p-cos.net wrote:
Can I set CL_SOURCE_REGISTRY to a value that deactivates all "default" paths? Then I don't care what the default is...
Yes, the example I gave you did that:
export CL_SOURCE_REGISTRY=~/lisp//
As you can see with (asdf::parse-source-registry-string "/home/tunes/lisp//"), it expands to: (:SOURCE-REGISTRY (:TREE "/home/tunes/lisp") (:IGNORE-INHERITED-CONFIGURATION))
The double-slash "//" is significative: it means recurse through the directory.
Those readers who do want to inherit the configuration should just add a colon ":" at the end — or a semi-colon, if using Windows: export CL_SOURCE_REGISTRY=~/lisp//:
Alternatively, you can put this in your ~/.config/common-lisp/source-registry.conf: (:source-registry (:tree (:home "lisp")) :ignore-inherited-configuration)
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Just because your semi-free country government is evil doesn't mean "native" governments have a right to exist and enslave "their" people. — Faré
Faré fahree@gmail.com writes:
On Wed, Mar 12, 2014 at 6:07 PM, Pascal Costanza pc@p-cos.net wrote:
Can I set CL_SOURCE_REGISTRY to a value that deactivates all "default" paths? Then I don't care what the default is...
Yes, the example I gave you did that:
export CL_SOURCE_REGISTRY=~/lisp//
As you can see with (asdf::parse-source-registry-string "/home/tunes/lisp//"), it expands to: (:SOURCE-REGISTRY (:TREE "/home/tunes/lisp") (:IGNORE-INHERITED-CONFIGURATION))
The double-slash "//" is significative: it means recurse through the directory.
Those readers who do want to inherit the configuration should just add a colon ":" at the end — or a semi-colon, if using Windows: export CL_SOURCE_REGISTRY=~/lisp//:
Alternatively, you can put this in your ~/.config/common-lisp/source-registry.conf: (:source-registry (:tree (:home "lisp")) :ignore-inherited-configuration)
Instructions like these are one of the reasons I have been unable to make or recommend regular use of the source registry configuration system.
Zach
On Wed, Mar 12, 2014 at 7:24 PM, Zach Beane xach@xach.com wrote:
Faré fahree@gmail.com writes:
On Wed, Mar 12, 2014 at 6:07 PM, Pascal Costanza pc@p-cos.net wrote:
Can I set CL_SOURCE_REGISTRY to a value that deactivates all "default" paths? Then I don't care what the default is...
Yes, the example I gave you did that:
export CL_SOURCE_REGISTRY=~/lisp//
As you can see with (asdf::parse-source-registry-string "/home/tunes/lisp//"), it expands to: (:SOURCE-REGISTRY (:TREE "/home/tunes/lisp") (:IGNORE-INHERITED-CONFIGURATION))
The double-slash "//" is significative: it means recurse through the directory.
Those readers who do want to inherit the configuration should just add a colon ":" at the end — or a semi-colon, if using Windows: export CL_SOURCE_REGISTRY=~/lisp//:
Alternatively, you can put this in your ~/.config/common-lisp/source-registry.conf: (:source-registry (:tree (:home "lisp")) :ignore-inherited-configuration)
Instructions like these are one of the reasons I have been unable to make or recommend regular use of the source registry configuration system.
You could also mkdir -p ~/.config/common-lisp/ echo ""$HOME/lisp//"" > ~/.config/common-lisp/source-registry.conf
I don't know what kind of instructions you want.
Having good defaults is precisely what makes such instructions superfluous for beginners, and why Robert wants to define a better default location for code than currently used.
Having instructions is still necessary for people who want to override the defaults — and anyone who wants to release software built in a controlled repeatable way needs understand how to do that.
If you have a better design to offer, I'm sure Robert is listening.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Verbal constructs of above-average phonemic quantity implement the qualitative actualization of cognitive disenlightenment. (Big words obscure meaning.)
Sent from my iPad
On 12 Mar 2014, at 23:39, Faré fahree@gmail.com wrote:
On Wed, Mar 12, 2014 at 6:07 PM, Pascal Costanza pc@p-cos.net wrote: Can I set CL_SOURCE_REGISTRY to a value that deactivates all "default" paths? Then I don't care what the default is...
Yes, the example I gave you did that:
export CL_SOURCE_REGISTRY=~/lisp//
As you can see with (asdf::parse-source-registry-string "/home/tunes/lisp//"), it expands to: (:SOURCE-REGISTRY (:TREE "/home/tunes/lisp") (:IGNORE-INHERITED-CONFIGURATION))
The double-slash "//" is significative: it means recurse through the directory.
Erm what? Do you or do you not recur with this syntax?
Those readers who do want to inherit the configuration should just add a colon ":" at the end — or a semi-colon, if using Windows: export CL_SOURCE_REGISTRY=~/lisp//:
What does "inheriting a configuration" mean?
Alternatively, you can put this in your ~/.config/common-lisp/source-registry.conf: (:source-registry (:tree (:home "lisp")) :ignore-inherited-configuration)
I'm confused. Which of those options does what I want?
Why can't I just say something like this?
export CL_SOURCE_REGISTRY=
or something similar, which just leaves this setting empty?
Pascal
I've open the following bug on launchpad for this issue: A non-hidden default source tree https://bugs.launchpad.net/asdf/+bug/1293278
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A programming language is low level when its programs require attention to the irrelevant. — Alan Perlis
On Wed, 12 Mar 2014, Robert P. Goldman wrote:
~/asdf-local-paths/
would work for me.
Squawks sooner rather than later, please.
If we are decided on adding a default path, please make it consistent with the other XDG stuff in ASDF...
I'm not XDG guru, but here's a link to the standard...
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
It looks like default paths would belong under $XDG_DATA_HOME and $XDG_DATA_DIRS.
Looking at the current ASDF manual, it appears that there is already some support for this concept?
http://common-lisp.net/project/asdf/asdf.html#Controlling-where-ASDF-searche...
"" The source registry will be configured from a default configuration. This configuration may allow for implementation-specific systems to be found, for systems to be found the current directory (at the time that the configuration is initialized) as well as :directory entries for $XDG_DATA_DIRS/common-lisp/systems/ and :tree entries for $XDG_DATA_DIRS/common-lisp/source/. For instance, SBCL will include directories for its contribs when it can find them; it will look for them where SBCL was installed, or at the location specified by the SBCL_HOME environment variable ""
Later, Daniel
I am sorry, but I promise you that this will NOT be consistent with XDG. I have no idea why those people think it's a good idea to put files in directories where ls cannot find them.
ASDF already has a deeply-nested, invisible-to-ls location that is XDG compliant where you can put your files if that's what floats your boat.
It was writing a description of where to put your files in this XDG-compliant location that convinced me that we needed an alternative that was obvious and easily accessible.
In case you haven't guessed, I'm not a fan of this standard! :-)
On March 12, 2014 10:10:20 PM CDT, Daniel Herring dherring@tentpost.com wrote:
On Wed, 12 Mar 2014, Robert P. Goldman wrote:
~/asdf-local-paths/
would work for me.
Squawks sooner rather than later, please.
If we are decided on adding a default path, please make it consistent with the other XDG stuff in ASDF...
I'm not XDG guru, but here's a link to the standard...
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
It looks like default paths would belong under $XDG_DATA_HOME and $XDG_DATA_DIRS.
Looking at the current ASDF manual, it appears that there is already some support for this concept?
http://common-lisp.net/project/asdf/asdf.html#Controlling-where-ASDF-searche...
"" The source registry will be configured from a default configuration. This configuration may allow for implementation-specific systems to be found, for systems to be found the current directory (at the time that the configuration is initialized) as well as :directory entries for $XDG_DATA_DIRS/common-lisp/systems/ and :tree entries for $XDG_DATA_DIRS/common-lisp/source/. For instance, SBCL will include directories for its contribs when it can find them; it will look for them where SBCL was installed, or at the location specified by the SBCL_HOME
environment variable ""
Later, Daniel
On Wed, 12 Mar 2014, Robert P. Goldman wrote:
I am sorry, but I promise you that this will NOT be consistent with XDG. I have no idea why those people think it's a good idea to put files in directories where ls cannot find them.
ASDF already has a deeply-nested, invisible-to-ls location that is XDG compliant where you can put your files if that's what floats your boat.
It was writing a description of where to put your files in this XDG-compliant location that convinced me that we needed an alternative that was obvious and easily accessible.
In case you haven't guessed, I'm not a fan of this standard! :-)
I would agree that XDG is over-engineered and under-specified.
However, ls finds dot files just fine (alias ls="ls -A" if it helps), and "normal users" usually install programs in "system directories", not their home directory.
Given the current CL ecosystem, things are constantly changing, implementations provide little fasl compatibility, CL installs are often per-user, etc. Thus the current best default for sources is in $HOME. I would argue that the use of $HOME is the real problem, and "hiding" things is the right solution for users (as opposed to developers who can be expected to memorize a slightly obscure path).
Two default paths is not better than one.
There is a reason MS Windows has "hide system files" enabled by default. Some things are too complicated for "casual users", and an obscure "~/common-lisp" is just asking for grandma to delete the folder she "doesn't want"...
In systems like OS-X-style "disk images" and Java-style jarfiles, the entire application is self-contained. Thus it is quite appropriate for the full path to be user-visible, for deleting the file is uninstalling the app.
- Daniel
P.S. In case I've gone off-kilter, I promise to get some sleep before any further replies.
: rpgoldman
: dherring
I am sorry, but I promise you that this will NOT be consistent with XDG. I have no idea why those people think it's a good idea to put files in directories where ls cannot find them.
ASDF already has a deeply-nested, invisible-to-ls location that is XDG compliant where you can put your files if that's what floats your boat.
Given the current CL ecosystem, things are constantly changing, implementations provide little fasl compatibility, CL installs are often per-user, etc. Thus the current best default for sources is in $HOME. I would argue that the use of $HOME is the real problem, and "hiding" things is the right solution for users (as opposed to developers who can be expected to memorize a slightly obscure path).
Two default paths is not better than one.
There is a reason MS Windows has "hide system files" enabled by default. Some things are too complicated for "casual users", and an obscure "~/common-lisp" is just asking for grandma to delete the folder she "doesn't want"...
In systems like OS-X-style "disk images" and Java-style jarfiles, the entire application is self-contained. Thus it is quite appropriate for the full path to be user-visible, for deleting the file is uninstalling the app.
I believe that there are different kinds of users, and that ASDF should provide sensible defaults for all of them.
On the one hand, there are hypothetical end-users of software written in CL. For these users, who don't program, and don't want to see the Lisp source, the XDG standard makes perfect sense, and we already support it.
On the other hand, there are also low-commitment programmers, who may be beginners or occasional members of the community, and who would like a simple no-configuration way of hacking code without having to deal with magic invisible XDG paths. For them, a ~/common-lisp/ is perfect; it would also play the role of ~/quicklisp/local-projects or whatever.
Once again, if someone already has a ~/common-lisp/, it should not matter too much, since the default only applies after whatever they explicitly configured, and only shadows other lower-priority defaults — and if it does affect them, they can easily configure ASDF to skip this default.
A small pain for a handful of hypothetical current users, a nice gain for all future users.
As for self-contained apps, you can already do that: just have your start script (either Lisp code or shell wrapper) properly configure the source-registry. Actually, any release engineer worth his grain will make sure his builds are self-contained and reproducible, built from well-versioned compilers, etc.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Language is froth on the surface of thought. — John McCarthy
I get all you're saying, but I don't think it's relevant. This is for people who want to WRITE code, so hiding their code from them in a config directory doesn't make sense.
I'm fine with putting config files in those hidden directories(although I feel compelled to say that XDG makes that you complicated), but not source code that people want to edit. People shouldn't have to play ls -a hide and seek to find their own source code...
On March 12, 2014 11:20:23 PM CDT, Daniel Herring dherring@tentpost.com wrote:
On Wed, 12 Mar 2014, Robert P. Goldman wrote:
I am sorry, but I promise you that this will NOT be consistent with
XDG. I have no idea why those people think it's a good idea to put files in directories where ls cannot find them.
ASDF already has a deeply-nested, invisible-to-ls location that is
XDG compliant where you can put your files if that's what floats your boat.
It was writing a description of where to put your files in this
XDG-compliant location that convinced me that we needed an alternative that was obvious and easily accessible.
In case you haven't guessed, I'm not a fan of this standard! :-)
I would agree that XDG is over-engineered and under-specified.
However, ls finds dot files just fine (alias ls="ls -A" if it helps), and "normal users" usually install programs in "system directories", not their home directory.
Given the current CL ecosystem, things are constantly changing, implementations provide little fasl compatibility, CL installs are often per-user, etc. Thus the current best default for sources is in $HOME. I would argue that the use of $HOME is the real problem, and "hiding" things is the right solution for users (as opposed to developers who can be expected to memorize a slightly obscure path).
Two default paths is not better than one.
There is a reason MS Windows has "hide system files" enabled by default. Some things are too complicated for "casual users", and an obscure "~/common-lisp" is just asking for grandma to delete the folder she "doesn't want"...
In systems like OS-X-style "disk images" and Java-style jarfiles, the entire application is self-contained. Thus it is quite appropriate for
the full path to be user-visible, for deleting the file is uninstalling
the app.
- Daniel
P.S. In case I've gone off-kilter, I promise to get some sleep before any further replies.
Daniel Herring wrote:
In systems like OS-X-style "disk images" and Java-style jarfiles, the entire application is self-contained. Thus it is quite appropriate for the full path to be user-visible, for deleting the file is uninstalling the app.
FWIW, Faré's new bundle operations begin to give support for this kind of thing.
I still don't feel that ASDF is a *user* tool at all; only a programmer tool. Except to the extent that a programmer is a user of libraries.
Best, r
Seriously, my source code is not config data, so IMO the XDG standard has nothing to say about where it's placed. Unlike the case for config files.
If my source code is to be hidden from me in a config directory what, pray tell is my home directory for?
On March 12, 2014 10:10:20 PM CDT, Daniel Herring dherring@tentpost.com wrote:
On Wed, 12 Mar 2014, Robert P. Goldman wrote:
~/asdf-local-paths/
would work for me.
Squawks sooner rather than later, please.
If we are decided on adding a default path, please make it consistent with the other XDG stuff in ASDF...
I'm not XDG guru, but here's a link to the standard...
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
It looks like default paths would belong under $XDG_DATA_HOME and $XDG_DATA_DIRS.
Looking at the current ASDF manual, it appears that there is already some support for this concept?
http://common-lisp.net/project/asdf/asdf.html#Controlling-where-ASDF-searche...
"" The source registry will be configured from a default configuration. This configuration may allow for implementation-specific systems to be found, for systems to be found the current directory (at the time that the configuration is initialized) as well as :directory entries for $XDG_DATA_DIRS/common-lisp/systems/ and :tree entries for $XDG_DATA_DIRS/common-lisp/source/. For instance, SBCL will include directories for its contribs when it can find them; it will look for them where SBCL was installed, or at the location specified by the SBCL_HOME
environment variable ""
Later, Daniel
The source-registry :tree thing already provides for recursive exclusions.
Ok good. Then how about having ASDF loudly announce that it is registering the default directory (e.g. ~/cl/), as well as providing the hint about using a .conf file with the right syntax with :tree, if the user wants to exclude certain subdirectories.
The goal here is to make the addition of the default registry directory as painless and surprise-free as possible for anyone who already happens to have stuff floating around in the new default directory.
Dave Cooper wrote:
The goal here is to make the addition of the default registry directory as painless and surprise-free as possible for anyone who already happens to have stuff floating around in the new default directory.
No, that would be the *subsidiary* goal.
The *primary* goal will be to make the probability of someone already having stuff floating around in the new default directory as close to zero as possible while still having a directory name that is easy to type!
Dave Cooper david.cooper@genworks.com writes:
The source-registry :tree thing already provides for recursive exclusions.
Ok good. Then how about having ASDF loudly announce that it is registering the default directory (e.g. ~/cl/), as well as providing the hint about using a .conf file with the right syntax with :tree, if the user wants to exclude certain subdirectories.
The goal here is to make the addition of the default registry directory as painless and surprise-free as possible for anyone who already happens to have stuff floating around in the new default directory.
I don't think I want to read loud announcements from ASDF. If it isn't acting like I want, I'd rather read about how to make it do what I want in a tutorial or manual.
Zach
On Wed, Mar 12, 2014 at 2:05 PM, Zach Beane xach@xach.com wrote:
I don't think I want to read loud announcements from ASDF. If it isn't
acting like I want, I'd rather read about how to make it do what I want in a tutorial or manual.
Loud announcement only in the initial ASDF release when the new default directory is first introduced. In subsequent ASDF releases the announcement would go away.
Dave
Dave Cooper david.cooper@genworks.com writes:
On Wed, Mar 12, 2014 at 2:05 PM, Zach Beane xach@xach.com wrote:
I don't think I want to read loud announcements from ASDF. If it isn't
acting like I want, I'd rather read about how to make it do what I want in a tutorial or manual.
Loud announcement only in the initial ASDF release when the new default directory is first introduced. In subsequent ASDF releases the announcement would go away.
I don't think it's a suitable way to communicate with me, even if it only happens for a certain period of time.
Zach
On Wed, Mar 12, 2014 at 2:25 PM, Zach Beane xach@xach.com wrote:
Dave Cooper david.cooper@genworks.com writes:
On Wed, Mar 12, 2014 at 2:05 PM, Zach Beane xach@xach.com wrote:
I don't think I want to read loud announcements from ASDF. If it isn't
acting like I want, I'd rather read about how to make it do what I want in a tutorial or manual.
Loud announcement only in the initial ASDF release when the new default directory is first introduced. In subsequent ASDF releases the announcement would go away.
I don't think it's a suitable way to communicate with me, even if it only happens for a certain period of time.
I'm not sure what way of communicating you recommend, for changes in default behavior of ASDF or recommended practice in using it.
Major changes like that happen less than once a year (ASDF 2 in 2010, ASDF 3 in 2013, ASDF 3.1 soon in 2014), and while backward-compatibility has always been a huge priority, improvements sometimes do mean the recommended way of using ASDF changes, for the better.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Clothes make the man. Naked people have little or no influence on society. — Mark Twain
Faré fahree@gmail.com writes:
On Wed, Mar 12, 2014 at 2:25 PM, Zach Beane xach@xach.com wrote:
Dave Cooper david.cooper@genworks.com writes:
On Wed, Mar 12, 2014 at 2:05 PM, Zach Beane xach@xach.com wrote:
I don't think I want to read loud announcements from ASDF. If it isn't
acting like I want, I'd rather read about how to make it do what I want in a tutorial or manual.
Loud announcement only in the initial ASDF release when the new default directory is first introduced. In subsequent ASDF releases the announcement would go away.
I don't think it's a suitable way to communicate with me, even if it only happens for a certain period of time.
I'm not sure what way of communicating you recommend, for changes in default behavior of ASDF or recommended practice in using it.
I'd like to see the behavior clearly documented in the manual and explained in a release announcement or blog post or tutorial or all of the above.
I don't want the software to print extra things out during some transition period.
Zach
On Wed, Mar 12, 2014 at 3:08 PM, Zach Beane xach@xach.com wrote:
Faré fahree@gmail.com writes:
On Wed, Mar 12, 2014 at 2:25 PM, Zach Beane xach@xach.com wrote:
Dave Cooper david.cooper@genworks.com writes:
On Wed, Mar 12, 2014 at 2:05 PM, Zach Beane xach@xach.com wrote:
I don't think I want to read loud announcements from ASDF. If it isn't
acting like I want, I'd rather read about how to make it do what I want in a tutorial or manual.
Loud announcement only in the initial ASDF release when the new default directory is first introduced. In subsequent ASDF releases the announcement would go away.
I don't think it's a suitable way to communicate with me, even if it only happens for a certain period of time.
I'm not sure what way of communicating you recommend, for changes in default behavior of ASDF or recommended practice in using it.
I'd like to see the behavior clearly documented in the manual and explained in a release announcement or blog post or tutorial or all of the above.
I don't want the software to print extra things out during some transition period.
Oh wait, you're right, I hadn't realized that Dave had proposed ASDF printing a message at runtime.
Indeed, it's a bug for ASDF to announce anything at runtime, unless verbosity is explicitly required and/or a warning or error happens. The test suite actually includes a test-clean-load target that fails if loading ASDF emits any information. A TODO item would be to also test that using ASDF produces no output.
I thought the "loud" announcement under discussion was to happen in the manual and release notes and while releasing the software — the usual procedure, just "louder" than usual due to major changes (yet still maintaining backward compatibility).
My apologies for the misunderstanding.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Every technique is first developed, then used, important, obsolete, normalized, and finally understood.
On Wed, 12 Mar 2014, Faré wrote:
Major changes like that happen less than once a year (ASDF 2 in 2010, ASDF 3 in 2013, ASDF 3.1 soon in 2014), and while backward-compatibility has always been a huge priority, improvements sometimes do mean the recommended way of using ASDF changes, for the better.
For essential infrastructure like what ASDF claims to be, I expect major changes to happen less than once every 5 to 10 years. The more backwards compatibility, the better. Projects like glibc have developed significant infrastructure to enable transparent improvements (see the ABI compliance checker, DSO symbol versioning, etc.).
Every breaking change inflicts cost on a fraction of the existing userbase, in exchange for some proposed benefit to future users. Every time I have to debug breakage and change something or redesign my workflow to maintain existing capability, it encourages me to explore other, more stable or better designed options...
Sometimes "good ideas" fade after a month or two of reflection. Some survive the test because the benefit truly outweighs the cost. When that is the case, it is often helps to give the community time to prepare and minimize the number of times the community must change. So propose the change, allow a long RFC window, allow users to obtain test implementations (while still promoting the stable branch), wait a while for several changes to collect before pushing them into major new releases, etc.
- Daniel
On Wed, 2014-03-12 at 23:30 -0400, Daniel Herring wrote:
On Wed, 12 Mar 2014, Faré wrote:
Major changes like that happen less than once a year (ASDF 2 in 2010, ASDF 3 in 2013, ASDF 3.1 soon in 2014), and while backward-compatibility has always been a huge priority, improvements sometimes do mean the recommended way of using ASDF changes, for the better.
For essential infrastructure like what ASDF claims to be, I expect major changes to happen less than once every 5 to 10 years.
You can expect whatever you want, but unless somebody is paid full-time to work on ASDF, it's not going to happen.
The more backwards compatibility, the better. Projects like glibc have developed significant infrastructure to enable transparent improvements (see the ABI compliance checker, DSO symbol versioning, etc.).
See above. That kind of backwards-compatibility is very difficult and burdensome.
Every breaking change inflicts cost on a fraction of the existing userbase, in exchange for some proposed benefit to future users. Every time I have to debug breakage and change something or redesign my workflow to maintain existing capability, it encourages me to explore other, more stable or better designed options...
Sometimes "good ideas" fade after a month or two of reflection. Some survive the test because the benefit truly outweighs the cost. When that is the case, it is often helps to give the community time to prepare and minimize the number of times the community must change. So propose the change, allow a long RFC window, allow users to obtain test implementations (while still promoting the stable branch), wait a while for several changes to collect before pushing them into major new releases, etc.
I agree that an RFC-like process would be useful, instead of jumping in and implementing new features, as long as it's not too lengthy.
Stelian Ionescu wrote:
On Wed, 2014-03-12 at 23:30 -0400, Daniel Herring wrote:
On Wed, 12 Mar 2014, Faré wrote:
Major changes like that happen less than once a year (ASDF 2 in 2010, ASDF 3 in 2013, ASDF 3.1 soon in 2014), and while backward-compatibility has always been a huge priority, improvements sometimes do mean the recommended way of using ASDF changes, for the better.
For essential infrastructure like what ASDF claims to be, I expect major changes to happen less than once every 5 to 10 years.
You can expect whatever you want, but unless somebody is paid full-time to work on ASDF, it's not going to happen.
Agreed. Tell me: am I to piss our contributors off by refusing to accept their patches, in order to make happy the people who contribute only complaints? New features may simply be the price users pay to have bugs getting fixed.
The more backwards compatibility, the better. Projects like glibc have developed significant infrastructure to enable transparent improvements (see the ABI compliance checker, DSO symbol versioning, etc.).
See above. That kind of backwards-compatibility is very difficult and burdensome.
We spend a great deal of time maintaining backwards compatibility. Consider how much work was spent making the bug-fix coming from PREPARE-OP from breaking previous OPERATION subclasses. Similarly, as someone who still uses ASDF:*CENTRAL-REGISTRY*, maintaining that is substantial backwards compatibility.
I find this complaint to be quite unfair considering what actually goes on in the maintenance of ASDF.
Every breaking change inflicts cost on a fraction of the existing userbase, in exchange for some proposed benefit to future users. Every time I have to debug breakage and change something or redesign my workflow to maintain existing capability, it encourages me to explore other, more stable or better designed options...
Sometimes "good ideas" fade after a month or two of reflection. Some survive the test because the benefit truly outweighs the cost. When that is the case, it is often helps to give the community time to prepare and minimize the number of times the community must change. So propose the change, allow a long RFC window, allow users to obtain test implementations (while still promoting the stable branch), wait a while for several changes to collect before pushing them into major new releases, etc.
I agree that an RFC-like process would be useful, instead of jumping in and implementing new features, as long as it's not too lengthy.
It has, in fact, been a long time since ASDF's last release, October 2013. During that time, there have been a very large number of tagged versions available to the community.
I don't think that this community can afford the time, nor can it muster the interest, to deal with such an RFC process.
Furthermore, I don't find people stumbling over each other to install ASDF prereleases from git and report bugs they find. So who exactly is going to be participating in this RFC process? And who is going to be testing these prereleases? We have quite a small community of testers, to whom I am very, very grateful.
Yours sincerely, R
On Thu, 2014-03-13 at 11:34 -0500, Robert P. Goldman wrote:
Stelian Ionescu wrote:
On Wed, 2014-03-12 at 23:30 -0400, Daniel Herring wrote:
On Wed, 12 Mar 2014, Faré wrote:
Major changes like that happen less than once a year (ASDF 2 in 2010, ASDF 3 in 2013, ASDF 3.1 soon in 2014), and while backward-compatibility has always been a huge priority, improvements sometimes do mean the recommended way of using ASDF changes, for the better.
For essential infrastructure like what ASDF claims to be, I expect major changes to happen less than once every 5 to 10 years.
You can expect whatever you want, but unless somebody is paid full-time to work on ASDF, it's not going to happen.
Agreed. Tell me: am I to piss our contributors off by refusing to accept their patches, in order to make happy the people who contribute only complaints? New features may simply be the price users pay to have bugs getting fixed.
The "force vs force-not" message is a good example. A feature was added at the request of a user without considering all the use cases and now we discover that it's poorly thought out. When you say "this has always been my impression...", it means that nobody ever even wrote down a rationale for that new feature so you don't *know*, you have impressions.
The more backwards compatibility, the better. Projects like glibc have developed significant infrastructure to enable transparent improvements (see the ABI compliance checker, DSO symbol versioning, etc.).
See above. That kind of backwards-compatibility is very difficult and burdensome.
We spend a great deal of time maintaining backwards compatibility. Consider how much work was spent making the bug-fix coming from PREPARE-OP from breaking previous OPERATION subclasses. Similarly, as someone who still uses ASDF:*CENTRAL-REGISTRY*, maintaining that is substantial backwards compatibility.
The backwards-compatibility is not complete, though. When we're talking about glibc, we're talking about versioning functions and keeping the old entry points bug-to-bug compatible for ever while the new version of that function is simply an addition. Issuing a warning that OPERATION is being directly subclassed is not backwards-compatibility.
I find this complaint to be quite unfair considering what actually goes on in the maintenance of ASDF.
Every breaking change inflicts cost on a fraction of the existing userbase, in exchange for some proposed benefit to future users. Every time I have to debug breakage and change something or redesign my workflow to maintain existing capability, it encourages me to explore other, more stable or better designed options...
Sometimes "good ideas" fade after a month or two of reflection. Some survive the test because the benefit truly outweighs the cost. When that is the case, it is often helps to give the community time to prepare and minimize the number of times the community must change. So propose the change, allow a long RFC window, allow users to obtain test implementations (while still promoting the stable branch), wait a while for several changes to collect before pushing them into major new releases, etc.
I agree that an RFC-like process would be useful, instead of jumping in and implementing new features, as long as it's not too lengthy.
It has, in fact, been a long time since ASDF's last release, October 2013. During that time, there have been a very large number of tagged versions available to the community.
I don't think that this community can afford the time, nor can it muster the interest, to deal with such an RFC process.
What "community" ?
Furthermore, I don't find people stumbling over each other to install ASDF prereleases from git and report bugs they find.
I'm not talking about mundane compatibility problems with pathnames, but design choices that will affect everybody that uses ASDF in production, for deployments and writes ASDF extensions. Most of the time there isn't even an announcement that a new feature was added, like a new keyarg to defsystem, etc...
So who exactly is going to be participating in this RFC process?
I, for one.
And who is going to be testing these prereleases? We have quite a small community of testers, to whom I am very, very grateful.
I've done a lot of testing on my own stuff and reported quite a lot of bugs to Faré in the past.
Stelian Ionescu wrote:
Issuing a warning that OPERATION is being directly subclassed is not backwards-compatibility.
For the record, that is NOT the solution that has been pushed.
Instead, after a lot of discussion from Faré, Anton, and others, we developed a solution that preserved the function of old OPERATION subclasses.
The solution in the current version *is* backwards-compatibility, and is not limited to issuing a warning.
Regards,
R
: dherring
: sionescu
: rpgoldman
: sionescu
For essential infrastructure like what ASDF claims to be, I expect major changes to happen less than once every 5 to 10 years.
Daniel, if you want changes only every 5 to 10 years, do like janderson: try an upgrade every 5 years, find that it breaks your code somehow and downgrade back to the old version without further investigation. Then maybe 10 years from now you'll get the system dependency bug fixed.
You can expect whatever you want, but unless somebody is paid full-time to work on ASDF, it's not going to happen.
Agreed. Tell me: am I to piss our contributors off by refusing to accept their patches, in order to make happy the people who contribute only complaints? New features may simply be the price users pay to have bugs getting fixed.
The "force vs force-not" message is a good example. A feature was added at the request of a user without considering all the use cases and now we discover that it's poorly thought out. When you say "this has always been my impression...", it means that nobody ever even wrote down a rationale for that new feature so you don't *know*, you have impressions.
force and force-not were done well. The interaction between the two was not well thought out, but obviously no one relied on the interaction before force-not was implemented, so that was backward compatible, and the recent change keeps the previously useful uses working, so it is arguably, too.
It's not like my changes were done in secret. I did it and explained what I did, and even mentioned at the time I didn't understand which setting should take precedence over the other. I only apologize for not understanding then the objection by Robert, though he also didn't care enough to submit a patch, and no one else even complained.
The more backwards compatibility, the better. Projects like glibc have developed significant infrastructure to enable transparent improvements (see the ABI compliance checker, DSO symbol versioning, etc.).
See above. That kind of backwards-compatibility is very difficult and burdensome.
We spend a great deal of time maintaining backwards compatibility. Consider how much work was spent making the bug-fix coming from PREPARE-OP from breaking previous OPERATION subclasses. Similarly, as someone who still uses ASDF:*CENTRAL-REGISTRY*, maintaining that is substantial backwards compatibility.
The backwards-compatibility is not complete, though. When we're talking about glibc, we're talking about versioning functions and keeping the old entry points bug-to-bug compatible for ever while the new version of that function is simply an addition. Issuing a warning that OPERATION is being directly subclassed is not backwards-compatibility.
We do care about backward compatibility, a lot. Yes, there are sometimes bugs in our backward-compatibility support. And then we painfully fix them, as in the case of OPERATION above. Are we perfect? No. Do we have symbol versioning for backwarder compatibility? No. The libc has additional issues and solutions because it's all about binary compatibility. We do not offer binary compatibility. We offer source compatibility. We consider binary compatibility is backward.
Every breaking change inflicts cost on a fraction of the existing userbase, in exchange for some proposed benefit to future users. Every time I have to debug breakage and change something or redesign my workflow to maintain existing capability, it encourages me to explore other, more stable or better designed options...
Sometimes "good ideas" fade after a month or two of reflection. Some survive the test because the benefit truly outweighs the cost. When that is the case, it is often helps to give the community time to prepare and minimize the number of times the community must change. So propose the change, allow a long RFC window, allow users to obtain test implementations (while still promoting the stable branch), wait a while for several changes to collect before pushing them into major new releases, etc.
I agree that an RFC-like process would be useful, instead of jumping in and implementing new features, as long as it's not too lengthy.
It has, in fact, been a long time since ASDF's last release, October 2013. During that time, there have been a very large number of tagged versions available to the community.
I don't think that this community can afford the time, nor can it muster the interest, to deal with such an RFC process.
What "community" ?
If someone wants a RFC process, he's welcome to write a specification for ASDF that all the currently documented or undocumented features implicitly relied upon by every piece of software in Quicklisp, and develop an independent reimplementation of ASDF based on that specification.
Now I'll be the one laughing, and even more so if the RFC gets to also specify all the backward compatibility "features" of ASDF.
For a start, I propose you try to RFCize quick-build, with which asdf-package-system is compatible — here you've already got two independent implementations of the same thing (three, if you count faslpath, after changing the separator from "." to "/"), and the implementations are both around a hundred lines of code only. Only the root registration protocols differ. If you can't standardize that, don't even dream of standardizing the rest of ASDF.
Furthermore, I don't find people stumbling over each other to install ASDF prereleases from git and report bugs they find.
I'm not talking about mundane compatibility problems with pathnames, but design choices that will affect everybody that uses ASDF in production, for deployments and writes ASDF extensions. Most of the time there isn't even an announcement that a new feature was added, like a new keyarg to defsystem, etc...
Every release comes with release notes that mention changes to the API. I haven't announced changes with every commit, because that would be verbose, and people who're interested can already read the git log.
Design choices are being discussed here, but only the small details lead to bikeshedding discussions like the recent flurry of messages. When there's a serious design choice, either no one replies, or it's a discussion between Robert and I, usually, though I readily admit you (Stelian) have sometimes contributed key ideas.
And who is going to be testing these prereleases? We have quite a small community of testers, to whom I am very, very grateful.
I've done a lot of testing on my own stuff and reported quite a lot of bugs to Faré in the past.
Yes, and I am grateful to you (Stelian), who indeed in IRC (and live! and launchpad) discussions contributed a lot to ASDF.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The highest of minds / Often have built for themselves / The tallest of jails.
I smell a need for a CDR, c'nest pas?
Tersely pecked on my iPad
On Mar 13, 2014, at 18:42, Faré fahree@gmail.com wrote:
: dherring
: sionescu
: rpgoldman
: sionescu
For essential infrastructure like what ASDF claims to be, I expect major changes to happen less than once every 5 to 10 years.
Daniel, if you want changes only every 5 to 10 years, do like janderson: try an upgrade every 5 years, find that it breaks your code somehow and downgrade back to the old version without further investigation. Then maybe 10 years from now you'll get the system dependency bug fixed.
You can expect whatever you want, but unless somebody is paid full-time to work on ASDF, it's not going to happen.
Agreed. Tell me: am I to piss our contributors off by refusing to accept their patches, in order to make happy the people who contribute only complaints? New features may simply be the price users pay to have bugs getting fixed.
The "force vs force-not" message is a good example. A feature was added at the request of a user without considering all the use cases and now we discover that it's poorly thought out. When you say "this has always been my impression...", it means that nobody ever even wrote down a rationale for that new feature so you don't *know*, you have impressions.
force and force-not were done well. The interaction between the two was not well thought out, but obviously no one relied on the interaction before force-not was implemented, so that was backward compatible, and the recent change keeps the previously useful uses working, so it is arguably, too.
It's not like my changes were done in secret. I did it and explained what I did, and even mentioned at the time I didn't understand which setting should take precedence over the other. I only apologize for not understanding then the objection by Robert, though he also didn't care enough to submit a patch, and no one else even complained.
The more backwards compatibility, the better. Projects like glibc have developed significant infrastructure to enable transparent improvements (see the ABI compliance checker, DSO symbol versioning, etc.).
See above. That kind of backwards-compatibility is very difficult and burdensome.
We spend a great deal of time maintaining backwards compatibility. Consider how much work was spent making the bug-fix coming from PREPARE-OP from breaking previous OPERATION subclasses. Similarly, as someone who still uses ASDF:*CENTRAL-REGISTRY*, maintaining that is substantial backwards compatibility.
The backwards-compatibility is not complete, though. When we're talking about glibc, we're talking about versioning functions and keeping the old entry points bug-to-bug compatible for ever while the new version of that function is simply an addition. Issuing a warning that OPERATION is being directly subclassed is not backwards-compatibility.
We do care about backward compatibility, a lot. Yes, there are sometimes bugs in our backward-compatibility support. And then we painfully fix them, as in the case of OPERATION above. Are we perfect? No. Do we have symbol versioning for backwarder compatibility? No. The libc has additional issues and solutions because it's all about binary compatibility. We do not offer binary compatibility. We offer source compatibility. We consider binary compatibility is backward.
Every breaking change inflicts cost on a fraction of the existing userbase, in exchange for some proposed benefit to future users. Every time I have to debug breakage and change something or redesign my workflow to maintain existing capability, it encourages me to explore other, more stable or better designed options...
Sometimes "good ideas" fade after a month or two of reflection. Some survive the test because the benefit truly outweighs the cost. When that is the case, it is often helps to give the community time to prepare and minimize the number of times the community must change. So propose the change, allow a long RFC window, allow users to obtain test implementations (while still promoting the stable branch), wait a while for several changes to collect before pushing them into major new releases, etc.
I agree that an RFC-like process would be useful, instead of jumping in and implementing new features, as long as it's not too lengthy.
It has, in fact, been a long time since ASDF's last release, October 2013. During that time, there have been a very large number of tagged versions available to the community.
I don't think that this community can afford the time, nor can it muster the interest, to deal with such an RFC process.
What "community" ?
If someone wants a RFC process, he's welcome to write a specification for ASDF that all the currently documented or undocumented features implicitly relied upon by every piece of software in Quicklisp, and develop an independent reimplementation of ASDF based on that specification.
Now I'll be the one laughing, and even more so if the RFC gets to also specify all the backward compatibility "features" of ASDF.
For a start, I propose you try to RFCize quick-build, with which asdf-package-system is compatible — here you've already got two independent implementations of the same thing (three, if you count faslpath, after changing the separator from "." to "/"), and the implementations are both around a hundred lines of code only. Only the root registration protocols differ. If you can't standardize that, don't even dream of standardizing the rest of ASDF.
Furthermore, I don't find people stumbling over each other to install ASDF prereleases from git and report bugs they find.
I'm not talking about mundane compatibility problems with pathnames, but design choices that will affect everybody that uses ASDF in production, for deployments and writes ASDF extensions. Most of the time there isn't even an announcement that a new feature was added, like a new keyarg to defsystem, etc...
Every release comes with release notes that mention changes to the API. I haven't announced changes with every commit, because that would be verbose, and people who're interested can already read the git log.
Design choices are being discussed here, but only the small details lead to bikeshedding discussions like the recent flurry of messages. When there's a serious design choice, either no one replies, or it's a discussion between Robert and I, usually, though I readily admit you (Stelian) have sometimes contributed key ideas.
And who is going to be testing these prereleases? We have quite a small community of testers, to whom I am very, very grateful.
I've done a lot of testing on my own stuff and reported quite a lot of bugs to Faré in the past.
Yes, and I am grateful to you (Stelian), who indeed in IRC (and live! and launchpad) discussions contributed a lot to ASDF.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The highest of minds / Often have built for themselves / The tallest of jails.
On Thu, 2014-03-13 at 13:42 -0400, Faré wrote: [...]
force and force-not were done well. The interaction between the two was not well thought out, but obviously no one relied on the interaction before force-not was implemented, so that was backward compatible, and the recent change keeps the previously useful uses working, so it is arguably, too.
It's not like my changes were done in secret.
They weren't done in secret, but many of them were just commits with no discussion on the list.
[...]
Every release comes with release notes that mention changes to the API. I haven't announced changes with every commit, because that would be verbose, and people who're interested can already read the git log.
Where are the release notes ? asdf-3.0.3.tar.gz(a tar bomb) contains no such thing, nor the git repository.
Where are the release notes ? asdf-3.0.3.tar.gz(a tar bomb) contains no such thing, nor the git repository.
The debian/changelog doubles as release notes. I just updated the README to point at them.
Release notes are otherwise posted to this mailing-list as part of each release's announcement.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Demand the establishment of the government in its rightful home at Disneyland.
It's not like my changes were done in secret.
They weren't done in secret, but many of them were just commits with no discussion on the list.
As long as the change hasn't been released, it's up for discussion. And it's much easier to discuss code that was committed than ideas in the air. When I've committed changes I thought might be controversial, I've always discussed them on the list, and indeed have backed out many of them before release (or sometimes, after release, because complaints only came afterwards).
I did my best to anticipate issues, but I often fail, and I can't read minds. Complaints that come a year later are a year late.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Fascists divide in two categories: the fascists and the anti-fascists — Ennio Flaiano
On Thu, 2014-03-13 at 14:52 -0400, Faré wrote:
It's not like my changes were done in secret.
They weren't done in secret, but many of them were just commits with no discussion on the list.
As long as the change hasn't been released, it's up for discussion.
Do you seriously expect people to review the commit stream for potentially harmful changes/addition ?
They weren't done in secret, but many of them were just commits with no discussion on the list.
As long as the change hasn't been released, it's up for discussion.
Do you seriously expect people to review the commit stream for potentially harmful changes/addition ?
Can you name a controversial ASDF feature that was not discussed on the list before release?
What exactly do you wish had been debated before that wasn't?
And yes, at some point, I expect people to start a discussion if something bugs them, instead of waiting for the maintainer to start the discussion.
NB1: I'm not counting unannounced bug fixes and refactorings of internals.
NB2: I'm not counting UIOP either, that I've indeed developed without much discussion, except for my attempting some namespace landgrabs and retreating at the backlash. But that I haven't seen anyone else try to discuss it much, apart from reporting a few bugs (for which I'm most grateful).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Nobody seems more obsessed by diet than our antimaterialist, otherworldly, New Age, spiritual types. But if the material world is merely illusion, an honest guru should be as content with Budweiser and bratwurst as with raw carrot juice, tofu, and seaweed slime. — Edward Abbey
Stelian Ionescu wrote:
The backwards-compatibility is not complete, though. When we're talking about glibc, we're talking about versioning functions and keeping the old entry points bug-to-bug compatible for ever while the new version of that function is simply an addition.
That's simply not going to happen. We don't have the level of resources needed to maintain this level of compatibility, nor is ASDF as critical as glibc.
It's not reasonable to expect that level of backwards compatibility for ASDF. Nor should we: Windows is a good example of where that particular Pied Piper can lead you. At some point it's better to throw away the old.
But look at what we have achieved (under Faré's leadership): compatibility with (at least) SBCL, ACL, Lispworks, CCL, ABCL, ECL, clisp, Genera (!), SCL, gcl (?), mkcl. We provide more backwards compatibility than most (all?) CL implementations!
Yours, R
Zach Beane wrote:
Dave Cooper david.cooper@genworks.com writes:
On Wed, Mar 12, 2014 at 2:05 PM, Zach Beane xach@xach.com wrote:
I don't think I want to read loud announcements from ASDF. If it isn't
acting like I want, I'd rather read about how to make it do what I want in a tutorial or manual.
Loud announcement only in the initial ASDF release when the new default directory is first introduced. In subsequent ASDF releases the announcement would go away.
I don't think it's a suitable way to communicate with me, even if it only happens for a certain period of time.
Zach
Agreed. This is why we will choose a default directory name that will not lead to such collisions.
Best,
r
Ok good. Then how about having ASDF loudly announce that it is registering the default directory (e.g. ~/cl/), as well as providing the hint about using a .conf file with the right syntax with :tree, if the user wants to exclude certain subdirectories.
The goal here is to make the addition of the default registry directory as painless and surprise-free as possible for anyone who already happens to have stuff floating around in the new default directory.
FTR, when i wrote my own version of :tree i also added a loud output that listed everything that got added to the registry, because previously i've wasted way too much time with loading the wrong systems, and with debugging build differences between dev environments and production deployments.
Zach Beane wrote:
Marco Antoniotti marcoxa@cs.nyu.edu writes:
On Mar 12, 2014, at 15:32 , Zach Beane xach@xach.com wrote:
Robert Goldman rpgoldman@sift.net writes:
Zach Beane wrote:
The complexity of the registry configuration is one reason why I added the ~/quicklisp/local-projects/ mechanism.
Right, so I don't see why there's such a huge objection to having a similar mechanism for ASDF. Stellian suggests using ~/quicklisp/local-projects/. So why is it wrong for ASDF to have a local-projects directory?
All I am suggesting is to have the local projects directory for ASDF be visible, instead of invisible.
I stand corrected about using a name that the user might have already had (thanks, Pascal!) but I don't yet see a solution that's as easy as a default directory location.
I think having a similar mechanism would be good. (And the loading-from-a-file thing could be nice too.)
I think the main problem is that giving it a nice name means that the chance is high of it clashing with a nice name one or more users is already using.
A while ago I was thinking it would be nice to have an API like this:
register-system-directory directory &key permanently
Registers DIRECTORY as a directory to search for system files. If PERMANENTLY is true, make the registration persist across sessions. But then I got hung up about how to make PERMANENTLY work -- I don't think there's any way to ask ASDF what directory is suitable for saving a config file.
And I am 100% in favor of a nice solution that does not involve Quicklisp. The simpler, the better.
That is what MK:DEFSYSTEM used to (actually still does) have.
mk:add-registry-location <pathname>
I don’t think you want the ‘permanently’. Your init file should be able to deal with that.
I'd like to use this interface *instead* of thinking about which config file to extend, and extend a cross-platform data file instead.
But I can't figure out how to do it, so it's a bit moot right now.
I think the fact that there are multiple, alternative ways to configure the source-registry, with different means of persistence (set the *CENTRAL-REGISTRY* variable, persistence left as an exercise to the programmer; use the DSL in code, ditto; use the DSL in config files, handled by config files), means that it will not be easy to automagically save a config change from lisp source. :-(
On Thu, Feb 27, 2014 at 11:30 PM, Robert P. Goldman rpgoldman@sift.info wrote:
How would you all feel about an alternate default location for lisp systems, in addition to
~/.local/share/common-lisp/source/
I hesitated about it, but ended not promoting something. I personally use ~/cl/ but I fear it's too short. Others use ~/lisp/ but I fear it's not common-lisp specific enough. There is no agreed upon answer. The most common location these days seems to be ~/quicklisp/local-projects/
I'm sure that .local was chosen out of the (in)finite wisdom of XDG, but it just seems odd to me to hide the lisp systems from the user, which we are doing by putting them in a location that requires ls -a.
XDG purposefully chose to put runtime files out of sight of mere users. Thing is, CL developers want the source code in sight, unlike mere users. In the past, I've had ~/.local/share/common-lisp/source/ be a symlink to ~/cl/ but that interfered with cl-launch's "magic" default installation parameters.
After all, these are systems, not configuration files.
One man's precious source code is another man's noisy ancillary files.
What about ~/asdf-systems which doesn't make the poor user play peekaboo?
What an ugly name, likely to confuse those who don't know, and to annoy those who do. Can we make it ~/common-lisp/ at least?
I came across this while editing the manual. I don't use this directory myself; maybe everyone loves it. Or maybe no one uses the standard default, and I shouldn't care.
Good luck.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Procrastination is great. It gives me a lot more time to do things that I'm never going to do.
On Fri, Feb 28, 2014 at 3:28 AM, Faré fahree@gmail.com wrote:
On Thu, Feb 27, 2014 at 11:30 PM, Robert P. Goldman rpgoldman@sift.info wrote:
How would you all feel about an alternate default location for lisp systems, in addition to
~/.local/share/common-lisp/source/
NB: I think a new additional location under ~/ for CL code would be great, and just *before* 3.1.1 is released would be the perfect time for it, since users can then rely on #-asdf3.1 for their backward compatibility recipes.
I personally used ~/cl/ but think ~/common-lisp/ would be great too, and while I think ~/lisp/ is a bit misleading I would accept it as well. I really dislike ~/asdf-systems/ since other tools (e.g. XCVB) may want to use the same path, too.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It's not ignorance that does so much damage; it's knowing so darned much that ain't so. — Josh Billings
Faré wrote:
On Thu, Feb 27, 2014 at 11:30 PM, Robert P. Goldman rpgoldman@sift.info wrote:
How would you all feel about an alternate default location for lisp systems, in addition to
~/.local/share/common-lisp/source/
NB: I think a new additional location under ~/ for CL code would be great, and just *before* 3.1.1 is released would be the perfect time for it, since users can then rely on #-asdf3.1 for their backward compatibility recipes.
I personally used ~/cl/ but think ~/common-lisp/ would be great too, and while I think ~/lisp/ is a bit misleading I would accept it as well. I really dislike ~/asdf-systems/ since other tools (e.g. XCVB) may want to use the same path, too.
I'm ok with either ~/common-lisp/ or *both* ~/common-lisp/ *and* ~/cl/, whatever is the sense of the community.
Let's make up our minds quickly, though, and make the change.
I agree that 3.1.1 is a good time, and I would like to get the change into the manual now, too.
Best, r
This has the potential of messing up already existing configurations (again!). The choice of ~/lisp would certainly mess up mine, and I can imagine many other scenarios. Please don't do that.
Thanks, Pascal
Sent from my iPad
On 12 Mar 2014, at 04:44, "Robert P. Goldman" rpgoldman@sift.info wrote:
Faré wrote:
On Thu, Feb 27, 2014 at 11:30 PM, Robert P. Goldman rpgoldman@sift.info wrote:
How would you all feel about an alternate default location for lisp systems, in addition to
~/.local/share/common-lisp/source/
NB: I think a new additional location under ~/ for CL code would be great, and just *before* 3.1.1 is released would be the perfect time for it, since users can then rely on #-asdf3.1 for their backward compatibility recipes.
I personally used ~/cl/ but think ~/common-lisp/ would be great too, and while I think ~/lisp/ is a bit misleading I would accept it as well. I really dislike ~/asdf-systems/ since other tools (e.g. XCVB) may want to use the same path, too.
I'm ok with either ~/common-lisp/ or *both* ~/common-lisp/ *and* ~/cl/, whatever is the sense of the community.
Let's make up our minds quickly, though, and make the change.
I agree that 3.1.1 is a good time, and I would like to get the change into the manual now, too.
Best, r
Pascal Costanza wrote:
This has the potential of messing up already existing configurations (again!). The choice of ~/lisp would certainly mess up mine, and I can imagine many other scenarios. Please don't do that.
[By "this" we mean "by default searching ~/common-lisp/ and/or ~/cl/ for source files when loading ASDF systems."]
Can you explain why this would mess up your existing configurations and what you would prefer?
The problem with the current default location is that it's in a directory that's hidden by default. So 'ls' and graphical file browsers would (in their default mode), hide the user's source code. [It is possible that hiding configuration files is a Good Thing; I can't imagine a world in which hiding my source code from me is a Good Thing.]
Since this is a *default*, this would not clash with any existing configurations in which the user has configured system search locations by hand.
Since this would be an *alternate* default, it should not clash with existing configurations that use the current default location, ~/.local/share/common-lisp/source
This is the reasoning behind my proposal. If there is something I'm missing or something I have wrong, I would certainly like to know now, before any changes are made and released to the world.
Thank you, Robert
On Wed, Mar 12, 2014 at 2:49 AM, Pascal Costanza pc@p-cos.net wrote:
This has the potential of messing up already existing configurations (again!). The choice of ~/lisp would certainly mess up mine, and I can imagine many other scenarios. Please don't do that.
I'm not sure what you mean by "messing up" your configuration.
How would it mess your configuration?
Do you have plenty of conflicting .asd's there that are going to shadow those you like and each other?
Or are you expecting many seconds of scanning through deep directory structures that may or may not contain .asd files?
Because adding them to the list is otherwise a NOP if the directories don't exist or don't contain .asd files.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org He who says he will die for a cause will probably lie for it and may kill for it. — John McCarthy
I'm expecting asdf to suddenly see asd files that it shouldn't. (In my configuration, only ~/lisp/develop/ contains "active" systems, the rest of ~/lisp may contain "inactive" ones - for example, alternate versions of the same systems.)
Pascal
Sent from my iPad
On 12 Mar 2014, at 08:04, Faré fahree@gmail.com wrote:
On Wed, Mar 12, 2014 at 2:49 AM, Pascal Costanza pc@p-cos.net wrote: This has the potential of messing up already existing configurations (again!). The choice of ~/lisp would certainly mess up mine, and I can imagine many other scenarios. Please don't do that.
I'm not sure what you mean by "messing up" your configuration.
How would it mess your configuration?
Do you have plenty of conflicting .asd's there that are going to shadow those you like and each other?
Or are you expecting many seconds of scanning through deep directory structures that may or may not contain .asd files?
Because adding them to the list is otherwise a NOP if the directories don't exist or don't contain .asd files.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org He who says he will die for a cause will probably lie for it and may kill for it. — John McCarthy
Pascal Costanza wrote:
I'm expecting asdf to suddenly see asd files that it shouldn't. (In my configuration, only ~/lisp/develop/ contains "active" systems, the rest of ~/lisp may contain "inactive" ones - for example, alternate versions of the same systems.)
Can you clarify?
Do you tell ASDF to load from particular subdirectories of ~/lisp/, but allow it to load from the default directory as well (instead of ignoring the inherited directories)?
I do not use the DSL, being entrenched in use of ASDF:*CENTRAL-REGISTRY*, so I am not familiar with many users' practice. I suppose if one uses the DSL, one is likely to not use :IGNORE-INHERITED-CONFIGURATION...
This suggests, regrettably, that using obvious directory names, such as ~/common-lisp/ might not be a good idea.
So we are searching for a directory name to use that will:
a. Be visible to standard directory listers, both graphical and textual b. Not introduce more confusion -- so no ~/quux/ c. Not already be in use by many, ideally any, users.
I suggest that this means we should use something that has "asdf" in its name. Such as
asdf-src cl-asdf-src cl-src-asdf
I am open for suggestions.
I just stumbled on this when editing the manual (I will try to push my edits today): I was sort of cringing at the idea of telling users they should "just" put their systems in
~/.local/share/common-lisp/source
which did not seem like something that anyone not wedded to XDG would even consider....
Suggestions welcome! Pascal, I appreciate your engaging in this discussion: your participation will lead to better decision making.
best, r
On Wed, Mar 12, 2014 at 3:16 AM, Pascal Costanza pc@p-cos.net wrote:
I'm expecting asdf to suddenly see asd files that it shouldn't. (In my configuration, only ~/lisp/develop/ contains "active" systems, the rest of ~/lisp may contain "inactive" ones - for example, alternate versions of the same systems.)
That's a fair complaint. And whichever name(s) we choose (if any), there is the potential for a similar complaint.
Of course, you can always :ignore-inherited-configuration, but then you might have to reproduce some of it that you like, and that's painful.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "I object to doing things that computers can do." — Olin Shivers
-
Antoniotti Marco -
Attila Lendvai -
Daniel Herring -
Dave Cooper -
Faré -
james anderson -
Marco Antoniotti -
Mark Evenson -
Pascal Costanza -
Robert Goldman -
Robert P. Goldman -
Robert P. Goldman
-
Stelian Ionescu -
Zach Beane