Preliminary analysis of existing ASDF practices
in [Lisp]
|
Prev: Is LISP divine?
Next: keywords & macros
From: Mario S. Mommer on 14 Apr 2010 03:39 Juanjo <juanjose.garciaripoll(a)googlemail.com> writes: > On Apr 14, 6:14 am, Tim X <t...(a)nospam.dev.null> wrote: >> 2. I would love a system similar to CPAN. I'd love to be able to just >> issue the command CLAN install <some-lib> and hav it identify any >> dependencies not available locally, download all necessary sources, >> build them, run tests and if all goes well install everything. My experience with CPAN has always been negative. It just did not work that way, and in fact for me it did not work. > This can be done if *.asd files at some point become really pure > descriptions of the software. Maybe a good starting point would be to find out if such a thing is possible. I mean, it certainly sounds like a good idea, but given the many decissions that are conditional on context (load-load-load-dump vs. alternatives, for example) I am not too optimisitc. Make & co certainly do not do it that way, I think.
From: Tim X on 14 Apr 2010 04:30 Juanjo <juanjose.garciaripoll(a)googlemail.com> writes: > On Apr 14, 6:14 am, Tim X <t...(a)nospam.dev.null> wrote: >> Juanjo <juanjose.garciarip...(a)googlemail.com> writes: >> >> > What I would like to learn is what people think they have learnt that >> > ASDF does wrong, things it gets right and to what extent the Common >> > Lisp community is willing to accept any progress along one or another >> > direction. >> >> I think this is the ideal starting point. It may also be worthwhile >> asking what people like and dislike about other approaches, though ther >> is a danger of information overload. [...] >> The main issue I can see with this approach is it does run the >> danger of decision by committee and could either result in an overly >> complex over designed mess that never gets realised or something that is >> so heavy-weight nobody wants to use it or is too limited and nobody >> finds it any more useful than what they already have. > > It depends on how one sets up the path. If the goal is > 1) Simplify ASDF till you can see the bare bones > 2) Build tools on top of it > you can get something that is not too complex by design. Yes, I can see merit in that approach and it probably would avoid some of the issues I was concerned about. Of course, the risk is that the bones have cancer and therefore are a bad base to try and build something better on. I guess we won't really know until we have actualy stripped away everything and can examine them closely. Perhaps that would be the point at which a decision is made whether to continue in that direction or some other one. > >> Juanjo, from the little I can tell from your posts, your initial efforts >> in this area and your track record with respect to work and >> contributions, you may well be the one who could do this (either that or >> you are an insane madman!). My only comments are >> >> 1. Your analysis of ASDF is a good starting point. However, I think you >> need to be careful regarding some of your phrasing as it can come across >> as an emotional rather than a valid technical criticism. > > Having experienced this myself in the last weeks. I am not a > diplomatic person, just a nerd who does Physics and programming, and I > can be rather emotional myself, specially when entering debates which > just lead to opinions and not to facts. I do not think I would qualify > for the person with leadership that you mentioned before and it was > not my intention to put myself forward as such, but rather stimulate a > more rational and more open discussion. > My intention is to encourage you, but in a realistic light. We are unlikely to find anyone with all the attributes I feel are important and of course, this is just my opinion anyway. Unfortunately, too often the person who is best able to do a task like this is frequently someone who is very reluctant to take it on. Conversely the person who really wants this sort of role is too often the wrong one for the task! Of course, you do have a few of the most important ingredients - enough interest and drive to put in an initial analysis, write it up and put it out there for comment and it is something that represents a 'personal itch' due to its impact on ECL. Maybe, with some support form others, you could kick things off and hope at some point someone will be prepared to pick it up and run with it. I would certainly be willing to try and assist where I can, but I don't feel I have enough technical experience with CL yet to really cotribute much at this early stage. >> 2. I would recommend being very careful about using examples. > > Yes, I found this myself. If I start talking about ECL and how we > build software people just disregard the rest of the discussion. If I > start talking about delivering *.deb or *.rpm, just the like. If I say > anything about the load & dump development model, people quickly > disconnect and forget the rest of the debate. > Yes, its extremely difficult. For some reason, it also seems to be a bigger problem within this community. I'm not sure why, but I am frequently amazed by the number of threads that start off dealing with something interesting and then rapidly degrade into opinions about matters that were only of partial or passing relevance to the initial topic and which usually cannot be resolved one way or the other. > It is very tough and discouraging, and one of the reasons I am > pursuing this is just because ECL's progress is impeded by the current > status -- hey, I can not even properly automate testing of existing > libraries because of it! > Thats the itch you just have to scratch :-) >> 1. Ability to easily define dependencies in systems I am developing. In >> general, ASDF does this pretty well provided I don't include other libs >> with unusual asdf forms or complex dependency graphs. > > It would be nice to have even artificially cooked examples, for any > effort that aims at fixing / replacing ASDF will encounter them. > Actually, thats a pretty good idea. A collection of difficult/unusual asd files and custom loaders etc would provide some very valuable data. It could help identify those difficult edge cases and could make up the basis for a good set of tests etc. I will keep an eye out for any 'unusual' asd files I coame across. I would be careful about artificially constructed ones. We have some very clever and deep thinkers in this community who could undoubtably come up with some hair curling 'theoretical' asdf examples. However, a complex mind melting asdf example is of little practicle use if it never actually arises in reality or if it only occurs extremely rarely. Such examples are likely to only cause distraction and discouragement. >> 2. I would love a system similar to CPAN. I'd love to be able to just >> issue the command CLAN install <some-lib> and hav it identify any >> dependencies not available locally, download all necessary sources, >> build them, run tests and if all goes well install everything. > > This can be done if *.asd files at some point become really pure > descriptions of the software. I agree. If 'lesser' languages are able to do it, then CL should be able to show them how it could have been done better! Tim -- tcross (at) rapttech dot com dot au
From: Tim X on 14 Apr 2010 05:06 m_mommer(a)yahoo.com (Mario S. Mommer) writes: > Juanjo <juanjose.garciaripoll(a)googlemail.com> writes: >> On Apr 14, 6:14 am, Tim X <t...(a)nospam.dev.null> wrote: >>> 2. I would love a system similar to CPAN. I'd love to be able to just >>> issue the command CLAN install <some-lib> and hav it identify any >>> dependencies not available locally, download all necessary sources, >>> build them, run tests and if all goes well install everything. > > My experience with CPAN has always been negative. It just did not work > that way, and in fact for me it did not work. > That is interesting. In the 10+ years that I have used it, I've only had a couple of times where it has let me down and without exception, that was due to bad decisions on my part. This is not to say I think its perfect. There are a few issues I've learnt to watch out for, but in an overwhelming majority of times, it has worked without a hitch. I frequently find a search to identify possible modules, together with a bit of background searching to see if anyohe has had issues with those modules and then a simple cpan -i <module name> and a few minutes later I'm coding with that module. Contrast this with the current CL situation, where it has taken me much much longer to even find a possible CL candidate, a lot more time getting it and getting it installed and then finding it doesn't do what I wanted in the first place or depends on other libs I cannot find or just won't load/compile etc. The result has been that if I'm doing something in CL, it will frequently be faster for me to implement something which I know has already been done millions of times by others. Unfortunately, while this is possibly good for improving my CL skills, it means that I often have to use another language if time is critical. Frequently, this will be something like Perl as I will probably be able to find a module that will do a large part of the work for me and allow me to get the job done within the deadline. The fact you have had problems with CPAN means you are likely to have some really valuable input into issues to watch out for, features that would be useful and things that may be best avoided. >> This can be done if *.asd files at some point become really pure >> descriptions of the software. > > Maybe a good starting point would be to find out if such a thing is > possible. I mean, it certainly sounds like a good idea, but given the > many decissions that are conditional on context (load-load-load-dump > vs. alternatives, for example) I am not too optimisitc. Make & co > certainly do not do it that way, I think. Well, its pretty difficult to determine if something is possible without trying to do it. Some concrete suggestons on how this could be done would be useful. I suspect that any solution will have some limitations and there will be some situations where it just won't work. However, provided these are small edge cases, I'm not sure that matters too much. If we have somehting that will work for over 80% of cases, then we are going to be a lot better off than we are now. The other 20% (maybe even less, with luck!), are not going to be any worse off, they just won't benefit as much. More likely, as our understanding improves, we will chip away at that last 80% and reduce it over time (though a system that would work with 100% of the possible cases is unlikely). What we need is concrete examples, not theoretical or vague 'gut feelings' regarding where problems may or may not exist. I think the object should be to improve the current situation, not aim for the ultimate perfect outcome. Even if we completely fail, we are likely to add additional knowledge that will be extremely useful for the next attempt! Tim -- tcross (at) rapttech dot com dot au
From: His kennyness on 14 Apr 2010 05:26 Juanjo wrote: > On Apr 13, 10:47 pm, His kennyness <kentil...(a)gmail.com> wrote: >> The beauty is Dr McCarthy's main contrib: code as data. Fix ASDF any way >> needed and then write one simple parser that can work off existing .asd >> files (with more or less hinting, perhaps). > > Point is not even that can be done 100% safely for all ASDF files out > there and for others that people write. > It is an illusion to try to > bring a new system out of the blue without some cooperation from > developers I think you are doing the right thing by first measuring community sentiment. If I am the only one who loathes ASDF, we're stuck with it. kt > > As an example, if you have a look at the code people have added to > their ASDF files (*) you will find #. reader evaluated forms and a lot > of other toplevel forms that only work when some dependencies have > been loaded prior to that or when the value of the current directory > is the appropriate one (sic). In the end there is going to be so much > ad-hoc in the rules to process all that information that it ends up > being quite a lot of manual work. > > Juanjo > > (*) See the failures in the html file to see the errors that happen > when one tries to parse *.asd files with simple READ.
From: Thomas M. Hermann on 14 Apr 2010 10:25
On Apr 13, 10:38 am, Juanjo <juanjose.garciarip...(a)googlemail.com> wrote: > ... and some ideas about the future. Some of them affect how existing > systems can be integrated with a particular implementation, ECL, but I > hope you will be able to see beyond that. > > http://tream.dreamhosters.com/tream/musings/49-lisp/76-analysis-of-ex... > > Comments better here at comp.lang.lisp I use ASDF, but my use is very rudimentary, so I generally don't run into the issues other people are encountering. Based on the number of criticisms I've seen, though, apparently I'm just not sophisticated enough to appreciate the failings of ASDF. I think it would be useful to get copies of existing systems, contrive examples, including pathological ones, apply each system to the example and analyze. The systems that I am aware of are: - mk-defsystem - ASDF - XCVB - mudballs The mudballs project has been discontinued and the website is down, but there is a point of contact for the author in the final Google groups message. To put the issue in context, look at the myriad of build systems for other languages. Personally, I like good ol' Makefiles, but, then again, maybe I'm just unsophisticated. So, is the goal a lisp only build system, or will it support defining rules and dependencies for building other things? I think a solid core that is lisp focused with 'contribs' for other things would be ideal. ~ Tom |