[asdf-devel] Last call before code freeze
I'd like to freeze the main branch of ASDF tomorrow for anything but bug fixes and documentation updates. Is there anything any of you want to commit before the freeze? Or as an exception to the freeze. I'm thinking in particular of the stuff in asdf-ecl. Juanjo, do you think it should be merged with ASDF itself? Especially in the light of it being semi-useful on other platforms where fasls can be concatenated? It might make things nicer if there is only one file needed for ASDF. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Be humble, for you are made of earth. Be noble, for you are made of stars. — Serbian proverb
On Thu, Apr 29, 2010 at 9:30 PM, Faré <fahree@gmail.com> wrote:
I'm thinking in particular of the stuff in asdf-ecl. Juanjo, do you think it should be merged with ASDF itself? Especially in the light of it being semi-useful on other platforms where fasls can be concatenated? It might make things nicer if there is only one file needed for ASDF.
Yes, but the point is that none of the things needed by those other platforms has been integrated and for these features to work properly we need fasl files themselves to be purer than they are -- otherwise concatenation does not suffice because the side effects of the system definitions would not propagate to those concatenated fasls. Furthermore, if the features I mentioned some time ago are introduced, such as merging the load-source- and load-op operations, then we could reimplement *all* of the ECL extensions in a much more different and much more robust way. So I would call for a not merging but also not further splitting at this particular release. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://tream.dreamhosters.com
On 4/29/10 Apr 29 -2:30 PM, Faré wrote:
I'd like to freeze the main branch of ASDF tomorrow for anything but bug fixes and documentation updates.
Is there anything any of you want to commit before the freeze? Or as an exception to the freeze.
I'm thinking in particular of the stuff in asdf-ecl. Juanjo, do you think it should be merged with ASDF itself? Especially in the light of it being semi-useful on other platforms where fasls can be concatenated? It might make things nicer if there is only one file needed for ASDF.
Do we have the system dependencies right yet? I was just looking at one of my systems that has a kind of system dependency that won't work in ASDF2 any better than ASDF Classic. Here's what we have: a large piece of software with many ASDF entry points. I.e., there are many .asd files which could be loaded at the top level. E.g., SYS-FOO, SYS-BAR, SYS-BAZ, ... We want all of these systems to have a common :VERSION. What this means is all of our .ASD files have this at their head: (asdf:oos 'asdf:load-op :SYS-VERSION) (defsystem SYS-FOO :version #.sys-version:+version+ ...) Unfortunately, our ASDF-LOAD of the SYS-VERSION system, which just defines a package and a constant, cannot be replaced by :system-dependencies ... This is effectively the same problem that James Anderson pointed out some time ago, but that I didn't yet appreciate. Do we ship with system-dependencies or try to come up with something better before shipping asdf 2.0? best, r
Robert Goldman wrote:
On 4/29/10 Apr 29 -2:30 PM, Faré wrote:
I'd like to freeze the main branch of ASDF tomorrow for anything but bug fixes and documentation updates.
Is there anything any of you want to commit before the freeze? Or as an exception to the freeze.
I'm thinking in particular of the stuff in asdf-ecl. Juanjo, do you think it should be merged with ASDF itself? Especially in the light of it being semi-useful on other platforms where fasls can be concatenated? It might make things nicer if there is only one file needed for ASDF.
Do we have the system dependencies right yet?
Probably not. However, I don't see that as a regression, nor has it prevented ASDF from gaining dominance. Thus it can probably wait until after the ASDF 2 release. No? I'd also make the same recommendation for asdf-ecl. We don't yet have experience generalizing fasl linking to other implementations; that sounds like a good project for ASDF 2.1. - Daniel
On 4/29/10 Apr 29 -3:00 PM, dherring@tentpost.com wrote:
Robert Goldman wrote:
On 4/29/10 Apr 29 -2:30 PM, Faré wrote:
I'd like to freeze the main branch of ASDF tomorrow for anything but bug fixes and documentation updates.
Is there anything any of you want to commit before the freeze? Or as an exception to the freeze.
I'm thinking in particular of the stuff in asdf-ecl. Juanjo, do you think it should be merged with ASDF itself? Especially in the light of it being semi-useful on other platforms where fasls can be concatenated? It might make things nicer if there is only one file needed for ASDF.
Do we have the system dependencies right yet?
Probably not. However, I don't see that as a regression, nor has it prevented ASDF from gaining dominance. Thus it can probably wait until after the ASDF 2 release. No?
You are half right. You are right that the absence of system-dependencies didn't hurt ASDF 1. But that's not the situation now. At this point system-dependencies are in ASDF 2. I'm arguing that if we don't have them right yet, we should rip them out. The regression vis a vis ASDF 1 is introducing a new feature that we know to be broken, not being missing a feature. James pointed out before that this was busted and I didn't realize it until I used it. So a tip of the "I told you so" hat to James. In other words, Daniel, we are agreeing about the principle of the thing, but are not on the same page about the status of the ASDF 2 code base. Best, r
: rpg : dherring : rpg
Do we have the system dependencies right yet?
Probably not. However, I don't see that as a regression, nor has it prevented ASDF from gaining dominance. Thus it can probably wait until after the ASDF 2 release. No?
You are half right.
You are right that the absence of system-dependencies didn't hurt ASDF 1.
But that's not the situation now. At this point system-dependencies are in ASDF 2. I'm arguing that if we don't have them right yet, we should rip them out.
The regression vis a vis ASDF 1 is introducing a new feature that we know to be broken, not being missing a feature.
James pointed out before that this was busted and I didn't realize it until I used it. So a tip of the "I told you so" hat to James.
In other words, Daniel, we are agreeing about the principle of the thing, but are not on the same page about the status of the ASDF 2 code base.
While I sympathize with the remarks by rpg, I still think this is not a blocker. 1- we mostly don't properly support versions anyway, and we claim that our system dependencies fix that particular issue. They fix a lot of other issues. Personally, I'd ditch the whole version thing, to be handled by some tool outside the base ASDF itself (say, dpkg). 2- in the future, we could support extracting versions from a file - supply a pathname or a sexp specifying what file to extract the version and how. 3- the system dependencies mechanism is already much better than what's in ASDF 1, and I think we should keep it. That said, I would yield to a strong opposition to it. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] The kind of man who demands that government enforce his ideas is always the kind whose ideas are idiotic. — H. L. Mencken
On 4/29/10 Apr 29 -3:59 PM, Faré wrote:
: rpg : dherring : rpg
Do we have the system dependencies right yet?
Probably not. However, I don't see that as a regression, nor has it prevented ASDF from gaining dominance. Thus it can probably wait until after the ASDF 2 release. No?
You are half right.
You are right that the absence of system-dependencies didn't hurt ASDF 1.
But that's not the situation now. At this point system-dependencies are in ASDF 2. I'm arguing that if we don't have them right yet, we should rip them out.
The regression vis a vis ASDF 1 is introducing a new feature that we know to be broken, not being missing a feature.
James pointed out before that this was busted and I didn't realize it until I used it. So a tip of the "I told you so" hat to James.
In other words, Daniel, we are agreeing about the principle of the thing, but are not on the same page about the status of the ASDF 2 code base.
While I sympathize with the remarks by rpg, I still think this is not a blocker.
It's not a blocker to not have good system-dependencies, as Daniel says. But given that, I think the blocker is that we should rip out the system-dependencies misfeature. It's not right yet, so we shouldn't ship it, and encourage people to use it. I.e., missing new features == not a blocker. busted new features == blocker. ASDF is already hobbled by too many things that are almost right and that we have to maintain backwards compatibility for. Please let us not install another one...
1- we mostly don't properly support versions anyway, and we claim that our system dependencies fix that particular issue. They fix a lot of other issues. Personally, I'd ditch the whole version thing, to be handled by some tool outside the base ASDF itself (say, dpkg).
NOOOOOOOOOOOOOOOO! Versions are CRITICAL. Even in the half-baked implementation we have, they are HUGELY valuable for developers. They could avert vast quantities of pain using ASDF-INSTALL, if people actually USED them. dpkg would be totally useless for people working from source code repositories. I promise you, if you took versions out, I would go back to logical pathnames and load-paths.
2- in the future, we could support extracting versions from a file - supply a pathname or a sexp specifying what file to extract the version and how.
3- the system dependencies mechanism is already much better than what's in ASDF 1, and I think we should keep it. That said, I would yield to a strong opposition to it.
I think James' objections are right -- it doesn't correctly interact with packaging, etc. Let's hold off until we get it right. Especially since it introduces a new double-processing of the defsystem form. If we decide later on that this is a mistake, it will be really hard to do away with it. best, r
Robert Goldman wrote:
It's not a blocker to not have good system-dependencies, as Daniel says. But given that, I think the blocker is that we should rip out the system-dependencies misfeature. It's not right yet, so we shouldn't ship it, and encourage people to use it.
Would it be possible to document this as an experimental feature? Say its busted, give an example why, and encourage people to suggest improvements? Insert a style-warning that triggers when people use it? Trying to avoid code changes right before a release, Daniel
: rpg : dherring
It's not a blocker to not have good system-dependencies, as Daniel says. But given that, I think the blocker is that we should rip out the system-dependencies misfeature. It's not right yet, so we shouldn't ship it, and encourage people to use it.
Would it be possible to document this as an experimental feature? Say its busted, give an example why, and encourage people to suggest improvements? Insert a style-warning that triggers when people use it?
Trying to avoid code changes right before a release,
Yes, I'm wary of having to change code, then change it back, especially considering how painful it is to get all the bugs out every time. Moreover, I'll argue that it's not the system-dependencies feature being deficient here, but the version feature being deficient. system-depends-on works fine, and does the job. Finally, this feature is already undocumented and therefore experimental. However, it works in the simple cases, and I don't see why not encourage its use, especially since ASDF now allows better control of which version of ASDF itself you use, and hence detection of version mismatches. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] "I wish there was a knob on the TV to turn up the intelligence. There's a knob called `brightness', but it doesn't work." — Gallagher
On 4/29/10 Apr 29 -6:18 PM, Faré wrote:
: rpg : dherring
It's not a blocker to not have good system-dependencies, as Daniel says. But given that, I think the blocker is that we should rip out the system-dependencies misfeature. It's not right yet, so we shouldn't ship it, and encourage people to use it.
Would it be possible to document this as an experimental feature? Say its busted, give an example why, and encourage people to suggest improvements? Insert a style-warning that triggers when people use it?
Trying to avoid code changes right before a release,
Yes, I'm wary of having to change code, then change it back, especially considering how painful it is to get all the bugs out every time.
Presumably this should be a single changeset to revert, yes? This is what our shiny new git repo is for, right?
Moreover, I'll argue that it's not the system-dependencies feature being deficient here, but the version feature being deficient. system-depends-on works fine, and does the job.
No, this really has nothing to do with the version feature. The deficiency is that we push the defsystem form through the lisp reader. That's why there are lots of cases that can't be helped by our new system-depends-on feature. The need to put (asdf:oos 'asdf:load-op <depended-on-system>) above the defsystem form (and not use system-depends-on) is forced on us because the defsystem goes through the lisp reader before we handle the system-depends-on argument. As James pointed out, this means that stuff with packages will not be helped by this. That suggests that the current approach, which is: read it all once process the system-depends-on process the other initargs won't get at the root of the system dependency problem. What we need instead is something like slurp it without reading process the system-depends-on /then/ expose it to the reader (if we so choose). I'd like to give this some thought before we lock ourselves into the first approach with as yet unconsidered problems of backward compatibility moving to the second. Best, r
On Thu, 29 Apr 2010, Robert Goldman wrote:
That suggests that the current approach, which is:
read it all once process the system-depends-on process the other initargs
won't get at the root of the system dependency problem. What we need instead is something like
slurp it without reading process the system-depends-on /then/ expose it to the reader (if we so choose).
I'd like to give this some thought before we lock ourselves into the first approach with as yet unconsidered problems of backward compatibility moving to the second.
That change looks complicated. I would not recommend delaying the release for it to be made. Unless you think a lot of projects will jump on this broken feature, I don't see an issue with backward compatibility in the future. Hence my belief that proper documentation and maybe a style-warning should be sufficient. Later, Daniel
Sorry. I seem to have been unclear. I was not arguing for holding up the release for the optimal solution to this problem. I was just arguing that we should withhold the partial solution (system-depends) so that people don't get wedded to it, in case it's not the Right Thing. We could withhold support for the new feature simply by not parsing those arguments, and leave in support so that we could experiment in v 2.1+. This will be my last word on the subject. I've laid out reasons why I believe it would be better to postpone judgment on this past 2.0 release. But this is Fare's call, not mine, and I respect his judgment Best, R On Apr 29, 2010, at 23:06, Daniel Herring <dherring@tentpost.com> wrote:
On Thu, 29 Apr 2010, Robert Goldman wrote:
That suggests that the current approach, which is:
read it all once process the system-depends-on process the other initargs
won't get at the root of the system dependency problem. What we need instead is something like
slurp it without reading process the system-depends-on /then/ expose it to the reader (if we so choose).
I'd like to give this some thought before we lock ourselves into the first approach with as yet unconsidered problems of backward compatibility moving to the second.
That change looks complicated. I would not recommend delaying the release for it to be made.
Unless you think a lot of projects will jump on this broken feature, I don't see an issue with backward compatibility in the future. Hence my belief that proper documentation and maybe a style-warning should be sufficient.
Later, Daniel
_______________________________________________ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Robert, I believe that the system-depends-on support, unsatisfactory as it is, is already useful in some cases, and probably forward-compatible with a future satisfactory solution, which is why I favor leaving it as is for 2.0. However, I will not object if you remove that support or add a trivial cerror when it is used (assuming you test the result before you commit). I don't think it's worth doing myself. If you think it's worth doing - prove it. That's my last word on the subject until 2.0 is released. So, apart from that, no objection to a freeze? So be it. Code freeze starting May 1st. Only bug fixes and documentation updates from then on. After two weeks of no change at all, I will declare 2.0 released. Hopefully on time for SBCL 1.0.39. (Note that before the freeze, I have made changes that allow to remove code from POIU.) [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Racists often attribute to genetics what is due to memetics. Anti-racists often do the opposite. Both groups involve legal violence where none is due.
participants (6)
-
Daniel Herring -
dherring＠tentpost.com
-
Faré -
Juan Jose Garcia-Ripoll -
Robert Goldman -
Robert P. Goldman