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