On 10/16/11 Oct 16 -8:53 PM, Gábor Balázs wrote: > hY Fare and Robert, > > I have my function, which does the described job for me too. The point > here is to offer this functionality in public on an easy, standard way. > Personally, I like to have a single defsystem sexp in the asd file, so I > would prefer avoiding function definitions there. I haven't met any > situation before when something serious had to be done around a > compilation, but you are probably right and wrapping arbitrary functions > is a useful functionality. However to do that nicely, asdf should be > refactored in a way described by Robert. But I think it would be still > nice to offer this (cheap) renaming functionality separately without > some heavy syntax (wrapping the whole defsystem into a function seems to > be heavy for me). > > So my function walks along the whole asdf component tree and set the > :before and :after for each (non-module) component. I had to do this way > just because the fact you described (I guess). But I was thinking > instead of putting this functionality around the compile-file call > itself inside asdf. So to apply this immediately to the whole component > tree (to each compilation unit). I think it is not a restriction with > renaming. At least I cannot imagine a reasonable scenario when one wants > to use different nicknames of the same package for different asdf modules.
I think the problem with doing this :before and :after of each component and operation is that it doesn't have sensible :around semantics. E.g., you can't easily use it to do something obvious like wrap a dynamic variable binding around the entire compilation of the system and then update that dynamic variable binding to communicate across individual compilations. I also worry about this nicknaming idea because it seems to rely on assumptions about the package-to-system mapping that aren't articulated clearly yet. Can you explain the use case more clearly so we understand why this is generally useful? > > So as I see this renaming functionality has the following properties: > > * it is fairly easy to implement into the current mainstream asdf version > * it is easy to use, so CL library developers could easily eliminate > the :nicknames options from the package definitions and use this > instead (they should basically change only a few lines of code in > the .asd and package.lisp files) > * unfortunately, it is not the most general solution, so the arbitrary > function wrapping would not be provided this way > > I feel the 2nd point very valuable, so I think it would worth doing... > > `bg` > > > On Sun, Oct 16, 2011 at 4:11 PM, Robert Goldman <[email protected] > <mailto:[email protected]>> wrote: > > On 10/16/11 Oct 16 -4:52 PM, Faré wrote: > > 2011/10/16 Gábor Balázs <[email protected] <mailto:[email protected]>>: > >> But there would be a nicer way, and this is the proposal. What > about a new > >> asdf option (eg :compile-with-nicknames), which could look like > something > >> this? > >> > >> (defsystem my-system > >> :depends-on ("package-1" "package-2" "package-3" ...) > >> :compile-with-nicknames (("package-1" "pckg-1") > >> ("package-3" "pckg-3")) > >> :components (...)) > >> > >> I think this approach nicely works in a "clear" environment for > non-parallel > >> compilation when there are no insane nickname requests. > >> The "clear" environment assumption can be relaxed to say that the > user > >> hasn't defined any nicknames which causes collisions for any > necessary > >> compilations. > >> > >> Or if you know a better way to handle this problem, I would be > happy to hear > >> about that... > > I think there is a better way to solve this problem, but it is an > ASDF3 method. > The basic idea is as follows: > > 1. ASDF currently works by developing a LINEAR plan for performing an > operation. Here's an example: > > CL-USER> (asdf:operate 'asdf:load-op :murphy-ltk-demo) > #<ASDF:LOAD-OP NIL @ #x1000d42f82> > ((#<ASDF:LOAD-OP NIL @ #x1000d57312> > . #<ASDF:CL-SOURCE-FILE "ltk" "ltk">) > (#<ASDF:LOAD-OP NIL @ #x1000d57312> . #<ASDF:SYSTEM "ltk">) > (#<ASDF:LOAD-OP NIL @ #x1000d62f32> > . #<ASDF:CL-SOURCE-FILE "murphy-ltk-demo" "package">) > (#<ASDF:COMPILE-OP NIL @ #x1000d62f52> > . #<ASDF:CL-SOURCE-FILE "murphy-ltk-demo" "ltk-demo">) > (#<ASDF:COMPILE-OP NIL @ #x1000d62f52> > . #<ASDF:SYSTEM "murphy-ltk-demo">) > (#<ASDF:LOAD-OP NIL @ #x1000d42f82> > . #<ASDF:CL-SOURCE-FILE "murphy-ltk-demo" "ltk-demo">) > (#<ASDF:LOAD-OP NIL @ #x1000d42f82> > . #<ASDF:SYSTEM "murphy-ltk-demo">)) > > Inspecting this plan reveals the problem: the operation COMPILE-OP on > #<ASDF:SYSTEM "murphy-ltk-demo"> is not done AROUND the compilation > operations > on the component files, but AFTER them. > > 2. A possible solution would be to restructure the plans so that > they are > TREE-SHAPED, instead of linear. So that there would be an operation > that > CONTAINS the compile-ops of the individual systems. > > Then, instead of the "plan interpreter" component of ASDF just being > a MAP, it > would be a tree-mapper. > > I think that this is in some sense The Right Thing. The only > problem is that > the LOAD-OP is not "convex" in some sense. Instead, there is > loading of files > done *during* the compilation. So if we were to do this, wrapping > something > around the LOAD-OP might have counterintuitive results. > > Note also that I believe that we would have to keep the original, > odd semantics > of the operations on systems, and add a new operation, for backwards > compatibility. So we might have COMPILE-COMPONENT-OP or something. > > Cheers, > r > > >> > > Dear Gábor, > > > > you describe a common problem and a shared frustration of many CL > developers. > > However, the problem is not limited to package nicknames, and instead > > I would prefer something more general: > > the ability to wrap something around compilation, > > essentially an advice around compile-file*. > > I recently added this feature to xcvb, so that it may compile > ironclad, > > that uses such a wrapper (an :around method on perform) > > to bind the *readtable* and muffle some warnings around compilation. > > > > And so, I propose something more like: > > > > (defun call-with-my-nicknames (thunk) > > (with-package-nicknames > > (("package-1" "pckg-1") > > ("package-3" "pckg-3")) > > (funcall thunk))) > > > > (defsystem my-system > > :depends-on ("system-1" "system-2" "system-3" ...) > > :around-compile call-with-my-nicknames > > :components (...)) > > > > What do you think? > > > > Of course, you'd have to use ASDF 2.018 or later for that. > > Or maybe it's time to call it ASDF 2.18 instead? > > > > —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• > http://fare.tunes.org > > > > _______________________________________________ > > asdf-devel mailing list > > [email protected] <mailto:[email protected]> > > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel > > > _______________________________________________ > asdf-devel mailing list > [email protected] <mailto:[email protected]> > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel > > _______________________________________________ asdf-devel mailing list [email protected] http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
