On 4/5/10 Apr 5 -11:58 AM, Faré wrote:
OK, so should the default be no translation, except for software that is system installed?
I still think that the cache being on by default is ultimately simpler, least surprising, and more useful.
I'd go with "ultimately simpler" and "more useful," but not "least surprising," at least not for an ASDF Classic user!
I would feel more confident shipping with the translation on by default if it didn't seem like it was complicated to turn it off. If I understand you correctly, one cannot simply turn it off, one must somehow grok how it handles system installed s/w to understand how to disable it correctly. If I'm wrong, please correct me.
Based on that (possibly erroneous) premise, it sounds like turning it on from off is an easier operation than turning it off from on, which reinforces my desire to see it off by default.
However, if there's a very simple single function, with no arguments (no need to understand, or even copy anything out of the DSL for A-O-T) that gives asdf classsic behavior, that would dissolve a lot of my objections.
I see four families of users I'd like to see supported with minimal-effort configurations:
1. ASDF classic users who want ASDF classic + bugfixes (at least initially);
2. ASDF-BINARY-LOCATIONS users ditto, with no centralized binaries
3. As 2, but with centralized binaries.
4. People who want the latest and greatest, with sensible default output relocations.
I would prefer that all of these be able to configure minimally, and in CL only, so that people who are currently using their CL init files as configurations will be on solid ground. Note that I'm not saying that the new configuration arrangement is bad, just that people should be able to work their way up to it with baby steps.
Is this reasonably achievable without crippling people who want all the good new stuff?
Mario's analogy with make is OK to a point, but ASDF differs very much from make, too. And with multiple implementations, making a "don't map" default can really get in the way. Especially as I'd like to promote some portability and "test with multiple architectures/implementations" style. I do catch more bugs thanks to SBCL, CLISP, ECL, etc.
Can anyone setup a google questionnaire or some other survey?
I'm reluctant to do this, because it seems to me that the people least likely to answer are the ones most relevant to the survey.
Best, r
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] I walked a mile with Pleasure, / She chattered all the way; But left me none the wiser, / For all she had to say. // I walked a mile with Sorrow / And ne'er a word said she; But, oh, the things I learned from her / When Sorrow walked with me! — Robert Browning Hamilton
On 5 April 2010 16:05, Robert Goldman rpgoldman@sift.info wrote:
On 4/5/10 Apr 5 -9:53 AM, Tobias C. Rittweiler wrote:
Robert Goldman rpgoldman@sift.info writes:
On 4/4/10 Apr 4 -9:50 PM, Faré wrote:
I would in order prefer the following:
- disable output-translations by default.
I think we can't do that, because of things like system-installed source code and users who use both clisp and ecl (that share the .fas suffix) or i386 and x86-64 SBCL (that share the .fasl suffix), etc.
If a novice wants to know where the fasls are, I prefer to give the explanation once than to give plenty of explanations with as many special rules.
Ah. I see. Then is there a "disable output translations for MY files, and do the right thing with system installed code"?
I agree with you about people who use clisp and ecl, multiple SBCLs, ACL
- SBCL, but I'm not convinced that those people are common enough that
we should arrange the world around them. I am, after all, one of these people and I am a user of ASDF-BINARY-LOCATIONS.
However, there are a lot of people out there who use only a single CL. Indeed, I work with them, both in my company and out.
Even if they work only with one implementation, why do you think they want their source directories be cluttered with fasls which just plays bad with RCS, grep, tar, and other tools?
With all due respect, I don't care why they want this. I just know that they do. They want ASDF to just build systems for them and get out of their way and not complicate their lives. They want the configuration of ASDF to be handed to them on a platter.
I have weaned many of these people from just using big files full of
(compile-file-if-needed ...) (load ...)
They do not want to learn ASDF any more than I want to learn autoconf just to build a piece of software, and I respect that. I don't fix my car, I just drive it.
cc by default drops .o files right in front of you. People seem to live with that just fine.
I used a symbolics for many years happily without fussing with the location of the binaries.
I think it's great that we have output-translations, and I have gradually spread their use, but I want to make the first spoonful of ASDF go down easily. This, IMO, means that if someone tells you to use ASDF, and gives you an ASDF system definition, you can load it and run. You don't have to learn the whole thing, you just do it, and it acts pretty much like a smarter replacement for COMPILE-FILE, just like make is a smarter replacement (from a user standpoint) for cc.
I also want the first spoonful of ASDF2 go down easily. This, IMO, means that it should behave as much like ASDF 1 as possible, modulo bug fixes, when it's turned on. Fiddling with the buttons and dials should give you all kinds of new goodness, but the /obligation/ to fiddle with buttons and dials should be avoided.
There are far too many FMs out there, and we cannot expect users to R them! If they want a new feature (if they want to install a shiny SBCL next to their copy of an old one, and need to keep the fasls from being confused, or if they like to have all their fasls together somewhere), great, they will read the manual. If they just want to load a system, they shouldn't have to and, in any case, we should not expect them to.